Hi Kathleen,
I have a couple of additional questions on the latest policy: #1) regarding the last sentence of the second bullet under the scope of the keyCompromise which says: * The CA MUST NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key. And specifically the statement “MAY block issuance… “. Should this be limited to this subscriber, or would a CA be permitted to block issuance of ALL certificates with this public key? If it’s globally, then I think there is a DoS issue. Should we clarify the scope of the “MAY” by adding “…for that certificate subscriber” to the end of the sentence? #2 privilegeWithdrawn I understand the prior intent that the CA must be the entity that sets this and that it cannot be supplied by the Subscriber; however, a new bullet was added that says: “the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization.” Isn’t this basically the subscriber specifying the reason without the CA actually “validating” it’s true? If so, then is it necessary to prohibit the subscriber from selecting this reason directly? #3 superseded This was recently added * or the CA has replaced the certificate due to domain authorization or compliance issues other than those related to keyCompromise or privilegeWithdrawn. but does a CA ever “replace” certificates? I think that the applicant/subscriber is the only entity that can request replacement certificates, unless there is a scenario that I’m not thinking of. #4 General question In a few places we say to use a specific reason code only when X, Y and Z reasons are not used. Is this necessary vs. just saying when it can be used and being silent on when it can’t be used or adding these dependencies? It makes determining the right reason code much more transparent, imo Doug From: [email protected] <[email protected]> On Behalf Of Kathleen Wilson Sent: Monday, March 14, 2022 7:19 PM To: [email protected] Subject: Re: Adjusting the Draft Policy for Revocation Reason Codes 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] <mailto:[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 <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/a3055259-d86c-449d-9588-8c5b61e0ab02n%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/PUZPR03MB612977DC6E156C6B1B8BF313F0179%40PUZPR03MB6129.apcprd03.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
