Re: [secdir] secdir review of draft-ietf-csi-send-name-type-registry-03

[Sean Turner <[e-mail]>]

Stephen Kent wrote:
> At 6:38 PM +0200 5/8/10, Roque Gagliano wrote:
>> Patrick,
>>
>> Thank you for your review.
>>
>> You are correct oonly 160 bits SHA-1 hash is defined in RFC 5280 and 
>> required in draft-ietf-sidr-res-cert
>>
>> Regards,
>> Roque
> 
> Roque,
> 
> 5280 defines how to use SHA-1, but it does not_ require_ use of this 
> specific
> hash function. 4.2.1.2 says:
> 
>    For CA certificates, subject key identifiers SHOULD be derived from 
> the public key or a method that generates unique values.  Two common 
> methods for generating key identifiers from the public key are:
> 
> ...
> 
> Other methods of generating unique numbers are also acceptable.
> 
> So, use of another one-way hash function, e.g., SHA-256 meets the 
> criteria defined above (associated with the "SHOULD") and is consistent 
> with the final comment.
> 
> CAs need to know which function to use, but RPs just perform 
> comparisons. We could modify the RPKI cert profile (if Geoff and the 
> SIDR WG don't mind) to specify use of SHA-256 for generation of SKI/AKI 
> values. I guess the real issue is whether commonly used software (e.g., 
> OpenSSL) will support this.

I'm sure somebody will correct me if I'm wrong.

At first, I was encouraged because OpenSSL allows you pick between 
"the guidelines in RFC3280 or a hex string giving the extension value 
to include".  If you want to follow the standard, then you use the 
following: subjectKeyIdentifier=hash.  But, then I went to the 
str_lib.c files, part of OpenSSL:

SHA_DIGEST_LENGTH,  /* ISSUERKEYID:  SHA1 digest, 160 bits */
SHA_DIGEST_LENGTH,  /* SUBJECTKEYID: SHA1 digest, 160 bits */

So it looks like it's hard coded to use SHA-1.

spt