Kathleen, I am curious about the decision to include superseded and affiliation change without a firm definition beyond the subscriber asked for these values to be set.
It seems that without a definition even if it was a subscriber-specified reason you would never be able to reason about what the reason itself means as a relying party. This is in contrast to, say privilege withdrawn and key compromise which signals a severity of the revocation to a relying party. Ryan On Tue, Nov 30, 2021 at 1:43 PM Kathleen Wilson <[email protected]> wrote: > All, > > Building on a previous discussion here in MDSP, Addressing Current > Limitations of CRL Revocation Reason Codes > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/SIqvgTmKnno/m/UPsTMDGAAwAJ>, > I would like to have a discussion about which CRL revocation reason codes > are applicable to TLS. My goals for this discussion are: > > - Specify when certain revocation codes should or should not be used. > - Determine when CAs should be required to put revocation codes into > CRLs. > - Begin drafting policy language about CRL revocation reason codes. > > > For reference, please see the “Revocation Reasons” section of the 2009 > paper, “Troubleshooting Certificate Status and Revocation > <https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc700843(v=technet.10)?redirectedfrom=MSDN>”, > by Brian Komar and David B. Cross, Microsoft Corporation. For this > discussion, I do not want to debate these meanings, but rather I would like > to use those meanings as reference to help us determine which revocation > reason codes should and should-not be used for TLS end-entity certificates. > > I propose that the following revocation reason codes are NOT applicable to > TLS server (end-entity) certificates, meaning that they MUST NOT be used in > CRLs for TLS server certificates. > > - Unspecified (0) > - cACompromise (2) > - cessationOfOperation (5) > - certificateHold (6) > - value 7 is not used > - removeFromCRL (8) > - aACompromise (10) > > > I propose that only the following existing revocation reason codes ARE > applicable to TLS server (end-entity) certificates, meaning that CRL > entries for TLS server certificates must either have one of these reason > codes or NO reason code. > > - keyCompromise (1) > - affiliationChanged (3) > - superseded (4) > - privilegeWithdrawn (9) > > == > Below is the beginning of potential policy text relating to these reason > codes, and is only intended for TLS server (end-entity) certificate > revocations. > Note that much of this text is copied from section 4.9.1.1 of the BRs. > > *keyCompromise (1)* > The CRLReason keyCompromise (1) MUST be used when the CA obtains evidence > that the Subscriber’s Private Key corresponding to the Public Key in the > Certificate suffered a Key Compromise, or the CA is made aware of a > demonstrated or proven method that can easily compute the Subscriber’s > Private Key based on the Public Key in the Certificate (such as a Debian > weak key, see https://wiki.debian.org/SSLkeys) > > If someone other than the Subscriber requests revocation by providing > verifiable evidence that the Subscriber's Private Key corresponding to the > Public Key in the Certificate suffered a Key Compromise, then the CA MUST > make the information regarding its intent to revoke available to the > Subscriber before revoking the certificate, and the CA MUST use the > keyCompromise (1) CRLReason. > > The CRLReason keyCompromise (1) MAY be used when one or more of the > following occurs: > > - The Subscriber requests that the CA revoke the Certificate for this > reason code; > - The Subscriber notifies the CA that the original certificate request > was not authorized and does not retroactively grant authorization; > - The CA obtains evidence that the validation of domain authorization > or control for any Fully‐Qualified Domain Name or IP address in the > Certificate should not be relied upon. > > *affiliationChanged (3)* > The CRLReason affiliationChanged (3) MUST be used when the certificate > subscriber has requested that their certificate be revoked for this reason, > otherwise this CRLReason MUST NOT be used. > > *superseded (4)* > The CRLReason superseded (4) MUST be used when the certificate subscriber > has requested that their certificate be revoked for this reason, otherwise > this CRLReason MUST NOT be used. > > *privilegeWithdrawn (9)* > The CRLReason privilegeWithdrawn (9) SHOULD be used if one or more of the > following occurs, and the CA MUST make the information regarding its intent > to revoke available to the Subscriber before revoking the certificate. > Otherwise this CRLReason MUST NOT be used. > > - The CA obtains evidence that the Certificate was misused; > - 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; > - The CA is made aware of any circumstance indicating that use of a > Fully‐Qualified Domain Name or IP address in the Certificate is no longer > legally permitted (e.g. a court or arbitrator has revoked a Domain Name > Registrant’s right to use the Domain Name, a relevant licensing or services > agreement between the Domain Name Registrant and the Applicant has > terminated, or the Domain Name Registrant has failed to renew the Domain > Name); > - The CA is made aware that a Wildcard Certificate has been used to > authenticate a fraudulently misleading subordinate Fully‐Qualified Domain > Name; > - The CA is made aware of a material change in the information > contained in the Certificate; > - The CA determines or is made aware that any of the information > appearing in the Certificate is inaccurate; or > - The CA is made aware of a demonstrated or proven method that exposes > the Subscriber’s Private Key to compromise or if there is clear evidence > that the specific method used to generate the Private Key was flawed. > > > == > > I will greatly appreciate your thoughtful and constructive feedback on > these proposals. > > Thanks, > Kathleen > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/9085ddee-5bea-4dec-9c08-08d70e3cfae9n%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/9085ddee-5bea-4dec-9c08-08d70e3cfae9n%40mozilla.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwayBRa5Gev9zPq6Z1Y7fRwuBQYVH1R%2B4cczyimX%2BsJR7A%40mail.gmail.com.
