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

Dimitris Zacharopoulos jimmy at it.auth.gr
Fri Feb 3 07:52:06 UTC 2017

On 3/2/2017 7:21 πμ, Peter Bowen via Public wrote:
>>   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 <http://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.

I agree with Peter and I would like to add that domain validation is 
even more interesting. Some methods prove ownership/control of an entire 
domain space (some require paperwork with registrars) and some prove 
ownership/control of an FQDN (usually simpler and easy to automate).

Would it make sense to agree on an expiration date for re-using 
validation information *for each method* under In the "any 
other method" (currently, we could pick the shortest duration.

In addition to re-using domain validation information, perhaps CAs could 
request re-validation of domain ownership/control every 12-13 months 
(even more frequently for some cases) and if the information is not 
provided, revoke the certificate. Since domains change owners frequently 
and there is a security risk, this would be a possible solution that 
keeps a balance in security of the domain owners and administrative 
overhead for Subscribers/CAs. A Subscriber would probably choose to 
prove domain ownership information every couple of months over replacing 
certificates every year.

I understand that this does not address all of Ryan's concerns but we 
need to highlight that Subscribers with a large volume of certificates 
will have a huge administrative overhead if they need to change these 
certificates annually. Most systems require manual operations to change 
a certificate. For exactly this reason, client or eID certificates have 
a lifetime of three years because going through the issuing process 
every year for citizens was unreasonable, because the crypto used in the 
certificates is reasonably safe for at least three years. Of course, if 
an algorithm breaks or is suspected to break, this changes things and 
measures are taken to move away from possibly compromised algorithms. 
There were lessons learned from the MD5 and SHA1 deprecation process and 
hopefully the same mistakes will not be repeated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170203/47ebcabc/attachment-0003.html>

More information about the Public mailing list