summaryrefslogtreecommitdiff
path: root/src/nss/README
diff options
context:
space:
mode:
Diffstat (limited to 'src/nss/README')
-rw-r--r--src/nss/README95
1 files changed, 52 insertions, 43 deletions
diff --git a/src/nss/README b/src/nss/README
index 65a0f45e..884ade99 100644
--- a/src/nss/README
+++ b/src/nss/README
@@ -1,29 +1,29 @@
WHAT VERSION OF NSS?
------------------------------------------------------------------------
-NSS 3.9 or greater and NSPR 4.4.1 or greater are required.
+NSS 3.8 or greater and NSPR 4.3 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
+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
+(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
+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.
@@ -41,88 +41,97 @@ are:
- NSS Database
-KNOWN ISSUES
+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.
+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
+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
+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
+ xmlsec bug: http://bugzilla.gnome.org/show_bug.cgi?id=118629
+
+4) There are 2 fixes in NSS that will be rolled into the next release (3.9).
+They are:
+ - http://bugzilla.mozilla.org/show_bug.cgi?id=208194
+ Once available, need to change src/nss/x509.c. Replace
+ PR_AtomicIncrement(&(crlSrc->referenceCount));
+ with
+ SEC_DupCrl(crlSrc);
+ (there is a comment there that already has the correct line)
+
+ - http://bugzilla.mozilla.org/show_bug.cgi?id=211384
+ No changes required. The "NSS_Shutdown failed" in some of the
+ current tests will go away
-4) CERT_FindCertByNameString does not work in all cases
+xmlsec bug: http://bugzilla.gnome.org/show_bug.cgi?id=118630
+
+5) 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
-
+6) 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
+7) 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
+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
+8) 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
+
+9) 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
+10) Not all file formats are supported
-- xmlSecNssAppKeyLoad(): This function loads a PKI key from a file.
+- 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
+ . 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
+ . xmlsecKeyDataFormatPkcs12
The following formats are not supported:
. xmlSecKeyDataFormatPkcs8Pem
. xmlSecKeyDataFormatPkcs8Der
-- xmlSecNssAppCertLoad(): This function loads a cert from a file.
+- 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
+11) "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
+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.