Subject: Certificate renewal and enveloped-data.

From: "Timothy J. Miller" <[email-masked]>
Date: Mon, 05 Apr 2004 14:35:51 -0500

I've skimmed the last year or so of the archive, but without a dedicated 
search function it's kind of hard to tell what's been previously discussed.

I was wondering if the issue of renewing certificates (i.e., same key 
material, different validity & serial, possibly different DN) has arisen 
before the WG and if anyone could point me to the relevant threads (or 
perhaps would be willing to discuss the subject on- or off-list).

I have an operational need to renew (extend the lifetime) rather than 
reissue certificates, but the messages my mailers create use 
issuerAndSerialNumber as the RecipientInfo pointer.  This means that 
after the removal of the old certificate the enveloped messages cannot 
be decrypted by the mail agent.  It seems to me that if the 
RecipientInfo were set to subjectKeyIdentifier, old messages could still 
be decrypted with renewed certificates (assuming that SKI is set to the 
key's hash as recommended), even after the old certificate is removed.

Unfortunately, all the S/MIME mailers I have access to all use 
issuerAndSerialNumber.  I've messed around trying to construct an 
envelop using SKI to test without success; this could be either a 
failure on my part or lack of support in the mail agent-- I can't tell 
which.

Thanks in advance.

-- 
-- Timothy J. Miller
    ( The MITRE Corporation )

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 08 Apr 2004 02:07:01 +1200

"Timothy J. Miller" <[email-masked]> writes:

>I have an operational need to renew (extend the lifetime) rather than reissue
>certificates, but the messages my mailers create use issuerAndSerialNumber as
>the RecipientInfo pointer.  This means that after the removal of the old
>certificate the enveloped messages cannot be decrypted by the mail agent.

Can't you just have two issuerAndSerialNumber index entries pointing to the
same private key?  I must admit it's not something that's come up before (I
strongly encourage users to generate new keys and not re-certify the same old
key year in, year out, which probably helps), but if you needed to do it you
could just retain the old iAndS index entry for the private key.

(Do you specifically need an MTA that does this, or will an S/MIME toolkit do?
:-).

>issuerAndSerialNumber.  I've messed around trying to construct an envelop
>using SKI to test without success; this could be either a failure on my part
>or lack of support in the mail agent-- I can't tell which.

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.

Peter.

---

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 07 Apr 2004 09:40:36 -0500

> could just retain the old iAndS index entry for the private key.

Unfortunately, the PKI users require new certificates because of 
changing email addresses before the certificates expire.  What I'm 
really after here is to avoid going through the whole key recovery mess 
simply so users can read old enveloped email.

Currently, the PKI in use adds the rfc822Name to the subjectAltName 
extension in the S/MIME encryption certificates being created.  Changing 
that is a long process already underway-- the eventual goal is to use 
S/MIME signing certs tied to email addresses, and S/MIME encryption 
certs that are not, but it could be a couple of years before that's ready.

I work for a rather large organization with a rather large PKI.  ;)

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.

 > (Do you specifically need an MTA that does this, or will an S/MIME

It would be nice if it all worked with Outlook, but that may be too much 
to ask (see below).

> 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.  So when I'm opening an enveloped 
message, I pull the sKID from RecipientInfo, search the cert store for 
that sKID, then find the private key that matches the modulus from that 
cert.

Or am I just wrong?  Why?

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.  But we're 
taking that as a separate issue.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 08 Apr 2004 03:21:17 +1200

"Timothy J. Miller" <[email-masked]> 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.