Subject: RE: OCSP response pre-production

From: "Deacon, Alex" <[email-masked]>
Date: Fri, 26 Sep 2003 14:08:51 -0700

This summary assumes that the OCSP responder has control of the OCSP
clients.  This may not be the case, especially when responding to OCSP
requests for certs issued from SSL CA's (i.e. every flavor of browser/ocsp
client on earth).  As I stated in my response to Russ, the responder could
reject a request with a nonce, but why not reply with a request without a
nonce, and let the client decided if it wants to accept or reject it.  If a
client requires that the nonce in the result, the result is the same, the
response is rejected.

Alex

> -----Original Message-----
> From: Ryan M. Hurst [mailto:[email-masked]]
> Sent: Friday, September 26, 2003 10:01 AM
> To: Paul Hoffman / IMC; Michael Myers; David Engberg;
> [email-masked]; Ambarish Malpani; [email-masked]
> Cc: Russ Housley; Stephen Kent; Tim Polk
> Subject: RE: OCSP response pre-production
> 
> 
> 
> I concur with this, er "me too" :)
> 
> Ryan
> 
> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[email-masked]] 
> Sent: Friday, September 26, 2003 9:40 AM
> To: Michael Myers; Ryan M. Hurst; David Engberg; [email-masked];
> Ambarish Malpani; [email-masked]
> Cc: Russ Housley; Stephen Kent; Tim Polk
> Subject: RE: OCSP response pre-production
> 
> I hate to send "me too" responses, but everything Mike says in his 
> extended discussion is exactly right. My summary would be:
> 
> - If you can't sign, you must reject requests with nonces.
> 
> - Caching servers can ask a different server to sign. They can 
> respond to all requests that don't ahve nonces, and they (probably 
> selectively) send back the requests that have nonces to a server 
> willing to sign them.
> 
> - If you control the OCSP clients and you don't want to sign the 
> responses, inhibit the clients from sending requests with nonces.
> 
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 
> 
>

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 26 Sep 2003 14:35:29 -0700

Alex,

I'm willing to discuss client-side "nonce capability discovery"
via this mechanism but it's clearly a v2 proposition.
Meanwhile, we're working to clarify what we meant in v1 when we
defined nonces in the first place.  The poll clearly establishes
a nearly unanimous consensus that the common understanding in
place at the time found its way into running code in all but, to
date, one case.  I propose we proceed on this basis.

Mike

> From: Deacon, Alex [mailto:[email-masked]]
> Sent: Friday, September 26, 2003 2:09 PM
> To: 'Ryan M. Hurst'; Paul Hoffman / IMC; Michael
> Myers; David Engberg;
> This summary assumes that the OCSP responder has
> control of the OCSP clients.  This may not be the
> case, especially when responding to OCSP requests
> for certs issued from SSL CA's (i.e. every flavor
> of browser/ocsp client on earth).  As I stated in
> my response to Russ, the responder could reject a
> request with a nonce, but why not reply with a
> request without a nonce, and let the client decided
> if it wants to accept or reject it.  If a client
> requires that the nonce in the result, the result
> is the same, the response is rejected.
>
> Alex

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 27 Sep 2003 10:54:19 -0700

At 2:08 PM -0700 9/26/03, Deacon, Alex wrote:
>clients.

No, it very explicitly doesn't.

>   This may not be the case, especially when responding to OCSP
>client on earth).

Correct.

>   As I stated in my response to Russ, the responder could
>nonce, and let the client decided if it wants to accept or reject it.

This does not make sense from an interoperability standpoint. If the 
responder does not have control of the clients, why do you say that 
the responder should send back malformed responses and let the client 
deal with them? If you have no control over the clients, you cannot 
assume that clients will be able to deal with malformed responses.

>   If a

No, the new result is that the client is confused by the malformed 
response. This is much worse.

--Paul Hoffman, Director

---

From: "Florian Oelmaier" <[email-masked]>
Date: Sat, 27 Sep 2003 21:09:17 +0200

> >   As I stated in my response to Russ, the responder could reject a 
> >request with a nonce, but why not reply with a request 
> without a nonce, 
> >and let the client decided if it wants to accept or reject it.
> 

Paul,

with all due respect: Please quote the paragraph of RfC 2560 stating
that a response without nonce is "malformed". This statement is simply
not true - if you wanted it to be true, you should have included it into
the RfC 3 years ago. 

As it stands now, nonces are optional on both sides: server and client.
If the server does not support nonces, it may as well respond without
nonce. This is conform with the published state of RfC2560 and the
clients have to deal with it. I am very sure that all client
implementors out there are aware of this situation. All my test of OCSP
clients back this statement up - most reject these reponses, but all are
able to deal with the situation.

-- 
Florian Oelmaier
SyTrust

PS: Currently RfC2560 states:

--------------
[...]
An OCSP request contains the following data:

   -- protocol version
   -- service request
   -- target certificate identifier
   -- optional extensions which MAY be processed by the OCSP Responder
[...]
A definitive response message is composed of:

   -- version of the response syntax
   -- name of the responder
   -- responses for each of the certificates in a request
   -- optional extensions
   -- signature algorithm OID
   -- signature computed across hash of the response
[...]
This section defines some standard extensions, based on the extension
model employed in X.509 version 3 certificates see [RFC2459]. Support
for all extensions is optional for both clients and responders.
[...]
--------------

Summary: Right now the RfC is VERY CLEAR in this point: a response
without nonce to a request with nonce is NOT MALFORMED and completely
conform with RfC2560.

---

From: "Michael Myers" <[email-masked]>
Date: Sat, 27 Sep 2003 12:46:53 -0700

"malformed" should be used to signal server-side syntax parsing
errors.

Yes, we have a hole with respect to signaling
"nonces-not-supported" and the consequent client-side behavior
in that instance.

I have several inputs along those lines, some privately
communicated.  Once I get this formed up into a coherent path
forward, I'll toss it out for discussion.

Mike

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 27 Sep 2003 12:53:47 -0700

At 9:09 PM +0200 9/27/03, Florian Oelmaier wrote:
>that a response without nonce is "malformed".

This is exactly what we are trying to write up now.

>I am very sure that all client

This is a very valuable data point, and one that is quite relevant to 
Mike's initial question. If it is true (we'd need to ask the 
implementers again), it would certainly make it possibl for the WG to 
go towards a solution like Alex's which puts the onus on the client 
to decide what to do with a response from a server that didn't do 
what it was told to.

>without nonce to a request with nonce is NOT MALFORMED and completely

It is malformed if you read section 4.4.1 as requiring a nonce in the 
response when it was included in the query, as many people here have 
interpreted. "Optional" doesn't mean "can be put in or omitted at 
will".

--Paul Hoffman, Director