Subject: Re: Renew/Rekey/Modification

From: Johannes Merkle <[email-masked]>
Date: Wed, 01 Apr 2009 14:49:06 +0200

Stephen,

I do not know the FPKI documents but I think your questions generally refer to RFC 3647.

> Re-key is said (in the FPKI CP) to be a good idea because the older a
> key gets, the more susceptible it is to loss and compromise.  Fair
> enough, but why wouldn't that consideration be factored into the chosen
> certificate validity period?
> 
Typically, a certificate is re-keyed when or right before it expires. In this case, the maximum key lifetime is factored
into the certificate.

> 
> Is there ever a real world scenario when a Subject would of their own
> accord request re-key because they feel the key is getting old?  If so,
Yes, right before the old certificate expires. An alternative scenario would be after revocation due to suspected key
compromise, but in this case the application for the new cert can not be secured by the old one.

> why wouldn't they revoke as well?  The FPKI CA says that after re-key
> "The old certificate may or may not be revoked".  Why would you not
> revoke, given the possibility that the key has got too old?  I don't
> think it would ever be sensible to keep using an old original key and a
> fresh key.  And if I were a Relying Party, I might like to know about
> this possible quality difference, yet there would be nothing in a CRL or
> anywhere else to mark the fact that the Subscriber has re-keyed.
If the old certificate is going to expire very soon, revocation might not be necessary. However, it is considered good
practice to revoke the old certificate in the process of re-keying.

> The FPKI CA goes on to say that after re-key "The old certificate ...
> must not be further re-keyed, renewed, or modified".  This seems almost
> oxymoronic.  Consider that I have certificate A and then I re-key A to
> create certificate B.  And then I re-key B to create certificate C.  I
> would say that C is indistinguishable from a re-keyed A since A, B and C
> will only differ by key value.  So how is it meaningful to forbid
> re-keying A more than once?
> 
You are right, they are indistinguishable. However, the rule refers to the re-key application process. In this process
the old certificate is used as a reference, typically to authenticate the certificate request and to verify the
correctness of the certificate content data. I understand this rule to prohibit future certificate requests being
authenticated and verified with the old certificate. In particular, if after a re-key a certificate modification has
occured (e.g. because the subject attributes have changed), a re-key based on the re-keyed certificate could result in a
certificate with the outdated attributes.

> Finally, why does RFC 3647 bother to describe "Certificate Modification"
> at all?  The term is inherently confusing since one of the most obvious
> characteristics of a digital certificate is that it cannot be tampered
> with.  I question the need for a special bit of counter intuitive jargon
> (and a whole slab of the RFC) to cover what is really a mundane
> scenario; viz a certificate Subject needs a certificate with different
> details in it.  That is, it's just a new certificate.  Why is it treated
> any differently from an original certificate application?
> 
As far as I understand certificate modification covers any application for a new certificate where the data requested to
include into the certificate differs from the old certificate in more than merely the public key. You are right, it is a
new certificate for the subject, but this also holds for re-key or renewal.

The reason why it is treated different from initial (original) certificate application is that registration process can
be facilitated. For instance, subject identification and verification of unchanged data can be omitted. Furthermore, the
old certificate can be used to authenticate and protect the certificate application process.

I agree that the term "certificate modification" is a bit misleading.

Johannes

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 1 Apr 2009 09:45:42 -0400

You may be over-analyzing the terms.  A certificate can be issued
ab-initio, or it can be related to an existing certificate.  If related,
various things can be held constant while others are changed:
* if only validity (and serial number, of course) changes, it's called
renewal
* if other information excluding the key changes, it's called an update
or modification
* if the key changes, it's called a rekey

If a certificate is replaced because of a known key compromise, the cert
is rekeyed and the old cert is revoked.  If a cert is replaced because
it is getting old (nearing the end of its validity) then the old cert
may either be revoked or be allowed to expire.  Key age is one factor in
determining validity period, but so is other information - it may be
useful to renew short-lived certificates many times without rekeying in
order to avoid or minimize the burden of revocation.

You are correct that if cert A is rekeyed twice, there isn't much
difference between saying cert C is a rekey of B or of A.  But there is
a difference for renew and update - it is a management best practice not
to renew or update A to produce C after rekeying A to produce B - once
A's key has been replaced, no new certificates should be created with
that key.  It may also be good practice to say that if cert A has been
rekeyed to produce B, then only B (and not A, even if still valid)
should be used to authenticate the subject when rekeying to produce C.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Wilson
Sent: Tuesday, March 31, 2009 10:42 PM
To: [email-masked]
Subject: Renew/Rekey/Modification

Colleagues,

There are a few things about certificate "renewal" and "re-key" that 
have long confounded me.  Things only seem to have got more convoluted 
in RFC 3647 and -- no offence! -- in newer Certificate Policies like the

US FPKI Policy Authority document.   Can anyone help me understand the 
rationale for the some of the following scenarios?  Thanks in advance!

Cheers,

Stephen Wilson
Lockstep Technologies
www.lockstep.com.au/technologies.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 01 Apr 2009 10:53:30 -0400

Stephen Wilson wrote:
> must not be further re-keyed, renewed, or modified".  This seems 
> almost oxymoronic.  Consider that I have certificate A and then I 
> re-key A to create certificate B.  And then I re-key B to create 
> certificate C.  I would say that C is indistinguishable from a 
> re-keyed A since A, B and C will only differ by key value.  So how is 
> it meaningful to forbid re-keying A more than once?

