On Mon, Mar 30, 2020 at 5:32 PM Matt Palmer via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > 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.
I've attempted the first two points with https://github.com/sleevi/cabforum-docs/pull/12 . You can seem some of the discussion at https://github.com/sleevi/cabforum-docs/pull/12/files#r401919547 and https://github.com/sleevi/cabforum-docs/pull/12/files#diff-7f6d14a20e7f3beb696b45e1bf8196f2R1425 > I, personally, do not have a problem with mandating that CAs keep records of > compromised keys in perpetuity. I've not yet addressed this part in the above PR, because I think there's still work to sort out the objectives and goals. We've seen some CAs express concerns (not unreasonably) at the potential of an unbounded growth of key sizes creating a disproportionate load on CAs. I think more napkin math is needed here in terms of load and lookups. It's not as easy as saying "use a bloom filter" if a bloom filter takes X amount of time to generate. I'd love to see more thoughts in this space before trying to nail down the precise language here, although I do agree with the spirit here of being something that 'seems' like it should be indefinitely maintainable. That said, there are obvious edge cases to think through, such as: - If CA Foo purchases CA Bar, what happens with Foo's database of compromised keys? - Scenarios: Foo ends up using Bar's database (Foo is transitioned to Bar's infrastructure), Bar ends up using Foo's database (Bar is 'reverse-transitioned' onto Foo's infrastructure), the database becomes Foo+Bar, etc - What happens if Foo's the crappy CA and their database doesn't record enough info for Bar to be able to reliably/safely implement? > > 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? Every time we've seen an existing requirement stated in two places, CAs have tried to argue they're disjoint requirements OR they become disjoint requirements through a lack of consistent updating. If a CA can't read 4.9.1.1 and reach the conclusion, I've got worries, but if a CA has reached that, they should be offering suggestions here as to why. > > 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. Unfortunately, I think that's where we might disagree. More words often creates more opportunity here for getting creative, so I want to figure out how to tighten up or entirely reframe requirements, rather than merely state them multiple times in slightly-different ways that might be seen as offering slightly different requirements. In short, I'd like to avoid the CA-equivalent of the Genesis creation narrative debate :) > > > > 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? Yeah, 4.9.5 is the "Time within which CA must process the revocation request" - that's where requirements for timeliness go. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
