I don’t understand why cessationOfOperation (5) would not be applicable for TLS certificates. If the service with the certificate is taken down prior to the expiration of the certificate and the operator of that service is responsible and notifies the CA, requesting revocation of the certificate, this seems like the most applicable reason code to use.
For TLS certificates, I would think this should be more common than affiliationChanged (3) which seems to me to be more likely a reason code used with certificates associated with people. Thanks, Wendy Wendy Brown Protiviti Government Services 703-965-2990 (cell) [email protected] From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of Kathleen Wilson Sent: Tuesday, November 30, 2021 4:44 PM To: [email protected]<mailto:[email protected]> Subject: Revocation Reason Codes for TLS End-Entity Certificates 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<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fg%2Fdev-security-policy%2Fc%2FSIqvgTmKnno%2Fm%2FUPsTMDGAAwAJ&data=04%7C01%7Cwendy.brown%40protiviti.com%7C9580c962524c4d67501808d9b513e615%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C637739920550786538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0qRM9V1SxNeEiwDmfJ%2BB9Cy9lMK3OxM3ZGPghQ2joa0%3D&reserved=0>> , 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<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fprevious-versions%2Ftn-archive%2Fcc700843(v%3Dtechnet.10)%3Fredirectedfrom%3DMSDN&data=04%7C01%7Cwendy.brown%40protiviti.com%7C9580c962524c4d67501808d9b513e615%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C637739920550786538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8%2FWlHxKE76b3RuFkNInjWbGdhk2mdr2uevaCFllqn9k%3D&reserved=0>> ”, 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<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=04%7C01%7Cwendy.brown%40protiviti.com%7C9580c962524c4d67501808d9b513e615%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C637739920550796520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TVPYDnlm7ebhY9qCl88qNYJVBoq%2BYGQbMifPuURYx4A%3D&reserved=0>) 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] <mailto:[email protected]> <mailto:[email protected]%20%3cmailto:[email protected]%3e%20> " group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]> <mailto:[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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2F9085ddee-5bea-4dec-9c08-08d70e3cfae9n%2540mozilla.org&data=04%7C01%7Cwendy.brown%40protiviti.com%7C9580c962524c4d67501808d9b513e615%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C637739920550796520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=t9OWvsozsRhMG3gT9owRAqXFXIgTOlIY56BTc1iKtUk%3D&reserved=0> <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<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2F9085ddee-5bea-4dec-9c08-08d70e3cfae9n%2540mozilla.org%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Cwendy.brown%40protiviti.com%7C9580c962524c4d67501808d9b513e615%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C637739920550806444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lsZNwcAi0oechSfLFcZFva1SDXjJG1RBH4jO9yfncs8%3D&reserved=0>> . NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you. -- 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/SA1PR03MB6626CAF6D5FA70D89E69546BEE6D9%40SA1PR03MB6626.namprd03.prod.outlook.com.
