435314 - nssToken_FindCertificatesByEmail returns certs whose email address(es) do not match

Status: NEW

(NSS :: Libraries, defect, P2)

Description

[Christophe Ravel]

When 2 certs in the database have the same Subject but different Subject Alt Name, cmsutil is not able to add the 2 certs in a pkcs7 package.

Comment 1

[Christophe Ravel]

Example:
Cert1:
  Issuer: "CN=Navy ROOT CA,O=Navy,C=US"
  Subject: "CN=Bridge BRIDGE,O=Bridge,C=US"
  Name: Certificate Subject Alt Name / RFC822 Name: "NavyRoot@Navy"
Cert2:
  Issuer: "CN=Army ROOT CA,O=Army,C=US"
  Subject: "CN=Bridge BRIDGE,O=Bridge,C=US"
  Name: Certificate Subject Alt Name / RFC822 Name: "ArmyRoot@Army"

These 2 certs are in the database BridgeDB.

Command to create a pkcs7 package containing these 2 certs:
cmsutil -O -r "NavyRoot@Navy,ArmyRoot@Army" -d BridgeDB > BridgeWithAIA.p7

The result file BridgeWithAIA.p7 contains 2 certs, but they are both the same:

pp -t pkcs7 -i BridgeWithAIA.p7 
PKCS #7 Content Info:
    PKCS #7 Signed Data:
        Version: 1 (0x1)
        Digest Algorithm List:
        Content Information:
            PKCS #7 Data:
                (empty)
        Certificate List:
            Certificate (1):
                Data:
                    Version: 3 (0x2)
                    Serial Number:
                        00:89:bb:06:ed
                    Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
                    Issuer: "CN=Navy ROOT CA,O=Navy,C=US"
                    Validity:
                        Not Before: Thu May 22 21:15:45 2008
                        Not After : Wed May 22 21:15:45 2013
                    Subject: "CN=Bridge BRIDGE,O=Bridge,C=US"
                    Subject Public Key Info:
                        Public Key Algorithm: PKCS #1 RSA Encryption
                        RSA Public Key:
                            Modulus:
                                bc:41:28:d2:5b:29:78:7c:fe:f8:e0:cb:31:d9:dd:
                                cf:47:01:83:4b:48:22:6f:28:d4:d6:e0:cb:c9:27:
                                40:58:ee:7b:45:fd:a5:e9:b6:4f:32:36:d1:1d:6b:
                                85:dc:55:1d:8a:5a:dc:fa:04:96:4b:67:64:bd:7c:
                                02:f1:64:62:d6:b0:28:72:db:f0:53:8c:c9:bf:53:
                                48:2f:97:d8:8c:6f:33:f9:c1:f2:8e:9d:fd:e0:1b:
                                ad:ef:8b:11:26:53:6f:af:6b:bf:df:2a:7e:ab:49:
                                bf:ef:b8:ea:61:89:21:14:7e:44:6b:5a:73:61:f6:
                                76:b6:27:c3:2c:20:40:8d
                            Exponent: 65537 (0x10001)
                    Signed Extensions:
                        Name: Certificate Basic Constraints
                        Critical: True
                        Data: Is a CA with no maximum path length.

                        Name: Certificate Subject Alt Name
                        RFC822 Name: "NavyRoot@Navy"

                Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
                Signature:
                    ab:6a:ef:63:6b:45:a2:ee:2b:f7:4a:4c:fd:c6:a2:1d:
                    e9:8e:1c:4c:d2:80:af:e2:ff:9f:87:82:af:0e:8e:3b:
                    20:9b:bf:c7:10:b0:47:0a:91:66:fb:34:3d:da:a5:28:
                    c6:75:39:f4:1e:26:4e:1a:d4:a8:9e:11:74:e4:5f:fe:
                    68:88:8d:17:5d:c6:e4:6f:fb:51:28:0c:b5:fa:12:90:
                    da:af:ea:25:2f:b7:12:7b:e1:18:45:55:51:1e:65:03:
                    93:11:4b:f8:b1:5a:75:d5:d9:1a:97:cc:83:02:24:ae:
                    b8:fb:70:d3:ae:76:96:10:ab:98:ee:9e:98:a6:14:98
                Fingerprint (MD5):
                    13:7B:7C:17:D8:5B:13:88:FA:E6:C5:48:B4:6E:16:5F
                Fingerprint (SHA1):
                    2E:12:12:39:C4:49:92:05:49:CE:0B:35:5C:22:B6:24:01:12:75:86

            Certificate (2):
                Data:
                    Version: 3 (0x2)
                    Serial Number:
                        00:89:bb:06:ed
                    Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
                    Issuer: "CN=Navy ROOT CA,O=Navy,C=US"
                    Validity:
                        Not Before: Thu May 22 21:15:45 2008
                        Not After : Wed May 22 21:15:45 2013
                    Subject: "CN=Bridge BRIDGE,O=Bridge,C=US"
                    Subject Public Key Info:
                        Public Key Algorithm: PKCS #1 RSA Encryption
                        RSA Public Key:
                            Modulus:
                                bc:41:28:d2:5b:29:78:7c:fe:f8:e0:cb:31:d9:dd:
                                cf:47:01:83:4b:48:22:6f:28:d4:d6:e0:cb:c9:27:
                                40:58:ee:7b:45:fd:a5:e9:b6:4f:32:36:d1:1d:6b:
                                85:dc:55:1d:8a:5a:dc:fa:04:96:4b:67:64:bd:7c:
                                02:f1:64:62:d6:b0:28:72:db:f0:53:8c:c9:bf:53:
                                48:2f:97:d8:8c:6f:33:f9:c1:f2:8e:9d:fd:e0:1b:
                                ad:ef:8b:11:26:53:6f:af:6b:bf:df:2a:7e:ab:49:
                                bf:ef:b8:ea:61:89:21:14:7e:44:6b:5a:73:61:f6:
                                76:b6:27:c3:2c:20:40:8d
                            Exponent: 65537 (0x10001)
                    Signed Extensions:
                        Name: Certificate Basic Constraints
                        Critical: True
                        Data: Is a CA with no maximum path length.

                        Name: Certificate Subject Alt Name
                        RFC822 Name: "NavyRoot@Navy"

                Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
                Signature:
                    ab:6a:ef:63:6b:45:a2:ee:2b:f7:4a:4c:fd:c6:a2:1d:
                    e9:8e:1c:4c:d2:80:af:e2:ff:9f:87:82:af:0e:8e:3b:
                    20:9b:bf:c7:10:b0:47:0a:91:66:fb:34:3d:da:a5:28:
                    c6:75:39:f4:1e:26:4e:1a:d4:a8:9e:11:74:e4:5f:fe:
                    68:88:8d:17:5d:c6:e4:6f:fb:51:28:0c:b5:fa:12:90:
                    da:af:ea:25:2f:b7:12:7b:e1:18:45:55:51:1e:65:03:
                    93:11:4b:f8:b1:5a:75:d5:d9:1a:97:cc:83:02:24:ae:
                    b8:fb:70:d3:ae:76:96:10:ab:98:ee:9e:98:a6:14:98
                Fingerprint (MD5):
                    13:7B:7C:17:D8:5B:13:88:FA:E6:C5:48:B4:6E:16:5F
                Fingerprint (SHA1):
                    2E:12:12:39:C4:49:92:05:49:CE:0B:35:5C:22:B6:24:01:12:75:86

        Signer Information List:

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Thank you, Christophe, for reporting this.  Please attach to this bug 
a copy of the cert8.db file with which this can be reproduced.  Thanks.

