[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: DISCUSSION: Nonce-specific error code for OCSP

To: <ietf-pkix@xxxxxxx>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
From: "Michael Myers" <mmyers@xxxxxxxxx>
Date: Fri, 17 Oct 2003 15:53:02 -0700
Cc: "David Engberg" <dave@xxxxxxxxxxxxxx>, "Alex Deacon" <alex@xxxxxxxxxxxx>
Importance: Normal
In-reply-to: <>
List-archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-id: <ietf-pkix.imc.org>
List-unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Sender: owner-ietf-pkix@xxxxxxxxxxxx




Because willful disregard of a client's nonce violates first
principles.  Enabling service providers a legal basis to do so
via reliance on an IETF standard is a whole different question.

Mike


> -----Original Message-----
> From: David Engberg [mailto:dave@xxxxxxxxxxxxxx]
> Sent: Friday, October 17, 2003 2:26 PM
> To: Michael Myers
> Cc: ietf-pkix@xxxxxxx
> Subject: DISCUSSION: Nonce-specific error code for OCSP
>
>
>
> Dumb question:  why is it possible to add a new
> OCSPResponseStatus code value (a non-backward-
> compatible addition) for v1, but not to convey
> this information through a new responseExtension in
> the signed body (a backward compatible change with
> better security semantics)?

Follow-Ups:
- RE: DISCUSSION: Nonce-specific error code for OCSP
  - From: Florian Oelmaier

References:
- DISCUSSION: Nonce-specific error code for OCSP
  - From: David Engberg

Prev by Date: DISCUSSION: Nonce-specific error code for OCSP
Next by Date: Re: POLL: Nonce-specific error code for OCSP
Previous by thread: DISCUSSION: Nonce-specific error code for OCSP
Next by thread: RE: DISCUSSION: Nonce-specific error code for OCSP
Index(es):
- Date
- Thread