Thank you to those of you who have already replied. I have incorporated your feedback into the draft policy text here:
https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit?usp=sharing Below are specific responses to your feedback so far. I agree that we need to define the circumstances under which the affiliationChanged (3) and superseded (4) reason codes may be used, so here is an initial attempt. *affiliationChanged* (3) The CRLReason affiliationChanged (3) MUST be used when the subscriber has requested that their certificate be revoked for this reason, or the CA has verifiable evidence that the subscriber no longer owns the domain names in the certificate and there is no evidence of a private key compromise. Otherwise this CRLReason MUST NOT be used. The affiliationChanged (3) CRLReason is intended to be used to indicate that the subscriber will no longer be using the certificate, or the subscriber has terminated their relationship with the organization indicated in the Distinguished Name attribute of the certificate and the organization's security policy requires that a new certificate be issued. *superseded* (4) The CRLReason superseded (4) MUST be used when the certificate subscriber has requested that their certificate be revoked for this reason or the CA has replaced the certificate due to compliance issues other than those related to keyCompromise (1) and privilegeWithdrawn (9). Otherwise this CRLReason MUST NOT be used. The superseded (4) CRLReason is intended to be used to indicate when either the subscriber or the CA has needed to replace the certificate for reasons other than certificate expiration, keyCompromise (1), privilegeWithdrawn (9), and affiliationChanged (3). ~~ > Does it make sense to make privilegeWithdrawn a catchall for all CA revocations due to compliance issues except those related to keyCompromise? There’s some revocations not covered by the other categories, for example where there was an audit issue and the CA is revoking the certs under that SubCA. I prefer to add this situation to superseded (4). Please let me know if you have feedback on the text above to make it more clear in regards to this type of situation. ~~ >> NOT applicable to TLS server (end-entity) certificates … Unspecified (0) > SC31 (Browser Alignment ballot) already introduced this prohibition for “unspecified”, so I don’t believe anything needs to be changed from a Mozilla policy standpoint for this reason code. Agreed. I’m thinking that the policy text will focus on the reason codes that ARE allowed for TLS server certs, and just state that any other reason code is not allowed to be used... When a CRL entry is for an end-entity SSL certificate the reasonCode extension MUST either not be provided or MUST contain one of the following CRLReason codes. ~~ >> the CA MUST make the information regarding its intent to revoke available to the Subscriber before revoking the certificate… > I believe that BR 4.9.5 already makes it clear that the CA SHALL notify (“work with”) the Subscriber prior to revocation, so I’m not sure what is different about this proposal and the existing requirement. Can you clarify how this proposal is different from the current BR language? Ooops. I temporarily forgot the original intent of this part of the proposal… The original intent was that the Subscriber should not experience a sudden DOS due to the CA revoking their certificate without any advance notice. So I will pull this out of the keyCompromise (1) and privilegeWithdrawn (9) reasons, and have it stand on its own for all revocations of TLS server certs. How about the following text at the top of the new section? The CA MUST make the information regarding its intent to revoke an end-entity SSL certificate available to the certificate subscriber before revoking the certificate. When the revocation is the result of a Certificate Problem Report as defined in the CA/Browser Forum Baseline Requirements, the CA must communicate with the subscriber as described in section 4.9.5 of the CA/Browser Forum Baseline Requirements. 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/b5951b04-0ffc-4b7d-9e6e-3f5f03fc8366n%40mozilla.org.
