<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 14 (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:Cambria;
        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;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 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";}
h2
        {mso-style-priority:99;
        mso-style-link:"Heading 2 Char";
        margin-top:12.0pt;
        margin-right:0in;
        margin-bottom:6.0pt;
        margin-left:0in;
        text-align:justify;
        page-break-after:avoid;
        font-size:14.0pt;
        font-family:"Cambria","serif";
        mso-fareast-language:X-NONE;
        font-weight:bold;
        font-style:italic;}
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
        {mso-style-priority:99;
        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";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.Heading2Char
        {mso-style-name:"Heading 2 Char";
        mso-style-priority:99;
        mso-style-link:"Heading 2";
        font-family:"Cambria","serif";
        mso-fareast-language:X-NONE;
        font-weight:bold;
        font-style:italic;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
span.EmailStyle21
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle22
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle23
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@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";color:#1F497D'>FORWARDED:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>On Behalf Of </span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Bruce Morton<br><b>Sent:</b> Thursday, March 13, 2014 9:45 AM<br><b>To:</b> questions@cabforum.org<br><b>Subject:</b> [cabfquest] FW: [cabfpub] SHA1 Deprecation Ballot<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Can someone please advise how shortening the lifetime of a SHA1 signed certificate to 15 months will increase security?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Per item (d), If you allow an exception for customers to renew a SHA1 certificate after 31 December 2015, you violate the Microsoft policy and you have created another signature that could be used for a collision attack.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Why not just let customers that need SHA1 to issue a 39 month certificate as late as 31 December 2015? This caps the issuing period to Microsoft’s requirement and gives the customer 39 months to transition to SHA2. The last date for a SHA1 certificate would be 31 March 2019.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>This will prevent collision attack and should not be susceptible to a preimage/second preimage attack in such an early period. This also provides hard dates with no exceptions.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I understand that the certificate will not work with Windows after 2016, but that is the customer’s choice and a matter for the CA to support. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Bruce.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Ben Wilson<br><b>Sent:</b> Wednesday, March 12, 2014 8:37 PM<br><b>To:</b> 'Ryan Sleevi'; 'Eddy Nigg (StartCom Ltd.)'<br><b>Cc:</b> 'CABFPub'<br><b>Subject:</b> Re: [cabfpub] SHA1 Deprecation Ballot<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>After discussions earlier today with Doug, here is where I think we were:<o:p></o:p></span></p><h2>9.8  Signature Algorithms<o:p></o:p></h2><p class=MsoNormal><span style='mso-fareast-language:X-NONE'>Effective as of January 1, 2015, the maximum validity of a Subscriber Certificate signed with SHA-1 shall be 15 months, unless the CA documents that the Subscriber Certificate (and corresponding CRL or OCSP response) is for a system or software that:<o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:X-NONE'>(a) is used by either the Applicant or a substantial number of Relying Parties;<o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:X-NONE'>(b) will fail to operate if the Certificate, OCSP Response, or CRL is not signed with the SHA-1 algorithm; <o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:X-NONE'>(c) does not contain known security risks to Relying Parties; and<o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:X-NONE'>(d) is difficult to patch or replace without substantial economic outlay.<o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:X-NONE'>Effective as of January 1, 2016, CAs SHALL sign all Subscriber Certificates using one of the following algorithms:  SHA-256, SHA-384, SHA-512, P-256, P-384, P-521, DSA 2048 (with prime q of 224 or 256 bits), or DSA 3072 (with prime q of 256 bits).  A CA MAY use the SHA-1 algorithm to sign Subscriber Certificates (including for re-keys, renewals, and corresponding CRLs or OCSP responses) beyond January 1, 2016, provided that the CA has documented that the system or software meet the four criteria above.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='mso-fareast-language:X-NONE'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Ryan Sleevi<br><b>Sent:</b> Wednesday, March 12, 2014 5:46 PM<br><b>To:</b> Eddy Nigg (StartCom Ltd.)<br><b>Cc:</b> CABFPub<br><b>Subject:</b> Re: [cabfpub] SHA1 Deprecation Ballot<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On Wed, Mar 12, 2014 at 4:36 PM, Eddy Nigg (StartCom Ltd.) <<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal><br>On 03/12/2014 02:51 PM, From Doug Beattie: <o:p></o:p></p><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>So, at this time, I’m in favor of:</span><o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-</span><span style='font-size:7.0pt;color:#1F497D'>          </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Specifying shorter max validity periods for SHA-1 SSL certificates (1-year starting Jan 2015?)</span><o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-</span><span style='font-size:7.0pt;color:#1F497D'>          </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Setting end dates for the creation of any new Root and Subordinate CAs with SHA-1</span><o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-</span><span style='font-size:7.0pt;color:#1F497D'>          </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Defining clear messaging to the user community regarding SHA-1</span><o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-</span><span style='font-size:7.0pt;color:#1F497D'>          </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Setting target dates for the next set of changes for improved security/performance (RSA-4096/ECC/SHA-512/etc)</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I’m against:</span><o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-</span><span style='font-size:7.0pt;color:#1F497D'>          </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Specifying an exact date at which no SHA-1 certificates can be issued globally</span><o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-</span><span style='font-size:7.0pt;color:#1F497D'>          </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Specifying the detailed legacy exceptions for using SHA-1 after the sunset date</span><o:p></o:p></p></div></blockquote><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Here it starts again...this is exactly what I'm afraid of and thought we should avoid. I prefer an exact date binding for all, clear limits when and for how long. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>A "Strong +1" to Eddy's remarks.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I think if a CA is going to issue these 'legacy' certificates, it should be exactly the same process as handling other legacy practices - eg: 1024-bit roots.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>It gets treated as a BR violation, it's a qualified finding, and, most importantly for Root Store Operators/Browsers, precisely *because* it's a qualified finding, that practice gets disclosed to the Operators.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Chrome's plan continues to remain aggressive - disallowing certain algorithms/key sizes if their issuance date is after their sunset-grace period, outright rejecting them if their validity period exceeds the sunset-fail period, and eventually outright removing support entirely. As such, a CA that (continues) to issue such certs would not (ultimately) be causing outright risk to *current* versions of Chrome users.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>However, such a qualified finding *would* be a point of concern for overall trustworthiness, and *does* highlight that the CA is engaged in practices for specific customers that may be dangerous overall, and that's exactly the kind of thing a qualified finding can highlight. It's entirely possible (read: probable) that it would not be an immediate cause for removal, but would be something to work closely with the CA to ensure the BR violations cease on an appropriate timeline.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This is the same way Operators are already handling legacy roots, and are already handling 1024-bit certs (eg: Symantec's BR-violating issuance of a <a href="http://pb.com">pb.com</a> cert - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=966350">https://bugzilla.mozilla.org/show_bug.cgi?id=966350</a> ), and is the way forward for these sorts of 'legacy' issues.<o:p></o:p></p></div></div></div></div></div></body></html>