Hi Matthias. That's an interesting idea, but I don't think it's compatible with how the X.509 specification defines that reason code. My understanding is that cACompromise can only be used in a revocation entry for a CA Certificate. Here's the relevant section from the 2008 edition of X.509:
8.5.2.2 Reason code extension This CRL entry extension field identifies a reason for the certificate revocation. The reason code may be used by applications to decide, based on local policy, how to react to posted revocations. [ASN.1 definition elided] The following reason code values indicate why a certificate was revoked: - unspecified can be used to revoke certificates for reasons other than the specific codes; - keyCompromise is used in revoking an end-entity certificate; it indicates that it is known or suspected that the subject's private key, or other aspects of the subject validated in the certificate, have been compromised; - cACompromise is used in revoking a CA-certificate; it indicates that it is known or suspected that the subject's private key, or other aspects of the subject validated in the certificate, have been compromised; - affiliationChanged indicates that the subject's name or other information in the certificate has been modified but there is no cause to suspect that the private key has been compromised; - superseded indicates that the certificate has been superseded but there is no cause to suspect that the private key has been compromised; - cessationOfOperation indicates that the certificate is no longer needed for the purpose for which it was issued but there is no cause to suspect that the private key has been compromised; - privilegeWithdrawn indicates that a certificate (public-key or attribute certificate) was revoked because a privilege contained within that certificate has been withdrawn; - aACompromise indicates that it is known or suspected that aspects of the AA validated in the attribute certificate, have been compromised. A certificate may be placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold notice may include an optional hold instruction code to convey additional information to certificate users (see 8.5.2.3). Once a hold has been issued, it may be handled in one of three ways: a) it may remain on the CRL with no further action, causing users to reject transactions issued during the hold period; or, b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons for revocation, the revocation date shall be the date the certificate was placed on hold, and the optional instruction code extension field shall not appear; or, c) it may be explicitly released and the entry removed from the CRL. The removeFromCRL reason code is for use with delta-CRLs (see 8.6) only and indicates that an existing CRL entry should now be removed owing to certificate expiration or hold release. An entry with this reason code shall be used in delta-CRLs for which the corresponding base CRL or any subsequent (delta or complete for scope) CRL contains an entry for the same certificate with reason code certificateHold. This extension is always non-critical. ________________________________ From: [email protected] <[email protected]> on behalf of Matthias van de Meent <[email protected]> Sent: 24 February 2022 00:18 To: Kathleen Wilson <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: Banned CRL Revocation Reason Codes for TLS End-Entity Certificates CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Wed, Feb 23, 2022 at 11:10 PM Kathleen Wilson <[email protected]<mailto:[email protected]>> wrote: These banned reason codes are either already banned by the BRs or they are not applicable to end-entity TLS certificates. Below is a detailed explanation for each of them. [...] cACompromise (2) This reason code is used when revoking an intermediate certificate. When an intermediate certificate is revoked and added to OneCRL all certificates signed by that intermediate certificate are also treated as revoked. https://www.ccadb.org/policy#4-intermediate-certificates<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ccadb.org%2Fpolicy%234-intermediate-certificates&data=04%7C01%7Crob%40sectigo.com%7C6cea10b79d4c479b946d08d9f72b4801%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637812587595055904%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=j%2Feyn8SGr9mNq9MBpD3Kq0V%2BIcv8N8wOtmBPVRy00Tg%3D&reserved=0> says: "If an intermediate certificate is revoked, the CCADB must be updated to mark it as revoked, giving the reason why, within 24 hours for a security incident, and within 7 days for any other reason." Section 4.1 of Mozilla's Root Store Policy says: "If the revocation of an intermediate certificate chaining up to a root in Mozilla’s root program is due to a security concern, as well as performing the actions defined in the CCADB Policy, a security bug must be filed in Bugzilla<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fenter_bug.cgi%3Fproduct%3DNSS%26component%3DCA%2520Certificate%2520Compliance%26groups%3Dcrypto-core-security&data=04%7C01%7Crob%40sectigo.com%7C6cea10b79d4c479b946d08d9f72b4801%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637812587595211272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AJJWzdy%2BVvYnC2Iwzmz%2F1RWUjeG8HkFZuSjJZ1VT3Xo%3D&reserved=0>." Is batch revoking leaf certificates because its CA (be it key or infrastructure) was compromised (e.g. DigiNotar) not supposed to use cACompromise as OCSP response? As in, in such cases there might have been no affiliation that could have changed, no new certificate subject information to supersede the revoked, no given privilige to withdraw, and no operation that is being ceased. Additionally, the key compromised is not that of the leaf certificate. Why not allow the use of cACompromise in such situations to allow accurate OSCP responses? Note that this allows the relying party to evict the OCSP caches of the signing certificate; potentially improving on the revocation latency induced by the OneCRL distribution process (Firefox's default "security.onecrl.maximum_staleness_in_seconds" setting is 108000, or 30 hours), and improves securty by faster revocation marking of the parent ca when OneCRL is not included in the program. - Matthias -- 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]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAAT_OQs5_5eL69UCiBV4a5w5bYWqPaj%2Baty5DMbZ58SvVcHcxQ%40mail.gmail.com<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FCAAT_OQs5_5eL69UCiBV4a5w5bYWqPaj%252Baty5DMbZ58SvVcHcxQ%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Crob%40sectigo.com%7C6cea10b79d4c479b946d08d9f72b4801%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637812587595211272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=FwMPMhrH4i%2BBkDEibPCH08jufpJ5oJCj9m9pci44NyI%3D&reserved=0>. -- 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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729BFFB009D6FC7260F5052AA3D9%40MW4PR17MB4729.namprd17.prod.outlook.com.
