7.2.2 requires CAs to make the default option be "Unspecified". Under the Mozilla policy (6.1.1), CAs must only use the keyCompromise reason code for situations listed in the TLS BRs as associated with the reason code. keyCompromises requires evidence of a compromise or that the key can be easily computed. A CA offering this reasoncode as the default probably violates the BR requirement.
However, the Mozilla guidance is somewhat at odds with this requirement as it offers more reasons to choose keyCompromise than the BRs: - the certificate subscriber requests that the CA operator revoke the certificate for this reason, with the scope of revocation being described below. The potential conflict in language is mitigated by 7.2.2 which says that the subscriber should be able to choose keyCompromise. To implement something like this, I would make it a SHOULD to block compromised keys on the list and a MUST to at least check the list. That way the CA needs to block unless there is a good reason not to. Once we figure out and address any good reasons not to block the key that the CAs provide, you could move the requirement to block compromised keys on the list a MUST. IMO, the biggest issue with a global key compromise list is that you would not want a requirement tied to a specific list operated by one entity. You'd want CAs to choose any public list of available blocked keys. Tying issuing to a single provider wrecks havoc on issuance times and creates a single point of failure. On Sat, Mar 8, 2025 at 3:04 AM Peter Gutmann <[email protected]> wrote: > Rollin Yu <[email protected]> writes: > > >Among them, certificates revoked due to CRLReason #1 (key compromise): > >254,690 > > How reliable are those figures though? Unless an attacker thoughtfully > notifies you that they've stolen your key, how would anyone know it's been > compromised? What if it's just the default setting in software for > revocations, since keyCompromise is the very first CRL reason entry? What > if > it's deliberately selected because keyCompromise gets given a higher > priority > (urgent) than any other reason (oh, just FYI...). > > What are the figures for other crlReasons? If superseded (due to forced > cert > turnover) has a much lower count than keyCompromise then we can be pretty > sure > the keyCompromise figures aren't realistic. > > Peter. > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ME0P300MB0713ECDBD50465977986D726EED42%40ME0P300MB0713.AUSP300.PROD.OUTLOOK.COM > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAFK%3DoS91ohQG49RqbBzgXjL%2Ba8cufg5DECQ5mfBWbDnUMp4Njw%40mail.gmail.com.
