RE: DISCUSSION: Nonce-specific error code for OCSP

[Tom Gindin <tgindin@xxxxxxxxxx>]

        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





"Michael Myers" <mmyers@xxxxxxxxx>
Sent by: owner-ietf-pkix@xxxxxxxxxxxx
10/18/2003 09:14 PM

 
        To:     "David Engberg" <dave@xxxxxxxxxxxxxx>
        cc:     <ietf-pkix@xxxxxxx>
        Subject:        RE: DISCUSSION: Nonce-specific error code for OCSP




Dave,

A few thoughts embedded below.

Mike

> -----Original Message-----
> From: David Engberg
>
> . . .
>
> An existing client can't tell the difference between a
> server that doesn't support nonces and a replay
> attack by an attacker who made a nonceless request.
> An explicit "nonceUnsupported" extension in the signed
> body of the response allows a client to securely tell the
> difference between these cases.


The requirement is to bind a request to its associated response
and thus enable relying parties to mitigate replay risks.  I
remain curious to an understanding of how unilateral server-side
response extensions achieve this effect.


> OCSP and other PKIX standards currently allow some
> policy decisions to be made by the infrastructure
> authorities (CAs, responders) and others by the
> relying parties.  For example, the pkix-nocheck
> extension allows the infrastructure to tell clients
> that they should accept a delegated responder cert
> without performing validation.  This extension was
> approved, even though someone could have made an
> argument that "only clients should be allowed to
> set responder validation policies."


In the instance of explicit delegation from a certification
authority, there then exists a business entity which places
itself in a position of risk against damage claims.  Are you
suggesting that an OCSP responder's unilateral inclusion of a
technical artifact is an assertion of willingness to absorb such
risks?

Bear in mind that the relying party problem is notoriously
difficult.  It only appears in the heterogeneous context we are
now debating; else contracts suffice.  If you are unfamiliar
with the issue, you may wish to consult with our legal peers in
the American Bar Association's Information Security Committee.


> Something like "nonceUnsupported" would fall in the
> same category ... the infrastructure is telling
> interested clients about the security characteristics
> of that PK infrastructure and suggesting a security
> policy based on that information.


Infrastructure should serve the needs of its participants rather
than the other way around.

Mike
(602) 739-7744