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

[Ryan Sleevi]

On Thu, Jun 25, 2020 at 1:26 PM Corey Bonnell <CBonnell at securetrust.com>
wrote:

> > 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.
>
> Many CAs provide the ability for Subscribers to revoke their own
> end-entity certificates and supply their own reasonCodes with no manual
> intervention by CA support personnel.
>

Ah, thanks for clarifying. This is really useful feedback!


> In attempting to fulfill the “MUST” for selecting the most appropriate
> reasonCode, is the expectation that CAs must now work with the Subscriber
> on a per-revocation basis to determine the facts and circumstances
> surrounding the revocation to arrive the most appropriate reasonCode? Or
> can CAs continue to allow Subscribers to select their own reasonCodes
> (presumably from an acceptable subset of reasonCodes that can be chosen
> from)?
>

I guess a question here is if a key is compromised, does the CA allow the
customer to *not* specify that reason? I'm particularly interested in the
case where the CA is informed (e.g. via a problem report) of the compromise.

Figuring out how that is handled is, I think, important to figuring out how
best to answer your question :)


>
>
> Thanks,
>
> Corey
>
>
>
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Thursday, June 25, 2020 12:40 PM
> *To:* Corey Bonnell <CBonnell at securetrust.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] Ballot SC31 Browser Alignment - CRL and
> OCSP profiles
>
>
>
>
>
>
>
> 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
> <https://scanmail.trustwave.com/?c=4062&d=ktP03jw8Wsdzf10VIGVklQrreSN-fYkNs3wNRif2sg&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fpull%2f195%2ffiles%23diff-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
> <https://scanmail.trustwave.com/?c=4062&d=ktP03jw8Wsdzf10VIGVklQrreSN-fYkNsyBfF3Ck4A&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fpull%2f195%2ffiles%23diff-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
> <https://scanmail.trustwave.com/?c=4062&d=ktP03jw8Wsdzf10VIGVklQrreSN-fYkNsyELECX15Q&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fpull%2f195%2ffiles%23diff-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
> <https://scanmail.trustwave.com/?c=4062&d=ktP03jw8Wsdzf10VIGVklQrreSN-fYkNs3NXRnTx5A&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fpull%2f195%2ffiles%23diff-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/295e52de/attachment.html>