On Fri, Sep 20, 2019 at 4:20 PM Curt Spann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This is a great discussion and I want to thank everyone for their
> continued input. Let me try and summarize my interpretation based on the
> input from this thread and related RFC.
>

I think an important part missing from this, overall, is to highlight that
these clauses only apply with respect to definitive responses. That is,
this only applies to the set of responses for which a pre-certificate
exists (and thus a matching certificate is presumed to exist) or for where
a certificate actually exists.

For situations where neither a pre-certificate nor the actual certificate
exist, a responder isn't required to respond with a definitive response.
This is important to highlight, because the BRs allow for the use of
either/both of the 6960-profile of OCSP, or the 5019 (Lightweight) profile
of OCSP. The latter is important, because it more realistically reflects
what the majority of CAs implement, and we've seen that running online
signing via 6960 is fraught with peril (e.g. Andrew Ayer's excellent
analysis in 2016 -
https://groups.google.com/d/msg/mozilla.dev.security.policy/x3TOIJL7MGw/0fzCI3q3BQAJ
).

In a 5019, the response of "unauthorized" is specifically extended to
account for some of these operational concerns, within Section 2.2.3.

So it was unclear if you were attempting to exhaustively list the statuses
that a CA might generate, or exhaustively list the statuses relevant to the
subset of (pre-cert || cet). For the rest, I'll assume the latter - that
we're only talking about "proof of existence" well, existing.


> My interpretation is an “unknown” OCSP response should be used in the
> following conditions:
> 1. When the OCSP request contains an issuerNameHash and issuerKeyHash for
> which the OCSP responder is NOT authoritative (wrong issuing CA).
>

Presuming the OCSP responder supports the requestor CertID algorithm :)


> 2. When the OCSP request contains an issuerNameHash and issuerKeyHash for
> which the OCSP responder IS authoritative (correct issuing CA) but for
> whatever reason the OCSP responder does not know the status of the
> requested certificates and ONLY if the certificate for which the status is
> requested contains another OCSP responder URL available in the AIA
> extension.
>

I'm not sure I understand where the "ONLY" clause comes from? 6960 and 5280
both presuppose the existence of other sources of revocation, beyond those
enumerated within the AIA. For 6960, Section 2.2 leaves this a bit up in
the air. So I don't think either the policies or text currently require
this "ONLY" clause, but I do think we want to nail down the situations
here. As it relates specifically to the (precert || cert) case, the BRs
treat the responder as a singular "the", so I don't think the ONLY
applies... so I think this whole thing washes out as "not allowed" for the
case of (precert || cert), and is met by "unauthorized", as well as
possible transport-layer options (RFC 5019 is somewhat silent, AFAICT, on
this)


> My interpretation is a “revoked” OCSP response should be used in the
> following conditions:
> 1. When the OCSP request contains an issuerNameHash and issuerKeyHash for
> which the OCSP responder IS authoritative and the requested certificate has
> been revoked.
>

Agreed


> 2. When the OCSP request contains an issuerNameHash and issuerKeyHash for
> which the OCSP responder IS authoritative and the CA corresponding to the
> issuerNameHash and issuerKeyHash has been revoked.
>

Agreed, with a caveat. This is a MAY derived from Section 2.7, and so I
wasn't sure if the suggestion was enumerating it as a MUST ("should be
used") or merely acknowledging it as a valid situation for revoked.


> 3. When the OCSP request contains an issuerNameHash and issuerKeyHash for
> which the OCSP responder IS authoritative and the requested certificate has
> not been issued. This OCSP response MUST include the extended revoked
> definition response extension in the response, indicating that the OCSP
> responder supports the extended definition of the "revoked" state to also
> cover non-issued certificates. The SingleResponse related to this
> non-issued certificate MUST specify the revocation reason certificateHold
> (6), MUST specify the revocationTime January 1, 1970, and MUST NOT include
> a CRL references extension or any CRL entry extensions. [1]
>

This is where we get messy, and what I was trying to untangle above.

If the assumption of policy is that the existence of a pre-certificate is
proof of equivalent issuance, then the only situation this arises is if and
only if the CA is running an online signing service in line with 6960,
rather than the pre-distribution approach of RFC 5019 that the scale of the
Web PKI effectively ensures is necessary, and only in the cases where a
pre-certificate /doesn't/ exist.

This isn't entirely pedantry on "issuance" either - as called out in 6960,
Section 2.2, "non-issuance" is
   the associated CA
   has no record of ever having issued a certificate with the
   certificate serial number in the request, using any current or
   previous issuing key

The existence of a pre-certificate is, as noted, proof that the CA has a
record of having issued a certificate with the certificate serial number in
the request.

It's important to realize that Section 5 of RFC 6960 highlights further
discussion here, which notes that this situation is completely avoided by
issuing serials with random entropy - i.e. what the BRs require.

So to recap:
- In RFC 5019, it's clear that one of the core goals of 5019 is to not
require the creation of definitive responses for the entire serial space.
So we're only talking (pre-cert || cert) definitive cases.
- In RFC 6960, it's clear that one of the core goals of the extended
response is to leave it /optional/ (MAY) for CAs to respond Revoked, and
for serial numbers they have no record of having issued. So we're talking
!(pre-cert || cert) cases.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to