<div dir="ltr">Hi Kirk,<div><br></div><div>While it's useful you quoted WebTrust, please note that the Forum's Guidelines also serve as input into ETSI, which has its own (separate) reporting requirement.</div><div><br></div><div>Note that the proposal is not that the Forum is enforcement. Merely, it serves as a collective body for transparency around requests. As we can see from members offering both technically and procedurally incorrect understandings of the Baseline Requirements, or in the conflicting responses from auditors, there's significant value in having this common transparency.</div><div><br></div><div>Are you suggesting that Entrust would be opposed to a transparency requirement that would allow the Forum to improve its requirements, and thus vote No?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 11, 2017 at 11:37 AM, Kirk Hall via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-933865628826422529WordSection1">
<p class="MsoNormal">Jeremy, going back to your original proposal – we agree with you that this ballot should focus on improving the requirements re timelines for responding to certificate problem reports and revocation requests (in Ballot 213, allowing more
time for investigation of non-critical requests), and that the ballot should not create any new public reporting requirements.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Our auditors already test us for compliance with BR 4.9.1, 4.9.3, and 4.9.5, including timeliness of our responses to certificate problem reports and revocation requests. See quoted material from BR WebTrust audit criteria below. We don’t
see any value in having CAs also post some sort of reports to the Forum (the Forum is not an enforcement agency) or even to the browser root programs, for that matter, if they face delays in completing the response process for some reason (e.g., slowness by
the certificate holder in responding with necessary information, etc.). So we don’t favor including new reporting language in Ballot 213.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Of course, if CAs are encountering problems in completing revocation request responses within the new timelines, they can bring information forward to the Forum with suggestions for changes in the BRs if appropriate, just as Jeremy has
done with this Ballot.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Here are the relevant portions of BR WebTrust on this issue – very extensive:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="text-autospace:none"><b>Principle 2: SSL Service Integrity
<u></u><u></u></b></p>
<p class="MsoNormal" style="text-autospace:none"><b><u></u> <u></u></b></p>
<p class="MsoNormal" style="text-autospace:none">The Certification Authority (CA) maintains effective controls to provide reasonable assurance that:
<u></u><u></u></p>
<p class="m_-933865628826422529MsoListParagraph" style="margin-bottom:1.5pt;text-autospace:none">
<u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u>Subscriber information was properly collected, authenticated (for the registration activities performed by the CA, Registration Authority (RA) and subcontractor) and verified;
<u></u><u></u></p>
<p class="m_-933865628826422529MsoListParagraph" style="text-autospace:none">
<u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u>The integrity of keys and certificates it manages is established and protected throughout their life cycles.
<u></u><u></u></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt;color:windowtext"><u></u> <u></u></span></p>
<p class="m_-933865628826422529Default"><b><span style="font-size:11.0pt;color:windowtext">CERTIFICATE REVOCATION AND STATUS CHECKING
<u></u><u></u></span></b></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt;color:windowtext"><u></u> <u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt;color:windowtext">BRWT Sec. 5.1 (BR 4.9.3)<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt;color:windowtext">The CA maintains controls to provide reasonable assurance that a process
</span><span style="font-size:11.0pt">is available 24x7 that the CA is able to accept and respond to revocation requests and related inquiries, and that the CA provides a process for Subscribers to request revocation of their own certificates.
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">BRWT Sec. 5.2 (BR 4.9.3, 4.9.5, 4.10.2)<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">The CA maintains controls to provide reasonable assurance that it:
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default" style="margin-left:.5in">
<u></u><span style="font-size:11.0pt;font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt">has the capability to accept and acknowledge Certificate Problem Reports on a 24x7 basis;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default" style="margin-left:.5in">
<u></u><span style="font-size:11.0pt;font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt">identifies high priority Certificate Problem Reports;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default" style="margin-left:.5in">
<u></u><span style="font-size:11.0pt;font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt">begin investigation of Certificate Problem Reports within 24 hours:
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default" style="margin-left:.5in">
<u></u><span style="font-size:11.0pt;font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt">decides whether revocation or other appropriate action is warranted; and
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default" style="margin-left:.5in">
<u></u><span style="font-size:11.0pt;font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt">where appropriate, forwards such complaints to law enforcement.
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">BRWT Sec. 5.3 (BR 4.9.1.2, 6.1.5, 6.1.6)<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">The CA maintains controls to provide reasonable assurance that Subscriber Certificates are revoked within 24 hours if any of the following events occurs:
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">1. The Subscriber requests in writing that the CA revoke the Certificate;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">3. The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of SSL Baseline Requirements
Sections 6.1.5 and 6.1.6; <u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">4. The CA obtains evidence that the Certificate was misused;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">5. 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;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">6. 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);
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">7. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">8. The CA is made aware of a material change in the information contained in the Certificate;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">9. 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;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">11. The CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">12. 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;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">13. The CA is made aware of a possible compromise of the Private Key of the Subordinate CA used for issuing the Certificate;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">15. 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).
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">BRWT Sec. 5.4 (BR 4.9.1.2, 6.1.5, 6.1.6)<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">The CA maintains controls to provide reasonable assurance that Subordinate CA Certificates are revoked within 7 days if any of the following events occurs:
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">1. The Subordinate CA requests revocation in writing;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">2. The Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">3. The Issuing CA obtains evidence that the Subordinate CA’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of SSL Baseline
Requirements Sections 6.1.5 and 6.1.6, <u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">4. The Issuing CA obtains evidence that the Certificate was misused;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">5. The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with these Baseline Requirements or the applicable Certificate Policy or Certification
Practice Statement; <u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">6. The Issuing CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">7. The Issuing CA or Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">8. The Issuing CA’s or Subordinate CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the Issuing CA has made arrangements to continue maintaining the CRL/OCSP
Repository; <u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">9. Revocation is required by the Issuing CA’s Certificate Policy and/or Certification Practice Statement; or
<u></u><u></u></span></p>
<p class="m_-933865628826422529Default"><span style="font-size:11.0pt">10. 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. <u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Public [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@<wbr>cabforum.org</a>] <b>
On Behalf Of </b>Jeremy Rowley via Public<br>
<b>Sent:</b> Wednesday, September 13, 2017 12:58 PM<br>
<b>To:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.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: [cabfpub] Ballot 213 - Revocation Timeline Extension<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I understand what you are saying, but revocation timelines seems like a different topic than challenges facing the space. There should be a mailing list for challenges, but I don’t think it should be tied to changing the revocation timelines
already in the BRs.<u></u><u></u></p>
<p class="MsoNormal"><a name="m_-933865628826422529__MailEndCompose"><u></u> <u></u></a></p>
<p class="MsoNormal"><b>From:</b> Ryan Sleevi [<a href="mailto:sleevi@google.com" target="_blank">mailto:sleevi@google.com</a>]
<br>
<b>Sent:</b> Wednesday, September 13, 2017 1:18 PM<br>
<b>To:</b> Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.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: [cabfpub] Ballot 213 - Revocation Timeline Extension<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Wed, Sep 13, 2017 at 3:10 PM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Sure, but I plan on uploading all these to the Mozilla dev list. Emailing the CAB Forum as well seems like duplicative effort, especially since the emails aren’t going to be readily
collaborated. If the CABForum is going to collect the problem reports, some format other than email would be much better for data collection.<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm not sure I understand your point about collaborated, but I think you may be misunderstanding the goal.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I appreciate the desire for transparency and engagement with the community, and I hope all CAs aspire to that level. However, I think the goal here is minimally to ensure public visibility, in a self-managed form (that is, I have difficulty
imagining the CABF requiring an MDSP posting). I think going above and beyond is good, but i think we should set minimum reasonable requirements.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">As I noted, I'm not wedded to the idea of public@, but I think there should be a CABF-managed, publicly-visible list for discussion about the challenges here in this space :) <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
<br>______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
<br></blockquote></div><br></div>