I don't think that this is the right answer. Let's separate out the question of (a) what people need to support and (b) what the code points mean. (b) needs to be unambigous, as that's the point of the extension and this PR actually makes it explicitly unambigous.
With that said, there seem to be two points of contention: - Whether the code point refers to signatures other than those in CertificateVerify - Whether the code point refers to SPKIs with OIDs other than rsaEncryption For the first point, I recognize that there are those who believe that the code point should refer only to CertificateVerify but that's not what it meant in TLS 1.2 and I don't think there's consensus to make that change. We could certainly introduce a new extension later which refers to just chain certificates. For the second point, I wouldn't be averse to having two code points, one for PSS that means "must be rsaEncryption" and one for "PSS with funny parameters" (with the hope we only ever needed the first). But that's not this PR. -Ekr On Tue, Nov 21, 2017 at 7:54 PM, Peter Wu <pe...@lekensteyn.nl> wrote: > Hi, > > At the moment there is still ambiguity in the requirements for PSS with > relation to certificates. Proposal to clarify this: > https://github.com/tlswg/tls13-spec/pull/1098 > > > This PR intends to clarify the requirements for PSS support. > > The requirements are intentionally minimal to reduce implementation > efforts, but recognizes that some other implementations may be more > complete. Notes: > > - "Supporting PSS signatures on certificates is a mandatory requirement > and I think we should be very clear about the parameters we permit." > https://www.ietf.org/mail-archive/web/tls/current/msg23007.html > - Martin Rex wishes to remove TLS requirements on signature algorithms > for certificates, hence the "MAY" for other PSS parameters in this PR. > https://www.ietf.org/mail-archive/web/tls/current/msg23021.html > - Regardless, rsa_pss_sha256 is currently MTI for CertificateVerify and > certificates, hence the strong MUST wording in this PR. > - It does not say anything about non-end-entity certificates, that's up > to the PKI verifier. Consider case "CA Key: rsa-pss; EE signature: > rsa-pss; EE key: rsa" from > https://www.ietf.org/mail-archive/web/tls/current/msg24453.html > - PSS params in certificates are explicitly not restricted, satisfying > https://www.ietf.org/mail-archive/web/tls/current/msg24457.html > > >From what I have heard, boringssl does not (or will not?) implement any > PSS support in the certificates (yet?). Don't know if anything should be > changed here to reflect that decision, but I thought it is worth > mentioning. It is possible that I'll follow boringssl's example in tris. > > If a TLS extension is introduced later, hopefully that improves interop > with odd keys and signatures that are optional in this PR (PSS pubkey or > custom salt lengths). > -- > Kind regards, > Peter Wu > https://lekensteyn.nl > > _______________________________________________ > 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
