BR revocation question

154 views
Skip to first unread message

Tavis Ormandy

unread,
Aug 9, 2022, 2:52:36 PMAug 9
to dev-secur...@mozilla.org
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

unread,
Aug 9, 2022, 6:28:01 PMAug 9
to Tavis Ormandy, dev-secur...@mozilla.org
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

unread,
Aug 10, 2022, 11:02:25 AMAug 10
to Matthew McPherrin, Tavis Ormandy, dev-secur...@mozilla.org

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

Amir Omidi

unread,
Aug 10, 2022, 11:10:37 AMAug 10
to dev-secur...@mozilla.org, ma...@letsencrypt.org, dev-secur...@mozilla.org, tav...@gmail.com
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

unread,
Aug 10, 2022, 12:13:25 PMAug 10
to Tavis Ormandy, dev-secur...@mozilla.org
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

unread,
Aug 10, 2022, 1:23:59 PMAug 10
to Matthew Hardeman, dev-secur...@mozilla.org
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

unread,
Aug 10, 2022, 1:48:42 PMAug 10
to Tavis Ormandy, dev-secur...@mozilla.org
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

unread,
Aug 10, 2022, 1:58:57 PMAug 10
to Tavis Ormandy, Matthew Hardeman, dev-secur...@mozilla.org
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

unread,
Aug 10, 2022, 2:22:10 PMAug 10
to Jeremy Rowley, Tavis Ormandy, dev-secur...@mozilla.org
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

unread,
Aug 10, 2022, 2:57:37 PMAug 10
to Matthew Hardeman, Tavis Ormandy, dev-secur...@mozilla.org
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>

Tavis Ormandy

unread,
Aug 10, 2022, 3:10:13 PMAug 10
to Jeremy Rowley, Matthew Hardeman, dev-secur...@mozilla.org
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.
Reply all
Reply to author
Forward
0 new messages