Clarification on affiliationChanged revocation reason code

246 views
Skip to first unread message

Jacob Hoffman-Andrews

unread,
Jun 24, 2022, 2:34:50 PM6/24/22
to dev-secur...@mozilla.org
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?

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.

Thanks,
Jacob

Ben Wilson

unread,
Jun 24, 2022, 3:06:21 PM6/24/22
to Jacob Hoffman-Andrews, dev-secur...@mozilla.org
Hi Jacob,

On Fri, Jun 24, 2022 at 12:34 PM 'Jacob Hoffman-Andrews' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> 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

Jacob Hoffman-Andrews

unread,
Jun 24, 2022, 3:47:36 PM6/24/22
to Ben Wilson, dev-secur...@mozilla.org
On Fri, Jun 24, 2022 at 12:06 PM Ben Wilson <bwi...@mozilla.com> wrote:
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.

We intend to specify the same reasonCodes in both CRLs and OCSP responses. The most straightforward choice would be for us to reject subscriber revocation requests that specify "affiliationChanged", requiring the subscriber to choose a more correct reasonCode. A second choice would be to accept those subscriber revocation requests but silently change them to "unspecified" before writing to our storage.

  - "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.

Sounds good! What about "subject's name" - what does that refer to? 

Ben Wilson

unread,
Jun 24, 2022, 5:02:02 PM6/24/22
to Jacob Hoffman-Andrews, dev-secur...@mozilla.org
"Subject's Name" would refer to the Organization Name.  We can clarify that more.

Kathleen Wilson

unread,
Jul 5, 2022, 6:59:32 PM7/5/22
to dev-secur...@mozilla.org
I updated https://wiki.mozilla.org/CA/Revocation_Reasons#Communication_to_Subscribers to add a sub-bullet under affiliationChanged:
" This option does not need to be made available by CAs who only issue DV certificates that do not include any Subject Identity information."

Thanks,
Kathleen
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaZzVgpk6p8DS9sxN-U%2B6rPqhgkeSu1hR42MEfnT9USVQ%40mail.gmail.com.

Jacob Hoffman-Andrews

unread,
Jul 5, 2022, 8:58:27 PM7/5/22
to Kathleen Wilson, dev-secur...@mozilla.org
Thanks!
Reply all
Reply to author
Forward
0 new messages