[cabfpub] Ballot 213 - Revocation Timeline Extension

Ryan Sleevi sleevi at google.com
Wed Oct 11 16:20:11 UTC 2017


Hi Kirk,

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.

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.

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?

On Wed, Oct 11, 2017 at 11:37 AM, Kirk Hall via Public <public at cabforum.org>
wrote:

> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> Here are the relevant portions of BR WebTrust on this issue – very
> extensive:
>
>
>
> *Principle 2: SSL Service Integrity *
>
>
>
> The Certification Authority (CA) maintains effective controls to provide
> reasonable assurance that:
>
> ·       Subscriber information was properly collected, authenticated (for
> the registration activities performed by the CA, Registration Authority
> (RA) and subcontractor) and verified;
>
> ·       The integrity of keys and certificates it manages is established
> and protected throughout their life cycles.
>
>
>
> *CERTIFICATE REVOCATION AND STATUS CHECKING *
>
>
>
> BRWT Sec. 5.1 (BR 4.9.3)
>
> The CA maintains controls to provide reasonable assurance that a process 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.
>
>
>
> BRWT Sec. 5.2 (BR 4.9.3, 4.9.5, 4.10.2)
>
> The CA maintains controls to provide reasonable assurance that it:
>
> ·       has the capability to accept and acknowledge Certificate Problem
> Reports on a 24x7 basis;
>
> ·       identifies high priority Certificate Problem Reports;
>
> ·       begin investigation of Certificate Problem Reports within 24
> hours:
>
> ·       decides whether revocation or other appropriate action is
> warranted; and
>
> ·       where appropriate, forwards such complaints to law enforcement.
>
>
>
>
>
> BRWT Sec. 5.3 (BR 4.9.1.2, 6.1.5, 6.1.6)
>
> The CA maintains controls to provide reasonable assurance that Subscriber
> Certificates are revoked within 24 hours if any of the following events
> occurs:
>
> 1. The Subscriber requests in writing that the CA revoke the Certificate;
>
> 2. The Subscriber notifies the CA that the original certificate request
> was not authorized and does not retroactively grant authorization;
>
> 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;
>
> 4. The CA obtains evidence that the Certificate was misused;
>
> 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;
>
> 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);
>
> 7. The CA is made aware that a Wildcard Certificate has been used to
> authenticate a fraudulently misleading subordinate Fully-Qualified Domain
> Name;
>
> 8. The CA is made aware of a material change in the information contained
> in the Certificate;
>
> 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;
>
> 10. The CA determines that any of the information appearing in the
> Certificate is inaccurate or misleading;
>
> 11. The CA ceases operations for any reason and has not made arrangements
> for another CA to provide revocation support for the Certificate;
>
> 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;
>
> 13. The CA is made aware of a possible compromise of the Private Key of
> the Subordinate CA used for issuing the Certificate;
>
> 14. Revocation is required by the CA’s Certificate Policy and/or
> Certification Practice Statement; or
>
> 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).
>
>
>
> BRWT Sec. 5.4 (BR 4.9.1.2, 6.1.5, 6.1.6)
>
> The CA maintains controls to provide reasonable assurance that Subordinate
> CA Certificates are revoked within 7 days if any of the following events
> occurs:
>
> 1. The Subordinate CA requests revocation in writing;
>
> 2. The Subordinate CA notifies the Issuing CA that the original
> certificate request was not authorized and does not retroactively grant
> authorization;
>
> 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,
>
> 4. The Issuing CA obtains evidence that the Certificate was misused;
>
> 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;
>
> 6. The Issuing CA determines that any of the information appearing in the
> Certificate is inaccurate or misleading;
>
> 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;
>
> 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;
>
> 9. Revocation is required by the Issuing CA’s Certificate Policy and/or
> Certification Practice Statement; or
>
> 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.
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] * On Behalf Of *Jeremy
> Rowley via Public
> *Sent:* Wednesday, September 13, 2017 12:58 PM
> *To:* Ryan Sleevi <sleevi at google.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* [EXTERNAL]Re: [cabfpub] Ballot 213 - Revocation Timeline
> Extension
>
>
>
> 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.
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com <sleevi at google.com>]
> *Sent:* Wednesday, September 13, 2017 1:18 PM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [cabfpub] Ballot 213 - Revocation Timeline Extension
>
>
>
>
>
>
>
> On Wed, Sep 13, 2017 at 3:10 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
> wrote:
>
> 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.
>
>
>
> I'm not sure I understand your point about collaborated, but I think you
> may be misunderstanding the goal.
>
>
>
> 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.
>
>
>
> 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 :)
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171011/879db8d8/attachment-0003.html>


More information about the Public mailing list