Re: [TLS] TLS 1.2 hash agility

>>> I think the solution we need is to specifically list each supported
>>> signature algorithm, e.g.
>>>
>>>      enum {
>>>        rsa_with_md5(0),    rsa_with_sha1(1),
>>>        rsa_with_sha256(2), rsa_with_sha384(3),
>>>        rsa_with_sha512(4), dsa_with_sha1(5),
>>>        (65535)
>>>      };
>>
>> And then we could change Signature structure to
>>
>>    struct {
>>       SignatureAlgorithm signature_algorithm;
>>       opaque signature_value<0..2^16-1>;
>>    } Signature;  
>>
>> Eric, what's your opinion?
> 
> OK, I started trying to wire this into TLS and it's messy.
> There are three contexts we have to think about:
> 
> - Certs (from either side)
> - CertificateVerify
> - ServerKeyExchange
> 
> The difficulty is that the latter two already have signals indicating
> what acceptable signature algorithms are, in the ClientCertificateType,
> and the ciphersuite respectively. So, we either need to significantly
> reconstruct those or have duplication of information, with the 
> result that you have to potentially deal with mismatched information,
> e.g., only offering RSA in the SKE, but offering RSA and DSA in the
> new value.

I think this information is disjoint.  For example, you can have a DSA
key in a certificate that is signed by RSA/SHA-1.

Mike

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls