miguelantonios-zz
commented
2 years ago Hello Kathleen,
We believe that there is a need to clarify two issues in the proposed language.
According to the current wording, a CA is allowed to use the keyCompromise reason if a third party contacts the CA and provides evidence that the Public Key in a Certificate suffered a Key Compromise. However, it does not mandate the use of this reason, so a CA can use unspecified (0), taking into consideration all the requirements on the use of this reason. Is this the intent or do we want to mandate the use of this reason in such cases?
In addition, the proposed wording specifies that
“if someone other than the Subscriber requests revocation by providing evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise, then the CA must communicate with the Subscriber before revoking the Certificate”.
We think it is important to clarify what is expected of CAs to avoid introducing notification obligations that cannot be met at scale. Also there is a risk that too onerous notification requirements could get in conflict with the BR requirement to revoke the certificate in time under Section 4.9.1.1. Specifically, We would like to clarify that CAs would not be expected to push notifications to subscribers given that this can likely be described as a push model for notifications. This model has had several problems within the context of the ARI ACME extension (ref: https://mailarchive.ietf.org/arch/msg/acme/3wDZfTxjDqmhSxwBKjX3uPBzULM/) which is why a pull model was finally adopted (ref: https://www.ietf.org/archive/id/draft-aaron-acme-ari-00.html). If the push model was a requirement then it would make ARI ACME incompatible with the Mozilla Root Store Policy.
To clarify this we would like to propose the following alternative wording:
“if someone other than the Subscriber requests revocation by providing evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise, then the CA must make the information regarding its intent to revoke available to the Subscriber before revoking the certificate.”
This wording ensures that the information is available to the Subscriber, and it is also compatible with ARI ACME.
Please let us know your thoughts on the proposed changes and thanks for taking the time to read.
Best wishes,
Miguel Sanchez on behalf of Google Trust Services
WilsonKathleen
Add policy to clarify when certain revocation codes must be used for TLS end-entity certificates.
For example:
CAs MUST offer to their TLS certificate subscribers the following revocation reason options, with explanation about when to choose each option. 1) keyCompromise 2) affiliationChanged 3) superseded
The CRLReason keyCompromise MUST only be used for TLS end-entity certificates when one or more of the following occurs:
If someone other than the certificate subscriber requests revocation, then the CA must communicate with the certificate subscriber before revoking the certificate. This can happen when the CA determines that the certificate should be revoked for one of the reasons listed above, or when someone other than the subscriber requests revocation by supplying the certificate's private key.
The CRLReason affiliationChanged (3) MUST only be used when the certificate subscriber has requested that their certificate be revoked for this reason.
The CRLReason superseded (4) MUST only be used when the certificate subscriber has requested that their certificate be revoked for this reason.