<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>+1</div><div><br></div>Put the world internet in danger just because they are big Internet company?<div><br><br><div>Regards,<div><br></div><div>Richard</div></div></div><div><br>On Dec 21, 2015, at 21:30, Doug Beattie <<a href="mailto:doug.beattie@globalsign.com">doug.beattie@globalsign.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"><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:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle18
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle19
        {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]--><div class="WordSection1"><p class="MsoNormal"><span style="color:#1F497D">Hi all,<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">To summarize I see the following changes in this ballot proposal. LV Certificates must:<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">  1) use SHA-1<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">  2) not expire after 31 March 2019<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">  3) have Serial numbers that contain at least 20 bits of entropy<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">  4) be OV (or EV?) validated<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">  5) have a new unique Policy OID in them<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">  6) be issued under new LV dedicated CAs<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">  7) be issued only as “replacements” for SHA-2 signed certificates<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">  8) only be used by the server if the server believes the client of the TLS session may not support SHA-2.<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">As far as I could tell, there are no penalties if the subscriber serves up an LV certificate to relying parties that might/can process SHA-2, nor are there obligations on the CA to enforce compliance with this.  Won’t everyone just ask for SHA-1 certs and use them?  As the browsers ratchet up the warnings and speed- bumps subscribers will be highly motivated to either use only SHA-2 or to implement server logic to only serve up SHA-1 to browsers that don’t block or complain about SHA-1.  I don’t see the point of the creating a while new class of certificates for this.  Let the subscribers decide what hashing algorithm to use and when,<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">This seems like a lot of work for CAs and subscribers “just” to continue the issuance and use of SHA-1 certificates for this class of customers.  Is there really a benefit in this proposal over allowing continued issuance of OV/EV SHA-1 certificates under existing CAs and policies except with the new maximum certificate expiration date and requiring 20 bits of entropy?<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">a) Why do we not allow issuance for DV (item 4)?  These are commonly used by web hosting companies and are likely the most widely deployed and used today.  They should not be precluded.<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">b) Why is there a requirement for a new CA and new OID (items 5 and 6)?  You can tell which are LV because of their not-before date and hashing algorithm, so what is driving this requirement?  Are the browsers going to process this OID and do something different?  Consider a requirement to post them to CT logs instead if it’s important to track issuance.<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">c) Why must they be issued only as replacements for SHA-2 certificates (item 7)?  Some subscribers will need only SHA-1 and know it from the beginning (legacy backend systems for example), so what’s the point of this requirement?<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">If we’re going to allow continued issuance of SHA-1 then let’s make sure we’re not vulnerable to known plain-text attacks (add the entropy requirement) and continue issuing them under the existing CAs and processes.  I don’t see the benefit to all of the other proposed changes, so I’m probably missing something.<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">Doug<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><a name="_MailEndCompose"><span style="color:#1F497D"><o:p> </o:p></span></a></p><div><div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal" style="margin-left:.5in"><b>From:</b> <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>Jeremy Rowley<br><b>Sent:</b> Friday, December 18, 2015 5:22 PM<br><b>To:</b> CABFPub <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br><b>Subject:</b> [cabfpub] LV Certificates<o:p></o:p></p></div></div><p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p><p class="MsoNormal" style="margin-left:.5in">Hi everyone, <o:p></o:p></p><p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p><p class="MsoNormal" style="margin-left:.5in">Attached is a proposal from Cloudflare and Facebook creating LV certificates in the baseline requirements.  This is a draft ballot for review that will, of course, change based on the debate in the forum. Although CAs will stop issuing SHA-1 on 2016/1/1, there isn’t any reason these changes couldn’t go into effect in early January (assuming a passing vote).<o:p></o:p></p><p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p><p class="MsoNormal" style="margin-left:.5in">If adopted, this ballot would permit continued use of SHA1 certificates past the deprecation deadline (to support older devices) but give newer browsers an easy way to reject SHA1 for users.  The ballot also increases the resiliency of SHA1 certs against attacks by requiring higher entropy serial numbers.<o:p></o:p></p><p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p><p class="MsoNormal" style="margin-left:.5in">I look forward to your comments.<o:p></o:p></p><p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p><p class="MsoNormal" style="margin-left:.5in">Thanks,<o:p></o:p></p><p class="MsoNormal" style="margin-left:.5in">Jeremy<o:p></o:p></p><p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Public mailing list</span><br><span><a href="mailto:Public@cabforum.org">Public@cabforum.org</a></span><br><span><a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a></span><br></div></blockquote></body></html>