[cabfpub] Draft Ballot 186 - Limiting the Reuse of Validation Information
Dimitris Zacharopoulos
jimmy at it.auth.gr
Fri Feb 3 00:52:06 MST 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 3.2.2.4? In the "any
other method" (currently 3.2.2.4.11), 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.
Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170203/47ebcabc/attachment.html>
More information about the Public
mailing list