Subject: RE: Recommendation on subject matching rules needed..

From: [email-masked] (Peter Gutmann)
Date: Wed, 12 Mar 2003 03:44:51 +1300

[CC'd to the S/MIME list, this is really an S/MIME and not a PKIX issue.  For
 those just joining us, the issue is what to do when you re-certify your
 encryption key (NB: Someone else is doing this, not me :-)]

"Olle Mulmo" <[email-masked]> writes:

>I don't follow the logic here... If hash of issuer+serial is used, 

Just the issuerAndSerialNumber, there's no hash.

>won't the same issue happen upon revalidation of the key pair (that is, when
>the original certificate expires)? Or am I more or less required to do a key
>replacement operation (or changeover, or whatever the correct terminology is)
>at that point?

It's a black hole.  The method I've seen used a few times (because it works
with pretty much anything) is some variation of running two systems, one with
the clock set back so it can still use the old key, and another one with the
clock running at the current time for the new key.  Every vendor does it
differently.  Some require a system rebuild (the equivalent of a
reformat+reinstall-Windows operation for the crypto/PKI software).  Some
handle both keys, with various amounts of manual intervention.  I've seen one
group that have a Grand Key Changeover day when everyone has to roll over
their keys (well, certs), and people are instructed not to send any critical
encrypted messages at that time.

My code allows multiple keys and preferentially grabs the most recent (that
is, currently-valid) one, since that's the behaviour the most users asked for.
On the decrypting side, it looks up the key purely by issuerAndSerialNumber
(ignoring date issues), so you can decrypt with both the old and new key,
depending on what the sender used.  That way you can swap in a new key at any
time and it just works (if you even happen to be reading PKCS #15/ISO 7816-15
and wonder why there are validity times attached to private keys, this is
why).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 12 Mar 2003 03:56:51 +1300

