Re: [pkix] OCSP and Privacy Issues

[Massimiliano Pala <Massimiliano.Pala at Dartmouth.edu>]

Answers inline...

On 11/17/2009 11:37 AM, Liaquat Khan wrote:
> Hi Max
>
> I am a bit confused by your statement:
[...]
> With your proposed solution of obfuscating the certID, the server would
> still need to unravel this in order to check the certificate status, so you
> have to accept the certID being revealed to the OCSP responder.

No, what you really do is to ask for a range that is sufficiently large
to guarantee n out of m type of privacy... the concept is not new (partitioned
CRLs), the addition is the use of hash functions to mask the real serial
and to evenly spread the revoked certs' identifiers in the hash-function
space. Efficient and easy to implement on top of regular OCSP servers.

> Maybe by "server" you mean a front-end TLS server which then forwards the
> request to OCSP responder in the back-end. However your threat scenario of
> malicious admins who can penetrate TLS server may also do the same to OCSP
> server.  It is true front-end TLS servers may be more exposed than back-end
> OCSP servers.

True, that does not apply to the solution that I envisage...

> Now and then we get asked for lots of strange and wonderful things from our
> OCSP responder, but so far none of our clients have asked for this.  Most
> seem happy with OCSP over HTTP, although some do prefer HTTPS (mainly for
> reasons of strongly authenticating the client access to the server, using
> TLS/SSL client certs).

I agree. It seems to me that, as usual, in PKIs we forget privacy issues..
and we are ok with it.. :) But if we want people to be comfortable with
using PKIs, we shall try to address the issue (as well as usability) at
each level when we design our PKIs... :D

Thanks,
Max

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature