Interested in reviving PSS support in NSS
Hi, A couple of years ago I participated in a summer of code project for NSS to create an implementation of the RSA-PSS signature scheme für X.509 signatures. Unfortunately the code never got fully merged. Right now the state is that code for the basic functions exists in freebl, but all upper layer code is not merged. I think if I remember correctly the code currently in freebl will also not work in some corner cases (keys mod 8 != 0). The bugtracker entry is here: https://bugzilla.mozilla.org/show_bug.cgi?id=158750 I would be motivated to take up that work again if someone from the NSS team would be willig to work on merging the code. I'd be interested in this because I want to make a proposal to get PSS support into TLS 1.3 and it would certainly help if I could say that all major TLS libraries support it already. cu, -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgp56J3gT1aWe.pgp Description: OpenPGP digital signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Interested in reviving PSS support in NSS
On Sun, February 15, 2015 3:07 pm, Hanno Böck wrote: Unfortunately the code never got fully merged. Right now the state is that code for the basic functions exists in freebl, but all upper layer code is not merged. I think if I remember correctly the code currently in freebl will also not work in some corner cases (keys mod 8 != 0). This is true for all of the RSA code in NSS (not handling non-mod 8 keys). This is also fairly consistent across several cryptographic libraries. I refactored this code to move it from softoken (the PKCS#11 shim) into freebl (the crypto primitives), where unit tests were also added (to bltest). This was tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=836019 There were also issues where it wasn't exposed (at the PKCS#11 layer) / wasn't validating parameters correctly, but those should be fixed. The bugtracker entry is here: https://bugzilla.mozilla.org/show_bug.cgi?id=158750 I would be motivated to take up that work again if someone from the NSS team would be willig to work on merging the code. I'd be interested in this because I want to make a proposal to get PSS support into TLS 1.3 and it would certainly help if I could say that all major TLS libraries support it already. I'm quite mixed on this as the motivation (PSS in TLS), but I think the state of implementing and exposing PSS through the appropriate layers (except for TLS) is worth doing. Here's the current status of PSS support: What works: - It's implemented (and tested) in freebl/ with bltests - It's implemented (but not tested) in softoken/ as a PKCS#11 mechanism for C_Sign/C_Verify What doesn't: - There's no way to reach it from PK11_Sign, due to the fact that PK11_Sign doesn't take a CK_MECHANISM_TYPE/SECITEM* param pair (like PK11_Encrypt), and thus you can't supply the CK_RSA_PKCS_PSS_PARAMS that you might have - PK11_MapSignKeyType is used rather extensively, and it maps the SECKEYPrivateKey KeyType incorrectly (rsaPssKey should map to PSS, but doesn't) - The more general issue of SECKEYPublicKey/SECKEYPrivateKey not handling the PSS appropriately (nearly every switch on KeyType will handle this wrong, for example; further, it's become enshrined in plenty of downstream code as to how to handle PSS keys here) - The SGNContext*/VFYContext* interface is entirely borked for PSS. - It assumes all the parameters can be expressed via a SECOidTag. That is, it's missing hash alg, mgf alg, salt length (e.g. the RSASSA-PSS-params construction) - SEC_GetSignatureAlgorithmOidTag is borked for PSS - SECOID_GetAlgorithmTag is borked for PSS - CERT_VerifySignedData doesn't handle PSS (e.g. policy checking flags) Of course, I'm ignoring all the issues with the nightmare that is the SPKI for PSS/OAEP and those behaviours. If you're expecting CAs to issue such certificates, I would call it extremely unlikely. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Interested in reviving PSS support in NSS
Ryan Sleevi ryan-mozdevtechcry...@sleevi.com wrote: - It assumes all the parameters can be expressed via a SECOidTag. That is, it's missing hash alg, mgf alg, salt length (e.g. the RSASSA-PSS-params construction) I believe there are only a small number of (hashAlgorithm, mgf alg, salt length) combinations that need to be supported, namely these two: (sha256, mgf1-SHA256, 32 bytes) (sha384, mgf1-SHA384, 48 bytes) I think that in NSS, these combinations can be identified internally with some new OID, perhaps in the Netscape OID tree. Note that the PSS RFC says that SHA-1 is the default for everything. By not supporting SHA-1 at all, we avoid having to deal with any implicit encodings of the various parameters. The PSS RFC also says that SHA-1 is mandatory, but that silliness is just an invitation for somebody to get their name as an author of a new, reasonable, RFC. Thoughts? Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Interested in reviving PSS support in NSS
[+antoine] Hanno Böck ha...@hboeck.de wrote: Unfortunately the code never got fully merged. Right now the state is that code for the basic functions exists in freebl, but all upper layer code is not merged. There are multiple upper layers and, depending on your goals, some should be prioritized higher than others. I think if I remember correctly the code currently in freebl will also not work in some corner cases (keys mod 8 != 0). IIUC, this is not urgent to support and may not be worth supporting at all. IIRC, there are lots of places in NSS and mozilla::pkix that explicitly reject keys and signatures that are not multiples of 8 bits. The bugtracker entry is here: https://bugzilla.mozilla.org/show_bug.cgi?id=158750 That bug is too big and messy to make sense of at this point. Also, some of the patches that haven't been checked in yet should be split up. I suggest that you proceed as follows: 1. Split 000a-pss-verification-v15.diff into two patches: One part that adds the pk11wrap functionality, and a separate part that adds the cryptohi functionality. Put each new patch in its own new NSS bug. 2. Move 0009-add-pk11-mgfmap-v3.diff, 000b-pss-sign-v15.diff, and 000c-tests-v2.diff to a new bug. 3. Move 0012-fix-pss-verification-for-uncommon-keysizes-v5.diff to a new bug, which will have low priority. 4. Close the existing bug as RESOLVED FIXED. Even with all the above patches landed, Firefox and other Gecko-based applications will not accept PSS signatures for certificates. Of the above patches, only the patch to add PK11_VerifyWithSigAlg is relevant to Gecko. New patches for mozilla::pkix and for its test suite, which basically duplicate all the work in the rest of the patches mentioned above, would be needed. But... I want to make a proposal to get PSS support into TLS 1.3 and it would certainly help if I could say that all major TLS libraries support it already. First somebody needs to create a reasonable specification detailing exactly which subset of the PSS specification should be supported for TLS. The current PSS specification allows *way* too much flexibility and also has terrible defaults. I believe Antoine and his team have a good idea of what a reasonable subset of PSS would look like. I recommend working with him to develop such a spec. Without such a spec, I wouldn't support adding PSS support to mozilla::pkix. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
