<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 3/2/2017 7:21 πμ, Peter Bowen via
Public wrote:<br>
</div>
<blockquote cite="mid:2A3198ED-4127-4755-A183-6584D6807D1C@amzn.com"
type="cite">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div style="font-size:12.8px" class=""> 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.</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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, <a
moz-do-not-send="true" href="http://peterbowen.org" class="">peterbowen.org</a>
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.</div>
<div><br class="">
</div>
<div>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.</div>
</blockquote>
<br>
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).<br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
<br>
Dimitris.<br>
</body>
</html>