
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I fail to see how this example shows a security improvement from reducing certificate validity.</div><div class=""><br class=""></div><div class="">In the case that CABForum declares that certs of a particular type are to be decorated with attribute X, there will naturally have to be a phase in period. The normal practice for such a phase in would be to grandfather all the existing CAs for the period of the phase in and require new entrants to start using the new decoration immediately. So the only practical impact of the phase in period is that clients would have to carry both sets of code for the duration of the phase in. If the period is three years instead of one, they have to carry the legacy grandfather code for 24 extra months.</div><div class=""><br class=""></div><div class="">That is an argument but it is not a security justification for the proposed change.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Note that CAs will probably have to support both OIDs until the relevant roots expire because many browsers are not updated.</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 10, 2017, at 12:04 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Feb 10, 2017 at 8:58 AM, philliph--- via Public <span dir="ltr" class=""><<a href="mailto:public@cabforum.org" target="_blank" class="">public@cabforum.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Which is the reason I think that making the change proposed for the reason proposed will actually make the WebPKI less secure, less robust.<br class=""></blockquote><div class=""><br class=""></div><div class="">s/reason proposed/reasons proposed/</div><div class=""><br class=""></div><div class="">Note the plural.</div><div class=""><br class=""></div><div class="">Absent this change, if Browsers were to require that all new certificates contain the id-kp-serverAuth EKU, from intermediates that contain the id-kp-serverAuth EKU, from roots that contain the id-kp-serverAuth EKU - as a very simple example - how long do you believe this migration would take?</div><div class=""><br class=""></div><div class="">Similarly, if Browsers were to require that all new EV certificates contain the CABForum EV OID, rather than the per-CA OID, how long do you believe this change should take?</div><div class=""><br class=""></div><div class="">Similarly, if Relying Parties want to be assured that all certificates they trust had their domain names validated via the methods in Ballot 169, rather than in the pre-169 or post-180 method, such as "The CA consulted a santeria to ensure that the domain was authorized" (under the basis of Any Other Method), when do you believe Relying Parties could have that confidence in the ecosystem?</div><div class=""><br class=""></div><div class="">Regrettably, I will find it necessary to highlight this every time it's advanced, because it's not the argument being presented, and needs to be corrected, lest this alternative fact be seen as correct through its continued repetition.</div></div></div></div>

</div></blockquote></div><br class=""></body></html>