Supporting RSA-PSS keys/certificates doesn't seem to be a blocker for deploying initial support for TLS 1.3, because RSA-PSS is just one of several mechanisms supported by TLS 1.3, and isn't widely deployed yet.

There's a difference between "certificates with RSA-PSS keys in them" and "certificates with RSA-PSS signatures in them". The former indeed is not a big issue as support for it is basically nowhere - OpenSSL gained support for them only in master branch, same for GnuTLS. This is a bug about the latter, not the former.

RSA-PSS signatures on the other hand is what this bug is about and they *are* a blocker and they *are* relatively widely deployed now (they are the default for current versions of Microsoft AD).

I am accumulating work-in-progress patches related to RSA-PSS signature on certificates:
https://github.com/ueno/nss/tree/wip/dueno/cert-rsa-pss

which was initially intended to address:
https://bugzilla.mozilla.org/show_bug.cgi?id=1341306

With those patches, the test cases here succeeds.  However, I guess it would require more work to make it strictly conform to RFC 5280 and RFC 4055, as we did in GnuTLS.

(In reply to Hubert Kario from comment #0)

> Additional info:
> Verifying the certificate with certutil works:
> certutil -A -d sql:./clnt-db -a -i server-pss/cert.pem -t ',,' -n server-pss
> certutil -V -d sql:./clnt-db -u V -n server-pss
> certutil: certificate is valid

This command line doesn't verify the signature.  If you add -e, it fails:

certutil -V -d sql:./clnt-db -e -u V -n server-pss
certutil: certificate is invalid: Peer's certificate has an invalid signature.

(In reply to Daiki Ueno from comment #7)
> I am accumulating work-in-progress patches related to RSA-PSS signature on
> certificates:
> https://github.com/ueno/nss/tree/wip/dueno/cert-rsa-pss
> 
> which was initially intended to address:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1341306

while that is bad, as long as NSS doesn't accept such certs as valid, it's not catastrophic (as nothing else will, so there's no chance they will proliferate)
 
> With those patches, the test cases here succeeds.  However, I guess it would
> require more work to make it strictly conform to RFC 5280 and RFC 4055, as
> we did in GnuTLS.

first priority is to get RSA-PSS signatures made using RSA keys in certificates be usable and verifiable by NSS - this is a MUST level requirement for TLS 1.3

CRLs, OCSP, CSRs, CMS, etc. would be nice addition

RSA-PSS signatures made using RSA-PSS keys being verifiable is a third level priority

NSS being able to produce such keys and signatures is a distant fourth

So, what do you mean by "strict conformity" with regards to those RFCs?
 
> (In reply to Hubert Kario from comment #0)
> 
> > Additional info:
> > Verifying the certificate with certutil works:
> > certutil -A -d sql:./clnt-db -a -i server-pss/cert.pem -t ',,' -n server-pss
> > certutil -V -d sql:./clnt-db -u V -n server-pss
> > certutil: certificate is valid
> 
> This command line doesn't verify the signature.  If you add -e, it fails:
> 
> certutil -V -d sql:./clnt-db -e -u V -n server-pss
> certutil: certificate is invalid: Peer's certificate has an invalid
> signature.

nice catch, thanks!

(In reply to Hubert Kario from comment #8)

> first priority is to get RSA-PSS signatures made using RSA keys in
> certificates be usable and verifiable by NSS - this is a MUST level
> requirement for TLS 1.3
> 
> CRLs, OCSP, CSRs, CMS, etc. would be nice addition
> 
> RSA-PSS signatures made using RSA-PSS keys being verifiable is a third level
> priority

Prioritization is good, but I am not sure those features are isolated in the implementation level.

> NSS being able to produce such keys and signatures is a distant fourth

I worry that, without the capability of producing such keys and signature by NSS itself, it could be difficult to upstream the patches.

> So, what do you mean by "strict conformity" with regards to those RFCs?

Aside from CRLs etc. I primarily meant parameter checking which I haven't yet implemented, for example:
- consistency between two RSA-PSS parameters, such as the one in SPKI and one used in signatureAlgorithm
- upper bound of the salt length

(In reply to Daiki Ueno from comment #9)

> > NSS being able to produce such keys and signatures is a distant fourth
> 
> I worry that, without the capability of producing such keys and signature by
> NSS itself, it could be difficult to upstream the patches.

Because that means writing upstream tests would rely on third party tools, I mean.

(In reply to Daiki Ueno from comment #9)
> (In reply to Hubert Kario from comment #8)
> 
> > first priority is to get RSA-PSS signatures made using RSA keys in
> > certificates be usable and verifiable by NSS - this is a MUST level
> > requirement for TLS 1.3
> > 
> > CRLs, OCSP, CSRs, CMS, etc. would be nice addition
> > 
> > RSA-PSS signatures made using RSA-PSS keys being verifiable is a third level
> > priority
> 
> Prioritization is good, but I am not sure those features are isolated in the
> implementation level.
> 
> > NSS being able to produce such keys and signatures is a distant fourth
> 
> I worry that, without the capability of producing such keys and signature by
> NSS itself, it could be difficult to upstream the patches.
> 
> > So, what do you mean by "strict conformity" with regards to those RFCs?
> 
> Aside from CRLs etc. I primarily meant parameter checking which I haven't
> yet implemented, for example:
> - consistency between two RSA-PSS parameters, such as the one in SPKI and
> one used in signatureAlgorithm
> - upper bound of the salt length

I think supporting RSA-PSS signatures rather than RSA-PSS key type and RSA-PSS signatures should be separated. The former can be done with regular RSA keys, so the amount of code necessary for generation and checking of them is smaller and it's different code, as it doesn't have any limitations on parameters selected.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0679