Eric Rescorla <e...@rtfm.com> writes:
>As we are currently working on a 8446-bis, the best thing to do would be to
>file a PR at: https://github.com/tlswg/tls13-spec
Before I do that I thought I'd get some input on what to say, there's actually
two issues, the first being the one I mentioned. I was thinking something
like:
TLS 1.2 defined the entries in the "extension_data" as two eight-bit values
constituting a { hash, signature } pair. TLS 1.3 changes the definition to
be a single 16-bit value constituting a cipher suite that encodes both the
signature and hash algorithm into a single value. Although some of the TLS
1.3 values, in particular the rsa_pss_rsae_xxx ones, appear to follow the
TLS 1.2 format, implementations SHOULD NOT treat them as { hash, signature }
pairs but as a single cipher suite identifier.
The second one is the fact that there are two different cipher suites for RSA-
PSS, rsa_pss_rsae_xxx and rsa_pss_pss_xxx, with conditions for use that are
stated in a somewhat backwards form, "If the public key is carried in an
X.509 certificate, it MUST use the RSASSA-PSS OID". Since the only reason
these exist AFAICT is to deal with rsaEncryption vs. RSA-PSS certs, it should
really be stated as something like "the RSA-PSS code point used depends on how
the key is carried in an X.509 certificate. If the certificate OID is
rsaEncryption then the rsa_pss_rsae_xxx form MUST be used. If the certificate
OID is RSASSA-PSS then the rsa_pss_pss_xxx form MUST be used".
And then add some explanation for why this is so and what'll go wrong if you
use the other one, since I can't see any reason why you can't just use
rsa_pss_rsae_xxx or rsa_pss_pss_xxx for everything. What vulnerability is
this mitigating?
Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
