211051 - CERT_FindCertBySubjectKeyID fails to find matching cert

Status: NEW

(NSS :: Libraries, defect, P3)

Description

[Tej Arora]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0

CERT_FindCertBySubjectKeyID and CERT_FindCertByIssuerAndSN
returned NULL when asked to find
a cert that is known to exist with the given attributes

To reproduce:
1. certutil -N -d . 
2. certutil -A -d . -n dsacert -t u,u,u -i dsacert.der
3. compile findcert.c and run 
or on Linux 2.4 x86, run findcert executable 

Will attach dsacert.der, findcert.c, findcert executable




Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Tej Arora]

Attachment: DSA der cert

DSA der cert file to use for reproducing the problem

Comment 2

[Tej Arora]

Attachment: code sample to reproduce problem

sample c code that can be used to reproduce the problem

Comment 3

[Tej Arora]

Attachment: Linux 2.4x86 executable to reproduce problem

Linux 2.4x86 executable to reproduce problem

Comment 4

[Tej Arora]

BTW, here is a dump of dsacert.der - the values hardcoded in the sample
code are from this dump:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ec:f9:21:7b:fa
        Signature Algorithm: dsaWithSHA1
        Issuer: C=IE, ST=Dublin, O=Baltimore Technologies Ltd., OU=X/Secure, CN=
Another Transient CA
        Validity
            Not Before: Apr  3 00:00:03 2002 GMT
            Not After : Apr  2 22:59:46 2012 GMT
        Subject: C=IE, ST=Dublin, O=Baltimore Technologies Ltd., OU=X/Secure, CN
=Macha
        Subject Public Key Info:
            Public Key Algorithm: dsaEncryption
            DSA Public Key:
                pub:
                    5d:e9:c4:68:fe:12:22:81:b7:ba:44:e3:b6:a4:fc:
                    4c:e2:9d:77:3c:9b:75:df:1e:a4:ea:46:0e:73:de:
                    98:2e:a1:9a:c8:e4:6d:f3:43:ac:a1:1d:6e:c6:fd:
                    00:a8:5b:d2:9a:76:1c:a5:b1:34:fc:cf:00:22:7a:
                    e4:b3:20:ae:d4:cf:63:fe:9f:34:bc:41:d7:fa:3e:
                    27:57:49:47:b9:de:84:a1:7d:5a:3c:03:8c:02:49:
                    e9:ff:56:73:83:b0:24:fe:c1:ec:39:70:5b:38:5a:
                    30:c3:4e:ce:60:12:01:45:3f:02:87:8b:59:3b:8c:
                    7e:30:37:3b:ee:a1:9b:a8
                P:
                    00:84:8a:b0:4a:27:8c:d1:a0:1e:cf:ee:87:ef:58:
                    2a:09:f0:67:c0:6d:dd:3e:ee:c9:00:49:5b:d7:71:
                    a4:c1:74:70:f5:17:cf:87:45:6d:21:58:e1:0c:96:
                    f2:28:02:2e:cc:29:39:af:9e:1c:71:18:b1:6b:c4:
                    d0:da:f5:95:c2:87:50:f5:ea:ee:ee:35:24:9c:07:
                    36:ad:51:00:57:99:89:4e:b0:6b:ed:45:2f:7b:f5:
                    fd:3d:6b:02:0c:de:a5:5e:f1:4b:88:9a:7f:3e:2f:
                    c5:d1:cc:95:fc:20:29:fa:32:29:fa:ba:25:4d:73:
                    a1:53:3f:6a:12:39:c5:60:c3
                Q:
                    00:98:4b:fa:78:82:6b:07:82:8d:d1:f3:d1:00:13:
                    f1:dc:d1:d8:72:59
                G:
                    25:86:e6:19:fc:0c:cf:b5:ae:fe:6c:4e:42:41:ab:
                    26:49:5c:dc:f2:e3:3f:7b:e2:cd:ec:00:65:11:7c:
                    10:46:4e:90:7d:90:5c:5f:c4:db:78:f3:44:f1:91:
                    67:83:85:1f:b7:f4:33:00:e5:31:00:b1:13:ee:42:
                    80:7a:4e:09:7b:2b:69:cd:cd:17:60:26:32:b8:62:
                    40:4e:6e:05:f5:96:35:a4:02:79:c9:09:94:9b:0b:
                    c3:61:d9:5a:64:9e:25:74:6c:ce:fd:1e:7b:12:f9:
                    e0:9f:f1:b8:b6:a8:e3:a2:2d:2c:c7:78:ea:ed:cc:
                    ef:0f:07:46:1e:79:32:d0
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Subject Key Identifier:
                8B:33:EC:41:79:93:C8:FA
            X509v3 Authority Key Identifier:
                keyid:8A:1C:56:30:5A:32:12:7D

    Signature Algorithm: dsaWithSHA1
        30:2d:02:15:00:89:3e:33:13:c0:01:ea:f7:8e:cd:57:16:c6:
        4c:98:17:01:dc:9c:5b:02:14:3a:2b:90:72:b3:3c:29:d6:92:
        6a:6e:0d:8d:fd:1a:f7:ca:11:80:40

Comment 5

[Wan-Teh Chang]

Nelson, could you take a look at this?  Thanks.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

This bug originally reported two completely separate issues, 
one for CERT_FindCertBySubjectKeyID and 
one for CERT_FindCertByIssuerAndSN

Those should have been separate bugs.  

The test for CERT_FindCertByIssuerAndSN appears to be invalid.  It appears 
to pass in an ASCII string representation of the issuer name, rather than 
the DER-encoded issuer name.  Likewise, the serial number is a binary value,
but is not the DER-encoded serial number (the DER encoding has been removed).

So, I have changed the summary line for this bug to include only the 
CERT_FindCertBySubjectKeyID issue, which I will investigate shortly. 

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Regarding the serial number component of the CERTIssuerAndSN struct:  
it should contain the content of an encoded DER integer, but not the encoded
tag and length bytes.  If the most significant bit of the first byte is 1,
the number will be treated as a negative number, IINM.  A new bug should be
filed if any additional problems with CERT_FindCertByIssuerAndSN are found.

Re: CERT_FindCertBySubjectKeyID, the ability to find certs by SubjectKeyID 
is, at best, not completely implemented.  

CERT_FindCertBySubjectKeyID searches a temporary in-memory map of 
subjectKeyID values to certs.  The search appears to be correct.  That is, 
if the cert is in the map, the function should find it.  But this map is not
populated automatically when NSS starts up.  By default, this map is empty.  
It is not updated when certs are imported (either as temporary or permanent
certs), nor when certs are deleted, nor when tokens are inserted or removed.  

In NSS 3.8, this map is populated by static function pk11_keyIDHash_populate
which is called only once in NSS, during the FIRST call to
PK11_FindCertAndKeyByRecipientListNew.  It presently adds only "User certs" 
to the map, making the map suitable for finding one's own encryption cert 
when handling received encrypted email.  Given that limited population, 
perhaps CERT_FindCertBySubjectKeyID should have been named
CERT_FindUserCertBySubjectKeyID.

Changing NSS to properly populate the map and keep it consistent with the 
cert cache looks like a lot of work.  We'll have to decide if we should
undertake to fix this for NSS 3.9.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Adding relyea to cc list.  Bob, we discussed this last Friday.