All, I have made the following changes to the “DRAFT Policy about CRLRevocation Reason Codes for TLS End-Entity Certificates <https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit?usp=sharing>” document, based on feedback received during a discussion with the CA/Browser Forum Server Certificate Working Group.
1) Changed the order of the list and sections to indicate an order of precedence: keyCompromise (RFC 5280 Reason Flag #1) privilegeWithdrawn (RFC 5280 Reason Flag #9) cessationOfOperation (RFC 5280 Reason Flag #5) affiliationChanged (RFC 5280 Reason Flag #3) superseded (RFC 5280 Reason Flag #4) 2) When applicable, moved the intended usage scenarios to the top of each section. 3) Added the information in parentheses to the following sentence in the third paragraph of top section. “Tools that the CA provides to the certificate subscriber MUST allow for these options to be easily specified when the certificate subscriber requests revocation of their certificate, with the default value being that no revocation reason is provided (i.e. the default corresponds to the CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL).” 4) Clarified the sentence about CSR in the keyCompromise section: Changed “A CSR does NOT prove possession of the certificate’s private key for the purpose of initiating a revocation.” To “A CSR alone does not prove possession of the certificate’s private key for the purpose of initiating a revocation.” 5) Added Note about updating the revocationDate to the third paragraph of the keyCompromise section: "Note: Backdating the revocationDate field is an exception to best practice described in RFC 5280 (section 5.3.2); however, this policy specifies the use of the revocationDate field to support TLS implementations that process the revocationDate field as the date when the certificate is first considered to be compromised." 6) Moved the paragraph about not-authorized/incomplete validations from the keyCompromise section to the privelegeWithdrawn section. “The CA MUST use either the privilegeWithdrawn reasonCode or the superseded reasonCode when the CA obtains verifiable evidence that the certificate was issued to a subscriber who does not own or control all of the domain names listed in the certificate. The CA SHALL determine which of those two reasonCodes is appropriate under the circumstances of the revocation. For example; - the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization; or - the CA obtains reasonable 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.” I will greatly appreciate feedback on the current draft of this policy <https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit?usp=sharing> . 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/a3055259-d86c-449d-9588-8c5b61e0ab02n%40mozilla.org.
