<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 20, 2016, at 12:51 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 20, 2016 at 11:57 AM, Peter Bowen <span dir="ltr" class=""><<a href="mailto:pzb@amzn.com" target="_blank" class="">pzb@amzn.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">What would you think about defining a new term, “Compliance Date”?</div><div class=""><br class=""></div><div class=""><div class="">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 class=""><br class=""></div><div class="">Then it can be used to make it very clear:</div><div class=""><br class=""></div><div class=""><div class=""><div style="margin:0in 0in 0.0001pt" class="">These Requirements <u class="">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 class="">with a Compliance Date of or after June 30, 2016 </u><u class="">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 class=""><br class=""></div><div class="">This seems to weaken Jeremy's proposal - but perhaps it's merely bringing clarity to what was already a weak proposal.</div></div></div></div></div></blockquote><div><br class=""></div><div>I admit that it might weaken it in one area — by saying the Compliance Date is the earlier of notBefore or CA signing, it would allow a CA to issue a certificate now with a notBefore of Feb 1, 2013 and avoid the rule. This is possible because there is no rule about how the notBefore date relates to the date when the CA signs the certificate.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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 class=""><br class=""></div><div class="">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></div></div></div></blockquote><div><br class=""></div><div>From CT logs, it seems that a number of CAs were issuing certificates with validity periods of up to 10 years prior to the BRs coming into effect. It doesn’t seem clear to me that this was against any rule.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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 class=""><br class=""></div><div class="">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>
</div></blockquote></div><br class=""><div class="">I think that putting in some compliance dates is a start. Yes, it might not be great, but at least it should create a closed set of certificates rather than continuing to have ambiguity.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Peter</div></body></html>