Hi Corey, thank you for the comments.
So, we have an allowed solution, which provides three different certificate status answers based on the verifier's software: based on the CARL: - good - revoked - crashed. And it fulfills the BRG, especially these: 4.10.1 Operational characteristics Revocation entries on a CRL or OCSP Response MUST NOT be removed until after the Expiry Date of the revoked Certificate. 4.9.7 CRL issuance frequency As issuing CA Certificates: 1. MUST update and publish a new CRL at least every twelve (12) months; 2. MUST update and publish a new CRL within twenty-four (24) hours after recording a Certificate as revoked. CAs MUST continue issuing CRLs until one of the following is true: - all Subordinate CA Certificates containing the same Subject Public Key are expired or revoked; OR - the corresponding Subordinate CA Private Key is destroyed. And ETSI 319 411-1: Where CARL is used: • CSS-6.3.9-12 [CONDITIONAL]: If CARL is used, a new CARL shall be generated at least once a year with a nextUpdate of at most 1 year after the issuing date. By the way, which nextUpdate should be inserted into the CARL containing revoked Root CA certificate if - not all subordinate CA certificates are revoked, or - all subordinate CA certificates are revoked? And I think one new paragraph would be very useful in the next BRG about the revocation of the Root CA certificates, if it is a really allowed method. Thank you in advance! Best Regards, Peter On Wed, Feb 14, 2024 at 11:40 PM Corey Bonnell <[email protected]> wrote: > 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 > ) > > > > "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 > ) > > > > 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 > /\\ _o) _o) $ finger [email protected] > _\_V _( ) _( ) @taviso > > -- > 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/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/CADuWVBXXoPqiGSd2z%3DFdYMR9YUBFKa5%3D4%2BwGWh4%2B6nwMNxW0KA%40mail.gmail.com.
