Re: [TLS] TLS 1.2 hash agility

[Eric Rescorla <ekr at networkresonance.com>]

At Thu, 9 Aug 2007 12:34:07 +0300,
<Pasi.Eronen at nokia.com> wrote:
> 
> Mike (mike-list at pobox.com) wrote:
> 
> > 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)
> >      };
> > 
> > These may not be specific enough, as I've seen suggestions for,
> > e.g. rsa_pkcs1v1_5_with_sha1, and I've heard that some algorithms
> > need parameters, but I think I've made my point.
> 
> I think your suggestion looks good; it seems to handle the DSA and
> ECDSA cases better than just a list of hashes, and it's more
> in TLS style than sending DER-encoded AlgorithmIdentifiers. 
> 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.

-Ekr

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