<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I don’t understand the reluctance for 400 days? For two extra days you get both substance and style. <o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></a></p><span style='mso-bookmark:_MailEndCompose'></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'> Public [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Ryan Sleevi via Public<br><b>Sent:</b> Wednesday, February 8, 2017 1:25 PM<br><b>To:</b> CABFPub <public@cabforum.org><br><b>Cc:</b> Ryan Sleevi <sleevi@google.com><br><b>Subject:</b> [cabfpub] Draft Ballot 185 (2) - Limiting the Lifetime of Certificates<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><span style='font-size:9.5pt'>Changes in this draft compared to the last draft ( <a href="https://cabforum.org/pipermail/public/2017-January/009373.html">https://cabforum.org/pipermail/public/2017-January/009373.html</a> ) <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>- Changed 12 months to 398 days, following the recommendation in <a href="https://cabforum.org/pipermail/public/2017-February/009449.html">https://cabforum.org/pipermail/public/2017-February/009449.html</a><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>  - Why: As Peter Bowen pointed out, utilizing a days-based approach offers the benefit of being a consistent duration, whereas 13 months could vary from being 365 + 28 days (Jan 1 -> Feb 28) to 366 + 28 days (Jan 1 of a leap year -> Feb 28) to being 365 + 29 days (Jan 1 -> Feb 29). Further, by utilizing days as the unit of measure, it allows for easier implementation of those measuring compliance (e.g. whether Feb 28 -> March 31 = 13 months) and for issuance (What day is 13 months from Jan 31?).<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>  - I understand and appreciate Kirk's concerns in <a href="https://cabforum.org/pipermail/public/2017-February/009450.html">https://cabforum.org/pipermail/public/2017-February/009450.html</a> , but I do not agree with the analysis; as this is a fully technically quantifiable measure, it does not require human vetters to make sense of it, and for those CAs that employ human vetters, it allows sufficient flexibility to address this via that individual CA's CP/CPS<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>  - I understand and appreciate Scott's concerns in <a href="https://cabforum.org/pipermail/public/2017-February/009485.html">https://cabforum.org/pipermail/public/2017-February/009485.html</a> , but the argument that 400 days is easier for humans to calculate has no evidence of support, and there's no technical argument provided. While I acknowledge it's aesthetically appealing, we should focus our efforts on substance over style.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>From the non-CA, non-browser participants on the list - and those requesting reposting - I believe we've seen support for this.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>  - Eric Mill: <a href="https://cabforum.org/pipermail/public/2017-February/009484.html">https://cabforum.org/pipermail/public/2017-February/009484.html</a><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>  - Carl Mehner: <a href="https://cabforum.org/pipermail/public/2017-February/009433.html">https://cabforum.org/pipermail/public/2017-February/009433.html</a><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>  - Walter Goulet: <a href="https://cabforum.org/pipermail/public/2017-February/009492.html">https://cabforum.org/pipermail/public/2017-February/009492.html</a><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>We've seen analysis about what is the 'floor' for the ecosystem to affect change ( <a href="https://cabforum.org/pipermail/public/2017-February/009483.html">https://cabforum.org/pipermail/public/2017-February/009483.html</a> ), but luckily, this ballot focuses on new certificates. By targeting 1 May 2017, any potential impact on subscribers does not manifest until June 2018. As to practical impact, we know that 56% of the sites most used by Relying Parties are already compliant with, or more aggressive than, this ( <a href="https://cabforum.org/pipermail/public/2017-February/009437.html">https://cabforum.org/pipermail/public/2017-February/009437.html</a> ), so we know that it is both technically and humanly possible.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>The remaining substance of the opposition largely centered around the argument that "customers prefer X", without any representation from CAs on behalf of the far more numerous Relying Parties, which Browsers are effectively responsible for proxying and who are disproportionately affected by such CA practices. Given how we see Browser members differentiating themselves on their security properties, and correspondingly see that reflected in both the media reports on browsers and through user surveys, we can quite reasonably conclude that security is important to relying parties.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>This ballot improves security two-fold:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>First, it allows the CA/Browser Forum to continue its careful deliberations about when new changes will be effective and required, while also providing greater assurance to Relying Parties that these changes can actually be technically enforced - regardless of what those changes are.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Second, by more closely aligning with the annual audit period, it allows Relying Parties to be confident that if an issue is noted during an annual audit, the duration of 'impact' from that issue will be limited to, at most, 13 months (for certificates issued on the last day of the period of audit), or less (for certificates issued closer to the start of the period of audit), rather than the current possibility of 39 months (for new certificates), or the possibility that it's been ongoing for years (and that previous audits failed to detect it, but those certificates are still valid). This allows for more targeted and careful remediation steps than have been necessary in the past, thereby allowing a broader deployment of such steps, thus better protection for more users.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>At this point, I believe I've addressed all meaningful objections or concerns raised, and would like to see this proceed. I've had several offers for endorsement privately, but to avoid any misinterpretations, I'll let them re-confirm on the list and we can proceed to a vote.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Background:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>The validity period of certificates represents the single greatest impediment towards improving the security of the Web PKI. This is because it sets the upper-bound on when legacy behaviours may be safely deprecated, while setting a practical lower-bound for how long hacks and workarounds need to be carried around by clients.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Further, in the event of misissuance related to internal control failures, rather than external security failures - for example, misissuance due to failing to properly vet subject information - the validity period represents the risk and exposure to customers and relying parties in the absence of revocation information (for example, constrained environments).<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>To keep this vote simple, it avoids any discussion of the reuse of validation information, described in Section 4.2.1 of the Baseline Requirements and Section 11.14.3 of the EV Guidelines.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>The following motion has been proposed by Ryan Sleevi of Google, Inc and endorsed by Josh Aas of ISRG and ___ of ___ to introduce new Final Maintenance Guidelines for the "Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates" and the "Guidelines for the Issuance and Management of Extended Validation Certificates"<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>-- MOTION BEGINS --<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Modify Section 6.3.2 of the "Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates" as follows:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Replace Section 6.3.2 with:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>"""<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>6.3.2. Certificate Operational Periods and Key Pair Usage Periods<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Subscriber Certificates issued on or after 1 May 2017 MUST NOT have a Validity Period greater than three hundred and ninety-eight (398) days.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Subscriber Certificates issued prior to 1 May 2017 MUST NOT have a Validity Period greater than thirty-nine (39) months.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>"""<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Modify Section 9.4 of the "Guidelines for the Issuance and Management of Extended Validation Certificates" as follows:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Replace Section 9.4 with:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>""""<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>9.4 Maximum Validity Period for EV Certificate<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>EV Certificates issued on or after 1 May 2017 MUST NOT have a Validity Period greater than three hundred and ninety-eight (398) days.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>EV Certificates issued prior to 1 May 2017 MUST NOT have a Validity Period greater than twenty seven (27) months.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>"""<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>-- MOTION ENDS --<o:p></o:p></span></p></div></div></div></body></html>