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.