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

Re: [pkix] OCSP and Privacy Issues



On 11/18/2009 01:00 PM, Stefan Santesson wrote:
[...]
This is what I guessed. If this is your threat, then I agree that running
over https should be the appropriate solution rather than obfuscating serial
numbers of the request.

Understood.

[...]
I have a hard time believing that a person having access to the server logs
would be prevented from determining the users activities even if requested
certificate serial numbers was protected.

It is not very difficult. What you are doing with this approach is to
ask for a range of serials instead of a single serial. The domain is
in the HASH space (that's how we mask the serial) and the range is
large enough to guarantee the level of privacy required by the client.
This way it is not possible to pin-point the exact serial even if you
have full access to the OCSP server.

[...]
All that is needed to properly consume a partitioned CRL is to do the
required IDP/CDP match. I.e if an IDP is present in the CRL, It need to
match the CDP. That way you know that the CRL in question is the one
intended for your certificate (partitioned or not).

Any Windows client (XP and beyond) supports this.

Thanks.. I'll make some tests to better understand how it works :D

[...]
This to me appears as a too drastic change of the basic protocol compared
with the presented problem.

Mmmmm.. really ? It would be just an extension that would enable
a different behaviour that is completely compatible with the current
request/response bits on the wire... I can not think of a less drastic
approach...

In case old servers do not check for the critical extension and reply
[...]
An initial I-D would be better :)

Yep, that is what I was thinking too...

But I'm afraid that my position at this stage is not supportive of the
approach.

Thanks for replying.. it is important to have different points of view :D

Cheers,
Max


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


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.