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

[Ryan Sleevi]

On Tue, Jun 2, 2020 at 6:22 PM Berg, Patrick van den via Servercert-wg <
servercert-wg at cabforum.org> wrote:

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

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)

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"

   The response "unauthorized" is returned in cases where the client is
>    not authorized to make this query to this server or
> *the server is not   capable of responding authoritatively* (cf.
> [RFC5019], Section 2.2.3).


https://tools.ietf.org/html/rfc5019#section-2.2.3

   As long as the OCSP infrastructure has authoritative records for a
>    particular certificate, an OCSPResponseStatus of "successful" will be
>    returned.  When access to authoritative records for a particular
>    certificate is not available, the responder MUST return an
>    OCSPResponseStatus of "unauthorized".  As such, this profile extends
>    the RFC 2560 [OCSP] definition of "unauthorized" as follows:
>        The response "unauthorized" is returned in cases where the client
>       is not authorized to make this query to this server or
> * the server      is not capable of responding authoritatively*


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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200602/af2a17d8/attachment.html>