Subject: Re: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt

From: "Julien Stern" <[email-masked]>
Date: Tue, 2 Nov 2004 11:08:07 +0100

Greetings,

I have a number of comments on the draft:

1) Section 1.2.3 states that the OCSP responder should reply with an
"unauthorized" reply code when it is not capable of replying
authoritatively.

I believe there are two problems with that:

First, it overrides the semantic of the "unauthorized" error code,
which originally means that the client is not, well, authorized :)
to access to service.

Second, because OCSP replies are unsigned, it allows for an easy
man-in-the-middle attack.

2) Regarding Nonces

This profile is obviously nonceless. No caching server in its sane
mind would ever implement nonce. So why imply that a server could
possibly send one ? If this is to cope with the case of a client that
does not know whether the server supports nonce or not, the extensive
discussions that occured on the list regarding this issue are not
solved. If this RFC is published as is, it will practically destroy
all nonced implementations of OCSP, because the client has no way to
know whether is it talking with a nonce-supporting server or not.
Hence, nonced implementations becomes useless, because replay attacks
always become possible, unless the client is pre-configured to know
that the server is indeed using nonces.
Several proposals have been suggested, including my proposal of forcing
nonce-supporting server to NOT include the nextUpdate field, as well as
other proposals using extra extensions.

3) Wouldn't it be a good idea to also specify the way a client should check
the OCSP responder signature ? RFC2560 authorizes three ways
i) CA itself
ii) directy signed by CA with the Im-an-ocsp-responder extension
iii) anything goes :)

How about restricting the lightweight profile to i) and ii),
or clarify iii) ?

Sincerely,

--
Julien Stern