Clarify CRLReason #9 (privilegeWithdrawn) description in BR 7.2.2

[mr-m0nst3r]

Summary

This PR updates the description of CRLReason#9 (privilegeWithdrawn) in Section 7.2.2 to better align with the actual usage scenarios enumerated in Section 4.9.1.1.

Problem

The current description in BR 7.2.2 states that privilegeWithdrawn indicates "a subscriber-side infraction that has not resulted in keyCompromise, such as the Certificate Subscriber provided misleading information in their Certificate Request or has not upheld their material obligations under the Subscriber Agreement or Terms of Use."

However, Section 4.9.1.1 provides several examples where CRLReason#9 is used that are not fully covered by this description:

1. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization (CRLReason#9, privilegeWithdrawn)
2. The CA obtains evidence that the Certificate was misused (CRLReason#9, privilegeWithdrawn)
3. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use (CRLReason#9, privilegeWithdrawn)
4. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name (CRLReason#9, privilegeWithdrawn)
5. The CA is made aware of a material change in the information contained in the Certificate (CRLReason#9, privilegeWithdrawn)
6. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate (CRLReason#9, privilegeWithdrawn)

The current description focuses primarily on misleading information in the certificate request and violations of material obligations, but does not explicitly cover:

• Authorization issues (invalid or withdrawn authorization)
• Certificate misuse scenarios
• Information accuracy issues (inaccurate or materially changed information)

Solution

Updated the description to comprehensively cover all scenarios where CRLReason#9 is used:

New description:

Indicates that there has been a subscriber-side infraction that has not resulted in keyCompromise, such as the Certificate Subscriber's authorization for the certificate was invalid or withdrawn, the Certificate was misused, the Certificate Subscriber violated material obligations under the Subscriber Agreement or Terms of Use, or any information contained in the Certificate is inaccurate or has materially changed.

Changes

• Section 7.2.2: Updated the Description column for privilegeWithdrawn (reasonCode value 9) in the CRLReason table

Impact

This change improves clarity and consistency between the definition in Section 7.2.2 and the practical usage examples in Section 4.9.1.1, ensuring that CAs have clear guidance on when to use CRLReason #9 for certificate revocation.

[BenWilson-Mozilla]

Thanks for putting this together. While I agree with the basic goal here of aligning privilegeWithdrawn in §7.2.2 with scenarios referenced in §4.9.1.1, I do have one concern about the inclusion of “any information contained in the Certificate is inaccurate or has materially changed.” (It presents a very broad scope.)

Separately from this PR, I have been working on language for both §4.9.1.1 and §7.2.2 to make the RFC 5280 reason codes a bit more semantically distinct. The general direction of that work is to:

• use keyCompromise (1) for all key-soundness issues;
• use affiliationChanged (3) for subject-identity accuracy and affiliation changes (with some possibility that certain items could move to 9-privilegeWithdrawn, depending on how the final taxonomy develops);
• use superseded (4) as a neutral, mostly administrative bucket for CP/CPS/profile and other purely technical-conformity clean-ups; and
• use privilegeWithdrawn (9) for authorization/eligibility cases where the privilege to obtain or use the certificate (or the names in it) was never valid or has been withdrawn, including some types of misuse and serious breach of subscriber obligations.

Because I plan to advocate that some of the current reason-code-9 items in §4.9.1.1 be re-assigned, or have their descriptions updated, I want to avoid introducing text in §7.2.2 that would implicitly lock those items into reason code 9 before the broader restructuring is discussed. In particular, if we expand §7.2.2 to explicitly cover “any information contained in the Certificate [that] is inaccurate or has materially changed,” we risk foreclosing options that might fit better under a different code.

One way to keep this PR compatible with the range of possible directions is to slightly narrow the new description so that it stays focused on authorization, privilege, and subscriber-side infractions, without pre-assigning all “inaccurate or materially changed information” to reason 9. That narrower scope would still cover the majority of existing subsections in §4.9.1.1 involving:

• invalid or withdrawn authorization,
• misuse, and
• material subscriber-agreement breaches.

Remaining matters can then be handled more cleanly in a forthcoming §4.9.1.1/§7.2.2 update, during which all revocation reasons and reason codes will be revisited holistically.

In summary, I support the aim of clarifying privilegeWithdrawn, but would prefer to avoid wording in §7.2.2 that might inadvertently constrain how we re-partition the cases in §4.9.1.1 when the group undertakes a more comprehensive review of revocation reasons and reason codes.

[mr-m0nst3r]

@BenWilson-Mozilla Hi Ben,
Thank you for the detailed feedback and for sharing your broader work on making the RFC 5280 reason codes more semantically distinct.

From a practical operational perspective as a CA, I want to ensure we're addressing a current compliance question: Currently, §4.9.1.1 item #13 explicitly requires that "The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate" must use CRLReason #9 (privilegeWithdrawn). This is the current requirement that CAs must follow when revoking certificates for information inaccuracy.

The motivation for this PR was to align the description in §7.2.2 with what §4.9.1.1 currently specifies, so that CAs have clear and consistent guidance. Without alignment, there's a risk that §7.2.2's definition may not clearly reflect the scenarios that §4.9.1.1 already requires to use reason code 9.

I understand your plan to potentially reassign some cases during the broader review. However, until that review is complete and any changes are adopted, CAs still need clear guidance that matches the current requirements in §4.9.1.1.

Would it be possible to:

1. Include language in §7.2.2 that acknowledges the current usage as specified in §4.9.1.1, while also noting that some scenarios may be subject to future reclassification?
2. Or, should I narrow the scope as you suggested, understanding that there will be a temporary inconsistency between §7.2.2 and §4.9.1.1 until your broader review addresses §4.9.1.1?

I want to ensure this PR serves both the immediate need for consistency and doesn't interfere with your planned taxonomy improvements. What approach would you recommend?

[BenWilson-Mozilla]

First, thanks for this effort to improve alignment between §7.2.2 and §4.9.1.1, and I recognize that the broader restructuring of revocation reasons is going to take time because any durable changes will ultimately need group consensus.

If we are opening §7.2.2, I think it is an opportunity to clean up other parts of the table, based on the current §4.9.1.1 reason codes (e.g. descriptions for “unspecified” and “certificateHold”). I have draft language for several of the other rows in the table, based on the existing section 4.9.1.1, that I will share.

With respect to the two options you presented for handling privilegeWithdrawn, I could support a hybrid approach that leaves a window open for future adjustments while still adding explanatory clarity consistent with the present §4.9.1.1 mapping. In other words, I would like a balanced approach that avoids hard-coding (13) in §7.2.2 while acknowledging the operational need for descriptions that reflect the current mandatory mappings, but I don't think we should add any "wait-and-see" language. For clarity, none of my comments change the fact that §4.9.1.1 governs the required reason codes today, and CAs should continue to follow those mappings until a future ballot modifies them.

This PR highlights one of the more challenging areas that I am working through--how to categorize “incorrect certificates,” whether because of incorrect content or incorrect encoding/formatting, and that question intersects with the long-term semantics of the RFC 5280 reason codes, which is why I am trying to keep the space open for a holistic adjustment in a subsequent ballot.

Finally, I want this PR to move forward productively, and I appreciate the willingness to incorporate feedback while keeping the immediate needs of CAs in mind.

[BenWilson-Mozilla]

I had another thought about subsections (11) and (13) of TLS BR 4.9.1.1 as I was working on revocation reason codes. Revocation reasons should be based on the underlying facts. Here is the current direction I'm going with subsections (11) and (13):

(11) The CA is made aware of a material change in the information contained in the Certificate.
If the material change reflects a loss, withdrawal, or absence of authorization or eligibility to use a domain name, IP address, or other identifier, the CA SHALL revoke the Certificate under §4.9.1.1(2) or §4.9.1.1(9) (“privilegeWithdrawn”), as applicable.
If the material change reflects that the Subject’s identity, affiliation, or relationship to the information in the Certificate is no longer accurate, the CA SHALL revoke the Certificate under §4.9.1.1(5) (“affiliationChanged”).

(13) The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate.
If the inaccuracy results from an error or failure in domain validation, IP address validation, or other information verification, such that the association reflected in the Certificate cannot be relied upon, the CA SHALL revoke the Certificate under §4.9.1.1(5) (affiliationChanged”).
If the inaccuracy results from a failure to properly confirm authorization or eligibility (including required authorization checks such as CAA), the CA SHALL revoke the Certificate under §4.9.1.1(2) or §4.9.1.1(9) (“privilegeWithdrawn”), as applicable.