Dr Stephen Henson wrote: > On 25/04/2017 15:36, Benjamin Kaduk wrote: >> >> RSASSA-PSS algorithms Indicates a signature algorithm using RSASSA- >> PSS [RFC3447 <https://tools.ietf.org/html/rfc3447>] with mask >> generation function 1. The digest used in >> the mask generation function and the digest being signed are both >> the corresponding hash algorithm as defined in [SHS >> <https://tools.ietf.org/html/draft-ietf-tls-tls13-19#ref-SHS>]. When used >> in signed TLS handshake messages, the length of the salt MUST be >> equal to the length of the digest output. This codepoint is also >> defined for use with TLS 1.2. >> >> >> Is the concern that this is insufficiently clearly indicated as placing >> requirements on signatures of certificates as opposed to signatures of >> TLS data structures? > > Yes that's my concern. Supporting PSS signatures on certificates is > a mandatory requirement and I think we should be very clear about the > parameters we permit. > > The above paragraph says nothing about salt length limitations on > signatures on certificates. We could have a situation where one > implementation enforces the salt length to be equal to the digest length > (and rejects everything else) and another will allow any valid length.
It has always been a terribly stupid bug that TLS started talking about signatures on certificates when negotiating TLS protocol properties, and it resulted in a few painfully broken TLSv1.2 implementations getting shipped (such as Microsoft Windows7/2008R2 through 8.1/2012R2). Please ensure that TLSv1.3 is cleaned from bogus references about requirements on signature algorithms for certificates. Signatures on certificates are created by CAs, rather than TLS endpoints, so any implementation that uses TLS protocol parameters (about TLS signature algorithms) for more than a mere cert selection hint, is actively creating interop problems while providing *NO* value. Many TLS peers will have just one suitable certificate anyway, so not even looking at certificate signatures will be the easiest to implement, most robust and perfectly secure behaviour anyway. The issue with RSA-PSS digital signatures is that they were defined with additional (unnecessary) parameters that are encoded (=hidden) in the ASN.1 AlgorithmIdentifier, and that are therefore unspecified when RSA-PSS is requested as (rsa-pss,sha-256) rather than with an ASN.1 AlgorithmIdentifier. The additional, unnecessary parameters are "saltLen" and "MaskGenerationFunction" (MGF), and the commonly-used MaskGenerationFunction (mgf1) adds yet another additional, unnecessary parameter (MGF-internal hash). In theory there is another additional, unnecessary parameter "TrailerField", which appears in the ASN.1 AlgorithmIdentifier parameter list (and in the XMLdsig encoding for RSA-PSS), but PKCS#1 v2.1 (rfc3447) essentially hardwires the Trailerfield to option TrailerfieldBC(1), internal value 0xbc. The definition of "implied" RSA-PSS parameters applies only to the "digitally-signed" signature blobs using inside the TLS protocol because these do not come with an ASN.1 AlgorithmIdentifier tag. The implied RSA-PSS paramters for TLS' digitally-signed are unrelated to RSA-PSS signatures on certificates (certificates come with explicit RSA-PSS parameters encoded in an ASN.1 AlgorithmIdentifer): Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } The original RSA-PSS AlgorithmIdentifer specification also defines a hierarchical policy concept, that is supposed to limit the kinds of signatures that can be created (verified) with a so-tagged public RSA key, and this policy is supposed to work/apply from the RootCA cert *downwards* to the leaf / end-entity cert. It seems silly trying to apply implied RSA-PSS parameter selections from the digitally-signed TLS protocol transform to the signature on the TLS end-entity cert (or worse, even to certs up the cert chain), because that would be the wrong/invalid direction. What should be spelled out, whether and how any RSA-PSS policy in the subjectPublicKeyInfo AlgorithmIdentifier of the end-entity certificate interacts with implied RSA-PSS parameters used by the TLS digitally-signed transform. In any case, the decision whether to accept a certificate should be _with_the_receiver_ (verifier / RP), and *NEVER* with the sender. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls