In my recent forays into mass-revocation for key compromise, one aspect that was particularly frustrating and unnecessary was having to send revocation requests for new certificates, issued by a CA using a private key which I had previously reported as compromised to that same CA. Once a key is compromised, it's never going to get *less* compromised, so there is no reason why a CA should ever be issuing another certificate using that same key. Also, the requirement to revoke all certificates with a compromised private key, regardless of whether a given certificate is explicitly listed in a certificate problem report, does not appear to be clear. Finally, CAs appear to have a variety of interpretations of the start time of the 24 hour period in which revocation must be completed, and so I thought I'd include a small change for that.
Thus, I would like to propose that either Mozilla Policy, or (preferably) the Baseline Requirements be amended to prohibit issuance of a certificate where the CA has previously revoked a certificate using the same key, and to clarify that all certificates using a compromised key are subject to revocation. 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. 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: > In accordance with Section 5.5.2, the CA SHALL maintain an internal > database of all Public Keys contained in Certificates which have been > revoked due to the CA obtaining evidence of Key Compromise. This > requirement exists regardless of the revocation reason (if any) published > in Certificate status information. > > The CA SHALL NOT issue a Certificate containing a Public Key which the CA > has previously recorded as having been used in a Certificate revoked due > to the CA obtaining evidence of Key Compromise. 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. 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. Step 3: Insert a new paragraph at the end of section 4.9.1.1, with the following contents (or a reasonable facsimile thereof): > The time periods specified in this Section SHALL BE measured from the time > that the communication which requests, notifies, makes the CA aware, > provides evidence which the CA later deems valid, or as otherwise > described above, is first received by a system or person acting on the > CA's behalf for the receipt of such communications. I know that's a phat sentence, but I wanted to try and get all the circumstances in there, to prevent another round of "BUT BUT BUT" in the future. Essentially, what I'm trying to get across is, "once it hits your MTA or phone tree, the clock starts ticking". No leaving a problem report in the inbox over the weekend and then claiming that they didn't "obtain evidence" until monday morning. ... and that's about it. Please tear my wording, rationale, and choice of font to pieces as you see fit. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
