<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=iso-8859-1"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 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";
color:black;}
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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;
color:windowtext;}
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";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
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:12.0pt;
font-family:"Times New Roman","serif";
color:windowtext;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:26148865;
mso-list-type:hybrid;
mso-list-template-ids:1109942202 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:338970092;
mso-list-template-ids:1052902704;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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 bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Although we appreciate Rick’s and Erwann’s points (and agree with a few of them), DigiCert still strongly supports CT. Speaking from experience (as we already make CT available to customers), only a few of Rick’s points caused us concern when developing our systems. The rest were really non-issues. Here is what we found and recommend when deploying CT:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Cambria","serif";color:windowtext'><o:p> </o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Cambria","serif"'><span style='mso-list:Ignore'>1)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Complexity. The deployment process was straightforward. It took one developer about a week to configure all our systems to support CT. Although every CA’s systems are different, CT is a simple and elegant solution that caused minimal impact on our systems. Since Google already supplies most of the code, even the log server was relatively easy to set up and operate. <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Cambria","serif"'><span style='mso-list:Ignore'>2)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Time Frames. Maximum Merge Delay is not a long period of time. Considering that sites can currently go weeks without detecting a mis-issued certificate, even a CT of 24 hours (which is ridiculous, it’s more like minutes) provides a substantial benefit over the existing landscape. A DoS attack against the log server is detectable, and a log server that fails to report for an extended period of time becomes untrusted, minimizing the possibility of an attack. Plus any attacker would need to attack every log that issued an SCT proof. <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Cambria","serif"'><span style='mso-list:Ignore'>3)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Preventative v. Remediation. Although we also favor preventative solution, we do not believe any currently proposed preventative solution alone is sufficient. CT helps fill the gaps where preventative solutions fail. Deploying CT does not eliminate prevent CAs from deploying other preventative solutions.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Cambria","serif"'><span style='mso-list:Ignore'>4)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Log Availability. The only requirement for a log operator at this time is availability. Considering DigiCert and Google are both willing to host log servers, two of the three log servers are highly available. If only a single log is required (see below), each CA can access Google’s log for the sole proof, making log availability and costs minimal. Given how Google has already minimized the cost to CAs, we believe the benefits of deployment far outweigh any risks identified.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Cambria","serif"'><span style='mso-list:Ignore'>5)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Size. We do not support Google’s recommendation for three separate time stamps. Two is sufficient to provide protection. In fact, I’d prefer to include only a single proof in each certificate. If you log a cert to multiple servers, you can include a new proof later on during re-issue, which minimizes concerns about log compromise. Regardless, I do not think Google should dictate the number of logs. Instead, each CA should individually evaluate the risks of a log compromise or unavailability and decide the number of proofs required.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Cambria","serif"'><span style='mso-list:Ignore'>6)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Costs. DigiNotar exposed a weakness in the multi-trusted CA model. As direct providers of these services, CAs are in the best position to remediate the problem. If expense is required in deployment of the fix, then CAs should bear it, especially where the change is an opportunity. We do not see the costs as disproportionately large if you remember that the attacks in this area are not theoretical. CT is a response to an actual event.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Cambria","serif"'><span style='mso-list:Ignore'>7)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Monitors. Monitors are already under development and will be deployed shortly. In fact, I believe some monitors are already in beta. The auditing role is already being assumed by several universities and (if I recall correctly) the EFF. CAs are not required to provide monitoring capability, meaning no expense is required. <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Cambria","serif"'><span style='mso-list:Ignore'>8)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Location of Log Servers. Google is providing a full list of trusted log servers. If the log is not on the Google trusted list, then the log server’s SCT response is useless. The entire universe of logs will always be known. <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Cambria","serif"'><span style='mso-list:Ignore'>9)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Privacy. This was a significant initial concern for us. However, crawlers used by CAs and EFF already find most of this information. Since only the certificate contents are included in the log (and client certs are not part of the log), the risk of unwanted solicitation is minimal, especially when all of this information is available through WHOIS. No certificates should be exempt from logging as the benefit of the log is only fully recognized if all certificates are included. Note that all certificates issued from a domain-constrained intermediate are considered logged if the intermediate is logged.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Cambria","serif"'><span style='mso-list:Ignore'>10)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Mandate. We believe Google should require CT for all certs, not just EV. To date, EV certificates have been free from missuance. Changing processes and creating logs for just EV requires a lot of work for little benefit. In fact, we are concerned that requiring logs for only EV certificates may have a negative impact on EV adoption and implementation. Implementing CT for DV certificates is of greater importance and will yield a more significant improvement in overall Internet security. We would really like to see a CT requirement date for DV and OV certificates, even if Google is unable to require full compliance by CAs for several years. EV are a higher caliber of certificate, and we’d like to see more done to encourage their use. As such, we highly recommend that Google establish a CT date for all certificates instead of just EV certificates. If Google insists on only requiring CT for EV, then the date for full CA compliance, and a loss of EV indicators, should be March 2016, two years from when CAs must include proofs in the certificates. EV certificates are only valid for two years, meaning this date will minimize the impact on issued certificates and keep the white list relatively small.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Cambria","serif"'><span style='mso-list:Ignore'>11)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Browser Dependence. We would like to see CT eventually become browser independent. To move towards independence, we’d like to see other industry groups committed towards operating logs. Indeed, we’d like to see Google’s log be less preferred than those operated by independent bodies. <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Cambria","serif"'><span style='mso-list:Ignore'>12)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Implementation Date. We suggest that March 2014 be the date when all certs are required to hit a log server. This will give CAs time to adapt, implement CT, and notify customers of the change. We suggest the same date be used for all certificate types. We do not thing CAs should be required to include the proof in the certificate at that time. Instead, that date should be later to ensure a smooth transition of certificates and encourage the spread of operational log servers. Because of the development time involved and encourage proofs through OCSP stapling, we propose March 2016 as the date when CT become mandatory for every certificate. OCSP stapled proofs are more elegant than embedding the proof, but we need time to promote OCSP stapling and encourage adoption.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Cambria","serif"'><span style='mso-list:Ignore'>13)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Other Technology. We agree with Rick that CAA (if implemented correctly) is a good bootstrap. However, CT and CAA are not mutually exclusive. CAA adds security the same way requiring OV certificates adds security. CAA records add an additional step that ensure the CA know the certificate is authorized, which is already part of the OV process. Although neither remediate certificate issuance in the event of a compromise both OV and CAA are great preventative measures. Therefore, we agree that the CAB Forum should continue discussing preventative technologies and improvements.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Cambria","serif"'><o:p> </o:p></span></p><p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Thank you,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Cambria","serif"'><o:p> </o:p></span></p><p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Cambria","serif"'>Jeremy<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><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";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Erwann Abalea<br><b>Sent:</b> Thursday, November 07, 2013 12:06 PM<br><b>To:</b> public@cabforum.org<br><b>Subject:</b> Re: [cabfpub] Upcoming changes to Google Chrome's certificate handling<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Ryan,<br><br>I share some (if not most) of the concerns clearly detailed by Rick.<br><br>The first proposition (certificate with 3 SCTs) for a certificate to be CT qualified is obviously the best one if we want to see a fast CT adoption, and thus get some quick benefit from CT. But it also is the most scary on CA software. We're currently evaluating how we can modify our software (luckily we have our own) with the lowest security impact, but neither is completely satisfactory:<o:p></o:p></p><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1'>2 certificates with the same serial number under the same CA is absolutely out of question; the issuer+serialNumber unicity is a strong requirement, nobody has ever asked for it to be removed, Mozilla recently has asked CAs to check for this unicity; we have additional security measures to ensure it<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1'>the pre-cert produced under a sub-CA may be a solution, but it requires that the issuing CA is not constrained with a pathLenConstraint=0 (unless you allow for a "nearly-sub-CA"), and this constraint is also a protection for us (that way, an online CA can't be asked to produce a CA cert)<o:p></o:p></li></ul><p class=MsoNormal><br>The second proposition (SCT in stapled OCSP response) allows for a shared responsibility between CAs and webservers, so while the impact on CA software is lower (some work effort is to be done on OCSP responders, fresh SCTs need to be regularly fetched), the adoption might be lower due to need for server support. Hopefully OCSPStapling is technically there, just not deployed.<br><br>The third proposition (SCT in TLS extension) won't be seen soon.<br><br>CT is a good idea. We don't have the same concerns about privacy (or haven't encountered the need for it) as Symantec, so being transparent and having some giant audit log is positive. It's not technically finished, some details need more work; the responsibilities/audit part hasn't been addressed at all.<br><br>As Rick wrote it, I think CT is not yet ready to be mandated.<br><br><br><o:p></o:p></p><pre>-- <o:p></o:p></pre><pre>Erwann ABALEA<o:p></o:p></pre><pre><o:p> </o:p></pre><p class=MsoNormal>Le 24/09/2013 12:50, Ryan Sleevi a écrit :<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p>Indeed, as we finalize dates and implementation, a corresponding policy update will follow.<o:p></o:p></p><p>At this time, we're soliciting feedback on the plans regarding Certificate Transparency, and wanted to provide broad notice to interested parties - in addition to individual efforts to reach out to CAs that are EV enabled within Google Chrome.<o:p></o:p></p><p>Cheers,<br>Ryan<o:p></o:p></p><div><p class=MsoNormal>On Sep 24, 2013 3:42 AM, "Rick Andrews" <<a href="mailto:Rick_Andrews@symantec.com">Rick_Andrews@symantec.com</a>> wrote:<o:p></o:p></p><p class=MsoNormal>Ryan,<br><br>Since not all CAs are members of the CA/Browser Forum, will you be publishing this to a Chrome policy web site? I see <a href="https://sites.google.com/a/chromium.org/dev/Home/chromium-security/root-ca-policy" target="_blank">https://sites.google.com/a/chromium.org/dev/Home/chromium-security/root-ca-policy</a>; I presume that's your policy page?<br><br>-Rick<br><br>> -----Original Message-----<br>> From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>]<br>> On Behalf Of Ryan Sleevi<br>> Sent: Tuesday, September 24, 2013 3:09 AM<br>> To: CABFPub<br>> Subject: [cabfpub] Upcoming changes to Google Chrome's certificate<br>> handling<br>><br>> I'm writing this message to provide notice to members of the<br>> CA/Browser Forum about exciting changes we have planned for future<br>> releases of Google Chrome and Google Chrome OS, in addition to the<br>> Chromium projects these products are based upon, in the hope of<br>> minimizing any surprises or inconvenience these may cause.<br>><br>> We look forward to continuing to work with members of the CA/Browser<br>> Forum to improve online security, and welcome feedback regarding these<br>> plans.<br>><br>> Regards,<br>> Ryan Sleevi, Chris Palmer, Adam Langley, and Ben Laurie on behalf of<br>> the Google Chrome team<br>><br>><br>> * Changes to Cryptographic Algorithm Minimum Requirements:<br>><br>> As specified in Appendix A of the Baseline Requirements, 31 December<br>> 2013 is the sunset period for the issuance of certificates containing<br>> RSA key sizes less than 2048 bits. Beginning in early 2014, Chrome<br>> will begin warning users who attempt to access sites with certificates<br>> issued by publicly-trusted CAs, that meet the Baseline Requirements'<br>> effective date, and with key sizes smaller than those specified in<br>> Appendix A.<br>><br>> The anticipated logic is as follows:<br>> - The end-entity certificate has a notBefore date after the Effective<br>> Date of 1 July 2012 of the Baseline Requirements<br>> - AND the end-entity certificate has a notAfter date after 31 December<br>> 2013<br>> - AND<br>> - EITHER the end-entity certificate has a key size weaker than those<br>> specified in Appendix A (eg: RSA key that is less than 2048 bits)<br>> - OR an intermediate certificate in the validated chain has a key<br>> size weaker than those specified in Appendix A (eg: an RSA key that is<br>> less than 2048 bits)<br>><br>> While we would like to extend this requirement to also include root<br>> certificates with sizes of less than 2048 bits, unfortunately not all<br>> Root Programs have been updated to remove 1024-bit root certificates.<br>> This exception for root certificates is temporary, and all CAs must<br>> immediately ensure that they are providing appropriately strong root<br>> certificates to Root Programs. Note that future versions of Google<br>> Chrome and Google Chrome OS MAY remove trust for root certificates<br>> with RSA keys less than 2048 bits, independent of platform<br>> configuration, as described at<br>> <a href="http://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-" target="_blank">http://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-</a><br>> Removal-of-Trust<br>> , so this should not be seen as a permanent exception.<br>><br>> While it would be ideal if this caused no issues for users, our<br>> current data suggests the enforcement of minimum key sizes will impact<br>> small percentage of sites - roughly, less than 0.1% of sites surveyed<br>> - due to CAs failing to adopt the technical requirements of the<br>> Baseline Requirements at the effective date. We want to ensure that<br>> CAs are aware of the upcoming changes and working with their customers<br>> to ensure that the CA is capable of passing a Baseline Requirements<br>> audit.<br>><br>> In addition, we anticipate applying these restrictions to so called<br>> 'legacy' certificates at a to-be-determined later date, as part of the<br>> natural sunsetting of weaker key sizes and algorithms. A hard cut date<br>> for such certificates has not yet been determined.<br>><br>> Note that these programmatic checks will also cover the DSA and ECDSA<br>> minimum size requirements, as also specified in Appendix A, but our<br>> data suggests this should cause no disruptions.<br>><br>><br>> * Improving the Security of EV Certificates<br>><br>> All values in [] are TBD.<br>><br>> In order to improve the security of Extended Validation (EV)<br>> certificates, Google Chrome intends to require Certificate<br>> Transparency (CT) for all EV certificates issued after [date TBD].<br>><br>> Once we have gained experience with EV certificates we will publish a<br>> plan to bring CT to all certificates.<br>><br>> We are soliciting feedback on the following plan.<br>> - Google is already running a pilot CT log.<br>> - By Dec 2013 Google will deploy three geographically diverse<br>> production CT logs which will accept all certificates issued by CAs<br>> accepted by any major browser (which are [Chrome, Internet Explorer<br>> versions [?], Safari, Firefox and Opera]).<br>> - Google invites other organisations to deploy CT logs in order to<br>> improve robustness.<br>> - On [date TBD] Chrome will begin providing CT status information<br>> through the UI.<br>> - By [date TBD] all EV certificates with validity periods beyond [date<br>> TBD] should be logged in at least [one] qualifying log (see below).<br>> - On [date TBD] Chrome will create a whitelist of valid EV<br>> certificates already issued without an embedded SCT [issued by CAs<br>> participating in CT] from all qualifying logs.<br>> - On [date TBD] Chrome will cease to show the EV indicator for<br>> certificates not in the whitelist and not CT qualified according to<br>> the criteria below.<br>><br>> Qualifying Logs<br>><br>> A log is qualified if its URL, public key and Maximum Merge Delay<br>> (MMD) are known to and accepted by Chrome.<br>><br>> Chrome will accept a log's URL, public and MMD key if<br>> - The log has not been shown to have acted in bad faith.<br>> - The log is run by an entity believed to be capable of keeping the<br>> log up at least [99.9%] of the time.<br>> - The log has an MMD of no more than [24 hours].<br>> - The log conforms to RFC 6962.<br>><br>> Qualifying Certificate<br>><br>> A certificate is CT qualified if the TLS handshake it is presented in<br>> satisfies at least one of<br>> - [Three] or more SCTs from different qualifying logs [or logs that<br>> once were qualifying] [operated by distinct entities] are embedded in<br>> the certificate.<br>> - [One] or more SCTs are embedded in a stapled OCSP response as<br>> specified in RFC 6962.<br>> - [One] or more SCTs are sent via the RFC 6962 TLS extension.<br>><br>> And at least one SCT for the certificate validates and was issued by a<br>> qualifying log.<br>><br>> Timeouts<br>><br>> Chrome will regularly synchronise its list of qualifying logs with<br>> Google's servers. If the last successful synchronisation was more<br>> than [10 weeks] ago, the client will [stop checking CT] and [cease to<br>> show EV indications].<br>><br>> Google will keep an authoritative list of qualifying logs and post<br>> changes to that list on the public CA/B Forum mailing list.<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></div><p class=MsoNormal><br><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Public mailing list<o:p></o:p></pre><pre><a href="mailto:Public@cabforum.org">Public@cabforum.org</a><o:p></o:p></pre><pre><a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></pre></blockquote><p class=MsoNormal><o:p> </o:p></p></div></body></html>