Confirm, administrator
5,526
edits
Changes
Creating page about Revocation Reason Codes for TLS end-entity certificates
{{DRAFT}}
== CRLReason Codes for End-Entity TLS Certificates ==
[https://www.mozilla.org/projects/security/certs/policy/ Mozilla's Root Store Policy] (starting with version 2.8) has a section dedicated to CRLRevocation Reasons for end-entity TLS certificates; e.g. website server authentication certificates. The section was added because Mozilla believes that [[CA/Revocation_Checking_in_Firefox#Revocation_Is_Important|revocation checking is important]], and there were several problems with not having such policy, including:
* There were no policies specifying when certain revocation codes should or should not be used, and no incentive for CAs to use the correct reason codes
* There were no policies specifying the information that CAs should provide to their certificate subscribers about revocation reasons
The following CRLRevocation Reasons may be specified in the CRL reasonCode extensionfor end-entity TLS certificates. They MUST be specified under the conditions detailed in section 6.1.1 of Mozilla's Root Store Policy.
* keyCompromise (RFC 5280 CRLReason #1)
* privilegeWithdrawn (RFC 5280 CRLReason #9)
* affiliationChanged (RFC 5280 CRLReason #3)
* superseded (RFC 5280 CRLReason #4)
== Communication to Subscribers ==
TO DO
* Suggestions about language that can be used to inform certificate subscribers about their choice for revocation reason, and that they can leave it unspecified (default value) if they do not know. The most common reason that Subscribers revoke certificates is because they were told to by their Security team, with no explanation.
* Make it clear that we expect most revocations to not have a reason. Subscribers are not required to select a reason code unless their private key has been compromised.
== Key Compromise ==
TO DO
* Have sub section about key compromise regarding CSRs and verifiable evidence of compromise.
* currently there is not a standard way to demonstrate possession of the private key.
* document a few non-exclusive ways to confirm possession of the private key
=== CSRs ===
TO DO
* While a generic CSR alone does not prove possession of the certificate's private key, could a CSR with a specific common name do (e.g. "Proof of Key Compromise for [name of CA]") ?
* If a CSR alone does not prove possession of the certificate's private key, what kind of verifiable evidence could it be?
* Why should CA bother whether the subscriber possess the associated private key, if CA has already authenticated the subscriber? Is it meant to let CA decline the subscriber request in this case?
* How can it be determined? By self-declaration of the requester?
== OCSP and CRL ==
TO DO
* Address questions about consistency between OCSP and CRL revocation reason codes for a certificate. (Not required by Mozilla)
* BR section 7.3.2 says: “The singleExtensions of an OCSP response MUST NOT contain the reasonCode (OID 2.5.29.21) CRL entry extension.”
* Answer question about certificateHold in OCSP responses per RFC 6960?
== Banned Revocation Reasons ==
TO DO<br>
The following reason codes are banned for TLS end-entity certificates. Meaning that if revocation is for one of the following, then the reasonCode extension MUST NOT be provided for that entry in the CRL.
* unspecified (0)
* cACompromise (2)
* certificateHold (6)
* "-- value 7 is not used"
* removeFromCRL (8)
* aACompromise (10)
These banned reason codes are either already banned by the BRs or they are not applicable to end-entity TLS certificates. Below is a detailed explanation for each of them.
unspecified (0)
Section 7.2.2 of the BRs says: “The CRLReason indicated MUST NOT be unspecified (0). If the reason for revocation is unspecified, CAs MUST omit reasonCode entry extension”
cACompromise (2)
This reason code is used when revoking an intermediate certificate.
When an intermediate certificate is revoked and added to OneCRL all certificates signed by that intermediate certificate are also treated as revoked.
https://www.ccadb.org/policy#4-intermediate-certificates says: "If an intermediate certificate is revoked, the CCADB must be updated to mark it as revoked, giving the reason why, within 24 hours for a security incident, and within 7 days for any other reason."
Section 4.1 of Mozilla's Root Store Policy says: "If the revocation of an intermediate certificate chaining up to a root in Mozilla’s root program is due to a security concern, as well as performing the actions defined in the CCADB Policy, a security bug must be filed in Bugzilla."
certificateHold (6)
Section 7.2.2 of the BRs says: “ If a CRL entry is for a Certificate subject to these Requirements, the CRLReason MUST NOT be certificateHold (6).”
removeFromCRL (8)
Section 4.10.1 of the BRs says: “Revocation entries on a CRL or OCSP Response MUST NOT be removed until after the Expiry Date of the revoked Certificate.”
aACompromise (10)
Not applicable to TLS certificates. aACompromise is used for attribute certificates when aspects of the attribute authority (AA) have been compromised.
