<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: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
{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;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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'>It all depends on the change. For this particular one, it will require a CA to update its CPS and its Subscriber Agreement. Changes to CPS require Policy approval and Subscriber Agreements touch legal, and web teams, which are change controlled. And if the CA holds multiple brands, the change must be propagated across all. Hence I would prefer a 45 day window for any such change.<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'>Coming up we have the validation ballot which has a date of March 2017, which seems reasonable given the impact of those recommendations. <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 think this type of change could be made without restarting the ballot clock?<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'>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><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'> Ryan Sleevi [mailto:sleevi@google.com] <br><b>Sent:</b> Friday, July 22, 2016 12:02 AM<br><b>To:</b> Dean Coclin <Dean_Coclin@symantec.com><br><b>Cc:</b> Josh Aas <josh@letsencrypt.org>; CABFPub <public@cabforum.org><br><b>Subject:</b> Re: [cabfpub] Ballot 173 - Removal of requirement to cease use of private key due to incorrect certificate info<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p>Dean,<o:p></o:p></p><p>In the past, when CAs have had concerns, there's been a suggestion of a timeframe that might be reasonable to make changes.<o:p></o:p></p><p>Is thirty days sufficient? Why or why not?<o:p></o:p></p><p>When the proposed changes relax, rather than toughen, a requirement, do you share the same concerns?<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Jul 21, 2016 7:32 PM, "Dean Coclin" <<a href="mailto:Dean_Coclin@symantec.com">Dean_Coclin@symantec.com</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-right:0in'><p class=MsoNormal style='margin-bottom:12.0pt'>Josh,<br><br>This is not a criticism of this specific ballot; I have no comment on its merit. However, in reviewing several recent ballots, I think it's problematic to have a ballot state that it is effective as of the date of passage.<br><br>If a CA has to make technical or policy changes, it's going to take some time to do so. If the ballot takes effect on the day of passage, then the CA has to make immediate changes, lest they be technically out of compliance as of that day.<br><br>For example, this ballot will require CAs to make CPS changes. How are they supposed to do this in one day? Am I reading this correctly?<br><br>Thanks,<br>Dean<br><br><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>] On Behalf Of Josh Aas<br>Sent: Thursday, July 14, 2016 10:18 AM<br>To: CABFPub <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>Subject: [cabfpub] Ballot 173 - Removal of requirement to cease use of private key due to incorrect certificate info<br><br>Ballot 173 - Removal of requirement to cease use of private key due to incorrect certificate info<br><br>The following motion has been proposed by Josh Aas of ISRG / Let's Encrypt. Ben Wilson of Digicert and Chris Bailey of Entrust endorse.<br><br>Background:<br><br>BR Section 9.6.3 point 5 says:<br><br>"Reporting and Revocation: An obligation and warranty to promptly cease using a Certificate and its associated Private Key, and promptly request the CA to revoke the Certificate, in the event that: (a) any information in the Certificate is, or becomes, incorrect or inaccurate, or (b) there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate;"<br><br>There is a problem here, which is that this requires a subscriber to stop using a private key just because information in a certificate is inaccurate or incorrect. People should stop using a cert with inaccurate or incorrect information, but they shouldn't be required to stop using a key pair unless there is known or suspected compromise.<br><br>This is particularly problematic for HPKP.<br><br>--Motion Begins--<br><br>Effective upon the date of passage, the following modifications are made to the Baseline Requirements:<br><br>Change the following text in Section 9.6.3:<br>=======================<br>Reporting and Revocation: An obligation and warranty to promptly cease using a Certificate and its associated Private Key, and promptly request the CA to revoke the Certificate, in the event that: (a) any information in the Certificate is, or becomes, incorrect or inaccurate, or (b) there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate; =======================<br><br>To:<br>=======================<br>Reporting and Revocation: An obligation and warranty to: (a) promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate; and (b) promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate.<br>=======================<br><br>--Motion Ends--<br><br>The review period for this ballot shall commence at 2200 UTC on 14 July 2016, and will close at 2200 UTC on 21 July 2016. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on 28 July 2016. Votes must be cast by posting an on-list reply to this thread.<br><br>A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response.<br>Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here:<br><a href="https://cabforum.org/members/" target="_blank">https://cabforum.org/members/</a><br><br>In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently ten (10) members– at least ten members must participate in the ballot, either by voting in favor, voting against, or abstaining.<br><br>--<br>Josh Aas<br>Executive Director<br>Internet Security Research Group<br>Let's Encrypt: A Free, Automated, and Open CA _______________________________________________<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><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></div></div></body></html>