On Mon, Apr 06, 2020 at 12:56:02PM -0400, Ryan Sleevi wrote: > 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
Thanks, I've made a comment on part of that change. > > 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. Well, I can say that indexing 1.3M private keys, at least, isn't a particular challenge, even comparing that against the entire corpus of known certificates. I don't know how many private keys CAs' customers are planning on dumping onto the public Internet, though... > It's not as easy as saying "use a bloom filter" if a bloom filter > takes X amount of time to generate. A bloom filter could potentially be a *part* of an approach, but it certainly can't be the entire solution (for a great many reasons). As an aside, if anyone wants to try out a bloom filter, I've generated one containing all the Debian weak keys I've generated so far: https://assets.pwnedkeys.com/public/debian-weak-keys.pkf (file format documented at https://pwnedkeys.com/filter.html). > > > 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. Yes, well, I suppose we should ask the CAs that have come to that conclusion as to how they managed that. I'm not hopeful, however; whenever I've asked questions about how a CA came to a particular conclusion, the best I've gotten back is "lol we dunno". The most common response is radio silence. > 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 :) I see your point. > > > > 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. Hmm, I think the cat's nose is poking out of the bag on that one, because of all the mentions of timeframes for different sorts of revocation already in 4.9.1.1. I don't have a problem with a clarification of exactly what "receipt" means into 4.9.5, though, if it works better there. The important thing is that there *is* a clear definition of such things, because there are CAs who aren't clear on what that means. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