Comment 3

[Christophe Ravel]

Attachment: BridgeDB database to reproduce the bug

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Christophe, what was the command that you used  with this database?

Comment 5

[Christophe Ravel]

cmsutil -O -r "NavyRoot@Navy,ArmyRoot@Army" -d BridgeDB > BridgeWithAIA.p7

(see comment #1)

Comment 6

[Christophe Ravel]

I tried to do some more investigation on this issue using the debugger.

cmsutil -O uses the function "signed_data_certsonly" from cmsutil.c.
This function calls "CERT_FindCertByNicknameOrEmailAddr" for each recipient (in the current case only email addresses).

In "CERT_FindCertByNicknameOrEmailAddr" (stanpcertdb.c), the corresponding cert is search through 3 successive ways:
#1: NSSCryptoContext_FindBestCertificateByNickname
#2: NSSCryptoContext_FindBestCertificateByEmail
#3: PK11_FindCertFromNickname

#1 returns no certificate (as expected)
#2 returns no certificate. It seems that this function looks for email address in the cert subject (store->subject), not the cert subject alt name
#3 returns 1 certificate. But because in the bridge all the certs have the same nickname (same subject, same issuer), we always get the same cert.

Comment 7

[Christophe Ravel]

Please forgive my lack of experience with NSS code and forget all about comment #6.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 7, why forget it?
I thought the analysis in comment 6 was insightful and pointed pretty 
clearly to the problem.  That analysis looked like a job well done to me.
Are you now saying that the analysis in comment 6 was incorrect?
If so, in what way was it incorrect?

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Christophe,

Prompted by your thorough analysis of the problems, I debugged the problem
myself, and traced the problem to here, at which point it was apparent.

nssdbm3.dll!lg_searchCertsAndTrust()  		Line 547
nssdbm3.dll!lg_searchTokenList()  		Line 843
nssdbm3.dll!lg_FindObjectsInit()  		Line 892
softokn3.dll!sftkdb_FindObjectsInit()  		Line 942
softokn3.dll!sftk_searchDatabase()  		Line 3937
softokn3.dll!sftk_searchTokenList()  		Line 4062
softokn3.dll!NSC_FindObjectsInit()  		Line 4115
nss3.dll!find_objects()  			Line 328 
nss3.dll!nssToken_FindCertificatesByEmail()  	Line 732 
nss3.dll!PK11_FindCertFromNickname()  		Line 607 
nss3.dll!CERT_FindCertByNicknameOrEmailAddr()  	Line 643 
cmsutil.exe!signed_data_certsonly()  		Line 932 
cmsutil.exe!main()  				Line 1546

The problem is an artifact of the way that NSS's softoken has historically
organized the storage of certificates in the old cert8.db files.  I will be
happy to explain this at length by phone or in person.

I would like you to repeat your test using the shareable DB feature, if 
possible, to see if the problem is also present when using the new sharable 
DBs.  

If the problem cannot be reproduced with the new shareable DBs, then I am
willing to say that this bug is fixed with the use of the new sharable DBs,
and live with the fact that the old cert DBs have this limitation.  

If the problem is also reproduced with the new shareable DBs, then we need
to do a bunch of work to fix it in softoken. 

Comment 10

[Christophe Ravel]

Nelson,

I ran the same test with shareable DBs and the problem disappeared.

Here is the content of the PKCS7 package (using shareable DBs):

pp -t pkcs7 -i BridgeWithAIA.p7 
PKCS #7 Content Info:
    PKCS #7 Signed Data:
        Version: 1 (0x1)
        Digest Algorithm List:
        Content Information:
            PKCS #7 Data:
                (empty)
        Certificate List:
            Certificate (1):
                Data:
                    Version: 3 (0x2)
                    Serial Number:
                        00:89:ce:72:2a
                    Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
                    Issuer: "CN=Army ROOT CA,O=Army,C=US"
                    Validity:
                        Not Before: Fri May 30 14:36:13 2008
                        Not After : Thu May 30 14:36:13 2013
                    Subject: "CN=Bridge BRIDGE,O=Bridge,C=US"
                    Subject Public Key Info:
                        Public Key Algorithm: PKCS #1 RSA Encryption
                        RSA Public Key:
                            Modulus:
                                cc:32:7a:54:06:a2:f2:8e:97:b8:d6:8a:36:fc:f1:
                                fa:05:3f:38:1d:7f:83:3a:32:10:59:41:81:dd:af:
                                c4:df:61:f8:00:eb:9b:7a:7c:1f:83:4c:08:f6:1b:
                                9f:6e:40:0f:df:fa:0c:25:47:4b:b0:82:08:19:53:
                                79:ed:98:d3:74:2d:7a:1d:c1:f3:ac:86:9c:4a:a4:
                                06:d8:78:66:6f:f8:2c:e8:13:65:48:9f:7a:10:6b:
                                cb:32:c4:e7:59:b4:f4:bc:06:3c:d7:6c:6d:95:dc:
                                08:84:ac:0f:36:d1:b3:73:89:2d:3c:ec:27:3c:a9:
                                f5:24:55:93:cb:2d:2b:03
                            Exponent: 65537 (0x10001)
                    Signed Extensions:
                        Name: Certificate Basic Constraints
                        Critical: True
                        Data: Is a CA with no maximum path length.

                        Name: Certificate Subject Alt Name
                        RFC822 Name: "ArmyRoot@Army"

                Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
                Signature:
                    97:78:69:4d:4e:db:9d:65:bb:e4:f0:ed:c8:d7:40:9b:
                    10:a9:3a:f7:70:94:18:78:b6:d4:dd:fd:c9:3d:6d:0b:
                    a1:0c:7d:10:d6:01:97:4d:fe:ef:76:3d:44:19:d5:7e:
                    14:c8:e2:3c:f9:cc:39:a6:cd:1d:8e:ab:eb:c2:4c:5f:
                    cd:f1:b9:db:ce:21:8c:4f:13:1d:2f:58:20:7b:2e:e4:
                    06:65:09:8b:0a:55:93:af:ea:92:a6:3f:ff:b0:fe:94:
                    0a:82:d2:40:89:fc:de:b9:0e:b4:97:dc:68:c5:d3:db:
                    3b:2c:bb:a6:28:98:b4:a4:09:5e:8f:fb:c4:69:37:0f
                Fingerprint (MD5):
                    32:7E:61:DA:13:77:76:41:EC:4A:63:59:41:F3:B7:6B
                Fingerprint (SHA1):
                    E4:11:83:95:4E:DA:48:62:4D:A9:F2:99:E9:9D:99:29:EA:62:B0:1D

            Certificate (2):
                Data:
                    Version: 3 (0x2)
                    Serial Number:
                        00:89:ce:72:2b
                    Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
                    Issuer: "CN=Navy ROOT CA,O=Navy,C=US"
                    Validity:
                        Not Before: Fri May 30 14:36:14 2008
                        Not After : Thu May 30 14:36:14 2013
                    Subject: "CN=Bridge BRIDGE,O=Bridge,C=US"
                    Subject Public Key Info:
                        Public Key Algorithm: PKCS #1 RSA Encryption
                        RSA Public Key:
                            Modulus:
                                cc:32:7a:54:06:a2:f2:8e:97:b8:d6:8a:36:fc:f1:
                                fa:05:3f:38:1d:7f:83:3a:32:10:59:41:81:dd:af:
                                c4:df:61:f8:00:eb:9b:7a:7c:1f:83:4c:08:f6:1b:
                                9f:6e:40:0f:df:fa:0c:25:47:4b:b0:82:08:19:53:
                                79:ed:98:d3:74:2d:7a:1d:c1:f3:ac:86:9c:4a:a4:
                                06:d8:78:66:6f:f8:2c:e8:13:65:48:9f:7a:10:6b:
                                cb:32:c4:e7:59:b4:f4:bc:06:3c:d7:6c:6d:95:dc:
                                08:84:ac:0f:36:d1:b3:73:89:2d:3c:ec:27:3c:a9:
                                f5:24:55:93:cb:2d:2b:03
                            Exponent: 65537 (0x10001)
                    Signed Extensions:
                        Name: Certificate Basic Constraints
                        Critical: True
                        Data: Is a CA with no maximum path length.

                        Name: Certificate Subject Alt Name
                        RFC822 Name: "NavyRoot@Navy"

                Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
                Signature:
                    24:c4:86:19:eb:dd:d0:62:cf:c1:e4:60:73:dc:2f:d5:
                    54:9c:1e:01:c5:07:4b:9f:d6:ec:5a:a7:42:38:c0:7e:
                    26:b1:d5:d3:5d:e1:39:b8:e7:aa:b9:a2:6c:7c:c3:23:
                    ea:5c:35:51:5f:f0:10:9e:bc:c1:39:e9:a7:de:92:1e:
                    36:27:bd:62:7a:a8:ca:19:59:ef:6f:63:fd:7c:0a:22:
                    36:cb:5e:24:43:bf:15:91:fa:5c:1c:e0:65:50:e7:9a:
                    8f:4b:a0:0b:0f:33:20:59:b7:2c:03:9b:24:80:49:8c:
                    a3:3f:28:71:24:fd:f0:7b:5f:ba:0f:86:42:81:4e:8c
                Fingerprint (MD5):
                    30:A0:0B:8D:7C:94:8D:D2:DF:3F:43:10:39:62:22:11
                Fingerprint (SHA1):
                    7D:F0:C9:6C:58:C9:3A:F7:D9:8B:3B:B3:D6:60:23:82:A3:16:1D:08

        Signer Information List:
----------

As you can see, we now have 2 different certs, 1 issued by the "Army", 1 issued by the "Navy", which is the expected result.

Comment 11

[Christophe Ravel]

Attachment: BridgeDB shareable database to show the bug doesn't exist with the new shareable DB

Comment 12

[Christophe Ravel]

Comment on attachment 323072 [details]
BridgeDB shareable database to show the bug doesn't exist with the new shareable DB

run:
cmsutil -O -r "NavyRoot@Navy,ArmyRoot@Army" -d BridgeDB > BridgeWithAIA.p7

to test

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Christophe, 
Thank you for doing this additional test and generating the additional DBs.
For posterity, please add a comment here about what extra steps you did 
to generate these DBs, e.g. environment variables used, or command line
parameters changed, to generate and update the newer DBs.

There are several problems here, one in softoken, and another in nssToken_FindCertificatesByEmail

In this test case, there are two certificates that have the same subject
name but differ in the contents of the Subject Alt Name (SAN).  

Softoken's "old" cert8 database schema predates the existence of SANs, 
and does not take them into account adequately.  It assumes that all 
email addresses are contained within the subject name.  So, it uses 
nicknames and email addresses as if they were abbreviations for subject 
names.  Internally, it maps nicknames and email addresses to subject names,
and then keeps a list of all certs with a certain subject name.  That is 
why all certs with the same subject name have the same nickname.  Multiple
email addresses may map to the same subject name.  When one asks for the 
certs with a certain email address, the DB code first finds the subject 
name associated with the email address, and then returns all certs with 
that subject name, whether they contain that email address anywhere (such
as in the SAN) or not.  This problem is as old as the cert8 DB schema itself,
and is not a recent regression.

We don't want to change the schema of the cert8 DB now.  In some sense, 
we have already fixed that problem in the schema of cert9 (the shareable DBs)
and so to fix the DB schema, we would recommend that the user move forward
to cert9.  

But there are nonetheless at least two places where we could fix the problem
reported here.  There are at least two places where it makes sense to further
filter the certs, to double-check them (as it were) to ensure that they all
do actually contain the email address specified.  

One place is in softoken, perhaps in lg_searchCertsAndTrust(), after amassing
the list of potential certs, we could filter it there to ensure that the 
list contains only certs that truly have the required email address. 
We can view it as a failure of softoken to return certs that meet the search
criteria given in the PKCS#11 template, and correct that failure, so that 
softoken will be honoring the template it is given.  That is the solution 
I would STRONGLY prefer, because it puts the cost of that extra filtration where the fault lies.  It means that users of cert9 need not pay that extra
filtration cost.

The other logical place to do it is in nssToken_FindCertificatesByEmail().
If we accept the notion that PKCS#11 modules may return certs that do not 
meet the search criteria (a notion that I would much prefer we NOT accept),
then it is reasonable to impose an extra filtration step, after the PKCS#11
module has returned the objects that it claims meet the filter criteria,
to ensure that the certs actually DO meet the criteria.  

Bob, are you willing and able to tackle the extra filtration in lg_searchCertsAndTrust()?  Or is it just too expensive (too much extra code)
to do it there?  Should we simply filter in nssToken_FindCertificatesByEmail() where the certs have already been parsed in great detail and checking the 
email addresses will be easier?

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Christophe, I recommend that the testing work you are doing, devising tests
for libPKIX, involving bridge CA cert chains (among other tests), should
convert to always using the new shareable DBs.  This way, your new tests will
be testing both libPKIX and the shareable DBs.

Comment 15

[Christophe Ravel]

Attachment: Shell script to recreate the PKI environment to reproduce this bug

NSS_DIR should be set to the location of NSS (where bin and lib are).
Example: export NSS_DIR=/mozilla/dist/SunOS5.10_DBG.OBJ

Set the DB type before running the script createPKI_bug435314.sh:
    Cert8DB: export NSS_DEFAULT_DB_TYPE="dbm"
or
    Cert9DB: export NSS_DEFAULT_DB_TYPE="sql"

Then run the createPKI_bug435314.sh script to create the PKI environment.

Once the PKI environment is created, run the following test:

To create the PKCS#7 package:
cmsutil -O -r "NavyRoot@Navy,ArmyRoot@Army" -d BridgeDB > certs.p7

To print the content of the PKCS#7 package:
pp -t pkcs7 -i certs.p7

The bug is:
With Cert8DB, the 2 certs in the certs.p7 file are the same (wrong behavior)
With Cert9DB, the 2 certs in the certs.p7 file are different (correct behavior)

Comment 16

[Slavomir Katuscak]

This bug causes some failures in Tinderbox tests, it fails on DBM and passes on SQL, there will be needed to create some workaround for tests of this, because now is result of vfychain tests compared with expected result - and there are different results for different types of DB.

Comment 17

[Slavomir Katuscak]

Attachment: Temporary workaround.

Temporary workaround - will expect different pass/fail results for different types of cert dbs - this would prevent Tinderbox failures.

Comment 18

[Alexei Volkov]

Comment on attachment 346472 [details] [diff] [review]
Temporary workaround.

Slavo, the meaning of the status sql is not clear. I'd prefer that we have
something like this:

result dbm:fail all:pass

you can do result values parsing with a simple loop and case statement.

Comment 19

[Slavomir Katuscak]

Attachment: Workaround v2.

Addressed suggestion from #18 (only added _ to value, because config is easier to process when it's one word). But my preferred solution is rather previous one with only sql status (maybe just add some comment what this status mean).

Comment 20

[Alexei Volkov]

Comment on attachment 346884 [details] [diff] [review]
Workaround v2.

A few things:
* No need to use underscore symbol. Read  will place all remained space separated values into the last variable listed in the read commend. 
* Prefer to have early assertion and return for simple pass/fail statuses.
* use of 'case' instead of 'if' is a better choice , since it improves readability.

I'll modify the script and integrate it today, since we try to make tinderboxes green by the end of the day.

Comment 21

[Alexei Volkov]

Attachment: Some tweaks to Workaround v2

Comment 22

[Alexei Volkov]

Comment on attachment 346931 [details] [diff] [review]
Some tweaks to Workaround v2

Slavo, I've integrated your patch with a minor change: remove underscore from list of statuses.

This patch is what I'd do for result parsing. Please review it.

Comment 23

[Slavomir Katuscak]

Comment on attachment 346931 [details] [diff] [review]
Some tweaks to Workaround v2

R+. Just small formating details (all is in '' and other keys are not, * is moved to right).

Comment 24

[Julien Pierre]

Nelson,

Regarding comment 13, I think this should be fixed in the softoken. We have many consumers of softoken only, which the fix above the PKCS#11 line wouldn't help. And this is clearly a spec compliance issue.

Comment 25

[Robert Relyea]

> And this is clearly a spec compliance issue.

Actually it's not. These searches are based on the S/MIME record, beyond the PKCS #11 spec.

The question is what should softoken be doing. For historical reasons, we use the S/MIME record to return  certificates based on email addresses inside the PKCS #11 module. This was to allow us to find certs which had more than one email address. This behavior itself is non-standard PKCS #11.

What should happen is the PK11 wrapper code should search for both email addresses and S/MIME records, and should filter at that level. This will allow this to all work with non-softoken PKCS #11 modules.

bob

Comment 26

[Nelson Bolyard (seldom reads bugmail)]

Regarding the presence or absence of a PKCS#11 "spec compliance issue", 
nssToken_FindCertificatesByEmail does a search for objects with these
attributes and values:
    CKA_CLASS,          CKO_CERTIFICATE
    CKA_TOKEN,          CK_TRUE                (optional)
    CKA_NETSCAPE_EMAIL, (target email address)

Now, clearly, the CKA_NETSCAPE_EMAIL attribute can be defined any way 
we want to, but PKCS#11's definition of C_FindObjectsInit says: 
   The matching criterion is an exact byte-for-byte match with all 
   attributes in the template.
That means that it is an error (not in compliance with the spec) if the 
result of the search includes any objects whose attributes do not match the values in the search templates.  I gather that that is what is happening
here.  

It is true, as Julien noted, that there are now many products that use NSS's
softoken without using the rest of NSS.  Java 6's JRE includes a crypto 
provider that uses any spec-compliant PKCS#11 module underneath.  It even 
has special code to pass the special init string to softoken, IINM.

A "fix" for this problem in PK11wrap will be of no benefit to such products.  
However, I doubt that any of those products use any of softoken's 
non-standard attributes, such as CKA_NETSCAPE_EMAIL.

Comment 27

[Robert Relyea]

> Now, clearly, the CKA_NETSCAPE_EMAIL attribute can be defined any way 
> we want to, but PKCS#11's definition of C_FindObjectsInit says: 
>    The matching criterion is an exact byte-for-byte match with all 
>    attributes in the template.
> That means that it is an error (not in compliance with the spec) if the 
> result of the search includes any objects whose attributes do not match the
> values in the search templates.  I gather that that is what is happening
> here. 

That is correct, but that is not what we do, and if we implement this semantic, we will break NSS binary compatibility.... at least until we fix the wrappers.

I know this because when developing the shared database design, I implemented exactly this. Our test suit broke because we were depending on this non-standard PKCS #11 semantic to support multiple email addresses in a certificate. The standard PKCS #11 interface could not do so.

For good or ill, We implemented a semantic in the softoken where we used the SMIME record to find all the EMAIL address. Until the wrappers are fixed, we cannot make softoken compliant to the PKCS #11 spec.

That being said, it is not possible to make the old database compliant anyway. There are to many "impedance" mismatches. The old Database offers and interface that looks enough like PKCS #11 to make NSS wrappers happy. 

The upshot is that implementing the filter suggestion in this bug in softoken will *NOT* make it PKCS #11 compliant because the whole feature is not compliant. The correct fix is to implement the entire "fetch S/MIME records as part of the EMAIL search" semantic in the wrappers. We can then decide if we want to remove that search in softoken at a future date, or if binary compatibility requires us to keep the non-standard behavior or not. 

bob

Comment 28

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 346884 [details] [diff] [review]
Workaround v2.

Slavo, Alexei, 
There a workaround patch for the test scripts with an r+ attached to this bug.
You two are the author and reviewer of that patch.  Please either commit it 
or mark it obsolete.  Thanks.