[cabfpub] [EXTERNAL] Reviving Ballot 213 - Revocation Timeline Extension

[Kirk Hall]

I will add this to the Agenda for the F2F plenary session in London

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer via Public
Sent: Wednesday, May 16, 2018 1:00 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: [EXTERNAL][cabfpub] Reviving Ballot 213 - Revocation Timeline Extension

Lat year, Jeremy proposed changes to section 4.9 of the BRs. I'd like to revive that discussion with the following ballot proposal: https://github.com/cabforum/documents/compare/master...wthayer:patch-1

Summary of Changes:
* The first change 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. This was the original motivation for the ballot, due in part to last year's wave of misissued certs identified by linting tools.

* A new critical (24 hour) "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": "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."

* Reason #10 states "The CA determines that any of the information appearing in the Certificate is inaccurate or misleading;" 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. [1]

* 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.

* It requires CAs to disclose their problem reporting mechanisms in a standard location: CPS section 1.5.2.

* 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.

This proposal has already been the subject of some debate on GitHub [2]. I encourage you to review that and last year's discussions [3][4][5] on this list.

I would appreciate your review and feedback on this proposal.

I think this is a good topic for the London meeting - Kirk, can we reserve a slot during the plenary session?

Thanks,

Wayne

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/NjMmyA6MxN0/Kj9T8WQ1CQAJ
[2] https://github.com/wthayer/documents/pull/1#discussion_r185324648
[3] https://cabforum.org/pipermail/public/2017-August/thread.html#11880
[4]https://cabforum.org/pipermail/public/2017-September/thread.html#11880
[5]https://cabforum.org/pipermail/public/2017-October/thread.html#12290

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180517/0f9eb1bf/attachment-0001.html>