Bug 1432142 - Connections to hosts using certificates with RSASSA-PSS signatures do not work
Summary: Connections to hosts using certificates with RSASSA-PSS signatures do not work
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nss
Version: 7.4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: pre-dev-freeze
: 7.4
Assignee: Daiki Ueno
QA Contact: Hubert Kario
Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks: rhel7-rsa-pss-in-nss rhel7-nss-tls1.3 1538081
TreeView+ depends on / blocked
 
Reported: 2017-03-14 15:57 UTC by Hubert Kario
Modified: 2019-04-21 07:29 UTC (History)
5 users (show)

Fixed In Version: nss-3.34.0-1.el7
Doc Type: Technology Preview
Doc Text:
.`NSS` is now able to verify `RSA-PSS` signatures on certificates Since the RHEL 7.5 version of the _nss_ package, the *Network Security Services* (NSS) libraries provide verifying `RSA-PSS` signatures on certificates as a Technology Preview. Prior to this update, clients using `NSS` as the `SSL` backend were not able to establish a `TLS` connection to a server that offered only certificates signed with the `RSA-PSS` algorithm. Note that the functionality has the following limitations: * The algorithm policy settings in the `/etc/pki/nss-legacy/rhel7.config` file do not apply to the hash algorithms used in `RSA-PSS` signatures. * `RSA-PSS` parameters restrictions between certificate chains are ignored and only a single certificate is taken into account.
Clone Of:
Environment:
Last Closed: 2018-04-10 09:25:43 UTC


Attachments (Terms of Use)
server certificate with rsa-pss signature (21.36 KB, application/x-xz)
2017-03-14 15:57 UTC, Hubert Kario
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0679 None None None 2018-04-10 09:26:39 UTC
Mozilla Foundation 158750 None None None 2019-07-31 10:10:59 UTC
Mozilla Foundation 1400844 None None None 2019-07-31 10:10:59 UTC

Description Hubert Kario 2017-03-14 15:57:35 UTC
Created attachment 1263008 [details]
server certificate with rsa-pss signature

Description of problem:
When nss client like tstclnt connects to a server that uses certificate signed using RSASSA-PSS algorithm, the connection is aborted with SEC_ERROR_BAD_SIGNATURE.

Version-Release number of selected component (if applicable):
nss-3.28.3-3.el7.x86_64

How reproducible:
always

Steps to Reproduce:
tar xJf certs.tar.xz

mkdir srv-db
certutil -N -d sql:./srv-db --empty-password
certutil -A -d sql:./srv-db -a -i ca/cert.pem -t 'cC,,' -n ca
pk12util -i server-pss/bundle.p12 -d sql:./srv-db/ -W ''

/usr/lib64/nss/unsupported-tools/selfserv -d sql:./srv-db -p 4433 -n server-pss

mkdir clnt-db
certutil -N -d sql:./clnt-db --empty-password
certutil -A -d sql:./clnt-db -a -i ca/cert.pem -t 'cC,,' -n ca

/usr/lib64/nss/unsupported-tools/tstclnt -d sql:./clnt-pss-db -h localhost -p 4433

Actual results:
tstclnt: authentication of server cert failed: SEC_ERROR_BAD_SIGNATURE: Peer's certificate has an invalid signature.

Expected results:
successful connection

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

Comment 5 Kai Engert (:kaie) (inactive account) 2017-07-28 13:24:39 UTC
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.

Comment 6 Hubert Kario 2017-07-30 17:46:39 UTC
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).

Comment 7 Daiki Ueno 2017-08-25 09:42:13 UTC
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.

Comment 8 Hubert Kario 2017-08-25 10:35:54 UTC
(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!

Comment 9 Daiki Ueno 2017-08-25 13:05:47 UTC
(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

Comment 10 Daiki Ueno 2017-08-25 13:15:51 UTC
(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.

Comment 11 Hubert Kario 2017-08-25 13:21:15 UTC
(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.

Comment 24 errata-xmlrpc 2018-04-10 09:25:43 UTC
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


Note You need to log in before you can comment on or make changes to this bug.