[Top] [All Lists]

RE: Recommendation on subject matching rules needed..

2003-03-11 08:25:49

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 (
                Secure Email (
                IP security IKE intermediate (
                Smart Card Logon (

nonrep: -

enc:            Secure Email (
                IP security IKE intermediate (

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).