<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 12 (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";
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";
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;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle26
{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'>Based upon discussion thus far, I agree with Dean and Bruce on the acceptable validity period issue. From a business perspective, it's far easier to replace a SHA-1 cert, which has had its effective life shortened by browser code, with a SHA-2 cert than it is to try to put in different acceptable validity periods for SHA-1. For the first case, we just have to advise a customer who is buying a max validity SHA-1 cert that if they want it to keep functioning they will have to have it re-issued with a SHA-2 prior to the browser's cut-off date. That means little if any code change to our core systems as we can already handle replacements/re-issuance within the current framework. Changing acceptable validity periods on the other hand is a lot of work all the way from web pages to back end systems. Not that it can't be done, but if Bruce is correct about the threat differences between collision attack and preimage/second preimage attacks (and no one has said he's wrong) then I'm not sure the threat model warrants that much additional coding to every system we run.<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'>-Rich<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 style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><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"'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Dean Coclin<br><b>Sent:</b> Thursday, March 13, 2014 6:43 PM<br><b>To:</b> Tom Albertson; ben@digicert.com; public@cabforum.org<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 lang=EN style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>“Any time valid SHA1 SSL certificates must be replaced with a SHA2 equivalent by 1 January 2017”</span><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'>Yes, but Tom, there may (will) be non-browser applications that require SHA-1 certificates beyond that point in time. Since Microsoft is planning on stopping support for SHA-1 in Windows, what does it matter to Windows if there are valid SHA-1 certs out there beyond that point since you won’t recognize them anyway? Am I misunderstanding your implementation of this control?<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'>Also, I agree with Bruce, there is no need to shorten this to 15 months.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><br>Thanks,<br>Dean<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>Tom Albertson<br><b>Sent:</b> Thursday, March 13, 2014 3:41 PM<br><b>To:</b> <a href="mailto:ben@digicert.com">ben@digicert.com</a>; <a href="mailto:public@cabforum.org">public@cabforum.org</a><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"'>39 month SHA1 certs issued as late as 31 December 2015 will create a base of time valid SHA1 certs past 31 December 2016, which we are trying very hard to avoid. When we cut off negotiation of SHA1 certs in Windows that will disable a large number of certs. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>However you address your issuance of SHA1 SSL certs, I recommend that you do so with the 31 December 2016 deadline in mind, and no other. </span><span lang=EN style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Any time valid SHA1 SSL certificates must be replaced with a SHA2 equivalent by 1 January 2017.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><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 #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><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"'> <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> Thursday, March 13, 2014 10:53 AM<br><b>To:</b> <a href="mailto:public@cabforum.org">public@cabforum.org</a><br><b>Subject:</b> [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'>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> <a href="mailto:questions@cabforum.org">questions@cabforum.org</a><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>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></p><p class=MsoNormal>(a) is used by either the Applicant or a substantial number of Relying Parties;<o:p></o:p></p><p class=MsoNormal>(b) will fail to operate if the Certificate, OCSP Response, or CRL is not signed with the SHA-1 algorithm; <o:p></o:p></p><p class=MsoNormal>(c) does not contain known security risks to Relying Parties; and<o:p></o:p></p><p class=MsoNormal>(d) is difficult to patch or replace without substantial economic outlay.<o:p></o:p></p><p class=MsoNormal>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></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></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></div></body></html>