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

[Sean Turner <[e-mail]>]

James,

Thanks for the review.  Comments inline.

spt

On 4/23/12 11:15 PM, Manger, James H wrote:
>> 	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.

Okay I struck "to avoid ...".

My primary reason for picking the 160-bit truncated length was that in 
sidr there was some discussion about what the output lengths would be if 
the alg to generate the key identifier was from the SHA2 family.  Some 
of the implementers seemed to like the idea of having it documented and 
fixed to the same length as the 160-bit truncated SHA-1 example in 5280 
(which is what they use now).  I realize that they could define any old 
method they wanted in their drafts, but this has come up a couple of 
times for me and I just wanted to document something so that it could be 
referenced.

Given the above, 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. 
Remember these are just listing some example methods - implementers are 
free to do these or not.

Sound like a plan?

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

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

I think you're right here and I'll remove kiLength.

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

Ah that should have been id-subjectPublicKeyInfo which is different than 
just the key because it includes alg id/parameters.