On Sat, Feb 18, 2017 at 02:31:19AM +0000, Dr Stephen Henson wrote:
> > If client includes RSA-PSS codepoints in its signature_algorithms,
> > then:
> >
> > - The server handshake signature MAY be signed using RSA-PSS in TLS
> > 1.2 or later. Yes, 1.2, not 1.3.
> > - The certificate chain MAY contain certificates signed with RSA-PSS
> > in any TLS version (however, the salt length must match hash length).
> >
> > In converse case:
> >
> > - The server MUST NOT sign handshake using RSA-PSS in any TLS
> > version
> > - The certificate chain SHOULD NOT contain certificates signed with
> > RSA-PSS in any TLS version.
> >
>
> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
> certificates too?
>
> For example could a TLS 1.2 server legally present a certificate containing an
> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client
> present
> a certificate contain an RSASSA-PSS key?
Isn't an RSA public key independent of the signature algorithms it
might be employed with? If the EE cert has an RSA key, and RSA-PSS
is not negotiated, can't the peer (client or server) just sign with
PKCS#1? So the same EE cert would then be valid for either PSS or
PKCS#1? Or have I missed the memo on how PSS works with EE certs?
As for the signatures in the X.509 chain itself, the "SHOULD NOT"
above just means that we have a non-PSS chain to offer, then we
offer that, but if PSS is all we have, then present that chain.
Fundamentally, X.509 verification lies outside of TLS, and it is
not the job of TLS to second-guess the X.509 stacks on either end.
The peers can provide hints about preferred/supported algorithms,
but in the case of X.509 these are not hard constraints. The X.509
algorithm hints in TLS are about increasing the chances of
interoperability, and not excluding unadvertised codepoints.
--
Viktor.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
