[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" <mulmo(_at_)pdc(_dot_)kth(_dot_)se> 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.