Subject: RE: DISCUSS: MUST reject in OCSPv1

From: "Deacon, Alex" <[email-masked]>
Date: Fri, 5 Dec 2003 15:58:47 -0800

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

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.  A MUST reject would not allow for this or force a client to not
be compliant with the spec.

Alex

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]] 
> Sent: Friday, December 05, 2003 10:47 AM
> To: Ryan M. Hurst; [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> 
> > From: Ryan M. Hurst
> > Sent: Friday, December 05, 2003 10:57 AM
> >
> > [rmh]As I said, I am willing to accept the
> > must reject if that means that others will
> > drop the idea of adding breaking changes to
> > the v1 protocol.
> 
> So now we've come full circle.  A plain MUST reject is where 
> we got started and which principle Russ affirmed in 
> Minneapolis. I'm curious what others think.
> 
> Mike
> 
>

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 5 Dec 2003 18:22:21 -0700

Alex,

Comments embedded below.

Mike

> From: Deacon, Alex [mailto:[email-masked]]
> Sent: Friday, December 05, 2003 4:59 PM
> To: 'Michael Myers'; Ryan M. Hurst; [email-masked]
> 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

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.