<div dir="ltr">While that proposes an alternative, it doesn't provide any explanation about the security benefits or value to relying parties/ecosystem, so I don't think it's worth discussing unless you wanted to expand on that.<div><br></div><div>I think aligning on 13 months, across the board, as an initial step, seems to be a far more reasonable step. We could then discuss specific cases where it might be desirable to be more frequent - in particular, domain validation (and the method used to validate that domain) have much more nuanced levels of assurance, and we should arguably couple the reuse of that information to the confidence and signals we have in how that information was obtained.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 1, 2017 at 11:59 AM, Jeremy Rowley <span dir="ltr"><<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-1479506658509357512WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">What if we decoupled revalidation of organization information and domain validation? Organization information wouldn’t change if a certificate is revoked for key compromise and tends to change less frequently than domain information. We could keep org information at 39 months and specify domain validation must occur more frequently. <u></u><u></u></span></p><p class="MsoNormal"><a name="m_-1479506658509357512__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u> <u></u></span></a></p><span></span><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>] <br><b>Sent:</b> Wednesday, February 1, 2017 12:24 PM<span class=""><br><b>To:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br></span><b>Cc:</b> Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>></span></p><div><div class="h5"><br><b>Subject:</b> Re: [cabfpub] Draft Ballot 186 - Limiting the Reuse of Validation Information<u></u><u></u></div></div><p></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Jeremy,<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Did you misread superseded as suspended? "Suspension" is indicated by certificateHold, which is different than the ones listed.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">For sake of completeness, here's the RFC5280 list of revocation reasons:<u></u><u></u></p></div><div><div><p class="MsoNormal">   ReasonFlags ::= BIT STRING {<u></u><u></u></p></div><div><p class="MsoNormal">        unused                  (0),<u></u><u></u></p></div><div><p class="MsoNormal">        keyCompromise           (1),<u></u><u></u></p></div><div><p class="MsoNormal">        cACompromise            (2),<u></u><u></u></p></div><div><p class="MsoNormal">        affiliationChanged      (3),<u></u><u></u></p></div><div><p class="MsoNormal">        superseded              (4),<u></u><u></u></p></div><div><p class="MsoNormal">        cessationOfOperation    (5),<u></u><u></u></p></div><div><p class="MsoNormal">        certificateHold         (6),<u></u><u></u></p></div><div><p class="MsoNormal">        privilegeWithdrawn      (7),<u></u><u></u></p></div><div><p class="MsoNormal">        aACompromise            (8) }<u></u><u></u></p></div></div></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Wed, Feb 1, 2017 at 11:13 AM, Jeremy Rowley via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Suspension is not permitted under 4.9.13 of the BRs. It didn’t work with the way browsers did caching, making it impossible to unrevoked a cert. Plus, it was pretty suspicious when CRL listings disappeared.</span><u></u><u></u></p><p class="MsoNormal"><a name="m_-1479506658509357512_m_-8129945046377862576__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></a><u></u><u></u></p><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Public [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@<wbr>cabforum.org</a>] <b>On Behalf Of </b>Peter Bowen via Public<br><b>Sent:</b> Wednesday, February 1, 2017 11:58 AM<br><b>To:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Cc:</b> Peter Bowen <<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>><br><b>Subject:</b> Re: [cabfpub] Draft Ballot 186 - Limiting the Reuse of Validation Information</span><u></u><u></u></p></div></div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><p class="MsoNormal">On Feb 1, 2017, at 10:51 AM, Ryan Sleevi via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<u></u><u></u></p></div><div><div><p class="MsoNormal"> <u></u><u></u></p><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">On Wed, Feb 1, 2017 at 10:49 AM, Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><div><div><p class="MsoNormal"><span style="font-size:9.5pt">Reposing on behalf of <span class="m_-1479506658509357512m-8129945046377862576gmail-m-2027377797794697035gmail-gd">Jürgen Brauckmann</span> <span class="m_-1479506658509357512m-8129945046377862576gmail-m-2027377797794697035gmail-go"><<a href="mailto:brauckmann@dfn-cert.de" target="_blank">brauckmann@dfn-<wbr>cert.de</a>></span></span><u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal"><span class="m_-1479506658509357512m-8129945046377862576gmail-"><span style="font-size:9.5pt">Ryan Sleevi via Public schrieb:</span></span><span style="font-size:9.5pt"><br><span class="m_-1479506658509357512m-8129945046377862576gmail-m-2027377797794697035gmail-im">>   4. The CA has not revoked any certificates which contain certificate</span><br><span class="m_-1479506658509357512m-8129945046377862576gmail-m-2027377797794697035gmail-im">> information verified using the document or data.</span><br><br><span class="m_-1479506658509357512m-8129945046377862576gmail-">Your goal is to kill OV?</span></span><u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal"> <u></u><u></u></p></div><div><div><p class="MsoNormal">And why does OV require revocation? OV totally remains valid, so long as you're not revoking those certs.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">As mentioned in my other message just now, beyond keyCompromise, what other reasons would you revoke a cert? Surely if you revoke a cert because of "affiliationChanged", you should very well be revalidating the affiliation before issuing a new cert; otherwise, you could revoke the cert and totally reissue it using the original bogus information.<u></u><u></u></p></div></div></div></div></div></div></div></div></blockquote><p class="MsoNormal"> <u></u><u></u></p></div><div><div><div><div style="border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 3.0pt;border-left-color:transparent;font-variant-ligatures:normal"><div style="margin-left:22.5pt"><div style="margin-top:3.75pt;margin-right:11.25pt" id="m_-1479506658509357512m_-8129945046377862576:5v7"><div id="m_-1479506658509357512m_-8129945046377862576:5xj"><p class="MsoNormal" style="background:white"><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:#222222">Consider these revocation reasons in the X.509 text:<br><br>- superseded indicates that the certificate has been superseded but<br>there is no cause to suspect that the private key has been compromised<br><br>- cessationOfOperation indicates that the certificate is no longer<br>needed for the purpose for which it was issued but there is no cause<br>to suspect that the private key has been compromise<br><br>If a customer is replacing certificate X with certificate Y (probably<br>with the same SANs), it is completely reasonable for them to request<br>revocation of X once Y is fully deployed.  I would use "superseded"<br>for this case.  It is also possible that a customer ceases to use a<br>server and wants to revoke using "cessationOfOperation".  Neither of<br>these cases says anything about the validity of the domain<br>registration or organization information.<br><br>Thanks,<br>Peter</span><u></u><u></u></p></div></div></div></div></div></div></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>______________________________<wbr>_________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><u></u><u></u></p></blockquote></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></blockquote></div><br></div>