The use of reason codes in RFC 5280

while reviewing RFC 5280, I noticed that the reason codes used in different extensions seem to vary. I would like to ask, for the CRL Distribution Points extension, which one does it use— the first one or the second one?

(1)CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), removeFromCRL (8), privilegeWithdrawn (9), aACompromise (10) }

(2)ReasonFlags ::= BIT STRING { unused (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), privilegeWithdrawn (7), aACompromise (8) }

Solution

They are both used, but have different purposes:

The 1st - the CRLReason - is used within a published CRL to state why a certificate was revoked. This is an enumeration as there can be only one reason for revocation.

The CRL Distribution Point uses the 2nd - the ReasonFlags - so that it can have different distribution points for different revocation reasons. This is a bit string as a distribution point can be used for multiple reasons.

Note however, that the RFC says:

This profile RECOMMENDS against segmenting CRLs by reason code.

For example, a hypothetical PKI for example.com (which goes against the recommendation) operates segmented Distribution Points:

A Distribution Point whose URL is http://pki.example.com/cdp/compromised.crl has reasons code 1,2, & 8, and
A Distribution Point whose URL is http://pki.example.com/cdp/others.crl has reasons code 3,4,5 & 7.
This hypothetical PKI doesn't support the certificateHold option, so there isn't a Distribution Point for reason code 6.

If a certificate was revoked due to its privilege being withdrawn, the CRLReason extension within the published CRL would contain the value 9 (privilegeWithdrawn) against that certificate's serial number.

The PKI would publish the CRL at the distribution point whose ReasonFlag contains the value 7 (for privilegeWithdrawn) - that is, in others.crl.

Both URLs and their ReasonFlags are already placed in the CRL Distribution Point extension of the certificate in question so that relying parties can find the correct CRL.

Presumably, the recommendation is not to segment as relying parties would have to check multiple CRLs each time they verify a certificate.