<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:11.0pt;
        font-family:"Calibri",sans-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.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;}
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:11.0pt;
        font-family:"Calibri",sans-serif;}
p.m-4014283919440558571msolistparagraph, li.m-4014283919440558571msolistparagraph, div.m-4014283919440558571msolistparagraph
        {mso-style-name:m_-4014283919440558571msolistparagraph;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.m-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-m6478909562512572563gmail-il
        {mso-style-name:m_-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-m6478909562512572563gmail-il;}
span.m-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-il
        {mso-style-name:m_-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-il;}
span.m-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-m6478909562512572563gmail-m-4515304547181379193gmail-blob-code-inner
        {mso-style-name:m_-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-m6478909562512572563gmail-m-4515304547181379193gmail-blob-code-inner;}
span.m-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-m6478909562512572563gmail-m-4515304547181379193gmail-x
        {mso-style-name:m_-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-m6478909562512572563gmail-m-4515304547181379193gmail-x;}
span.EmailStyle23
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.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;}
/* List Definitions */
@list l0
        {mso-list-id:787044141;
        mso-list-template-ids:1051890488;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0: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 l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1
        {mso-list-id:1819758424;
        mso-list-type:hybrid;
        mso-list-template-ids:-458177982 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
        {mso-level-text:"%1\)";
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level3
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l1:level4
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level5
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level6
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l1:level7
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level8
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1:level9
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
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 lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>I’m surprised no one has given any examples yet. There are a lot of them if you go through the revocation requests:<o:p></o:p></p><ol style='margin-top:0in' start=1 type=1><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo2'>Certs reported on a long weekend where we can’t reach anyone at the organization. You’re looking at 4 days there in the US sometimes. Outside of the US there can be up to a week or so where response are difficult (especially in Europe and China)<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo2'>See the Blizzard cert that we had to revoke. (Although this mixes investigation with revocation timelines)<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo2'>Sometimes we get requests for revocation through third parties alleging key compromise without proof. Takes a while for them to generate a CSR and send it over.<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo2'>Emails about cert misuse on sites that contain wares or similar items can take 7 days to figure out whether it is indeed  phishing or something similar. <o:p></o:p></li></ol><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’d have to dig out the exact emails on each off these to send over, but 7 days for investigation is pretty short unless we get a copy of the private key in the first go-around from the reporting entity. <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>From:</b> Public <public-bounces@cabforum.org> <b>On Behalf Of </b>Ryan Sleevi via Public<br><b>Sent:</b> Tuesday, August 21, 2018 11:08 AM<br><b>To:</b> Bruce Morton <Bruce.Morton@entrustdatacard.com>; servercert-wg@cabforum.org<br><b>Cc:</b> CABFPub <public@cabforum.org><br><b>Subject:</b> Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><p class=MsoNormal>On Tue, Aug 21, 2018 at 1:01 PM Bruce Morton via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='color:#1F497D'>Per Mike’s items:</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=m-4014283919440558571msolistparagraph><span lang=EN-CA style='color:#1F497D'>1.</span><span lang=EN-CA style='font-size:7.0pt;font-family:"Times New Roman",serif;color:#1F497D'>      </span><span lang=EN-CA style='color:#1F497D'>7 days would be preferable as this would provide a “business week” for the CA to investigate the issue. It will also provide 2 extra days to have reach and discuss the issue with the Reporter and the Subscriber.</span><span lang=EN-CA><o:p></o:p></span></p></div></div></blockquote><div><p class=MsoNormal>As Mike summarized correctly, Google felt and feels that 7 days is too long. We repeatedly asked for specific examples and details of where the additional time would be valuable, and to date, no CA has provided them. We had previously proposed that anything longer should require a mandatory public, unredacted incident report from the CA, and the concession to avoid such a requirement was to find a balance, while also ensuring that CAs were gathering and collecting concrete reports to provide that.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=m-4014283919440558571msolistparagraph><span lang=EN-CA style='color:#1F497D'>2.</span><span lang=EN-CA style='font-size:7.0pt;font-family:"Times New Roman",serif;color:#1F497D'>      </span><span lang=EN-CA style='color:#1F497D'>Given the examples for unacceptable risk, I would assume that this item would have a deadline set in the BRs. We have done this before with non-registered domain name certificates. So if the certificate has not been revoked by the deadline, then it must be revoked immediately. As such, perhaps this requirement should be better defined and also moved to the 24 hour section.</span><span lang=EN-CA><o:p></o:p></span></p><p class=m-4014283919440558571msolistparagraph><span lang=EN-CA style='color:#1F497D'>3.</span><span lang=EN-CA style='font-size:7.0pt;font-family:"Times New Roman",serif;color:#1F497D'>      </span><span lang=EN-CA style='color:#1F497D'>I do agree that the CA should work with both the Reporter and the Subscriber; however, please note that the investigation may mean that the certificate will not be revoked. Also, having a preliminary report within 24 hours may not be feasible to have a report with substantial substance as there may not be time to discuss with the Subscriber. I do suggest that within 24 hours the CA should advise the Reporter and the Subscriber that an investigation has started which may result in the certificate being revoked.</span><span lang=EN-CA><o:p></o:p></span></p></div></div></blockquote><div><p class=MsoNormal>I don't think this is something we'd agree on. As noted above, our goal is to improve the transparency. There are some who've said that the best solution to these issues is to know what it's like by going to work for a CA. Absent changing employers, the next best thing is going to be to improve the transparency of the ecosystem, which will improve the trust overall. CAs are already required to conduct their activities within 24 hours - this doesn't relax that particular item, but allows them to make it available as a report, while offering greater flexibility. That seems a meaningful compromise to balance the need for transparency while providing CAs and Subscribers some degree of flexibility.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='color:#1F497D'>Thanks, Bruce.</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA style='color:#1F497D'> </span><span lang=EN-CA><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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Servercert-wg [mailto:<a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank">servercert-wg-bounces@cabforum.org</a>] <b>On Behalf Of </b>Mike Reilly (GRC) via Servercert-wg<br><b>Sent:</b> August 21, 2018 12:17 PM<br><b>To:</b> Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>>; Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>>; Wayne Thayer <<a href="mailto:wthayer@mozilla.com" target="_blank">wthayer@mozilla.com</a>><br><b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Subject:</b> [EXTERNAL]Re: [Servercert-wg] [cabfpub] Ballot SC6 - Revocation Timeline Extension<span lang=EN-CA><o:p></o:p></span></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-CA> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi all.  Some areas of clarification requested from the Microsoft team:<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>I don’t remember why 5 days was chosen vs. 7 or 3 days.  I believe it was we felt 7 days was too long but 5 days was reasonable.  I believe we also considered the scenario where an incident occurs on a Friday evening of a three day weekend and the difficulty of the CA dealing with a subscriber who may be unavailable over a weekend for a non-urgent revocation requirement.  5 days covered that scenario without being too far past 24 hours.  3 days was felt to be too short and 7 days seemed too long.  Correct?<span lang=EN-CA><o:p></o:p></span></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Regarding point 11. Will this "given period of time" means up to 5 days as well?  Point 11 reads: <i>“The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by <b>CAs within a given period of time</b>)”</i><span lang=EN-CA><o:p></o:p></span></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>There is also a bit of confusion about the following statement as it is still governed by the 5 day requirement so we’re not sure why it’s called out this way.  <i>“Within 24 hours of receiving a problem report, the CA is now required to report back to both the entity reporting the problem and the Subscriber on the CA's findings, and to work with the reporter <b>to establish a date by which the CA will revoke the certificate</b>.”</i>  Should this be clarified to include both the reporter and the Subscriber included in both steps to reduce potential impact to relying parties.  Perhaps add more clarification in this statement: <span lang=EN-CA><o:p></o:p></span></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'>Report back the findings to reporter and the Subscriber within 24 hours<span lang=EN-CA><o:p></o:p></span></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'>Work with the reporter and the Subscriber to revoke within 5 days<span lang=EN-CA><o:p></o:p></span></li></ul></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Thanks, Mike<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank">servercert-wg-bounces@cabforum.org</a>> <b>On Behalf Of </b>Doug Beattie via Servercert-wg<br><b>Sent:</b> Monday, August 20, 2018 1:43 PM<br><b>To:</b> Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>>; Wayne Thayer <<a href="mailto:wthayer@mozilla.com" target="_blank">wthayer@mozilla.com</a>><br><b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Subject:</b> Re: [Servercert-wg] [cabfpub] Ballot SC6 - Revocation Timeline Extension<span lang=EN-CA><o:p></o:p></span></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Tim,</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>I agree that Vulnerability is different from key compromise and the actions we take should reflect that and I think we should try to keep 12 and 13 type events in the 5-day list.</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Is our strategy to have vulnerabilities fall into the 5 day list and exploited vulnerabilities fall into the 24 hour list?</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>Key Compromise:</b> A Private Key is said to be compromised if:<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>1)<span style='font-size:7.0pt;font-family:"Times New Roman",serif'>      </span>its value has been disclosed to an unauthorized person<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>2)<span style='font-size:7.0pt;font-family:"Times New Roman",serif'>      </span>an unauthorized person has had access to the private keys<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>3)<span style='font-size:7.0pt;font-family:"Times New Roman",serif'>      </span>a vulnerability has been exploited to disclose private keys<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>And the remainder of the definition can be removed because those are examples of vulnerabilities being exploited ( Debian weak  and poor key generation).  If we want a list of possible vulnerabilities or bad practices, then we can put in an appendix.<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>I think #13 is a special case of #12 (both vulnerabilities), so I still recommend removing it.  Is the distribution of a private key in in a software package any different than the distribution of a private key in any other (insecure) method?  </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Here’s what I’d recommend:</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>a) Use the new definition I listed above</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>b) change:</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>12. The CA is made aware of a vulnerability that exposes the Subscriber's Private Key to compromise; or</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>to</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>12. The CA is made aware of a vulnerability that has been exploited to disclose the Subscriber's Private Key; or</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>c) Delete #13</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Doug</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank">servercert-wg-bounces@cabforum.org</a>> <b>On Behalf Of </b>Tim Hollebeek via Servercert-wg<br><b>Sent:</b> Monday, August 20, 2018 3:57 PM<br><b>To:</b> Wayne Thayer <<a href="mailto:wthayer@mozilla.com" target="_blank">wthayer@mozilla.com</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br><b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Subject:</b> Re: [Servercert-wg] [cabfpub] Ballot SC6 - Revocation Timeline Extension<span lang=EN-CA><o:p></o:p></span></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Vulnerability is different from key compromise.  Replacing all the heartbleed certificates within 24 hours would have been a huge fire drill.  It’s important to get them replaced as quickly as possible, but mandatory revocations within 24 hours is going to make things worse, not better.<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>There are potential mitigating factors for a vulnerability.  For example, the technical details may not be publicly known yet, or there may be no public exploit available yet.  The vulnerability might not affect all OS versions, might be easily blocked by firewalls, and so on.  The amount of effort necessary to turn a vulnerability into a key compromise can vary from insignificant to “lots and lots”.<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>A compromised key, on the other hand, is clearly compromised.<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-Tim<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank">servercert-wg-bounces@cabforum.org</a>> <b>On Behalf Of </b>Wayne Thayer via Servercert-wg<br><b>Sent:</b> Monday, August 20, 2018 12:52 PM<br><b>To:</b> CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br><b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Subject:</b> Re: [Servercert-wg] [cabfpub] Ballot SC6 - Revocation Timeline Extension<span lang=EN-CA><o:p></o:p></span></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>This has the potential to cause confusion, so I'd like to attempt to fix it. Given that a reasonable interpretation of the existing definition of key compromise encompasses reasons 12 and 13, but I want to leave those two reasons in the document for the sake of clarity as Ryan suggests, maybe I should just move those two up to the 24-hour section? I could also be persuaded that a vulnerability is different than proof of key compromise, in which case 12 could stay in the 5-day section and we could move "or there exists a practical technique by which an unauthorized person may discover its value" from the definition of key compromise to 12. What do others think?<span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>- Wayne<span lang=EN-CA><o:p></o:p></span></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Mon, Aug 20, 2018 at 7:04 AM Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:<span lang=EN-CA><o:p></o:p></span></p></div><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'><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'> <span lang=EN-CA><o:p></o:p></span></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Mon, Aug 20, 2018 at 9:17 AM Doug Beattie via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<span lang=EN-CA><o:p></o:p></span></p></div><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'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>We’re having a hard time determining the differences between the following:</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>The CA SHALL revoke a Certificate within 24 hours if:</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise; or</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>and </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a name="m_-4014283919440558571_m_-36894299260419"><span style='color:#1F497D'> </span></a><span style='mso-bookmark:m_-4014283919440558571_m_-36894299260419'></span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>The CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days if one or more of the following occurs:</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>12. The CA is made aware of a vulnerability that exposes the Subscriber's Private Key to compromise; or</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>13. The CA is made aware that the Subscriber's Private Key is being publicly distributed in a software package.</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>If  </span>“<span style='color:#1F497D'>Subscriber's Private Key is being publicly distributed in a software package”, isn’t that the same as #3: “obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise”?</span> <span lang=EN-CA><o:p></o:p></span></p></div></div></blockquote><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'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>How do you see #12 in reality?  What types of vulnerabilities do you envision that could expose a subscribers Private Key that are not also consistent with #3?</span><span lang=EN-CA><o:p></o:p></span></p></div></div></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>While this is the same argument that I've made in the past, I think the goal here is to reduce ambiguity for those that might take a tortured reading of the text.<span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>For example, at least one vendor 'obfuscated' the private key within their binary, requiring running the embedded private key through a transformation (I hesitate to say decryption, since the passphrase was itself fixed within the binary). Such a vendor might argue that the key has not been compromised until someone reverses the binary. This resolves that ambiguity by saying that the distribution within the binary itself constitutes a compromise, regardless of whether a passphrase is used.<span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p></div><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'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Also, the definition of Private Key Compromise is very broad, and the scenarios in #12 and #13 would appear to fall into “Key Compromise” which further causes confusion about them.  What constitutes a “<b>practical technique</b>”?  If we applied this definition to #12 and #13, wouldn’t these all fall into the 24 hour rule?</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>Key Compromise:</b> A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, an unauthorized person has had access to it, or there exists a practical technique by which an unauthorized person may discover its value.  A Private Key is also considered compromised if methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=02%7C01%7CMike.reilly%40microsoft.com%7Ccc86f18ac7f1436d776808d606dd9e4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636703946261915965&sdata=VTjxlqVQj%2F5CEUKsG10UF2UoC75AtmFi3d51%2Fj9wdZ4%3D&reserved=0" target="_blank">http://wiki.debian.org/SSLkeys</a>) or if there is clear evidence that the specific method used to generate the Private Key was flawed.<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Doug</span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Public <<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>> <b>On Behalf Of </b>Wayne Thayer via Public<br><b>Sent:</b> Monday, August 13, 2018 4:58 PM<br><b>To:</b> CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br><b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Subject:</b> [cabfpub] Ballot SC6 - Revocation Timeline Extension<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>This begins the formal discussion period for ballot SC6.<span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>==========================================<span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span class=m-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-m6478909562512572563gmail-il>Ballot</span> <span class=m-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-il>SC6</span>: Revocation Timeline Extension<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Purpose of <span class=m-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-m6478909562512572563gmail-il>Ballot</span>:<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Section 4.9.1.1 of the Baseline Requirements currently requires CAs to revoke a Subscriber certificate within 24 hours of identifying any of 15 issues affecting the certificate. In cases where there is not an immediate threat of misuse of the certificate, this requirement can cause undue harm to a Subscriber that isn't capable of replacing the certificate prior to revocation. This ballot makes a number of improvements to the revocation rules imposed by the Baseline Requirements:<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>* Primarily, it creates a tiered timeline for revocations. The most critical "reasons" still require revocation within 24 hours, but for many others 24 hours becomes a SHOULD and the CA has 5 days before they MUST revoke.<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>* A new "reason for revocation" was added to address the fact that there is currently no requirement for CAs to revoke a certificate when requested by the domain name registrant. After considering some more specific language that required CAs to follow 3.2.2.4 to validate domain control, I settled on the following more general "reason": "<span class="m-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-m6478909562512572563gmail-m-4515304547181379193gmail-blob-code-inner">The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon</span>."<span lang=EN-CA><o:p></o:p></span></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>* Reason #10 states "<span class="m-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-m6478909562512572563gmail-m-4515304547181379193gmail-blob-code-inner">The CA determines that any of the information appearing in the Certificate is inaccurate</span><span class="m-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-m6478909562512572563gmail-m-4515304547181379193gmail-x"> or misleading</span><span class="m-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-m6478909562512572563gmail-m-4515304547181379193gmail-blob-code-inner">;</span>" This ballot removes "or misleading" because that is a subjective judgement that could effectively be used to justify censorship, as discussed at length in relation to the "Stripe, Inc of Kentucky" EV certificates.<span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>* Current reasons #11 and #13 were removed from the section on subscriber certificates because they address cases where the intermediate and/or root must be revoked, so there isn't much sense (and some possible harm) in requiring revocation of all the leaf certs.<span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>* It requires CAs to disclose their problem reporting mechanisms in a standard location: CPS section 1.5.2.<span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>* Within 24 hours of receiving a problem report, the CA is now required to report back to both the entity reporting the problem and the Subscriber on the CA's findings, and to work with the reporter to establish a date by which the CA will revoke the certificate.<span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The following motion has been proposed by  Wayne Thayer of Mozilla and endorsed by Tim Hollebeek of DigiCert and Dimitris Zacharopoulos of Harica.<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>--- MOTION BEGINS ---<br><br>This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 1.6.0:<br><br>** Modify Section 4.9.1.1 to read as follows: **<br><br>The CA SHALL revoke a Certificate within 24 hours if:<br><br>1. The Subscriber requests in writing that the CA revoke the Certificate;<br>2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization;<br>3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise; or<br>4. The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon.<br><br>The CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days if one or more of the following occurs:<br><br>1. The Certificate no longer complies with the requirements of Sections 6.1.5 and 6.1.6;<br>2. The CA obtains evidence that the Certificate was misused;<br>3. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use;<br>4. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant's right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name);<br>5. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;<br>6. The CA is made aware of a material change in the information contained in the Certificate;<br>7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's Certificate Policy or Certification Practice Statement;<br>8. The CA determines that any of the information appearing in the Certificate is inaccurate;<br>9. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;<br>10. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement;<br>11. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time);<br>12. The CA is made aware of a vulnerability that exposes the Subscriber's Private Key to compromise; or<br>13. The CA is made aware that the Subscriber's Private Key is being publicly distributed in a software package.<br><br>** Modify section 4.9.3 as follows: **<br><br>The CA SHALL provide a process for Subscribers to request revocation of their own Certificates. The process MUST be described in the CA's Certificate Policy or Certification Practice Statement. The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports.<br><br>The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.<br><br>** Modify section 4.9.5 to read as follows: **<br><br>Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report.<br><br>After reviewing the facts and circumstances, the CA SHALL work with any entity reporting the Certificate Problem Report or other revocation-related notice to establish a date when the CA will revoke the Certificate which MUST not exceed the time frame set forth in Section 4.9.1.1. The date selected by the CA SHOULD consider the following criteria:<br><br>1. The nature of the alleged problem (scope, context, severity, magnitude, risk of harm);<br>2. The consequences of revocation (direct and collateral impacts to Subscribers and Relying Parties);<br>3. The number of Certificate Problem Reports received about a particular Certificate or Subscriber;<br>4. The entity making the complaint (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that she didn't receive the goods she ordered); and<br>5. Relevant legislation.<br><br>--- MOTION ENDS ---<br><br>A comparison of the changes can be found at: <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fcompare%2Fmaster...wthayer%3Apatch-1%3Fshort_path%3D7f6d14a%23diff-7f6d14a20e7f3beb696b45e1bf8196f2&data=02%7C01%7CMike.reilly%40microsoft.com%7Ccc86f18ac7f1436d776808d606dd9e4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636703946261925974&sdata=ZF1OJR2W60OJ9%2BA1c4BlDwDEQVzFc3ze2gI87AXrXow%3D&reserved=0" target="_blank">https://github.com/cabforum/documents/compare/master...wthayer:patch-1?short_path=7f6d14a#diff-7f6d14a20e7f3beb696b45e1bf8196f2</a><span lang=EN-CA><o:p></o:p></span></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The procedure for approval of this <span class=m-4014283919440558571m-3689429926041964044m-5768670656815563643gmail-m6478909562512572563gmail-il>ballot</span> is as follows:<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Discussion (7+ days)<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Start Time: 2018-08-13  19:00 UTC<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>End Time: Not before 2018-08-20  19:00 UTC<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Vote for approval (7 days)<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Start Time: TBD<span lang=EN-CA><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>End Time: TBD<span lang=EN-CA><o:p></o:p></span></p></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>_______________________________________________<br>Servercert-wg mailing list<br><a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br><a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=02%7C01%7CMike.reilly%40microsoft.com%7Ccc86f18ac7f1436d776808d606dd9e4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636703946261935982&sdata=o5VhYd5QGEiWefWo1P4jkRtFfioP%2FkeEx2nJYGXLo%2FY%3D&reserved=0" target="_blank">http://cabforum.org/mailman/listinfo/servercert-wg</a><span lang=EN-CA><o:p></o:p></span></p></blockquote></div></div></blockquote></div></div></div></div><p class=MsoNormal>_______________________________________________<br>Servercert-wg mailing list<br><a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br><a href="http://cabforum.org/mailman/listinfo/servercert-wg" target="_blank">http://cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></p></blockquote></div></div></div></body></html>