[cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

[Ryan Sleevi]

This isn't something inherently required by the BRs, nor has it ever been.

I think folks can look at how some CAs, notably Amazon, have leveraged
compliance with the BRs and an understanding of the DNS technology to
minimize the friction for their Subscribers and customers. In this model,
the per-issuance unique code being referred to is not needed, and the
extant configuration a domain operator needs to do is roughly equivalent to
the CAA check.

Amazon's documentation here -
https://aws.amazon.com/blogs/security/easier-certificate-validation-using-dns-with-aws-certificate-manager/
-
shows how truly easy it is for CAs to put their customers first, and pursue
innovative solutions that help improve overall security. For more technical
details,
https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-validate-dns.html is
helpful.

Again, this is fully compliant with the BRs, and always has been.
Importantly, it measurably moves the needle towards security, in that it
allows fresh DNS checks, to ensure the registrant is still configured and
authorizing the CA to issue certificates on their behalf, while allowing
what CAs desire most, which is a binding between a set of authorized domain
names and a given account identifier.

I wasn't sure, were you familiar with that approach when you replied? It
seems functionally similar to the additional valid methods recently
introduced, and has definitely been something discussed in the context of
the Validation WG with respect to 3.2.2.4.6, which functionally can do the
same.

On Thu, Aug 1, 2019 at 2:23 PM Tim Shirley <TShirley at securetrust.com> wrote:

> One important distinction between CAA and domain validations though is
> that CAA assumes permission to issue unless otherwise specified, whereas
> domain validation requires a per-issuance unique code to be placed in DNS
> per issuance (assuming a DNS-based DV method is used.)  So there is no
> additional burden placed on the site operator by not allowing reuse of CAA
> checks.
>
>
>
>
>
> *From: *Validation <validation-bounces at cabforum.org> on behalf of "
> validation at cabforum.org" <validation at cabforum.org>
> *Reply-To: *"sleevi at google.com" <sleevi at google.com>, "
> validation at cabforum.org" <validation at cabforum.org>
> *Date: *Thursday, August 1, 2019 at 12:34 PM
> *To: *"doug.beattie at globalsign.com" <doug.beattie at globalsign.com>, "
> validation at cabforum.org" <validation at cabforum.org>
> *Subject: *Re: [cabf_validation] Draft Ballot SCXX: Improve Certificate
> Lifetimes
>
>
>
>
>
> This ballot proposes changes to several components and not just the
> maximum validity period.  I’d like to understand the reasons for each,
> perhaps in the above proposed blog.
>
>    - Maximum validity period: Yes, this is the driving reason for the
>    ballot, I understand that.
>    - Maximum re-use of domain validation data: Is limiting this to 13
>    months necessary?  If this is the primary reason for the ballot, then is
>    the reduction in certificate validity necessary?  How do these 2 changes
>    relate to each other?  Do these have to match, and if so, why?
>
> I actually think we need to get this particular bit down as aggressively
> as possible. From a security point of view, the ideal end state is zero
> reuse of domain validation data. We already have that for CAA, and it has
> not caused significant harm.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190805/27eedc93/attachment.html>