[Servercert-wg] Concrete revocation reason proposal based on Ben Wilson's F2F presentation

[Aaron Gable]

We've already made good updates to the list of acceptable revocation reason
codes and the circumstances in which they may/must be used in the last few
years, but I think we all agree that we can still do better. I like the
idea of fully specifying which reason codes can only be requested by the
Subscriber versus which reason codes can only be administratively set by
the CA. And I like the idea of having clear delineations around which
revocation reasons are more "security critical" than others.

Yes, this means departing somewhat from the original reason code
definitions as laid out by ITU-T X.509, but I think the result is clean.
And in the end the most important thing is that CAs and Browsers agree on
what each reason code means, and that's what this forum is for.

So here's a concrete starting proposal:

0 / unspecified: Can be requested by either the Subscriber or the CA, but
can only be used administratively by the CA if no other reason applies.

1 / keyCompromise: Can be requested by either the Subscriber or the CA.
MUST be used in specific circumstances (when compromise is demonstrated or
demonstrably easy) and MUST NOT be used in others (when compromise is not
demonstrated).

3 / affiliationChanged: Indicates that the certificate has been revoked
because the CA messed up as part of validation (e.g. failed to perform DCV
correctly, put a typo in the Organization field). Can only be
administratively set by the CA, and only in response to incidents.

4 / superseded: Indicates that the certificate has been replaced. Can only
be requested by the Subscriber because only they know if it's actually been
replaced. Intended to be used to reduce the "stale certificate" issue as
presented by Zane Ma.

5 / cessationOfOperation: Indicates that the certificate has been revoked
because the CA messed up *other than* during validation (e.g. issued with a
too-long validity period, included the wrong CRL URL, etc). Can only be
administratively set by the CA, and only in response to incidents.

9 / privilegeWithdrawn: Indicates that the certificate has been revoked
because the Subscriber messed up (e.g. violated the Subscriber Agreement,
presented false validation information, etc). Can only be administratively
set by the CA.

The other reason codes (2 / cACompromise, 6 / certificateHold, 7 / unused,
8 / removeFromCRL, and 10 / aACompromise) MUST NOT be used.

With this framework, it's easy to see that keyCompromise and
affiliationChanged are the most critical revocation reason codes to pay
attention to. It's clear that Subscribers can only request reason codes 0,
1, and 4; and clear that CAs can only unilaterally set reason codes 0, 1,
and 9, except in exceptional circumstances that should be reflected by a
public incident report. It makes it much easier to tell if the appropriate
reason code has been set in each circumstance, which in turn makes it much
easier for user-agents to react to different reason codes differently.

We'd still have the list of circumstances under which a cert must be
revoked in Section 4.9.1.1, but the corresponding reason code in each
bullet point would change.

I'm certainly not wedded to the details of this proposal, but I wanted to
kick off discussion with a concrete starting point. What do people think
about moving in a direction similar to this?

Thanks,
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20241008/161572be/attachment.html>