Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt

[Michael Ströder <michael@xxxxxxxxxxxx>]

Tomas Gustavsson wrote:
> 
> > Hmm, I think the cert store implementation itself should deal with
> > these kind of index optimization issues. I vote for just submitting
> > search values as is and let the certificate store backend do the bit
> > reducing at the server-side if necessary at all. That makes client
> > implementations simpler and leaves up decisions about how to deal
> > with possible collisions to the server-side cert store
> > implementation.
> 
> I would agree with this. It simplifies things to use 'real'
> values and let the backend/middleware do the optimization.

While we're at it: It could also be useful to simply use a string
hex-encoding of e.g. SHA-1 fingerprint as search value instead
base64-encoding the binary SHA-1 value. I'd also like to suggest
that a cert store implementation simply strips colons or spaces used
as hex-byte separator to determine the search value. This would
enable the cert store to search for values which the user can
cut&paste from another software's output. (Off course the search
value is assumed to be URL-encoded as already stated in the draft.)

Example of typically used representations of SHA-1 fingerprint used
as search value treated as equal:

C1:50:FF:EF:93:5A:FA:8C:15:49:AE:74:C1:A0:8E:FA:CC:10:99:1F

C150 FFEF 935A FA8C 1549 AE74 C1A0 8EFA CC10 991F

C150FFEF935AFA8C1549AE74C1A08EFACC10991F

c150ffef935afa8c1549ae74c1a08efacc10991f

This can all be implemented very easily with typical programming
languages used for web apps today.

Ciao, Michael.