Re: [TLS] Possible TLS 1.3 erratum

[Peter Gutmann <[e-mail]>]

Hubert Kario <[e-mail]> writes:

>I suggest you go back to the RFCs and check exactly what is needed for proper
>handling of RSA-PSS Subject Public Key type in X.509. Specifically when the
>"parameters" field is present.

Looking at the code I'm using, it's four lines of extra code for PSS when
reading sigs and four lines extra when writing (OK, technically seven if you
include the "if" statement and curly braces lines).

>You definitely won't be able to implement it in just "few lines".

See above.

>2. "What certificates can peer accept" is totally within the purview of TLS.

Two things, firstly those values are used in two different extensions, only
one of which covers signatures in certificates, and secondly, what happens if
the client says rsa_pss_pss and the server only has an rsa_pss_rsae
certificate?  Does the server admin rush out and buy an rsa_pss_pss
certificate (or, at the moment, found a new public CA that will issue them an
rsa_pss_pss certificate) just to keep the client happy?  Or are they expected
to go out and buy two lots of every certificate that differ only in the RSA
OID used just to play along with the client's request?  This is exactly the
reason why CMS rejected special-case handling for this stuff, because it
doesn't make any sense.  And now TLS is doing the exact thing that CMS
rejected for not making any sense.

Since the next step in the exchange will be to send the client the
certificate, the only thing it could potentially do is save a single round
trip when the handshake is rejected by the server for lack of an
appropriately-OIDed cert rather than the client when it gets said cert.

Peter.