<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 2, 2020 at 6:22 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_140011039835693220WordSection1">
<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)">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.<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="gmail-m_140011039835693220MsoNoSpacing"><span lang="EN-US">> > However, when looking at the three definitive responses in RFC 6960,<u></u><u></u></span></p>
<p class="gmail-m_140011039835693220MsoNoSpacing"><span lang="EN-US">> > it is only possible to adhere to the BR when answering with either “good”<u></u><u></u></span></p>
<p class="gmail-m_140011039835693220MsoNoSpacing"><span lang="EN-US">> > or “revoked”. It is inherently impossible to do this for “unknown”<u></u><u></u></span></p>
<p class="gmail-m_140011039835693220MsoNoSpacing"><span lang="EN-US">> > because the issuer is unrecognized (not served by the responder).<u></u><u></u></span></p>
<p class="gmail-m_140011039835693220MsoNoSpacing"><span lang="EN-US">><u></u> <u></u></span></p>
<p class="gmail-m_140011039835693220MsoNoSpacing"><span lang="EN-US">> This isn't correct. In order for this to hold, you have to read "usually"<u></u><u></u></span></p>
<p class="gmail-m_140011039835693220MsoNoSpacing"><span lang="EN-US">> (emphasis added to your original message) as MUST; that is, that unknown<u></u><u></u></span></p>
<p class="gmail-m_140011039835693220MsoNoSpacing"><span lang="EN-US">> can <i>only</i> be about that. But that's not the case, and so there's nothing wrong<u></u><u></u></span></p>
<p class="gmail-m_140011039835693220MsoNoSpacing"><span lang="EN-US">> for using "unknown" beyond that.<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)">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?</span></p></div></div></blockquote><div><br></div><div>It's not an absolute requirement that you use "UNKNOWN" here. There's not a MUST-level requirement (or, in your wording, HAS level ;D)</div><div><br></div><div>That's not me getting creative on the fly; you can see this in the discussion of Section 2.3's exception cases, such as "unauthorized"</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> The response "unauthorized" is returned in cases where the client is<br> not authorized to make this query to this server or <b>the server is not<br> capable of responding authoritatively</b> (cf. [RFC5019], Section 2.2.3).</blockquote><div><br></div><div><a href="https://tools.ietf.org/html/rfc5019#section-2.2.3">https://tools.ietf.org/html/rfc5019#section-2.2.3</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> As long as the OCSP infrastructure has authoritative records for a<br> particular certificate, an OCSPResponseStatus of "successful" will be<br> returned. When access to authoritative records for a particular<br> certificate is not available, the responder MUST return an<br> OCSPResponseStatus of "unauthorized". As such, this profile extends<br> the RFC 2560 [OCSP] definition of "unauthorized" as follows: <br> The response "unauthorized" is returned in cases where the client<br> is not authorized to make this query to this server or<b> the server<br> is not capable of responding authoritatively</b></blockquote><div><br></div><div>In this case (both in 5019 and 6960), if the issuer is unrecognized, the server is not capable of responding authoritatively, and returning "unauthorized" is fine.</div><div><br></div><div>If a CA had to respond with "Unknown", then the entire point of RFC 5019 is defeated, and more broadly, the act of pre-generating OCSP responses, since you'd have to sign responses for every possible serial, all the time.</div><div><br></div><div>The semantics here of the response are, in part, left to the profile. The syntax is set forth in the RFCs, and some of the semantics are nailed down, but this isn't the case here. You can see in RFC 5019 that it's a MUST of "unauthorized" - which is to say, MUST NOT Unknown. The BRs profile here right now only requires that you must not reply Good to unissued certificates, which was the default behaviour for OCSP responders populated by CRLs. </div></div></div>