RE: DISCUSSION: Nonce-specific error code for OCSP

["Michael Myers" <mmyers@xxxxxxxxx>]

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