form reading those I don't think it actually said to not use keyCompromise revocation reason when subscriber can't prove key leak, just ask CA to not apply revoke cert from different subscriber because of that: it'd be nightmare to manage but wording of documents allow set reason 1 for CRL just because subscriber explicitly say so.
2025년 3월 10일 월요일 오후 9시 51분 24초 UTC+9에 Rollin Yu님이 작성: > As Jeremy highlighted, according to TLS BR 7.2.2 > <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#722-crl-and-crl-entry-extensions>, > > the default revocation reason shall be “unspecified (0)”, ensuring that > “keyCompromise (1)” is not set as the default. TLS BR 4.9.1.1 > <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#4911-reasons-for-revoking-a-subscriber-certificate> > > specifies that the “keyCompromise (1)” reason code may be used in two > scenarios: when the CA has obtained evidence of the subscriber’s private > key compromise, or when the CA can easily compute the subscriber’s private > key using known methods. In terms of urgency, both “unspecified (0)” and > “keyCompromise (1)” require CAs to revoke the certificate within 24 hours > upon the subscriber’s request. > Mozilla Root Store Policy section 6.1.1 > <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#611-end-entity-tls-certificate-crlrevocation-reasons> > > and the Mozilla wiki on Revocation Reasons > <https://wiki.mozilla.org/CA/Revocation_Reasons?_gl=1*146600n*_ga*MzI2ODI3NDIyLjE2ODEyOTUxMjA.*_ga_MQ7767QQQW*MTc0MTU2ODQyOC4xLjAuMTc0MTU2ODQzNS4wLjAuMA..#Key_Compromise> > > provide detailed guidance, allowing subscribers to request revocation with > the “keyCompromise (1)” reason without providing explicit evidence. > Therefore, > if CAs operate in compliance with these standards, the “keyCompromise (1)” > reason code in CRLs should be relatively reliable. > Based on my previous analysis, certificates revoked due to keyCompromise > (1) account for approximately 3% of all revocation data. > However, since Certificate Transparency (CT) logs primarily contain data > on TLS certificates, the proportion of public keys associated with > keyCompromise (1) revocations found in CT logs represents only about 0.4% > of all revocation data. > > Regarding the maintenance of a global key compromise list, community > collaboration, especially from CT monitor data providers, would enhance its > effectiveness. > > 在2025年3月10日星期一 UTC+8 00:55:53<Jeremy Rowley> 写道： > >> 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/4a5ef314-03a7-4111-acc2-e3b17a2ff24en%40mozilla.org.
