<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 11:57 AM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>What would you think about defining a new term, “Compliance Date”?</div><div><br></div><div><div>Compliance Date: The Compliance Date of a certificate is the earlier of the notBefore field or when the CA signs the certificate</div></div><div><br></div><div>Then it can be used to make it very clear:</div><div><br></div><div><div><div style="margin:0in 0in 0.0001pt">These Requirements <u>apply to all Certificates with a Compliance Date of or after February 15, 2013 that include id_kp_serverAuth (1.3.6.1.5.5.7.3.1) in the extended key usage extension. Additionally, these Requirements apply to all Certificates </u><u>with a Compliance Date of or after June 30, 2016 </u><u>that either do not include the extended key usage extension or include anyExtendedKeyUsage (2.5.29.37.0) in the extended key usage extension.</u></div></div></div></div></blockquote><div><br></div><div>This seems to weaken Jeremy's proposal - but perhaps it's merely bringing clarity to what was already a weak proposal.</div><div><br></div><div>That is, it leaves an unknown portion of non-BR certificates out there for an unknown number of years (since, by being non-BR, we cannot presume that the certificates themselves will expire within the 39 months prescribed by the BRs, nor the 60 months previously allowed)</div><div><br></div><div>The problem with the Web PKI is determining what the known-knowns are, but also trying to map out the unknown-unknowns - there's a vast portion of 'hidden' certificates which do not comply to the BRs, but were issued by BR conforming roots. The past two years of Mozilla's CA communications demonstrate Mozilla's own attempts to map out the scope and impact of such certificates - even when the requirements were much clearer.</div><div><br></div><div>If we adopt a position of "go forward" of June 30, 2016 being when anything in scope (and there may still be some wording tweaks needed here to clarify that issuance from a CA that has the EKUs but leaves that do not have EKUs, the leaf is _still in scope_), I think we should also look at an internal-server-name like "revoke-or-disclose" sunset clause.</div><div><br></div><div>The end goal being that, for roots and intermediates that conform to the BRs, the entire population of certificates - and the requirements that they were expected to abide by - can be known.</div></div></div></div>