RE: DISCUSS: MUST reject in OCSPv1

["Deacon, Alex" <alex@xxxxxxxxxxxx>]

Mike,

Clearly education and interop testing is a large part of the solution (and
one we have spent some time doing).

As for your blunt statement, the issue is when the non-normative statement
"The nonce cryptographically binds a request and a response to prevent
replay attacks." is read in the broader context of the normative statements
regarding extension support, things start to crumble. 

Alex


> -----Original Message-----
> From: Michael Myers [mailto:mmyers@xxxxxxxxx] 
> Sent: Friday, December 05, 2003 5:22 PM
> To: Deacon, Alex; Ryan M. Hurst; ietf-pkix@xxxxxxx
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> Alex,
> 
> Comments embedded below.
> 
> Mike
> 
> > -----Original Message-----
> > From: Deacon, Alex [mailto:alex@xxxxxxxxxxxx]
> > Sent: Friday, December 05, 2003 4:59 PM
> > To: 'Michael Myers'; Ryan M. Hurst; ietf-pkix@xxxxxxx
> > Subject: RE: DISCUSS: MUST reject in OCSPv1
> >
> >
> >
> > If I could be ensured that every OCSP client used to
> > hit ocsp.verisign.com would not include a nonce,
> > then I would have no problem with a MUST reject.
> 
> Well, that probably won't happen in the given target 
> environment.  But what you can do is tell them they shouldn't 
> while still providing them the full value of your OCSP 
> services. Given a sufficiently reliable clue, they probably 
> won't do so again.
> 
> > However because this environment receives requests
> > from a heterogeneous population of clients over
> > which we have no administrative control (to
> > paraphrase an earlier email of yours), there will
> > undoubtedly be cases where cert validation will
> > fail....not because the cert has been revoked, but
> > because the response does not include a nonce.
> 
> Not necessarily.  Be up front about it.  Tell them you don't 
> support nonces.  Let them decide IAW local security policy 
> whether to fail path validation process.  Give them a clue.
> 
> > I believe that clients should have the ability to
> > make up their own mind (local policy) in determining
> > if they should reject or accept such a response.
> 
> But to make that decision, they must be able to differentiate 
> between a server/service that chooses not to support nonces 
> and one that is willing to but which service is being blocked 
> by an attacker.
> 
> > A MUST reject would not allow for this or force a
> > client to not be compliant with the spec.
> 
> Apologies in advance for being so blunt about this, but 
> Section 4.4.1 of RFC 2560 opens with the sentence "The nonce 
> cryptographically binds a request and a response to prevent 
> replay attacks."  I remain curious how disregard of a 
> client's nonce nonetheless achieves this intended effect.  I 
> further note that RFC 3546 (TLS) defers to this precise 
> section regarding nonces.
> 
> 
> 
> 
>