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

[Ryan Sleevi]

I think you're definitely reading too deeply into it. You're
seemingly applying a SHOULD-level semantic, but that sort of semantic
doesn't apply here, and if it did, it'd be flagged as SHOULD.

As you can see from what I cited, re: RFC 5019, that the conclusion you're
reaching can't logically hold, and was intentionally being addressed (re:
unauthorized). Even if it was a SHOULD, the existence of RFC 5019 would
demote that to a MAY, at best, because the dominant use case is actually to
respond "unauthorized"

In terms of Web PKI, RFC 5019 is more aligned with what the ecosystem
benefits from and what clients are more in line to expect.

In the end, both cases cause the same processing behaviour with respect to
RFC 5280, and so it's a bit of a moot point, right?

On Wed, Jun 3, 2020 at 6:00 PM Berg, Patrick van den via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Hi Ryan,
>
>
>
> I do recognize my case is getting thinner with every exchanged message and
> I do see the reasoning behind your answers. One thing still bothers me
> though: limited context is provided in RFC 6960 regarding “unknown” and
> “unauthorized” messages. But the one example given with a definitive
> response of “unknown” is “the request indicates an unrecognized issuer that
> is not served by this responder”. The fact that the word “usually” prefixes
> this example in the RFC for me indicates the authors intended this as the
> primary use case for using the “unknown” message. Although I concur with
> your observation there is no “MUST” involved so “unauthorized” can also be
> an option, it does feel to me like your explanation is following the letter
> (or rather: deductions from the letter) but not the spirit of the standard.
> At the very least the RFC could use a clarification!
>
>
>
> Best regards,
>
> Patrick van den Berg
>
>
>
>
>
> *Van:* Ryan Sleevi <sleevi at google.com>
> *Verzonden:* vrijdag 29 mei 2020 17:35
> *Aan:* Berg, Patrick van den <Patrick.Berg at logius.nl>; 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> 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.
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200603/69d493d6/attachment.html>