Consider a scenario in which the private key corresponding to 
certificate A has been compromised (e.g., an attacker, without my 
knowledge, infects my computer with a virus, obtains a copy of the file 
containing the private key, and guesses the password used to encrypt the 
private key file).  When certificate A is about to expire, if I wish to 
continue to have a certificate from this CA, then one of two scenarios 
may happen:

1) I perform re-key, authenticating myself using certificate A, and 
obtain certificate B.  The attacker is now prevented from performing an 
on-line re-key to obtain a new certificate in my name, since the system 
will not permit any further re-key based on certificate A.  Thus, the 
attacker's ability to impersonate me ends either immediately (if 
certificate A is revoked) or when certificate A expires.

2) The attacker performs a re-key, authenticating himself using the 
stolen private key, and obtains certificate B.  Later, I attempt to 
perform a re-key and am unsuccessful, since the system will not permit 
any further re-key based on certificate A.  I call the help desk and 
complain, which will (hopefully) result in certificate B being revoked.  
(It is unlikely that there would be a certificate C since many CAs will 
not allow re-key to be performed until the current certificate is 
approaching its expiration date.  But, it wouldn't matter anyways, since 
presumably my help desk call would result (after authentication of my 
identity) in all of my certificates being revoked.)

If the system permitted more than one re-key based on certificate A, 
then it would be more likely that the attacker could continue to 
impersonate me even after certificate A expired.  Granted, this is not a 
foolproof, but I don't think it's moronic either.

Dave

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 1 Apr 2009 17:00:50 -0400

Stephen,

See responses in-line. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Wilson
> There are a few things about certificate "renewal" and 
> "re-key" that have long confounded me.  Things only seem to 
> have got more convoluted in RFC 3647 and -- no offence! -- in 
> newer Certificate Policies like the 
> Re-key is said (in the FPKI CP) to be a good idea because the 
> older a key gets, the more susceptible it is to loss and 
> compromise.  Fair enough, but why wouldn't that consideration 
> be factored into the chosen certificate validity period?

It should be.  The goal here is to use the current certificate to
authenticate to create new certificates.

> 
> 
> Is there ever a real world scenario when a Subject would of 
> their own accord request re-key because they feel the key is 
> getting old?

PKI obligations and policy may require that subject perform the re-key
and take some concrete action in order to be bound to the subscriber
obligations and agreements.

>  If so, why wouldn't they revoke as well?

Two reasons come to mind for not revoking.  You do not want to
invalidate existing, unexpired signatures.  You do not want to have
built in mechanism for large CRL.

BTW, you can compensate for it by destroying the current key after
re-key.

> The 
> FPKI CA says that after re-key "The old certificate may or 
> may not be revoked".  Why would you not revoke, given the 
> possibility that the key has got too old?

See previous response.

>  I don't think it 
> would ever be sensible to keep using an old original key and 
> a fresh key.  And if I were a Relying Party, I might like to 
> know about this possible quality difference, yet there would 
> be nothing in a CRL or anywhere else to mark the fact that 
> the Subscriber has re-keyed.
> 

You do not need to use the old authentication/signature key.  You do not
need to revoke it either.  You can simply destroy it.

You do need to keep old decryption keys.

> must not be further re-keyed, renewed, or modified".  This 
> seems almost oxymoronic.  Consider that I have certificate A 
> and then I re-key A to create certificate B.  And then I 
> re-key B to create certificate C.  I would say that C is 
> indistinguishable from a re-keyed A since A, B and C will 
> only differ by key value.  So how is it meaningful to forbid 

Certificates are not the only objects.  CA and RA can keep other
information that can be used to enforce that A is used to rekey only
once.

> at all?  The term is inherently confusing since one of the 
> most obvious characteristics of a digital certificate is that 
> it cannot be tampered with.  I question the need for a 
> special bit of counter intuitive jargon (and a whole slab of 
> the RFC) to cover what is really a mundane scenario; viz a 
> certificate Subject needs a certificate with different 
> details in it.  That is, it's just a new certificate.  Why is 
> it treated any differently from an original certificate application?

Certificate Modification (like renewal and rekey) refer to the fact that
a new certificate with different information is created.  If you feel
that the term is confusing, let us know of a better term.

As to why deal with differently that original certificate is that the
modification may be carried out using fully or partly automated process
based on the current certificate to be modified.  That is why framework
identifies this.  Of course, many certificate policies require initial
process for certificate modification.  For that matter, policies do not
permit renewal and some require initial process for rekey as well.

The framework tries to accommodate many plausible scenarios.

---

From: "EXT-Glatting, Dennis P" <[email-masked]>
Date: Thu, 2 Apr 2009 09:23:43 -0700

> authenticate to create new certificates.

I'm a little confused here. If we're getting rid of the key because it's
getting old, then how is it young enough to validate a new key? A
problem is there is an implicit "continuance of legacy" in the new key
of the old key that doesn't end with the immediate generation but
follows all generations of the original key.

I'm not suggesting something is "wrong" but there seems like there is a
logic error somewhere.

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 2 Apr 2009 17:05:34 -0400

As Santosh said, if the old key is compromised and used first by an
adversary to rekey, then the subscriber will detect the compromise when
he tries to rekey and is rejected.  If the subscriber rekeys first, then
the adversary is out of luck.

The subscriber could be allowed to spawn multiple new rekeyed
certificates (such as generating an email encryption certificate based
on a signature certificate) as long as the validity is not extended from
old to new, but should be allowed only one rekey with a new validity
period.

-----Original Message-----
From: EXT-Glatting, Dennis P

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 2 Apr 2009 17:05:34 -0400

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 1 Apr 2009 17:00:50 -0400

Stephen,

See responses in-line. 

See previous response.