Re: [pkix] Fwd: I-D Action: draft-turner-additional-methods-4kis-02.txt

["Manger, James H" <[e-mail]>]

>	Title           : Additional Methods for Generating Key Identifiers
>	Filename        : draft-turner-additional-methods-4kis-04.txt

Using a more recent hash alg than SHA-1 to generate key ids sounds fine.

Keeping the 160-bit size "to avoid adversely affecting relying party code" sounds strange. RFC5280 already recommends 2 methods with different lengths (160-bit and 64-bit) so relying party code better handle that. Perhaps using a size no longer than 160-bit is nice (so it takes no more space in a database field, for instance). Since we are truncating the hashes in all the new algs, why not truncate to something shorter? 64-bits would be a good choice (matching the shorter existing recommended method). We could even set the first 4 bits to 0101, 0110, 0111, 1000 for the 4 new methods so it matches the existing recommendation even more closely.


What is the reason for having a certificate extension to describe how a key id is generated?
I don't think the draft gives any reason.

The kiLength field seems pointless. You can look at the actual key id (also in the cert) to get its length.

A kiHashInput value of id-subjectPublicKey seems to mean the same thing as the kiHashInput field being absent. Two ways to say the same thing is bad.


--
James Manger