On Sat, Oct 29, 2016 at 2:27 PM, Joseph Birr-Pixton <jpix...@gmail.com>
wrote:
> Just a quick question. In TLS1.3 we have:
>
> enum {
> rsa_pkcs1_sha1 (0x0201),
> rsa_pkcs1_sha256 (0x0401),
> rsa_pkcs1_sha384 (0x0501),
> rsa_pkcs1_sha512 (0x0601),
> ecdsa_secp256r1_sha256 (0x0403),
> ecdsa_secp384r1_sha384 (0x0503),
> ecdsa_secp521r1_sha512 (0x0603),
> (then)
> rsa_pss_sha256 (0x0804),
> rsa_pss_sha384 (0x0805),
> rsa_pss_sha512 (0x0806),
> } SignatureScheme;
>
> This kind of looks like someone was trying to make the
> rsa_pss_shasomething ordinals be decodable by a TLS1.2 implementation
> given a SignatureAlgorithm reservation for PSS of 8, but got the bytes
> the wrong way around.
>
> Is this an error, or am I missing something subtle?
>
No, it's not an error. We deliberately allocated code points with (what
would be in TLS 1.2)
an unknown hash and an unknown signature algorithm. AFAIK it's just
coincidence that the second
byte matches up with the 1.5 digest algorithms, by virtue of us counting
upward.
-Ekr
> Cheers,
> Joe
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