[Also CC'd to S/MIME]

"Vainikainen Saku EINT" <[email-masked]> writes:

>>>It seems that all the software we have tested (eg. MSoft, Utimaco)
>>
>>Everyone, not just those two.
>
>OK - this is more or less what I assumed :( Do you know if there is any work
>being done on this subject in terms of a recommendation
>paper/draft/something?

See my previous message.  It's really an application/policy issue, I don't
know if there's much to say in standards except maybe to post a skull and
crossbones next to a description of the problem to let people know what
they're in for.

>Our cards (=certs) are valid for three years. If the card has been in use for
>2 years when we reissue it with recovered enc key, we need to reissue the enc
>cert also - otherwise the recovered enc key cert could be usable only for one
>year whereas the other certs would be usable for three years.

Why not just leave the decryption key as is and issue a new 3-year decryption
cert?  This in effect is what I do in my code (with the date-based transparent
rollover).

>Also - if we pile up all the previous enc certs to the card along with the
>new cert, we run out of card space as well as introduce new problems since
>the apps usually don't iterate though all the certs and end up using the
>first cert available.

Can you fit 4 keys?

(On a completely unrelated topic, are you sure the software you're using is
 able to make sense of the NR key there?  A lot of software is totally
 incapable of distinguishing between signature and NR keys, and just takes the
 first one that it finds with {signature,NR} enabled.  For that matter, I've
 found a number of card issuers in [looks at sender's country code], uhh,
 well, Scandinavia who set PKCS #11 key usage bits incorrectly on cards, so
 you get crypto keys marked as signing keys and vice versa, or all keys marked
 as crypto or signing keys, or other oddities, and no-one even notices that
 they're encrypting with the NR key.  The point is that if your software can't
 differentiate between signature and NR (or even all three key types), you
 could dump the NR key and add an extra encryption key instead).

Peter.

---

From: "Vainikainen Saku EINT" <[email-masked]>
Date: Tue, 11 Mar 2003 17:25:35 +0200

> >Our cards (=certs) are valid for three years. If the card 
> has been in 
> >use for 2 years when we reissue it with recovered enc key, 
> we need to 
> >reissue the enc cert also - otherwise the recovered enc key 
> cert could 
> >be usable only for one year whereas the other certs would be 
> usable for 
> >three years.
> 
> Why not just leave the decryption key as is and issue a new 
> 3-year decryption cert?  This in effect is what I do in my 
> code (with the date-based transparent rollover).

This is how we do it. And this is why the decryption does not work since
the new enc cert gets a new serial number, ie. the encryption cert gets
reissued, ie. the encryption key pair gets recertified, ie. cert hash
changes. One cannot change the contents of a certificate without
generating a new certificate serial number, ie. issue a new certificate.

> >Also - if we pile up all the previous enc certs to the card 
> along with 
> >the new cert, we run out of card space as well as introduce new 
> >problems since the apps usually don't iterate though all the 
> certs and 
> >end up using the first cert available.
> 
> Can you fit 4 keys?

Yep - but we don't want to do that because when we take that path we
need to have space for (not infinite but anyways) many keys, since if
start maintaining key chains (generating a new key on every reissue and
attaching it to the chain of old enc keys) there is no end to it..
 
> (On a completely unrelated topic, are you sure the software 
> you're using is  able to make sense of the NR key there?  A 
> lot of software is totally  incapable of distinguishing 
> between signature and NR keys, and just takes the  first one 
> that it finds with {signature,NR} enabled.  For that matter, 
> I've  found a number of card issuers in [looks at sender's 
> country code], uhh,  well, Scandinavia who set PKCS #11 key 
> usage bits incorrectly on cards, so  you get crypto keys 
> marked as signing keys and vice versa, or all keys marked  as 
> crypto or signing keys, or other oddities, and no-one even 
> notices that  they're encrypting with the NR key.  The point 
> is that if your software can't  differentiate between 
> signature and NR (or even all three key types), you  could 
> dump the NR key and add an extra encryption key instead).

Our card has following PKCS#15 key usages on the private keys:

auth: 	sign, sign-recover, unwrap
nonrep:	nonrepudiation
enc:		decrypt, unwrap

Certs go as follows:

auth:		digital signature, key encipherment
nonrep:	nonrepudiation
enc:		key encripherment, data encipherment

Extended key usages on certs:

auth:		Client Authentication (1.3.6.1.5.5.7.3.2)
		Secure Email (1.3.6.1.5.5.7.3.4)
		IP security IKE intermediate (1.3.6.1.5.5.8.2.2)
		Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

nonrep:	-

enc:		Secure Email (1.3.6.1.5.5.7.3.4)
		IP security IKE intermediate (1.3.6.1.5.5.8.2.2)

Authentication key is used in SSL authentication, W2k logon, VPN
authentication and email signing (=authentication).

Nonrepudiation key is not yet used anywhere (lack of document management
software supporting smartcards).

Encryption key is used in e-mail encryption as well as in
disk/folder/file encryption (option to use in VPN connections as well).

Saku.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 12 Mar 2003 05:04:52 +1300

"Vainikainen Saku EINT" <[email-masked]> writes:

>This is how we do it. And this is why the decryption does not work since the
>new enc cert gets a new serial number, ie. the encryption cert gets reissued,
>ie. the encryption key pair gets recertified, ie. cert hash changes. One
>cannot change the contents of a certificate without generating a new
>certificate serial number, ie. issue a new certificate.

But why is this a problem?  If you get something addressed to the old cert,
you use the old key to decrypt.  If it's for the new cert, you use the new
key.  In fact there isn't even any need to keep the old cert around if it's
decrypt-only, you mention PKCS #15, well that stores all the index info you
need with the key, so you don't need the cert at all.

>Our card has following PKCS#15 key usages on the private keys:

Have you actually tested all the combinations with your software?  That is,
added two certs that differ only in encryption vs.signature usage and then see
what the app does if asked for a signature or encryption cert?  Some of the
people I pointed out problems to were surprised at the problems, since things
seemed to work OK (meaning that the app just grabbed the first key it found
and used that, so everything appeared to work fine).

Peter.

---

From: "Vainikainen Saku EINT" <[email-masked]>
Date: Tue, 11 Mar 2003 18:41:03 +0200

> >This is how we do it. And this is why the decryption does not work 
> >since the new enc cert gets a new serial number, ie. the encryption 
> >cert gets reissued, ie. the encryption key pair gets 
> recertified, ie. 
> >cert hash changes. One cannot change the contents of a certificate 
> >without generating a new certificate serial number, ie. issue a new 
> >certificate.
> 
> But why is this a problem?  If you get something addressed to 
> the old cert, you use the old key to decrypt.  If it's for 
> the new cert, you use the new key.  In fact there isn't even 
> any need to keep the old cert around if it's decrypt-only, 
> you mention PKCS #15, well that stores all the index info you 

Yes, but then we need to store encryption key and certificate chains.
Our smartcard has only limited space available, so we would need to
recover the old encryption keys and certificates to PKCS#12 files or
other software tokens. Then again the software tokens tend to be a bit
difficult since you have to store them somewhere (disk/cd-rom/whatever,
preferrably a read-only media) to deliver them to the user.

Then in order to use the keys, the user has to import them to his/her
user profile or disk to have them available. And since roaming profiles
are not so common (at least in our environment) copies of the keys
(along with automatic password managers memorizing the passphrases) lay
around in multiple workstations, which is not good in sense of privacy.

Unfortunately most of the software we are using uses Microsoft
CryptoAPI, which hides all PKCS#15 info quite efficiently, thus forcing
the software to use the key usage info stored in the certs.
 
> Have you actually tested all the combinations with your 
> software?  That is, added two certs that differ only in 
> encryption vs.signature usage and then see what the app does 
> if asked for a signature or encryption cert?  Some of the 
> people I pointed out problems to were surprised at the 
> problems, since things seemed to work OK (meaning that the 
> app just grabbed the first key it found and used that, so 
> everything appeared to work fine).

No - since we issue only one cert per key at a time, and we don't issue
multiple certificates with identical serial numbers. And the apps we are
using allow us to choose the certificate (=key) to be used, although
they do some filtering based on key usage information found in the
certificates.

Saku.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 12 Mar 2003 06:52:40 +1300

"Vainikainen Saku EINT" <[email-masked]> writes:

>Yes, but then we need to store encryption key and certificate chains. Our
>smartcard has only limited space available, so we would need to recover the
>old encryption keys and certificates to PKCS#12 files or other software
>tokens. 

But why do you need to store all this cruft?  If it's a legacy/superseded
decryption key, all you need is the private-key components for decryption
(usually stored in a highly compact card-specific format) and the
issuerAndSerialNumberHash so you can locate it (in fact for any decryption
key, even a currently active one, you don't actually need to store the cert).
The overhead for the non- private-key components would probably be 50-100
bytes, depending on how much other stuff your PKCS #15 implementation stores
alongside it.  So your card contains the current decryption key and its cert,
and one (or possibly more, although you probably need to ask why the user is
losing that many keys) decryption keys and the index info needed to find them.
The indexing overhead for half a dozen decryption keys is going to be less
than that for a single certificate.

Peter.

---

From: "Vainikainen Saku EINT" <[email-masked]>
Date: Tue, 11 Mar 2003 21:49:59 +0200

> But why do you need to store all this cruft?  If it's a 
> legacy/superseded decryption key, all you need is the 
> private-key components for decryption (usually stored in a 
> highly compact card-specific format) and the 
> issuerAndSerialNumberHash so you can locate it (in fact for 
> any decryption key, even a currently active one, you don't 
> actually need to store the cert). The overhead for the non- 
> private-key components would probably be 50-100 bytes, 
> depending on how much other stuff your PKCS #15 
> implementation stores alongside it.  So your card contains 
> the current decryption key and its cert, and one (or possibly 
> more, although you probably need to ask why the user is 
> losing that many keys) decryption keys and the index info 
> needed to find them. The indexing overhead for half a dozen 
> decryption keys is going to be less than that for a single 
> certificate.

Sounds good, but I suppose we still need to select the keys somehow
(using the certs) through the CryptoAPI CSP and RSA CrypTokI interface,
so that the applications are satisfied.

I assume PKCS#11 is not that a big problem in terms of key
types/parameters since it recognises keys with key usage bits and relays
key parameters from the PKCS#15 structure, but if I don't remember
incorrectly, MSoft CSP is a problem since it only recognises two types
of keys (AT_KEYEXCHANGE and AT_SIGNATURE) and thus it has no clue about
the key usage bits. And both interfaces can do the mapping between
public keys and corresponding private keys.

But I don't recall if there is an attribute that could store
issuerAndSerialNumber in either PKCS#11 or CSP specifications. So could
we really relay this info to apps ?

This implies more or less that the applications have to locate the
decryption key (private key) based on certificate comparison (or public
key comparison) to locate the related public key. And when using
certificates, comparing issuerAndSerialNumber is not good enough since
it only recognises the certificate, not the entity nor the key pair
described in the cert.

If we compare the subject and issuer data (key ids, subject and issuer
names, subject and issuer unique ids), we recognise the entity
identified by the certificate, not the certificate itself - and in my
opinion, this is what we are after when we are using certificates. Eg.
in S/MIME, we figure out if the encrypted mail is really intended to the
entity trying to open it rather than figuring out if the certificate
linked to the recipient's private key he/she is trying to use in
decrypting the mail, is the same certificate that was used to encrypt
the mail.

Saku.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 18 Mar 2003 01:25:26 +1200

>so that the applications are satisfied.

It looks like you've been painted into a corner by the selection of software
you have to use.  The solution using other software is fairly simple, but
if you're stuck with using CryptoAPI and have various other constraints I
don't really know what you could do, sorry.  I guess saying "Don't do that
then" isn't much help :-).

Peter.

---

From: "Vainikainen Saku EINT" <[email-masked]>
Date: Tue, 18 Mar 2003 14:16:28 +0200

> It looks like you've been painted into a corner by the 
> selection of software you have to use.  The solution using 
> other software is fairly simple, but if you're stuck with 
> using CryptoAPI and have various other constraints I don't 
> really know what you could do, sorry.  I guess saying "Don't 
> do that then" isn't much help :-).

Yep. Although I don't know of any other non-proprietary
crypto-interfaces that have "widespread" application support so I don't
really see another way around the problem other than put pressure on the
application vendors.

And putting this pressure would be greatly helped by you guys at IETF
PKIX & SMIME if you would draft up a paper about the subject. It could
be part of SMIME specs but I would like to see it a part of PKIX specs,
since the same issue is present when building certification paths during
certificate verification process, as well as when making the call wether
to trust the presented CA certificate or not..

Saku.