Hubert Kario <hka...@redhat.com> 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
