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

[Michael Ströder <michael@xxxxxxxxxxxx>]

Peter Gutmann wrote:
> 
> Tomas Gustavsson <tomasg@xxxxxxx> writes:
> 
> >How much space is saved by only using 128 bits from the SHA1 hash?
> 
> The short answer is: It's quite significant (even 128 bits is far larger than
> is optimal, but I figured that was the lower bound of what I could get away
> with.  64 bits would be better).  The space saving on disk is irrelevant,
> what's significant is the space in indices.  The less keys you can fit per
> page, the more pages the index consumes, and the worse performance gets.
> That's still not the full answer, for that I'd recommend any book on database
> design, or the paper I reference in the draft which looks at this in some
> detail.

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.

Peter, as I understand your draft it's only an interface definition.
There shouldn't be e.g. database-specific limits in this draft
because they are dependent on the DB backend used by an
implementation. Only limitations imposed by the protocols used for
the interface (HTTP in this case) should be considered.

BTW: I'm not an DB expert but IMHO index generation with hashes of
appropriate size and collision handling is made internally by DB
servers anyway.

> >Is the added chance of collision insignificant when truncating the hash?
> 
> Yes.  I doubt there are more than about 2^20 certs in the whole world, let
> alone 2^64.

You know this famous sentence about "640kByte on DOS systems is
enough"... ;-)

Ciao, Michael.