 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
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 at lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls