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

[Wendy Brown - QT3LB-C]

I disagree with your categorization of  5 / cessationOfOperation
Only the subscriber might know if they have decided to stop operating the
system for which the certificate was issued and should be able to request
revocation for that reason. It does not necessarily mean that the CA messed
up.

Thanks,

Wendy


Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services
703-965-2990 (cell)


On Tue, Oct 8, 2024 at 5:37 PM Aaron Gable via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> 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
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20241009/1c12f139/attachment.html>