Hi Peter, Comments inline.
> What do you think, is it an acceptable practice, if the Root CA revokes its > self-signed certificate and puts this revocation information into the CARL > signed by the (revoked(?)) Root CA private key? (Subscribers of the NR-CA are > the subordinate CA owners only.) I think it’s acceptable and currently allowed, but largely ceremonial and insufficient for Relying Parties (clients) to distrust the root certificate. Checking the status of self-signed root certificates used as trust anchors is largely never done by clients. Additionally, revoking the certificate does not relieve the CA’s obligation to continue operating the root CA in accordance with browser policy, including periodic audits. The CA would have to request removal of the CA from the browser trust store and wait for its removal to be relieved of the ongoing compliance requirements. * How to use this "suicide CRL"? Peter answered this quite well, although I have heard reasonable arguments that the root CA certificate appearing on a CRL that the CA itself issued is the clearest signal that it is revoked. It’s on the CRL either due to explicit action by the CA, or an attacker has gained control of the root key material and is using the key material to issue a CRL that revokes the certificate. In either case, the root should no longer be trusted. Thanks, Corey From: [email protected] <[email protected]> On Behalf Of Peter Mate Erdosi Sent: Tuesday, February 13, 2024 4:59 AM To: [email protected] Cc: Tavis Ormandy <[email protected]>; Matthew Hardeman <[email protected]>; [email protected] <[email protected]>; Jeremy Rowley <[email protected]> Subject: Re: BR revocation question Dear all, I have a question about the revocation of the root certificate. I have not found "Reasons for Revoking a Root CA Certificate" chapter in the BRs. I read the following in this CPS ( <https://ecac.pki.gov.pk/repository/cps/ECAC_Certification_Authorities_CP_CPS_v1.4.pdf> https://ecac.pki.gov.pk/repository/cps/ECAC_Certification_Authorities_CP_CPS_v1.4.pdf) "1.4.1 Appropriate Certificate Uses For certificate issued to the NR-CA itself: it is a special class of self-signed certificate that being the trust anchor of the Pakistan PKI. The NR-CA certificate can be used for (...): - Sign CRLs containing the list of subscribers’ revoked certificates and of NR-CA revoked self-signed certificates," where "NR-CA" means "National Root CA". What do you think, is it an acceptable practice, if the Root CA revokes its self-signed certificate and puts this revocation information into the CARL signed by the (revoked(?)) Root CA private key? (Subscribers of the NR-CA are the subordinate CA owners only.) How to use this "suicide CRL"? I read in several places that the root CA certificate cannot be revoked. (e.g. <https://security.stackexchange.com/questions/90254/can-a-rootca-be-revoked> https://security.stackexchange.com/questions/90254/can-a-rootca-be-revoked) Thank you in advance for any comments! Best Regards, Peter Tavis Ormandy a következőt írta (2022. augusztus 10., szerda, 21:10:13 UTC+2): On Wed, Aug 10, 2022 at 06:57:32PM +0000, Jeremy Rowley wrote: > The general instruction I got was you couldn’t use revocation as a threat to > keep customers from switching CAs. That was pretty clear from Ryan. Other bad > actions were implied as prohibited, like revocation just because a contract > terminated. Like I said, I’d love to see it written down as an official > policy as the bounds and applicability are hearsay. Thanks, I'll send some emails! On Wed, Aug 10, 2022 Matthew Hardeman wrote: > This sounds less like it was about a customer amidst migration and more like > it was a "sell long validity cert on `credit` and collect payment over cert > lifetime". Hardly. Regardless, is revocation intended to protect trust in the ecosystem, or as an asset recovery and reposession tool for the CA industry? I think it's the former. Tavis. -- _o) $ lynx lock.cmpxchg8b.com <http://lock.cmpxchg8b.com> /\\ _o) _o) $ finger [email protected] _\_V _( ) _( ) @taviso -- You received this message because you are subscribed to the Google Groups "[email protected] <mailto:[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/4607eddf-5d61-4bdb-b589-fc19796d7f03n%40mozilla.org <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/4607eddf-5d61-4bdb-b589-fc19796d7f03n%40mozilla.org?utm_medium=email&utm_source=footer> . -- 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/DM6PR14MB21867CC4D264E3F16411D296924E2%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
