[Servercert-wg] Ballot SC31 Browser Alignment - CRL and OCSP profiles

[Ryan Sleevi]

On Thu, Jun 25, 2020 at 12:12 PM Corey Bonnell via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> In giving another pass on the SC31 ballot text, I have the following
> questions/comments:
>
>
>
> From 7.2.2 (
> https://github.com/cabforum/documents/pull/195/files#diff-7f6d14a20e7f3beb696b45e1bf8196f2R1986
> ):
>
> > The `CRLReason` indicated MUST NOT be unspecified (0), MUST NOT be
> certificateHold (6), and MUST indicate the most appropriate reason for
> revocation of the certificate.
>
>
>
> 1. Does this requirement apply to end-entity certificate CRL entries? The
> formatting makes it appear that it does, but the Root Program requirement
> where this is derived from only is for CA certificates.
>

So there's two parts to unpack:
A)  Is the reason code required
B) If the reason code is present, what's expected

The attempt to answer A is
https://github.com/cabforum/documents/pull/195/files#diff-7f6d14a20e7f3beb696b45e1bf8196f2R1990-R1994

It MUST be present for Intermediates. This comes from Microsoft.
It SHOULD be present for end-entities. This comes from browsers consuming
CRLs and acting on them (Apple, Google, Mozilla), and those that prioritize
reason status (Google).

The answer for B is
https://github.com/cabforum/documents/pull/195/files#diff-7f6d14a20e7f3beb696b45e1bf8196f2R1995-R1997

This is profiling a SHOULD of the relevant RFCs into a MUST, and is
effectively saying "Use the smallest possible encoding". If a Subscriber
certificate is revoked for an unspecified reason, the "minimal encoding" is
actually to omit the CRLReason entirely. It has the same semantics, but
saves twelve bytes.

Here, this applies to *all* entries in the CRL. The prohibition on
certificateHold reflects the prohibition on certificate suspension.

2. Given that the semantics of the X.509 reasonCodes are not well defined
> [1], do Root Programs have guidance on what each allowed reasonCode means
> and when it is most appropriate to use? Absent this, I think the “MUST”
> requirement should be relaxed to a “SHOULD” (or eliminated entirely) until
> there are commonly agreed-upon semantics for the allowed set of reasonCodes.
>

The intent here is that the CA defines this, and what they define, they
follow. I agree that there's an opportunity to improve the consistency
across CAs, but I think similar to SC30, or past work (e.g. CAA), the first
step is to permit CAs to work through their policies as to what most
appropriate means, based on the criteria they define and the guidance
within RFC 5280 and, where appropriate, ITU-T X.509.


>
>
> From 7.3 (
> https://github.com/cabforum/documents/pull/195/files#diff-7f6d14a20e7f3beb696b45e1bf8196f2R1998
> ):
>
> > The `CRLReason` used SHALL contain a value permitted for CRLs, as
> specified in Section 7.2.2.
>
>
>
> Similar to question #1 above, does this apply to OCSP responses for
> end-entity certificates?
>

 If present, yes.

Similar to answer A, this is optional for end-entity certificates to be
present, but when it is present, it should follow a consistent form as the
CRL, since OCSP and CRLs are meant to be interchangeable to an extent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200625/93a7f975/attachment-0001.html>