Comments inline: On Wed, Dec 1, 2021 at 5:16 PM Kathleen Wilson <[email protected]> wrote:
> *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. > Is the intent here that, if the CA receives verifiable evidence that the subscriber no longer owns the identifiers in the certificate, then they must revoke with `affiliationChanged`? Or is the intent that, if the CA is *asked* to revoke, and they also have verifiable evidence that the subscriber no longer owns the identifiers, then they must use the `affiliationChanged` reason code? The latter makes complete sense to me. But the former sounds to me like it would require CAs to set up systems similar to how they handle key compromise certificate problem reports. The standard for "demonstration of key compromise" is pretty easy -- either show the private key itself, or something you signed with the private key -- but it's not clear to me what "verifiable evidence" would constitute for this case, and how / how quickly a CA would be expected to respond when receiving such information unsolicited (aside from the normal 24-hour requirement if it is the subscriber requesting revocation themself). > *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). > nit: the paragraph above for `affiliationChanged` has a comma in "...revoked for this reason, or the CA has..."; this one does not. > > 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. > > I think that there is a meaningful difference between this text and the current text of the BRs, and that is slightly concerning to me. The BRs currently say (section 4.9.5) "the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or other revocation-related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate." The phrase "work with" is supremely vague, but it does not (to me) mean the same thing as "make the information regarding its intent to revoke... available to the certificate subscriber". For example, when a Subscriber uses the ACME API to request the revocation of their own certificate, that feels like it satisfies the "work with" requirement -- the subscriber and the entity reporting the revocation-related notice are the same, and they have requested immediate revocation, and the ACME CA complies. However, there is no room in the protocol for the ACME CA to notify the subscriber of its intent to revoke: by the time the API call has completed, the cert has already been revoked. As another example, the ACME protocol marks the "contact" field on subscriber accounts as optional, meaning that some subscribers cannot be notified prior to revocation if (e.g.) their key is demonstrated to be compromised. I'm not sure what the right solution here is (and I'm not really a fan of the vague "work with" language either) but this proposed notification requirement feels like a meaningful change, not just a rephrasing or clarification. Thanks, Aaron -- 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/CAEmnErdgGysZBEYem_3N1ZABEdbGriAdvmfoFwc7u8FioD5ggQ%40mail.gmail.com.
