BR revocation question

[Tavis Ormandy]

Apologies if I send this twice, I tried posting it via gmane and I think it
failed.

I understand the BRs require revocation in some circumstances, but are there any
limits on when an issuer can revoke? Can they revoke for any reason whatsoever?
Is the reason code required to be honest?

I was recently surprised by an issuer demanding maintenance fees to *not* revoke
a certificate. The certificate was not compromised and not expiring. Is this
permitted by the BRs? It feels like misusing a mechanism that was intended to
protect the PKI, not extract profit.

I was being lazy and not migrating a very old system to ACME. I've
migrated it now, because that felt really gross. I don't know what reason code
they use for the revocation, I guess I'm curious if they will lie.

Tavis.

--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger tav...@sdf.org
_\_V _( ) _( ) @taviso

[Matthew McPherrin]

The only restrictions on reason codes for revocations that I am aware of is Mozilla's recent addition to their root program rules, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#611-end-entity-tls-certificate-crlrevocation-reasons

The corresponding wiki page definitely appears to imply that reason codes were generally not restricted, https://wiki.mozilla.org/CA/Revocation_Reasons

(but I am far from an expert in such policy matters)

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20220809175618.GA9423%40thinkstation.cmpxchg8b.net.

[Corey Bonnell]

Matthew’s understanding matches mine. As far as I’m aware, the only requirements in currently place are that the following reason codes are either explicitly prohibited or non-sensical for end-entity TLS certificates:

 

• Unspecified (CAs must not explicitly encode this value, per the BRs)
• certificateHold (suspension is prohibited)
• removeFromCRL (suspension is prohibited, so specifying this value makes no sense)
• cACompromise (this reason code is for CA certificates only)
• aACompromise (this reason code is for attribute certificates only; TLS certs are PKC certs)

 

Any other reason code can be assigned for any reason. This will change in October, when the new Mozilla policy that Matthew pointed out comes into effect.

 

Thanks,

Corey

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAKh5S0a1RxXsYuU74EXN8VPXxzgSV__rGwFVA%3DuUMB%3DxXLFimg%40mail.gmail.com.

[Amir Omidi]

To add to that, the CA in question may have put additional restrictions on when and how it can revoke in its CPS (Certification Practice Statement).

There are some restrictions on when you can use keyCompromise as well, but that's all I'm aware of.

[Matthew Hardeman]

Assuming that the subscriber agreement provided for an annual fee for certificates issued under the agreement, or incorporated such contractual terms with the subscriber, it seems like revocation for privilegeWithdrawn would be the correct code.  It also appears that Mozilla's new policy would allow for that in the bullet under privilegeWithdrawn which reads "the CA operator is made aware that the certificate subscriber has violated one or more of its material obligations under the subscriber agreement or terms of use".

Presumably the use case here is providing a certificate with max permissible validity for ease of install/maintenance but billing for said certificate on a subscription basis without requiring full payment for the period up front?

[Tavis Ormandy]

On Wed, Aug 10, 2022 at 11:13:11AM -0500, Matthew Hardeman wrote:
> Assuming that the subscriber agreement provided for an annual fee for
> certificates issued under the agreement, or incorporated such contractual
> terms with the subscriber, it seems like revocation for privilegeWithdrawn
> would be the correct code. It also appears that Mozilla's new policy would
> allow for that in the bullet under privilegeWithdrawn which reads "the CA
> operator is made aware that the certificate subscriber has violated one or
> more of its material obligations under the subscriber agreement or terms of
> use".

I suppose so. It's dissapointing, it allows CAs to use revocation as a sabre to rattle to keep subscribers acquiescent.

> Presumably the use case here is providing a certificate with max
> permissible validity for ease of install/maintenance but billing for said
> certificate on a subscription basis without requiring full payment for the
> period up front?

Sure, "protection racket" is such an ugly term :)

[Matthew Hardeman]

I broadly agree with the points that you make here, but presumably some CA built the product & work flow for this because some set of subscribers found value in it.

As you note, for a subscriber with more capability or better software stack, it seems as in your case the mechanism may simply spur evolution toward automation.  Not really a net negative outcome there.

[Jeremy Rowley]

Well yes, but actually no. Google has previously said CAs caught in behavior where revocation is used as a hammer on migrating customers would be penalized. Although Ryan Sleevi isn't with Google now, I assume that policy still stands. You can report bad acting CAs there. See https://groups.google.com/g/mozilla.dev.security.policy/c/nU1bIZ9LgjU/m/sJC8TtAgCAAJ

