Re: [TLS] rfc4366-bis-03 Discuss #2: hash alg. agility for TrustedCA?

[<Pasi.Eronen at nokia.com>]

I don't think having hash agility in this particular case is 
needed -- this use doesn't require a cryptographically
strong hash function (even a CRC would do).

Best regards,
Pasi 

> -----Original Message-----
> From: tls-bounces at ietf.org [mailto:tls-bounces at ietf.org] On 
> Behalf Of ext Alfred HÎnes
> Sent: 21 October, 2008 23:01
> To: tls at ietf.org
> Subject: [TLS] rfc4366-bis-03 Discuss #2: hash alg. agility 
> for TrustedCA?
> 
> (A)  hash algorithm agility for the Trusted CA Keys TLS extension
> 
> Section 5 of the rfc4366-bis draft contains the following
> TLS presentation language definition (from RFC 4366):
> 
> ---------------------------snip----------------------
>       struct {
>           TrustedAuthority trusted_authorities_list<0..2^16-1>;
>       } TrustedAuthorities;
> 
>       struct {
>           IdentifierType identifier_type;
>           select (identifier_type) {
> !             case pre_agreed: struct {};
> !             case key_sha1_hash: SHA1Hash;
> !             case x509_name: DistinguishedName;
> !             case cert_sha1_hash: SHA1Hash;
>           } identifier;
>       } TrustedAuthority;
> 
>       enum {
> !         pre_agreed(0), key_sha1_hash(1), x509_name(2),
> !         cert_sha1_hash(3), (255)
>       } IdentifierType;
> 
>       opaque DistinguishedName<1..2^16-1>;
> ---------------------------snip----------------------
> 
> where SHA1Hash is borrowed form Section 5:
> 
> ---------------------------snip----------------------
>       opaque SHA1Hash[20];
> ---------------------------snip----------------------
> 
> This WG is tasked by the IESG & IAB to introduce crypto algorithm
> agility into the protocols it supports, whereas the above definition
> is still restricted to SHA-1 only.
> 
> Therefore, the questions arise:
> 
> -  Should the enum IdentifierType be extended with new values
>    indicating other hashes for keys and certificates?
> 
> -  If yes, adding only SHA-256 (in the spirit of TLS v1.2),
>    or adding more variants?
> 
> 
> Any opinions?  Further considerations?
> 
> 
> (B)  Non-uniqueness of x509_name in Trusted CA Keys TLS extension
> 
> The 3rd-to-last paragraph of Section 6 in the -03 version
> of the rfc4366-bis draft states:
> 
> !  Note also that it is possible that a key hash or a 
> Distinguished Name
> !  alone may not uniquely identify a certificate issuer (for 
> example, if
> !  a particular CA has multiple key pairs). However, here we 
> assume this
> !  is the case following the use of Distinguished Names to identify
> !  certificate issuers in TLS.
> 
> It seems rather unlikely that this non-uniqueness happens for
> a key hash.
> 
> But in the course of rekeying or when multiple signature algorithms
> (RSA/DSA/ECDSA) are supported by a CA, this non-uniqueness could be
> expected to happen rather commonly for x509_name.
> 
> -  Is the above quoted assumption still justified?
> 
> -  If not, should another common identifier type,
>    IssuerAndSerialNumber,
>    be introduced to help avoid the ambiguity?
>  -or-
> -  Does everybody use hashes anyway, such that deprecating
>    the x509_name variant might be considered ?
> 
> Any opinions?  Further considerations?
> 
> 
> Kind regards,
>   Alfred.
> 
> -- 
> 
> +------------------------+------------------------------------
> --------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., 
> Dipl.-Phys.  |
> | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18 
>         |
> | D-71254  Ditzingen     |  E-Mail:  ah at TR-Sys.de             
>         |
> +------------------------+------------------------------------
> --------+
> 
> _______________________________________________
> TLS mailing list
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls