[cabfpub] Draft Ballot 186 - Limiting the Reuse of Validation Information

Peter Bowen pzb at amzn.com
Thu Feb 2 22:21:14 MST 2017


I’m still working through all the parts and implications this proposal, but a few thoughts are below.

> On Jan 31, 2017, at 9:00 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> Background:
> This Ballot is complementary to, but distinct from, Ballot 185, but itself represents a significant impediment towards improving online security. The Baseline Requirements only require that a CA validate a domain name once every 39 months, and that presently (notwithstanding Ballot 185), such certificates may have a validity period of up to 39 months. This effectively means that a CA may validate a domain once, and issue any number of certificates for an effective validity period of 74 months, minus a day.

I’m assuming this should be 78 months (39 + 39).

> To prevent further misissuance for domains in the event of transfer of control, whether through sale or the registration lapsing, as well as to ensure that newly issued certificates reflect industry best practice for domain validation, rather than reusing information from insecure or forbidden validation methods, this Ballot significantly reforms the reuse of validated information.
> 
> -- MOTION BEGINS --
> […]
> Section 6.3.2 limits the Validity Period of Subscriber Certificates.
> 
> For certificates issued prior to 1 May 2017, the CA MAY use the documents and data provided in Section 3.2 to verify certificate information, provided that the CA obtained the data or document from a source specified under Section 3.2 no more than thirty‐nine (39) months prior to issuing the Certificate. 
> 
> For certificates issued on or after 1 May 2017, the CA MAY use the documents and data provided in Section 3.2 to verify certificate information if the documents or data meet all of the following criteria:

>   1. The CA obtained the data or document from a source specified under Section 3.2 no more than thirteen (13) months prior to issuing the Certificate.

This seems to miss all nuance.   For data used in validation, the focus should be how long it is reasonably valid.  The fact that I’m Peter Bowen is going to be true for a very long time (well more than 13 months).  On the other hand, peterbowen.org currently has an expiration date of 2017-11-01.  What we really should be doing is focusing the expiration of the validated information, not the duration, and ensuring that certificates don’t overrun their expiration of the information being certified.

As a concrete proposal, how about allowing data on legal entities and individuals to have an expiration date 39 months after verification and domain verification to expire on the registration expiration date?  Combine this with a requirement that the notAfter date an a certificate must be on or before the earliest expiration date of information used to validate the request.

>   2. The method used to obtain the document or data was acceptable under Section 3.2 at the time the document or data was obtained.

This seems unnecessary given that basically anything was acceptable under 3.2, as it has included "any other" since the beginning of existence.  

>   3. The method used to obtain the document or data is acceptable under Section 3.2 at the time the documents or data is used to verify certificate information.

Makes sense; if methods are fixed, CAs need to ensure that what was done is still good.

>   4. The CA has not revoked any certificates which contain certificate information verified using the document or data.

This has is being discussed in another part of the thread.

Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170202/ae6a1291/attachment.html>


More information about the Public mailing list