Subject: Re: DISCUSS: MUST reject in OCSPv1

From: "Florian Oelmaier" <[email-masked]>
Date: 28 Nov 2003 09:00:09 -0000

> If the client puts a nonce in a request and doesn't behave differently 
> depending on the presence/absence of the nonce in the response, then why 
> put the nonce in at all?

I agree. But the client behaves differently! It may
- display a warning to the user
- apply another local policy regarding time checking
- add additional measures to ensure freshness if a nonce is not present
- etc.

-- 
Florian Oelmaier
SyTrust

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 28 Nov 2003 08:05:56 -0700

These are constructive discussions but somewhat off topic for
this thread.  We need to determine if we as a WG can agree on a
least-impact near term path forward for disambiguating the
relationship between nonces and pre-produced responses.

After much work, we finally have a potential resolution on the
table.

David and Florian agree with it.
Ryan does not.
Marc, your response was ambiguous.

Anyone else care to voice an opinion on the proposal?

Mike

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 28 Nov 2003 12:27:02 -0400

Mike:

I do not know if this was said or not, but with the new extension, a 
compliant Responder must not be permitted to switch between nonce supported 
and nonce not supported responses

On Fri, 28 Nov 2003 08:05:56 -0700, Michael Myers wrote

---

From: Marc Branchaud <[email-masked]>
Date: Fri, 28 Nov 2003 09:27:44 -0800

> Marc, your response was ambiguous.

Just to clarify, then:

The resolution started with a "big if": Cycling at proposed.  I have no 
objection to cycling at Proposed and issuing an OCSPv2 that works all 
this out.

It's the "then" I am objecting to.  The proposed "then" is bad.

		M.

---

From: Marc Branchaud <[email-masked]>
Date: Fri, 28 Nov 2003 09:33:17 -0800

> - display a warning to the user

Please.

> - add additional measures to ensure freshness if a nonce is not present

Why not apply those measures in the first place and not bother with the 
nonce?

If the client has a policy that can let it live with the risk of replay 
within certain parameters, then it has no need for nonces.

Putting nonces into requests willy-nilly, just in case, is bad design.

		M.

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 28 Nov 2003 11:22:24 -0700

Marc,

The proposal is to cycle *v1* at Proposed to address this one
issue.
We would also take the opportunity to clarify encoding of nonce
as OCTET STRING, which was going to happen anyway as v1 went
from
Proposed to Draft.

I take it then you have no objection to the core technical
aspects of the proposed resolution?

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Marc Branchaud
> Sent: Friday, November 28, 2003 10:28 AM
> To: [email-masked]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
> Michael Myers wrote:
> >

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 28 Nov 2003 20:56:41 +0100

> > - display a warning to the user

Our client actually does in the default configuration. Sorry that I
(once again) could not live up to your imagination.

> Why not apply those measures in the first place and not 

Come on. Answer that one for yourself. Those additional measures do not
come at no cost. E.g. contacting a trusted time source costs time. 

> Putting nonces into requests willy-nilly, just in case, is bad design.

Read the above. A response with nonce will trigger another handling than
a response without nonce according to the local policy. 

-- 
Florian Oelmaier
SyTrust

---

From: Marc Branchaud <[email-masked]>
Date: Fri, 28 Nov 2003 14:22:42 -0800

Mike just gave me an offline whack to the head.

I have no objection to the original nonceUnsupported proposal, as 
described in
	http://www.imc.org/ietf-pkix/mail-archive/msg07210.html
including David's "return an error" addition in
	http://www.imc.org/ietf-pkix/mail-archive/msg07214.html

Having clarified my earlier clarification, I wish to reset the 
conversation...

Florian: As we both support the proposal, we may be in danger of violent 
agreement.

Ryan: Your arguments have failed to convince me that the proposal is bad.

Apologies to all for the churn.

		M.