Subject: RE: DISCUSS: MUST reject in OCSPv1

From: "Ryan M. Hurst" <[email-masked]>
Date: Thu, 27 Nov 2003 08:48:02 -0800

I don't think its silly, the client is still protected from the replay if the server responds to a nonced request with a un-nonced one as the client can decide decide if he wanted the protection or needed it.
 
That may sound strange, but nonce has other implications that re-play protection; it also implies freshness since pre-produced responses can not have the right nonce in it.
 
I still am not sure anything new is needed, but if it is leveraging criticality is probably the right way to go as long as it will not break folks; if it would I would fall back to the extension approach.
 
Ryan

________________________________

From: [email-masked] on behalf of Michael Myers
Sent: Thu 11/27/2003 5:49 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

> -----Original Message-----
> From: Santosh Chokhani
> Sent: Wednesday, November 26, 2003 9:25 PM
> To: [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> Mike:
>
> Section 4.1.2 and 4.4 of the RFC 2560 support the
> position that the nonce can
> be ignored.  I can not find any statement in the RFC
> that is close to these
> two to support what you are saying.

Yes, extensions are optional.  What's missing is language along
the lines that while optional, if used must be used in the
manner indicated in the extension's definition.

Prior to the first poll, I was reviewing some list traffic on
the subject, I think it was between Florian and Ambarish.  I was
about to advise that 2560 asserts nonces must be respected but
was dismayed to learn that we hadn't done so.

Why the hard line?  Because it just seems rather silly to enable
a client to include a nonce for the purposes of anti-replay but
then leave open a loophole that allows that nonce to be ignored,
this, against all good sense of how a secure protocol should
work.  With a loophole like that, it isn't secure.  I guess we
all figured, well *of course* the nonce would be incorporated.

Mike

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 27 Nov 2003 10:09:35 -0700

RE: DISCUSS: MUST reject in OCSPv1The more important thing is what a caching
server is required to send back in the event it can't respond to a nonce.

Mike
  -----Original Message-----
  From: Ryan M. Hurst [mailto:[email-masked]]
  Sent: Thursday, November 27, 2003 9:48 AM
  To: Michael Myers; Santosh Chokhani; [email-masked]
  Subject: RE: DISCUSS: MUST reject in OCSPv1

  I don't think its silly, the client is still protected from the replay if
the server responds to a nonced request with a un-nonced one as the client
can decide decide if he wanted the protection or needed it.

  That may sound strange, but nonce has other implications that re-play
protection; it also implies freshness since pre-produced responses can not
have the right nonce in it.

  I still am not sure anything new is needed, but if it is leveraging
criticality is probably the right way to go as long as it will not break
folks; if it would I would fall back to the extension approach.

  Ryan

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 27 Nov 2003 10:40:35 -0800

Ryan M. Hurst wrote:
> I don't think its silly, the client is still protected from the replay 
> if the server responds to a nonced request with a un-nonced one as the 
> client can decide decide if he wanted the protection or needed it.

Why can't the client can decide this before making the request?

What does the client gain by making a nonced request but accepting a 
nonceless response?

> protection; it also implies freshness since pre-produced responses can 
> not have the right nonce in it.

If the group wishes to address the use of nonces for more than replay 
prevention, then I think the only option is to devise a new OCSPv2 spec.

		M.