Subject: RE: DISCUSSION: Nonce-specific error code for OCSP

From: Tom Gindin <[email-masked]>
Date: Thu, 30 Oct 2003 19:04:12 -0500

I should have been more precise in my suggestion.  The unilateral 
server-specified practice I can think of that would most effectively ban 
relays is for an extension called nonceSupported to be defined, whose 
syntax is a single Boolean.  A responder supporting this extension should 
include it, with the appropriate value, in every response other than those 
which contain nonces.  This extension is of limited value in responses 
which do contain nonces, although you could put it in them.  With such an 
extension, any replay of a response from a responder with nonce support 
would be detectable by the client.  If the client doesn't use nonces, or 
the responder doesn't support them, I don't see what you can do to detect 
replays.
        It would be possible to make the value of such an extension a 
3-valued enumeration: unsupported, deprecated (meaning it's expensive but 
we'll do it if you insist), and supported.  That variant would probably be 
called "nonceSupport", and it might be desirable to include that in 
responses which include nonces as well as in those which don't.  However, 
we'd need yet another mechanism to demand a response including a nonce in 
order to support the deprecated value.
        I am not suggesting that anyone standardize both of these 
variants, which would be egregious bloat.  I won't be at Minneapolis, so 
I'm getting my suggestions in early.

                Tom Gindin

        IMHO, a client should take the following action where the 
requestor includes a nonce:
a)      Nonce present, accept if response.nonce == request.nonce
b)      NonceSupported == false (with no nonce), accept (also NonceSupport 
== unsupported)
c)      NonceSupported == true but no nonce, reject             (also 
NonceSupport == supported)
d)      NonceUnsupported present (with no nonce), accept
e)      Neither nonce nor extension present, DEBATABLE (see this thread 
for the debate)
f)      NonceSupport == deprecated (with no nonce), accept or rerequest 
(BUT there's no good rerequest technique)

"Michael Myers" <[email-masked]>
10/22/2003 12:49 PM

        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     "David Engberg" <[email-masked]>, <[email-masked]>
        Subject:        RE: DISCUSSION: Nonce-specific error code for OCSP

Tom,

Your proposal certainly provides an opportunity for compromise.
But I think we first need to see what emerges from Minneapolis.

Mike

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: Wednesday, October 22, 2003 9:19 AM
> To: Michael Myers
> Cc: David Engberg; [email-masked]
> Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
>
>
>         Michael:
>
>         Does your skepticism about the usefulness of
> unilateral
> server-side extensions mean that we should permit a
> variant of nonce in
> which the client specifies how strongly he needs a
> nonce?  Since the
> current syntax of nonce is not officially published,
> I posted a possible
> extension several weeks ago.  The options were
> original (with unclear
> semantics in this respect), nonce required in
> response, and nonce optional
> in response.
>         For a server to actually prevent
> misunderstandings of whether or
> not he supports nonces by using a unilateral
> server-side extension, you'd
> need a server-side extension called "nonceSupported"
> with boolean syntax,
> which would have to be placed in EVERY response
> whether nonces are present
> in the request or not.  The "nonceUnsupported"
> extension strikes me as
> less useful than that.
>
>                 Tom Gindin
>