Thanks for starting this! On Mon, Mar 30, 2020 at 6:28 AM Matt Palmer via dev-security-policy <[email protected]> wrote: > If such a modification were deemed appropriate for the BRs, I would suggest > that the following changes would fit the bill. All sections, etc taken from > version 1.6.7 of the BRs.
Discussing changes to the BRs here are a bit complicated, for IP reasons (And no, disclaiming IP doesn't make this go away) 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. > > 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 > 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) By this logic, Debian weak keys would not need to be blocked, because that even occurred in 2006. 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? > 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. 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? > 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 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. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
