Subject: Recommendation on subject matching rules needed..

From: "Vainikainen Saku EINT" <[email-masked]>
Date: Tue, 11 Mar 2003 12:22:23 +0200

Hello all!
 
I'll layout the problem we have run into:
 
We have setup a PKI with encryption key archival and recovery 
features, and we are using a smartcard with three key pairs 
(auth, nonrep, enc). Our CA-hierarchy has two levels (root + 
subs). All subject certs and related CA certs are stored in 
the chip along with the key pairs.

The card personalisation process has two phases: 
prepersonalisation and personalisation phase. During 
prepersonalisation we generate keypairs, PINs and PKCS#15 
file structure to the card and in personalisation phase we 
certify the keys.

Now, when we create a new card to replace a lost/damaged/etc. 
card, we recover the archived encryption keypair and generate 
new auth and nonrep keypairs. Then we create new certs to all 
of the key pairs.

We are testing signing and encryption in S/MIME software and 
encryption in file/directory/volume encryption software, 
which all encrypt and decrypt nicely using our card. The 
problem emerges when trying to access encrypted data with a 
reissued card.

It seems that all the software we have tested (eg. MSoft, 
Utimaco) tend to do somekind of binary comparison (hash 
values I suppose) on the certificate used to encrypt the data 
(which is usually stored with the encrypted data) and on the 
certificate related to the encryption keypair being used to 
decrypt the data.

This of course works fine as long as the same certificate is 
used to encrypt and "decrypt" the data. The only problem is 
that the encryption key pair may have been recertified in between.

Certificate contains enough data to compare the subjects and 
the keys instead of the certificates. The comparison should - in 
my opinion - go more or less as follows:

Allow decrypt

1) if Subject Key Identifiers match
2) if Subject Unique Identifiers match
3) if Subjects + Subject Alt. Names match
4) if Issuer Key Identifiers match
5) if Issuer Unique Identifiers match
6) if Issuers match

Has anyone run into this problem as well ? Is this 
problem discussed in any existing papers (I haven't yet found 
any) ? I suppose this is going to be quite a problem if not 
addressed properly..

Saku Vainikainen
PKI-Specialist

Elisa Internet Oy
FINLAND

---

From: "Markus Lorch" <[email-masked]>
Date: Tue, 11 Mar 2003 10:27:39 -0500

> 5) if Issuer Unique Identifiers match

Shouldn't just being in possession of the private key be enough to 
decrypt previously encrypted data. (what is a certificate needed
for in this use case? )

I can think of a minor reason to have a certificate: to locate the 
key pair by searching for subject and key usage - however, that should
not
be the only way by which a software can locate the right key to use, or?

Markus

--------------------------------
Markus Lorch

Dept. of Computer Science (0106)
Virginia Tech, Blacksburg, VA 24061

Phone/Fax: (206) 227 0428
http://csgrad.cs.vt.edu/~mlorch

---

From: Stephen Kent <[email-masked]>
Date: Tue, 11 Mar 2003 10:52:18 -0500

At 12:22 PM +0200 3/11/03, Vainikainen Saku EINT wrote:
><SNIP>

As Marcus points out, if you have the right key, technically you 
should be able to decrypt the data (old messages in this case). I 
assume the problem is that the software in question is trying to 
verify that the key being presented is the right one, by matching 
against a stored cert in the message, and t a cert bound to the 
private key to be employed. One might ask the vendors why they are 
doing this, other than to save the user time if/when the wrong key is 

>certificate related to the encryption keypair being used to

This is not quite right, in that no CERT was used to encrypt the 
data. It is the PUBLIC KEY from the cert that was used. This suggests 
that the answer to your question is that IF software wants to check 
that the right key is going to be used in an attempt to decrypt a 
message, and IF the means of checking is based on a cert bound to the 
private key and a cert stored with the data to be decrypted,  THEN 
the only appropriate comparison is on the respective public keys, or 
hashes thereof.  Any comparison based on other parts of the certs in 
question is including unnecessary data, which is why you are 
encountering this problem.

BTW, this problem is even more complex is DH was used instead of RSA, 
so one would hope that the vendors have a more through scheme for 
this sort of checking in that case, i.e., assuming they have 
generated algorithm independent code :-)

Steve