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

Tue Jun 2 15:22:19 MST 2020

Hi Ryan,

Sorry for this late reply, but I had a long weekend. Thanks for your clear and elaborate answer! It helps to get a clearer picture. I do however think the problem I wanted to pay attention to still stands, albeit in a narrower fashion. Let me explain.

> > 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”

> >  or “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.

Your points are all valid, but assuming the issuer is indeed unrecognized (so in this case we are not following the scenario in the Bugzilla ticket anymore), the responder HAS to answer with an UNKOWN as started in RFC 6960, but it will never be possible for it to sign the response as stated in BR 4.9.9. Therefore I think there still should be a clarification in the BR. Or am I still overlooking something here?

Best regards,
Patrick van den Berg

Van: Ryan Sleevi <sleevi at google.com>
Verzonden: vrijdag 29 mei 2020 17:35
Aan: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Onderwerp: Re: [Servercert-wg] Possible conflict between BR and RFC 6960?

On Fri, May 29, 2020 at 4:06 AM Berg, Patrick van den via Servercert-wg <servercert-wg at cabforum.org<mailto: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).
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200602/5d9b8c7d/attachment-0001.html>