Re: [TLS] TLS 1.2 hash agility

At Fri, 14 Sep 2007 15:50:22 -0700,
Mike 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)
> >>>      };
> >>
> >> 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.

Yes, that's why I separated certificates from the other two situations.

Currently (in TLS 1.1) there are basically no restrictions on what
algorithms are used to sign the certs.

The ciphersuite and the ClientCertificateType indicate only the 
public key algorithm and not the hash algorithm.

So, we need to extend all three cases, to indicate the hash algorithms
that are supported.

-Ekr

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