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
