1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
WHAT VERSION OF NSS?
------------------------------------------------------------------------
NSS 3.11.1 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.
|
