"Timothy J. Miller" <tmiller(_at_)mitre(_dot_)org> writes:
We're also using a smartcard token to hold the certs & keys, and there's no
room to retain the old certs. More capacious tokens are coming, but that
will be a long process in and of itself.
If the card uses PKCS #15 then it'd be a pretty minor change (that's what my
code uses, and what I was thinking of in my previous message when I mentioned
retaining an index entry for the old iAndS). Each PKCS #15 object has a
number of search keys you can use to locate it, in your case all you'd need to
do is retain the previous iAndS associated with the private key when you re-
issue the cert.
That's the theory, in practice you'd need a considerable amount of vendor
cooperation to make this happen.
I don't think this will help, when you delete the old cert the sKID goes
with it, so when you lose the iAndS you also lose the sKID.
But in the new cert the sKID should be the same as the old one, since they
key material hasn't changed.
Only if the CA generates the sKID in a repeatable, deterministic way from the
the public key. You can't rely on this (unless you control the CA), in
general it's just another search key for the cert, and may be completely
unrelated to the public key.
I can say that retaining the old certificate probably won't work on Windows
anyway; it appears that Windows associates key pairs via a specific pointer
rather than by shared modulus, *and* it enforces a one-to-one mapping of
certs and private key containers.
AFAIK it uses a unique ID to connect the two. The PKCS #11 model follows this
pattern as well, although it doesn't require a 1:1 mapping - you can have lots
of things tied by a common ID if you want, although I suspect some apps would
handle this rather poorly.
Peter.