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

RE: POLL: Nonce-specific error code for OCSP



Julien,

I modified the subject line to keep the POLL thread clean for
votes.

OCSP errors are unsigned to enable handling of DOS-type attacks
at the edge rather than the core.  This feature was argued in
favor of those who might deploy this protocol using pre-produced
responses.  That said, presenting a pre-fetched (pre-signed?)
error response does nothing to mitigate anti-replay.

Mike

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of
> Julien Pierre
> Sent: Thursday, October 16, 2003 2:28 PM
> To: ietf-pkix@xxxxxxx
> Subject: Re: POLL: Nonce-specific error code for OCSP
>
>
> Florian Oelmaier wrote:
>
> >Rationale:
> >My first idea was to say: if it is OPTIONAL for the
> responder to use that error code it is ok. But in
> fact even the OPTIONAL inclusion harms the security
> of the protocol, as an attacker can fool clients into
> believing a particular OCSP-Responder would not
> support nonces, when in fact it does.
> >
> Agreed. The OCSP responses with error codes are not
> signed, so this
> would present a security hole. We should not let the
> server return this
> error code in an unsigned response.
>
> IMO, it would be acceptable to have an error code
> only if the response
> was signed and included a validity period. Each
> caching responder would
> have to prefetch such a response in order to be able
> to serve it back to
> clients that send nonces.
>
>