Greetings,

I have two comments on the draft (that I had already posted
after the -02 draft was published):

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. How would one know when he is actually not
authorized ?

Second, because OCSP replies are unsigned, it allows for an very
easy man-in-the-middle attack. Because most client software assume
by default that the certificate is valid when the revocation status
is unknown, it is easy to turn an invalid certificate into a valid
one is you control a proxy in the middle, by sending an
unsigned "unauthorized" reply.

I totally understand that sending signed replies for certificates
of unknown status is not possible for "caching" server. However,
the present draft just refers to the security considerations
of RFC2560, whereas they have more impact in the present case.

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
do not seem to be definitely 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.

To make my point(s) clearer: I have nothing against this protocol
and think it is important to have it because it's very efficient.
However, I do not think that, security-wise, it is a _profile_
of OCSP.

Lightweight OCSP is less secure than OCSP (the price to pay
for efficiency), but because 
1) a client cannot know whether it is talking to a standard OCSP or
   a lightweight OCSP server, and
2) the lightweight OCSP mandates that the client falls back
   to less secure mode

it means that lightweight OCSP practically prevents a regular OCSP
server to provide extra security to its clients.


Note that, in my very humble opinion, this problem comes from RFC2560
and not from this draft. If RFC2560 was modified to include the
following semantic behavior, we could have a bit-on-the-wire compatible
protocol AND allow regular OCSP to cohabit with lightweight OCSP without
sacrifying security:

the changes would be:

1) A server (identified by a ResponderID) can serve "fresh" responses
or "cached" responses, but MUST NOT serve both (else one MUST use
different responderIDs).

2) For a "caching" server:
- the nextUpdate field of all the SingleResponse elements MUST be present.
  It should indicate the expiration date of the (cached) information validity.
- the nonce extension MUST be ignored

3) For a "live" server:
- the nextUpdate field of all the SingleResponse elements MUST be absent,
  thus indicating the information is live
- the nonce extension MUST be honored


Sincerely,

--
Julien Stern

On Tue, Feb 07, 2006 at 04:53:25PM -0500, Stephen Kent wrote:
> 
> Folks,
> 
> I am initiating a WG last call for the lightweight OCSP profile:
> 
>  draft-ietf-pkix-lightweight-ocsp-profile-03.txt
> 
> I have provided the authors with an initial set of comments.
> 
> Please send your comments to the list by February 17th, 1.5 weeks from 
> today.
> 
> Thanks,
> 
> Steve
>