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

>> ...Since we are truncating the hashes in all the new algs, why not truncate to something shorter? 64-bits would be a good choice...

> ...I don't want to remove the 160-bit truncated versions, 
but I don't have any problem adding the 64-bit methods you describe...
>
> Sound like a plan?

No. One variety per hash is enough.
I feel that 160-bits is so far beyond what you need to be unique with high probability, that it is almost suggesting (erroneously) to the reader that the key-id needs to have "crypto" strength.
But if you want 160-bits, don't complicate it with shorter options as well.


You could ditch the SHA-224 and SHA-384 methods. Those 2 algs are just truncations of SHA-256 and SHA-512 (with different initial constants) so it is inconceivable that an implementation supports, say, SHA-224 but not SHA-256.



>> 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.

> I added it because there was some discussion on the list about it - 
> granted it was like 2 years ago.  Some folks were on about it here:
> https://www.ietf.org/mail-archive/web/pkix/current/msg27849.html
>
> I'll add some wording after I've run it by my co-author.

I look forward to seeing the reason. I read that thread, saw people asking for the extension, but still failed to discern a reason. 



How can you indicate that you used the 2nd recommended mechanism to generate a key-id (ie 0100 + truncate_to_60bits(sha1(public_key))) in the ext-kiAlgAndLen extension? I don't think you can given the extensions assumption of a purely truncated hash. Perhaps a special rule for 64-bit key ids is needed.

--
James Manger