[Servercert-wg] Possible conflict between BR and RFC 6960?

[Ryan Sleevi]

On Fri, May 29, 2020 at 4:06 AM Berg, Patrick van den via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> *The "unknown" state indicates that the responder doesn't know about the
> certificate being requested, usually because the request indicates an
> unrecognized issuer that is not served by this responder.*
>
>
>

> *Conflicting requirements*
>
> When comparing these two I can deduce the BR is stricter in who can sign a
> response: “a Trusted Responder whose public key is trusted by the
> requestor” is no longer allowed. This sounds reasonable.
>

Not just reasonable, necessary. A trusted responder is defined by the
client, not the server; that is, it's an out-of-band mechanism to allow a
client to designate a different responder than the one provided for in the
certificate; similar to the approach by SCVP (RFC 5055)


> However, when looking at the three definitive responses in RFC 6960, it is
> only possible to adhere to the BR when answering with either “good” of
> “revoked”. It is inherently impossible to do this for “unknown” because the
> issuer is unrecognized (not served by the responder).
>

This isn't correct. In order for this to hold, you have to read "usually"
(emphasis added to your original message) as MUST; that is, that unknown
can *only* be about that. But that's not the case, and so there's nothing
wrong for using "unknown" beyond that.

For example, responding "unknown" to a non-issued serial is perfectly fine.

However, the issue in the bug is that an affirmative "unknown" was provided
for a certificate for which the OCSP responder is very explicitly the
responder of note, by virtue of it being included within the certificate
itself, and using it with a different responder certificate than that for
the CA certificate. An OCSP responder responding "unknown" for a
certificate it affirmatively issued is a problem, just as an OCSP responder
responding "good" for a certificate it affirmatively does not know about is
an issue (and why 4.9.10 seeks to prevent it). Equally, however, responding
with a signed message that doesn't validate for the certificate (that is,
using a "default responder") is also a problem.

I think everybody agrees on the first part of the definition of
> “unauthorized” in that the client itself is not authorized to make a query.
> This was not relevant in the case of the bug post. I assume people thought
> this was about “the server is not capable of responding authoritatively”.
> However, “not capable of responding authoritatively” and “not an authorized
> responder” are two different things. The meaning of “not capable of
> responding authoritatively” is in fact (using a quite prosaic example)
> “Yes, I am in theory capable of giving an answer because I **do** know
> the issuer, but am just not **allowed** to because I cannot do this
> authoritatively; in the distributed environment I operate in the responder
> next to me has more up-to-date information on the requested certificate and
> therefore is the authoritative one”. At least, that is the only way I can
> interpret RFC 6960 and the example they refer to in it in RFC 5019.
>

And that's a scenario (responder failover) that is intentionally not
supported by the BRs. The RFC 5280 approach of attempting every URL is
itself fraught with peril, and that's why the BRs require there be a
canonical responder capable of answering for an issued certificate, and
that the canonical responder appear as an HTTP-schemed URL within the
certificate.


> The way I see it right now is using the work-around in the bug post does
> fix the issue of not signing with the right issuer certificate in
> accordance to the BR, but introduces a new issue of being not compliant
> with RFC 6960.
>
>
>
> Does this all make sense to you, or am I overlooking or misinterpreting
> anything?
>

Yes, you're misinterpreting "usually" to mean MUST, but it's not. It's an
informative example, rather than a normative restriction.


> *OCSP definitive response Unknown MUST be signed with a Trusted Responder
> whose public key is trusted by the requestor.*
>
> *OCSP error responses MUST [in the RFC this is a MAY!] either:*
>
> *1.      **Be signed by the CA that issued the Certificates whose
> revocation status is being checked, or*
>
> *2.      **Be signed by an OCSP Responder whose Certificate is signed by
> the CA that issued the Certificate whose revocation status is being
> checked, or*
>
> *3.      **Be signed by a Trusted Responder whose public key is trusted
> by the requestor.*
>
The question of "MAY either" in an enumerated has raised interpretive
issues, although PKIX/LAMPs has aligned on "MAY either" being a "MUST only"
(see, for example, the LAMPs discussion on key usages for EC), although
clarity is good here. The problem, however, is that the notion of "Trusted
Responder" is not something the server knows; it's a client configuration
state that exists outside of the Web PKI state. It exists to allow local
policy, typically enterprise policy, override or supplant the processing
rules, and was envisaged as part of the monetization-of-OCSP-schemes that
we saw early on in OCSP's introduction. User agents broadly don't support
Trusted Responders; macOS removed support, NSS [Firefox] and Chrome never
supported, and while Microsoft has this capability vis-a-vis the root
certificate attributes, it's only exposed for Enterprise configuration.

The problem is we actually *want* Unknown responses to only be signed by
the first two. The elimination of "Trusted Responder" is largely handled
via 7.1.2.2 (c) / 7.1.2.3 (c), but I'd be supportive of making it explicit
within Section 7.3 (which
https://github.com/sleevi/cabforum-docs/pull/10 already
begins to add to).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200529/e7d55dcf/attachment.html>