[cabfpub] Ballot 213 - Revocation Timeline Extension

[Kirk Hall]

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]
Sent: Wednesday, September 13, 2017 1:18 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org<mailto: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<mailto: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 :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171011/6fce9dd3/attachment-0003.html>