RE: OCSP response pre-production

["Florian Oelmaier" <oelmaier@xxxxxxxxxxx>]

> >>- re-assert that it is not conformant to RFC2560 to send back
> >>a response 
> >>without to nonce to a request requiring a nonce (it might 
> >>change in OCSPv2)
> > 
> > The RfC states: "[A request includes] [...] optional 
> extensions which 
> > MAY be processed by the OCSP Responder".
> 
> I don't know.
> This is not in line with RFC3280 definition of extensions, in 
> which if 
> you *do* recognize an extension, you have to treat it 
> correctly and not 
> simply ignore it.
> With that definition if you implement RFC2560, you can say I 
> don't know 
> what id-pkix-ocsp-nonce means so I don't care about it, because it's 
> defined in the standard.

You are partly right for RfC3280 - while it in fact lists some
extensions that SHALL be recognized by CAs/applications, in general
extension are optional. The exact wording of RfC3280 is:

"A certificate using system MUST reject the certificate if it encounters
a critical extension it does not recognize; however, a non-critical
extension MAY be ignored if it is not recognized. [...] [List of
extensions CAs and Applications SHOULD recognize] Support for the
remaining extensions is OPTIONAL." [nearly same wording for CRLs]

Nevertheless the wording of RfC3280 and RfC2560 is very different. If we
apply the rationale behind RfC3280 to RfC2560, we should allow a client
to mark his nonce-extension critical, thus indicating that it does not
wish that any responder ignores the nonce. But currently RfC2560 states
clearly: 

"Support for any specific extension is OPTIONAL. The critical flag
SHOULD NOT be set for any of them."

Allowing an extension (e.g. the nonce-extension) to be critical would be
a change to RfC2560. I would really like such a change, but as Ambarish
already pointed out, this may put an unwanted semantic into the requests
of some existing clients out there. As these clients adhere to RfC2560,
the nonce is not critical - thus they would indicate that a nonceless
response is ok for them.

Remark: With this whole system, we have not yet solved the problem
adressed by David's proposal: A client wants to know securely if a
response without nonce was generated by an OCSP-responder not supporting
nonces or by an OCSP-responder normally being able to generate nonces. 

-- 
Florian Oelmaier
SyTrust