On Tuesday, 12 September 2017 02:39:02 CEST Nick Sullivan wrote: > This situation is likely to arise every time a new signature algorithm is > introduced. Suppose a TLS client library is updated to support Ed25519 > certificates, but that the PKIX library only supports validating Ed25519 > certificates signed by RSA or ECDSA, which signature schemes should the > client present? This is similar to the 2014 issue with ECDSA and Chrome on > XP (https://bugs.chromium.org/p/chromium/issues/detail?id=409901), in which > the PKIX library didn't support ECDSA, but the TLS stack did. As long as > TLS and PKIX libraries are decoupled, the dual meaning of the signature > scheme makes the addition of a new algorithm to one or the other a bit > messy. > > For example: In the current situation, it is mandatory to support > rsa_pss_sha256, but how many of these clients support certificates signed > with PSS? Not many -- including OpenSSL ( > https://github.com/openssl/openssl/issues/2878#issuecomment-328576616).
Actually OpenSSL does support certificates signed with RSA-PSS, it doesn't
support RSA-PSS keys in certificates.
> Without PSS certificate support, if we chose EKR's option 1, these clients
> would not be able to support TLS 1.3 according to the spec. This seems like
> an unnecessary dependency.
With RSA-PSS the situation is even more complex, as you have it in two places,
in the signature and in the public key id.
So the possibilities are as follows:
- CA key: rsa; EE signature: rsa; EE key: rsa
- that certificate can be used with any version of TLS and can make both
rsa-pss and rsa signatures
- CA key: rsa; EE signature: rsa; EE key: rsa-pss
- that certificate can be used only with TLS 1.3 or TLS 1.2 that was
updated to support TLS 1.3 signatures, does not require support for
RSA-PSS in PKIX (with the assumption that the library allows the TLS
library to extract the RSA-PSS parameters from the certificate)
- CA key: rsa; EE signature: rsa-pss; EE key: rsa
- that certificate can be used again only with TLS 1.3 or TLS 1.2 but
that's because RFC compliant peer can send only certificates that have
signatures listed in SignatureAlgorithms. Can sign using both rsa and
rsa-pss but it DOES require RSA-PSS support in PKIX
- CA Key; rsa; EE signature: rsa-pss; EE key: rsa-pss
- similarly to the above, but does limit the usage of certificate to
TLS 1.2 with rsa-pss or TLS 1.3, cannot be used to make RSA-PKCS#1 v1.5
signatures in TLS 1.2
- CA Key: rsa-pss; EE signature: rsa-pss; EE key: rsa
- exactly as with CA key: rsa; EE signature: rsa-pss; EE key: rsa
- CA Key; rsa-pss; EE signature: rsa-pss; EE key: rsa-pss
- similarly to the above, but cannot be used to make RSA-PKCS#1 v1.5
signatures in TLS 1.2, thus requires RSA-PSS support in TLS 1.2 from
the TLS part of the library
Now, if a client sends only rsa_pss_sha256, I'd say, that all of the following
need to work:
- CA key: rsa; EE signature: rsa-pss; EE key: rsa
- CA Key; rsa; EE signature: rsa-pss; EE key: rsa-pss
- CA Key: rsa-pss; EE signature: rsa-pss; EE key: rsa
- CA Key; rsa-pss; EE signature: rsa-pss; EE key: rsa-pss
If both rsa_pss_sha256 and rsa_pkcs1_sha256 are sent, then all 6 combinations
should be supported by client.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
