Confirm, administrator
5,526
edits
Changes
fixing problems with normative text (all-caps MUST) introducing requirements more stringent than MRSP
* No reason provided or unspecified (RFC 5280 CRLReason #0)
** When the reason codes below do not apply to the revocation request, the subscriber MUST NOT must not provide a reason code other than "unspecified".
* keyCompromise (RFC 5280 CRLReason #1)
** The certificate subscriber MUST must choose the "keyCompromise" revocation reason when they have reason to believe that the private key of their certificate has been compromised, e.g. an unauthorized person has had access to the private key of their certificate.
* affiliationChanged (RFC 5280 CRLReason #3)
** The certificate subscriber SHOULD should choose the "affiliationChanged" revocation reason when their organization's name or other organizational information in the certificate has changed.
* superseded (RFC 5280 CRLReason #4)
** The certificate subscriber SHOULD should choose the "superseded" revocation reason when they request a new certificate to replace their existing certificate.
* cessationOfOperation (RFC 5280 CRLReason #5)
** The certificate subscriber SHOULD should choose the "cessationOfOperation" revocation reason when they no longer own all of the domain names in the certificate or when they will no longer be using the certificate because they are discontinuing their website.
Section 7.2.2 of the [https://cabforum.org/baseline-requirements-documents/ CA Browser Forum Baseline Requirements] says:
''If a reasonCode CRL entry extension is present, the CRLReason MUST indicate the most appropriate reason for revocation of the certificate, as defined by the CA within its CP/CPS.''
Therefore, the CA MUST must ensure that their CP/CPS documents are in sync with their Subscriber Agreements in regards to appropriate reasons for revocation of TLS end-entity certificates.
== Tools for Requesting Revocation ==
