diff options
Diffstat (limited to 'src/nss/README')
| -rw-r--r-- | src/nss/README | 128 |
1 files changed, 128 insertions, 0 deletions
diff --git a/src/nss/README b/src/nss/README new file mode 100644 index 00000000..65a0f45e --- /dev/null +++ b/src/nss/README @@ -0,0 +1,128 @@ +WHAT VERSION OF NSS? +------------------------------------------------------------------------ +NSS 3.9 or greater and NSPR 4.4.1 or greater are required. + +KEYS MANAGER +------------------------------------------------------------------------ + +xmlsec-nss key manager uses a custom Keys Store, and a custom X509 Store. +The custom Keys Store and the X509 Store use the NSS database as the underlying +store for public/private keys, Certs and CRLs. + +The NSS Keys store uses the Simple Keys Store on top of the NSS repository. +The reason for this is that XMLSEC's generic adoptkey/getKey functions use a +XMLSEC key object that contains more attributes than the raw NSS key object, +and the getkey function may use a combination of one or more of these attributes +(name, type, usage, Id) to find a key. There is no straightforward 1-1 mapping +between XMLSEC's adoptkey/getkey and NSS's APIs. + +For example, the store may be asked to adopt a symmetric key, and later asked +to find it just by name. Or the store may be asked to adopt a private key +just by its type, and later asked to find it just by type. The key returned +by getKey is expected to contain all the attributes that were present at the +time of adoptkey - NSS store does not provide a way to store app-specific +attributes. + +When a key is adopted by the NSS Keys Store, it is simply saved in the +Simple Keys Store. It is not saved into the NSS database. The only +way to load keys into the NSS database is with a load operation through +the XMLSEC API or via an administrator operation. + +When a getKey is done on the NSS Keys Store, it first checks the Simple +Keys Store. If the key is found there, it is returned. If not, the key +is searched in the NSS database. If found, the key is stored in the +Simple Keys Store before it is returned. + + +Thus, the various sources for keys/certs/crls for an XMLSEC-NSS application +are: +- elements in XML documents +- PKCS12 and DER files +- NSS Database + + +KNOWN ISSUES +------------------------------------------------------------------------ +1) NSS needs to provide a way to convert a DER integer string to an ASCII +decimal string. Once NSS is fixed, the function xmlSecNssASN1IntegerWrite +in src/nss/x509.c needs to be implemented. + NSS bug: http://bugzilla.mozilla.org/show_bug.cgi?id=212864 + xmlsec bug: http://bugzilla.gnome.org/show_bug.cgi?id=118633 + +2) RSA Encryption/Decryption using PKCS#1 v1.5 padding not currently exposed +in NSS. This causes some tests to fail. + + NSS bug: http://bugzilla.mozilla.org/show_bug.cgi?id=214236 + xmlsec bug: http://bugzilla.gnome.org/show_bug.cgi?id=118628 + +3) RSA-OAEP is not yet implemented in NSS. This is the only REQUIRED algorithm +that is missing from xmlsec-nss. + + NSS bug: http://bugzilla.mozilla.org/show_bug.cgi?id=158747 + xmlsec bug: http://bugzilla.gnome.org/show_bug.cgi?id=118629 + +4) CERT_FindCertByNameString does not work in all cases + + NSS bug: http://bugzilla.mozilla.org/show_bug.cgi?id=210709 + xmlsec bug: http://bugzilla.gnome.org/show_bug.cgi?id=118631 + +5) CERT_FindCertBySubjectKeyID does not work in all cases + + NSS bug: http://bugzilla.mozilla.org/show_bug.cgi?id=211051 + xmlsec bug: http://bugzilla.gnome.org/show_bug.cgi?id=118632 + +6) Finding a cert by Issuer & Serial Number needs the ability to +convert an ASCII decimal string to a DER integer string. Filed +an RFE against NSS. Once fixed, xmlSecNumToItem in x509vfy.c +needs to be changed to use the new function(s) provided + + NSS bug: http://bugzilla.mozilla.org/show_bug.cgi?id=212864 + xmlsec bug: http://bugzilla.gnome.org/show_bug.cgi?id=118633 + +7) RIPEMD160 Digest and RIPEMD160 HMAC is not supported by NSS + + xmlsec bug: http://bugzilla.gnome.org/show_bug.cgi?id=118634 + +8) AES Key wrap algorithm is implemented in NSS but not exposed due to +some bug src/nss/kw_aes.c uses a workaround which should be removed +when the bug is fixed + + NSS bug: http://bugzilla.mozilla.org/show_bug.cgi?id=213795 + xmlsec bug: http://bugzilla.gnome.org/show_bug.cgi?id=118635 + +9) Not all file formats are supported + +- xmlSecNssAppKeyLoad(): This function loads a PKI key from a file. + The following formats are supported: + . xmlSecKeyDataFormatDer: This expects the private key to be in + PrivateKeyInfo format. Note that the DER files containing + private keys in the xmlsec test suite aren't in that format + . xmlsecKeyDataFormatPkcs12 + + The following formats are not supported: + . xmlSecKeyDataFormatPkcs8Pem + . xmlSecKeyDataFormatPkcs8Der + + +- xmlSecNssAppCertLoad(): This function loads a cert from a file. + The following formats are supported: + xmlSecKeyDataFormatDer + + The following formats are not supported: + xmlSecKeyDataFormatPem + +10) "Trusted" vs "Untrusted" certificates: +The distinction between "trusted" and "untrusted" certificates in +xmlsec-openssl is maintained because the OPENSSL application (and +not the OPENSSL library) has to maintain a cert store and verify +certificates. With NSS, no such distinction is necessary in the +application. + +Aleksey: Not sure that I understand this point but thats what Tej wrote. + +11) NSS doesn't support emailAddress in the cert subject. There is a hack +that needs to be removed in xmlSecNssX509FindCert function (x509vfy.c): + +https://bugzilla.mozilla.org/show_bug.cgi?id=561689 + +12) CRLs from xml document support is not working at all. |