Open Bug 170301 Opened 22 years ago Updated 2 years ago

Smart Card Certificate could not be used for decrypting a message

Categories

(MailNews Core :: Security: S/MIME, defect, P5)

1.0 Branch
x86
Windows 2000

Tracking

(Not tracked)

People

(Reporter: schliwa, Unassigned)

Details

(Whiteboard: [kerh-coz])

1. A Certificate requested with Mozilla 1.x, stored on a Smart Card (Key 
generation on SC and Certificate installation directly on SC) could be used for 
digitaly sign a message but not for decrypting the encrypted return email.

2. If the SC-Certificate is requested and stored with Netscape 4.75 it could be 
used for decrypting the encrypted return email with Netscape 4.7x as well as 
with Mozilla 1.x.

3. A Soft-Token-Certificate requested with Mozilla 1.x, could be used for 
digitaly sign a message and for decrypting the encrypted return email.

4. If this Soft-Token-Certificate is stored as PKCS#12-file and then imported 
as well with Mozilla 1.x to a blank (initialyzed) Smart Card, the Smart Card 
Certificate could be used for digitaly sign a message but not for decrypting 
the encrypted return email.

5. If the stored PKCS#12-file is imported with Netscape 4.7x to a blank 
(initialyzed) Smart Card, the Smart Card Certificate could be used for digitaly 
sign a message and for decrypting the encrypted return email.

6. I compared these two SC-Certificates (4. & 5.) with pkcslstn.exe and I found 
that the S/N of the Mozilla-stored Certificate is 16 bytes long and the S/N of 
the Netscape-stored Certificate is 14 bytes long what seems to be true. The S/N 
of the Mozilla-stored SC-Certificate has two additional bytes (02 0E) in front 
of the original S/N!!! 

Please delete the DER-Encoding command in front of the CKA_Serial_number :-)

7. I tested two kinds of Smart Cards (Siemens CardOS M4 with API V2.14 and G&D 
Starcos SPK 2.3 with AET SafeSign 1.0.8.42) with SC-Reader Utimaco 2010 and 
with TC TrustCenter Class 0 CA Demo Certificates 
http://www.trustcenter.de/set_de.htm. The behavior is allways the same.
S/MIME
Assignee: mstoltz → ssaux
Component: Security: General → S/MIME
Product: MailNews → PSM
QA Contact: junruh → carosendahl
Version: other → 2.4
Kai,Bob,

Can you transfer owners of this bug to NSS if this true?  I can't confirm this
as I don't have the appropriate hardware/smartcards to reproduce his findings.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sigh, There has been a long standing bug in NSS since the very first days of
PKCS #11 support. The PKCS #11 spec quite clearly states that Serial numbers
must be the DER encoded values. NSS, however, has used the decoded serial
numbers. This was incorrect. We have been slowly correcting this problem, but
there is an issue that very old versions of NSS (namely those in Communicator
4.x) still expects the old behavior.

Currently NSS (I'm not sure which release of Mozilla it is), can handle both
certs with and without the DER Serial number, so we can now handle both
compliant and non-compliant issued cards. To be fully compliant, however, NSS
needs to write the full DER serial number. This means old applications will not
be able to use these cards.

bob
BTW I checked in a patch for the smart card not reading the DER serial numbers
corrrectly into the NSS tree, but I'm not sure if it made it into NSS 3.5 or if
it's in NSS 3.6.

bob
reporter, can you test a recent mozilla build to verify that Mozilla now works?
Priority: -- → P2
Target Milestone: --- → 2.4
Bob, the reporter says that he can't decrypt with the NEW NSS, old NSS versions
seem to work. Is this compatible with what you say? You seem to say that mozilla
should be fine but may generate certs that 4.7 can't use. The reporter says the
opposite.
There were bugs is some intermediate versions of NSS that were fixed where they
would generate the correct PKCS #11 serial numbers, but not read them. those
bugs where fixed in the latest version of NSS. I'm not sure if that version when
out in Netscape 7.0 or not.

bob
We checked the Netscape 7.0 with SmartCards and found the same problems as with 
Mozilla 1.0 and Mozilla 1.1: 
The stored certificate serial number starts with 02 0E (start byte length byte) 
followed by the correct SN (14 bytes).
So, the private key could not be used for decrypting an email!!!

We'll check Mozilla 1.2b next. Anything changed yet in regard to the posted 
problem???
We just made some corrections in this area over the last couple of days.  I
would pull the latest nightly build and see if it now works.
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
Product: PSM → Core
Whiteboard: [kerh-coz]
changing obsolete psm* target to --- (unspecified)
Target Milestone: psm2.4 → ---
QA Contact: carosendahl → s.mime
Version: psm2.4 → 1.0 Branch
Product: Core → MailNews Core

As I understand, people can do this. WFM?

Severity: critical → normal
Priority: P2 → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.