On Mon, Mar 30, 2020 at 10:59:02AM -0400, Ryan Sleevi wrote: > On Mon, Mar 30, 2020 at 6:28 AM Matt Palmer via dev-security-policy > <[email protected]> wrote:
> It's useful to focus on the goal, rather than the precise language, or > where you see folks getting confused or misunderstanding things. That > is, making sure we have a common understanding of the problems here. Righto, the goals are: * Make it a policy violation for CAs to issue a certificate using a public key they've revoked before. * Clarify the language around key compromise revocation to make it obvious that CAs have to revoke everything with a given private key. * Clarify the language around revocation time limits to make it obvious that the time period starts when the communication leaves the reporter. > > Step 1: add a new section 4.2.3 (pushing down the existing 4.2.3 to be > > 4.2.4, because RFC3647 says that "Finally, this subcomponent sets a time > > limit", which I assume means that the time limit section needs to be last), > > worded something like this: > > Well, no, that doesn't work with https://tools.ietf.org/html/rfc3647#section-6 Drat. Makes it hard to fit key checks into there anywhere, then. Shoehorn it into 4.2.2, perhaps? > > I know that Section 5.5.2 only requires storage of records for seven years; > > I figure if someone's going to hold onto a compromised private key for seven > > years just so they can bring it out for another cert, then they've earned > > the right to get their cert revoked again. Requiring CAs to maintain a list > > of keys in perpetuity may be considered an overly onerous burden. > > I don't think we want the explicit dependency on 5.5.2, because it > would be good to reduce that time in line with reducing certificate > lifetimes. > > The 7 years is derived from the validity period of the certificates > being issued (at the time, up to 10 year certs; 7 years was a > compromise between the 5 years the BRs were phasing in and the 10y+ > existing practice) Huh, that's interesting; I figured the 7 year requirement was in line with other standard business record-keeping requirements, like tax records. > By this logic, Debian weak keys would not need to be blocked, because > that even occurred in 2006. Hmm, no, unless the CA had previously issued a certificate for every Debian weak key and subsequently revoked them for key compromise. The existing provisions regarding Debian weak keys (as potentially to-be-amended in the near future) would still be in force, with no expiry time limit. I, personally, do not have a problem with mandating that CAs keep records of compromised keys in perpetuity. > Broadly, it seems your problem that this first proposal is trying to > solve is that CAs don't see it as logical that they must maintain a > database of revoked keys. Is that a fair statement? Close, but I'll quibble with "logical", and I dislike talking about "revoked keys" because it gives people the wrong mental shorthand -- you can't "revoke" a key, as such. Although I suppose published attestations of compromise are pretty close to a kind of OKSP, if you wanted to think that way. I'd rather word it as: "CAs don't see it as necessary that they must maintain a database of keys from *all* certificates they revoked for key compromise, and that they must check that database before issuance." > > Step 2: Replace the existing text of section 4.9.12 with something like the > > following: > > > > > In the event that the CA obtains evidence of Key Compromise, all > > > Certificates issued by the CA which contain the compromised key MUST be > > > revoked as per the requirements of Section 4.9.1.1, including the time > > > period requirements therein, even if no Certificate Problem Report for a > > > given Certificate has been received by the CA. > > > > In a perfect world, this sentence wouldn't be necessary, because 4.9.1.1 > > doesn't say that the certificate has to be revoked if a problem report comes > > in alleging key compromise, but since CAs don't appear to have interpreted > > 4.9.1.1 in that way, we may as well use 4.9.12 for a good purpose and > > clarify the situation. > > While I appreciate the suggestion, I'm worried this does more to sow > confusion rather than bring clarity. As you note, 4.9.1.1 is liked to > evidence about the Private Key, not the Certificate, so this is > already a "clear" requirement. What about it sows (additional) confusion? > I think we'd want to understand why/how CAs are misinterpreting this. > I think we've seen a common thread, which is CAs thinking about > systems in terms of Certificates, rather than thinking about Keys and > Issuers. We've seen that problem systemically come up in other areas, > such as OCSP, Precertificates, and SHA-1. > > Does that seem to track with the root cause of the problem? That is, > that this is an existing requirement, but CAs aren't recognizing it as > such? Yes, I certainly believe that you and I are in agreement that this is an existing requirement. However, CA interpretations appear to diverge from ours, and the easiest way to re-align CA interpretations would seem to be to add more words to the BRs. > > Step 3: Insert a new paragraph at the end of section 4.9.1.1, with the > > following contents (or a reasonable facsimile thereof): > > This isn't where the suggested requirements go. That's covered in 4.9.5 I'm not sure what you mean by this. Could you expand a little? > Did I miss reports where this seemed to be an issue? I didn't really > see this one coming up, since 4.9.5 tried to make it pretty clear. > Please feel free to highlight the incidents though, I'm happy to take > a second look. Jeremy Rowley, in https://groups.google.com/d/msg/mozilla.dev.security.policy/gpSw0tqfHYk/BpTNo8uuAwAJ, said: "I'm wondering when we obtained the private key for the 24 hour purposes." That, to me, seems pretty clear that Digicert, at least, isn't clear on the starting time for the 24 hour time limit. The timestamp in the OCSP/CRL for Digicert's mass-revocation is also (for all the certificates I audited) outside the 24 hour period from the time at which the CPR was received by Digicert's MTA. I did (attempt to) report that, however it was rejected by the list manager for being too big (I attached screenshots) and by the time it was bounced back to me, enough related discussion had ensued on the "failure to revoke certificate with previously compromised key" topic around revocation timelines that I thought it somewhat superfluous to make a separate report. I haven't comprehensively checked the revocations for other CAs for similar discrepancies, simply because as CA-provided data, I don't trust it (sorry, CAs, but I lean heavily on the "verify" part of "trust, but verify"). Before I do another round of revocation notifications, I intend to build a system which will "ping" OCSP responders looking for when a revocation is published, at which point there will probably be a flurry of 4.9.5 violation reports (time from receipt to publication), along with (potentially) 4.9.1.1 violation reports (revocation timestamp greater than 24 hours from report time). - Matt _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
