Our discussion of this proposal at the F2F uncovered two issues: 1. A minor update to section 4.9.5 clarifying that the report the CA must produce within 24 hours of receiving a problem report is meant to be a report on the current status of their investigation. This is now described as a "preliminary report". [1] 2. A long discussion [2] about removing revocation reason 4.9.1.1(4): The CA obtains evidence that the Certificate was misused; The scope of this change (including Geoff's observation about the definition of key compromise and the desire to allow use/misuse to be defined in accordance with RFC 3647) is big enough that I've decided to leave those changes for a separate ballot (that I will propose unless someone else beats me to it).
Are two members willing to endorse the current ballot proposal [3]? I will convert this to a formal ballot and begin the discussion period after the July 2nd governance change. Thanks, Wayne [1] https://github.com/wthayer/documents/commit/0a214f0bb5a09db4d12e2dc6f19463dcdef6c82a [2] https://cabforum.org/pipermail/public/2018-June/013547.html [3] https://github.com/cabforum/documents/compare/master...wthayer:patch-1 On Thu, May 17, 2018 at 1:17 AM Kirk Hall <[email protected]> wrote: > I will add this to the Agenda for the F2F plenary session in London > > > > *From:* Public [mailto:[email protected]] *On Behalf Of *Wayne > Thayer via Public > *Sent:* Wednesday, May 16, 2018 1:00 PM > *To:* CA/Browser Forum Public Discussion List <[email protected]> > *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 > > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
