Hi Jacob, On Fri, Jun 24, 2022 at 12:34 PM 'Jacob Hoffman-Andrews' via [email protected] <[email protected]> wrote:
> Putting together the documentation for our subscribers about revocation > reason code, I ran into a bit of a snag: > > > The CRLReason affiliationChanged is intended to be used to indicate that > the subject's name or other subject identity information in the certificate > has changed, but there is no cause to suspect that the certificate’s > private key has been compromised. > > > > Unless the keyCompromise CRLReason is being used, the CRLReason > affiliationChanged MUST be used when: > > > > - the certificate subscriber has requested that their certificate be > revoked for this reason; or > > - the CA operator has replaced the certificate due to changes in the > certificate’s subject information and the CA has not replaced the > certificate for the other reasons: keyCompromise, superseded, > cessationOfOperation, or privilegeWithdrawn. > > Otherwise, the affiliationChanged CRLReason MUST NOT be used. > > As a DV-only CA, there is no Subject Identity Information in any of our > certificates, so it cannot change. But we are obligated to use this reason > code if the certificate subscriber requests it, even if we know that it can > never be the correct reason code. > > Telling our subscribers that they should use this when Subject Identity > Information changes is confusing. Is it acceptable to tell them simply > "this reason code should not be used for Let's Encrypt certificates?" Is it > acceptable to reject this reason code when requested via API? > I think it would be appropriate to shield the "affiliationChanged" reason code from appearing in your CRLs when you only issue DV certificates, and they don't include Subject Identity Information. > > Also, a couple of drafting nits (sorry for not noticing these during > review): > > - Presumably "subject identity information" refers to the definition in > the BRs, but it is not capitalized here and does not explicitly reference > the BRs. > - "subject's name" is not totally clear to me. From context it seems like > it means a subset of "subject identity information" (specifically the > Organization field), but that would be redundant. Alternatively, it could > refer to the entire Subject field (which is encoded as an X.501 Name), but > then "subject identity information" would be a subset of "name" and it > would be redundant in the other direction. > Yes. We should have been more clear that Subject Identity Information" refers to the definition in the BRs. We can make this clearer in the guidance. Meanwhile, does the answer above resolve this issue for you? > > Thanks, > Jacob > > Thanks! Ben -- 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/CA%2B1gtaZ7eg%2BgsGWUKu6rt7jBOWeXQMUfK9i%2B7%2B14AiUFHntH%3DA%40mail.gmail.com.
