<div dir="ltr"><div>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.</div><div><br></div><div>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"</div><div><br></div><div>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.</div><div><br></div><div>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?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 3, 2020 at 6:00 PM Berg, Patrick van den via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="NL">
<div class="gmail-m_-5486981972261634074WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Hi Ryan,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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!<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Best regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Patrick van den Berg<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">Van:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>
<br>
<b>Verzonden:</b> vrijdag 29 mei 2020 17:35<br>
<b>Aan:</b> Berg, Patrick van den <<a href="mailto:Patrick.Berg@logius.nl" target="_blank">Patrick.Berg@logius.nl</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br>
<b>Onderwerp:</b> Re: [Servercert-wg] Possible conflict between BR and RFC 6960?<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, May 29, 2020 at 4:06 AM Berg, Patrick van den via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><i><span lang="EN-US">The "unknown" state indicates that the responder doesn't know about the certificate being requested,
<b>usually</b> because the request indicates an unrecognized issuer that is not served by this responder.</span></i><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US">Conflicting requirements</span></b><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US">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. </span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">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).</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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
<i>only</i> be about that. But that's not the case, and so there's nothing wrong for using "unknown" beyond that.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">For example, responding "unknown" to a non-issued serial is perfectly fine.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">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
<span style="color:black">in </span>theory capable of giving an answer because I *<b>do</b>* know the issuer, but am just not *<b>allowed</b>* 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.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US">Does this all make sense to you, or am I overlooking or misinterpreting anything?</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Yes, you're misinterpreting "usually" to mean MUST, but it's not. It's an informative example, rather than a normative restriction.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><i><span lang="EN-US">OCSP definitive response Unknown MUST be signed with a Trusted Responder whose public key is trusted by the requestor.</span></i><u></u><u></u></p>
<p class="MsoNormal"><i><span lang="EN-US">OCSP error responses MUST [in the RFC this is a MAY!] either:</span></i><u></u><u></u></p>
<p class="gmail-m_-5486981972261634074gmail-m9036143656361435283msolistparagraph"><i><span lang="EN-US">1.</span></i><i><span lang="EN-US" style="font-size:7pt">
</span></i><i><span lang="EN-US">Be signed by the CA that issued the Certificates whose revocation status is being checked, or</span></i><u></u><u></u></p>
<p class="gmail-m_-5486981972261634074gmail-m9036143656361435283msolistparagraph"><i><span lang="EN-US">2.</span></i><i><span lang="EN-US" style="font-size:7pt">
</span></i><i><span lang="EN-US">Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked, or</span></i><u></u><u></u></p>
<p class="gmail-m_-5486981972261634074gmail-m9036143656361435283msolistparagraph"><i><span lang="EN-US">3.</span></i><i><span lang="EN-US" style="font-size:7pt">
</span></i><i><span lang="EN-US">Be signed by a Trusted Responder whose public key is trusted by the requestor.</span></i><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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 <a href="https://github.com/sleevi/cabforum-docs/pull/10" target="_blank">https://github.com/sleevi/cabforum-docs/pull/10</a> already begins to add to).<u></u><u></u></p>
</div>
</div>
</div>
</div>
<br>
<hr>
<font color="gray" size="1" face="Arial">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.<br>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. <br></font></div>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div></div>