It would be nice to see this rule actually canonized somewhere instead of it just being several old discussions on MDSP.

-----Original Message-----
From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Tavis Ormandy
Sent: Wednesday, August 10, 2022 11:24 AM
To: Matthew Hardeman <mhar...@gmail.com>
Cc: dev-secur...@mozilla.org
Subject: Re: BR revocation question

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20220810172355.GA23189%40thinkstation.cmpxchg8b.net.

[Matthew Hardeman]

In so far as it's not really a written rule, I wonder if what was described here would really qualify in the same way?

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".

[Jeremy Rowley]

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.

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Matthew Hardeman <mhar...@gmail.com>
Sent: Wednesday, August 10, 2022 12:21:56 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: Tavis Ormandy <tav...@gmail.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPAx59FRYaMEHF0CcM37nLGW5%3D8VL95SdL5hNYPuUL3u8FKf6g%40mail.gmail.com.

[Tavis Ormandy]

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.

[Peter Mate Erdosi]

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

[Peter Gutmann]

Peter Mate Erdosi <per...@gmail.com> writes:

>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.

That's because it's... well...

The handling of CA root certificates is particularly problematic because
there’s no effective way to replace or revoke them. Consider what would be
required to revoke a CA root certificate. These are self-signed, which means
that the certificate would be revoking itself. In the presence of such a
revocation applications can react in one of three ways: they can accept the
CRL that revokes the certificate as valid and revoke it, they can reject the
CRL as invalid because it was signed by a revoked certificate, or they can
crash, and some applications will indeed crash in this situation. Since
revocation of a self-signed certificate is the PKI version of Epimenedes
paradox “All Cretans are liars” and PKI applications are unlikely to be
coded to deal with self-referential paradoxes, crashing is a perfectly valid
response.

Peter.

[Corey Bonnell]

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: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Peter Mate Erdosi
Sent: Tuesday, February 13, 2024 4:59 AM
To: dev-secur...@mozilla.org
Cc: Tavis Ormandy <tav...@gmail.com>; Matthew Hardeman <mhar...@gmail.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>; Jeremy Rowley <jeremy...@digicert.com>
Subject: Re: BR revocation question

 

Dear all,

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

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.

[Peter Mate Erdosi]

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

[Aaron Gable]

On Thu, Feb 15, 2024 at 12:47 AM Peter Mate Erdosi <per...@gmail.com> wrote:

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.

Right, which means that revocation of a self-signed root in this manner is not particularly useful or helpful. Meaningful, yes -- the CRL should be taken as very strong evidence that the root should no longer be trusted -- but not effective, as few if any clients will actually behave that way.

 

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? 

A date no more than 12 months beyond thisUpdate. The acceptable validity intervals do not depend on the status of the issuing CA.

But thank you very much for asking this question, as you have caused me to realize that there seems to be a bug in the BRs regarding when Root CAs may stop issuing CRLs. I have filed https://github.com/cabforum/servercert/issues/484 to clarify the language in this section.

Thanks,

Aaron

[Corey Bonnell]

Hi Aaron,

> A date no more than 12 months beyond thisUpdate. The acceptable validity intervals do not depend on the status of the issuing CA.

 

Agreed on no more than 12 months, but for a different reason.

 

If there is no longer a valid certification path from a root trusted in Mozilla to the issuing CA in question, then that issuing CA is no longer in scope of policy and thus is relieved of all compliance    requirements, including those regarding its publication of revocation information about certificates it has issued. For example, a subordinate TLS serverauth CA that no longer has a valid certification path to a Mozilla-trusted root no longer needs to issue CRLs for end-entity certificates it may have issued.

 

However, as I mentioned in my previous email, roots are not removed from Mozilla policy scope by the CA revoking the self-signed certificate through publication of a CRL. Rather, they are removed from scope by Mozilla removing them from its root store. Until that removal occurs, the root CA must continue to be operated in accordance with root program policy, which would include compliance with the BRs. Specifically, this would include the issuance and publication of CRLs for the certificates it has issued in accordance with the requirements in the BRs (i.e., issue CRLs at least once every 12 months).

 

Thanks,

Corey

 

From: Aaron Gable <aa...@letsencrypt.org>
Sent: Thursday, February 15, 2024 11:38 AM
To: Peter Mate Erdosi <per...@gmail.com>
Cc: Corey Bonnell <Corey....@digicert.com>; dev-secur...@mozilla.org
Subject: Re: BR revocation question

 

On Thu, Feb 15, 2024 at 12:47 AM Peter Mate Erdosi <per...@gmail.com> wrote: