<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;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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'>+1<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><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'> Public [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Doug Beattie via Public<br><b>Sent:</b> Thursday, February 9, 2017 2:30 PM<br><b>To:</b> CA/Browser Forum Public Discussion List <public@cabforum.org><br><b>Cc:</b> Doug Beattie <doug.beattie@globalsign.com><br><b>Subject:</b> Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates: User input<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'>I say go ahead and block them, they’ve all been warned and should be prepared for the consequences. <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'>Doug<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 #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'> Public [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Ryan Sleevi via Public<br><b>Sent:</b> Thursday, February 9, 2017 3:44 PM<br><b>To:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br><b>Cc:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>><br><b>Subject:</b> Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates: User input<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>To Jody's point:<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Consider the following sites (all times Pacific, because I'm on a Mac right now and I'm too lazy to adjust back to GMT from the UI)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><a href="https://amd.com">https://amd.com</a> (Symantec; expires 2017-07-21, issued 2014-07-21; <a href="https://crt.sh/?id=4638163">https://crt.sh/?id=4638163</a> )<o:p></o:p></p></div><div><p class=MsoNormal><a href="https://americancrew.com">https://americancrew.com</a> (Symantec; expires 2018-07-10, issued 2014-06-09; <a href="https://crt.sh/?id=4324896">https://crt.sh/?id=4324896</a> )<o:p></o:p></p></div><div><p class=MsoNormal><a href="https://www.ashevillechamber.org/">https://www.ashevillechamber.org/</a> (GoDaddy; expires 2017-03-06, issued 2012-03-06; <a href="https://crt.sh/?id=982926">https://crt.sh/?id=982926</a> )<o:p></o:p></p></div><div><p class=MsoNormal><a href="https://bitcoin.hu">https://bitcoin.hu</a> (Comodo; expires 2019-08-14, issued 2014-08-14; <a href="https://crt.sh/?id=4816214">https://crt.sh/?id=4816214</a> ) <o:p></o:p></p></div><div><p class=MsoNormal><a href="https://gm.ca">https://gm.ca</a> (DigiCert/Verizon; expires 2017-09-18, issued 2014-09-18; <a href="https://crt.sh/?id=5021956">https://crt.sh/?id=5021956</a> )<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Despite the Forum's efforts, all of these certificates are SHA-1 and valid through 2017-01-01. That means these sites break when you disable SHA-1, such as Chrome has. I'm sure, if members want to keep debating this as if it's not an issue, I can find certificates from most of the CA members opposed that demonstrate these sorts of issues.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>You might be wondering where I came up with this list. It wasn't Certificate Transparency. It was courtesy of Mozilla, by way of understanding what's currently preventing them from disabling SHA-1 on Firefox 51 at 100% - specifically, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1330043#c7">https://bugzilla.mozilla.org/show_bug.cgi?id=1330043#c7</a><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Until Mozilla disables SHA-1, their users are at risk. They're at risk from malicious parties having taking advantages of CA's past reticence to adopt serial entropy - and I'm happy to name the specific CAs I'm thinking about, if members would like - and they're at risk of CAs misissuing SHA-1 - of which, again, I'm happy to name some specific members who have already proven this is a valid concern.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>But this also demonstrates the balance that browsers face when charged with protecting their users - do we block access to these sites (as Chrome is doing, and as Microsoft will around February 15) or not? If we do block these sites, we run the risk of causing the average user to see too many of these messages a day, thus succumbing to warning fatigue, and causing them to ignore these warnings when their information is truly at risk. This makes everyone less secure - either through warning fatigue or through lack of automatic protection.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>We can talk about how revocation is the answer - but this is clearly irrelevant, because every one of these certificates is unrevoked. We can argue about how many outgoing links to those specific addresses exist and whether they're "used" - for example, <a href="https://www.amd.com">https://www.amd.com</a> has corrected the error, but <a href="https://amd.com">https://amd.com</a> has not - but that's irrelevant, because browsers intentionally don't collect data to that degree, precisely because it's invasive to users' privacy. So we - the Forum - have no way of determining whether or not our users care about these sites, whether or not the server operators care about these sites, whether or not the CAs care about these sites - but we know these sites will and do break.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>For those who are unfortunately arguing we should "phase these requirements in" - we did that, with 60 month certs to 39 month certs. Notice how those 60 month certs are still causing pain in the examples I gave above? That phase in approach doesn't meaningfully work - at least not for validity periods.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>What would the world look like if we had required 398 day (nee 13 month) certificates from the get-go? Not a single one of those certificates would be valid beyond 2017-02-01. Browsers - such as Chrome, Firefox, Edge, Safari, Opera, Qihoo360 - could all make an informed decision that they can enforce "no SHA-1" on 2017-02-01, and know *it will not break a single site*.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>What an amazing world that would be.<o:p></o:p></p></div><div><p class=MsoNormal>Because it would mean our users were protected from SHA-1 issues - whether past or future.<o:p></o:p></p></div><div><p class=MsoNormal>That's the world we want to move to.<o:p></o:p></p></div><div><p class=MsoNormal>That's the world some member CAs are opposing.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>That's why this is about security.<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Thu, Feb 9, 2017 at 11:59 AM, Christian Heutger via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><p class=MsoNormal style='margin-bottom:12.0pt'>I’m following the discussion already for a while. I understand the reasons, but I also see the customers situation out there. I also saw the votes recently and as a compromise I believe a two year timeframe + up to 90 days on renewal (so a total of 27 months or 820 days to be clear) would be a reasonable timeframe for most customers. However, I still expect some trouble, but maybe some exceptions would be granted. For the need to eliminate any X fast, OCSP still should be the solution, to get an evolution process running, two years should be enough.<br><br>Am 09.02.17, 18:47 schrieb "Jody Cloutier" <<a href="mailto:jodycl@microsoft.com">jodycl@microsoft.com</a>>:<br><br> I'm the first to admit that I haven't been following this thread as closely as I would like, but, from Microsoft's perspective, we want shorter certificates and not longer. We would certainly endorse a ballot that would mandate shorter certificate life for the very reason stated below: if we want to eliminate X we would know exactly when the last cert will expire. We've gone so far as to consider mandating this as a program requirement. Anyway, that's our .02.<br><br> -----Original Message-----<br> From: Public [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] On Behalf Of Christian Heutger via Public<br> Sent: Thursday, February 9, 2017 9:31 AM<br> To: CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br> Cc: Christian Heutger <<a href="mailto:ch@psw.net">ch@psw.net</a>><br> Subject: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates: User input<br><br> > I can see why there's some confusion here :-) Ryan is not arguing that we should switch to 13 months so that we will always in future move from "let's eliminate Algorithm X" to "Algorithm X is gone" in 13 months. One would always consider lots of data points in setting such a timetable. His point is that 3.25 > year certs make it very hard to move faster than that in _any_ deprecation scenario, whether simple or complex.<br><br> I don’t believe, moving faster is required for normal situations. If there are issues arising needing faster reaction, revocation and reissue is still a possible way. For normal situations, enterprises need to be able to react and they can’t move faster. Why are most enterprises skipping one Windows version and roll out the next one? As they are not able to move faster in controlled enterprise security environments.<br><br> > I don't agree that replacing your certificates once a year requires automation. It's made easier by automation, but it doesn't require it.<br><br> As I understood the discussion, 1 year is the first step on a road to months or weeks.<br><br> > I'm sure there are plenty of CAs, big and small, who would assert their automation solutions are secure. :-)<br><br> But as you know, there is nothing, which is 100% secure and if we talk about certificates in their sense of encryption and(!) identity assurance, such job shouldn’t be based on automatism.<br><br><br><br> PSW Secure Mail Gateway Info - <a href="http://www.psw.net/" target="_blank">http://www.psw.net/</a><br><br> - The message was not encrypted and not digitally signed<br> PSW Secure Mail Gateway Info - <a href="http://www.psw.net/" target="_blank">http://www.psw.net/</a><br><br> - The message was not encrypted and not digitally signed<br><br><br>_______________________________________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>