Hi, I would like to discuss the case 3 / affiliationChanged. What if Subscriber has changed their O name and want to replace their current now invalid certificates. Today we have instructed them to use 3 / affiliationChanged but the described new proposal would deny that. I think that Subscriber initiated 3 / affiliationChanged is better in this use case than 4 / superseded (or 0 / unspecified).
Best Regards Pekka Telia Company From: Servercert-wg <[email protected]> On Behalf Of Wendy Brown - QT3LB-C via Servercert-wg Sent: Wednesday, October 9, 2024 2:31 PM To: Aaron Gable <[email protected]>; CA/B Forum Server Certificate WG Public Discussion List <[email protected]> Subject: Re: [Servercert-wg] Concrete revocation reason proposal based on Ben Wilson's F2F presentation 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://lists.cabforum.org/mailman/listinfo/servercert-wg This email may contain information which is privileged or protected against unauthorized disclosure or communication. If you are not the intended recipient, please notify the sender and delete this message and any attachments from your system without producing, distributing or retaining copies thereof or disclosing its contents to any other person. Telia Company processes emails and other files that may contain personal data in accordance with Telia Company’s Privacy Policy<https://www.teliacompany.com/en/about-the-company/privacy/>.
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
