Subject: Is certificate renewal a good idea?

From: "Tammy Carter" <[email-masked]>
Date: Tue, 03 Nov 1998 16:23:41 -0700

In the recent thread about keyIdentifiers, Robert Moskowitz and a few others have mentioned 
certificate renewal.  I had found this topic conspicuously absent from any of the PKIX drafts and 
had assumed that renewing certificates was considered bad practice.  Can someone enlighten 
me?

It seems as though there are two cases to consider:
1)  Same CA, same public key, different subject name
2)  Same CA, same public key, same subject name, 
      different information in the certificate (e.g., alternative names, validity period, CP/CPS)

It would seem to me that case #1 should be prohibited by a PKIX-compliant CA.  It would also
seem, on the surface, that case #2 should be discouraged as "bad practice."  Of course, case 
#2 cannot be prohibited by a CA since that would mean that a CA would have to store all of the 
certificates it ever generated and look through them each time it generated a new certificate.

Case #2 is troubling to me, however.  What would stop a subordinate (non-root) CA from doing 
the following:
A)  Get a certificate from a root CA with a CPS indicating that the subordinate CA assumed  
       a large amount of liability for certificates that it issued
B)  Collect lots of money issuing certificates to end entities
C)  Renew it's certificate using the same root CA with a different CPS indicating that the 
       subordinate CA assumed no liability for any certificates it issues, and set the validity 
       period in the certificate to be the same as in the previous certificate
In such a case, it would seem that the users who paid lots of money for their "high quality 
certificates" have just been swindled!  

Comments?

Tammy Green Carter
[email-masked]

---

From: "Flanigan, Bill" <[email-masked]>
Date: Wed, 4 Nov 1998 08:31:04 -0500

See comments below.

> -----Original Message-----
> From:	Tammy Carter [SMTP:[email-masked]]
> Sent:	Tuesday, November 03, 1998 6:24 PM
> To:	[email-masked]
> Subject:	Is certificate renewal a good idea?
> 
	Actually, the most prevalent case is likely to be:
	3) Same CA, different public key, same CN

	[snip]

> Comments?
	Above.

> [email-masked] 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           (703) 681-2318
Defense Information Systems Agency      Fax:           (703) 681-2814 
Information Assurance Office (JED)      DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           (703) 681-2318   
Falls Church, VA 22041-2717        Internet:  <[email-masked]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

---

From: "Tammy Carter" <[email-masked]>
Date: Wed, 04 Nov 1998 12:28:39 -0700

Bill, 

I hope that you are right that your case #3 is the prevalent case.  However,
my question is more along the lines of what a CA should do in cases #1 and #2.
And, should client software be built to support case #2?

>>> "Flanigan, Bill" <[email-masked]> 11-4-98 6:31:04 AM >>>
See comments below.

	[snip]

	Above.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 04 Nov 1998 23:19:04 +0100

I would suggest that all cases #1, #2 and #3 could be valid and should be
considered good practice as long as the certified information is correct.

All certificates are individual statements with individual liabilities. 

We have also identified several scenarios where the same public key can be
associated with different subject names as long as they are associated with
the same subject. The only "wrong" case I can see is if the same public key
is certified to separate individuals in different certificates.

It will be the relying party who in the end will decide if a particular
certificate is suitable for the present case, taking all factors in
consideration. In this decision the relying party shall not have to be
aware of any other related certificate for the same subject or key.

In cases of name change it would also be OK to re-issue the same
certificate with the new name as long as the old certificate is revoked (if
the old name is invalid).

For those interested in liabilities and the legal jungle associated with
digital signatures, I would highly recommend to take a look at INCITRALs;
"Planning of future work on electronic commerce: digital signatures,
certification authorities and related legal issues", found at:
http://www.un.or.at/uncitral/en-index.htm

/Stefan

>	3) Same CA, different public key, same CN
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: "Flanigan, Bill" <[email-masked]>
Date: Thu, 5 Nov 1998 13:40:14 -0500

Let's, for a moment, go back to case # 2, viz.:  " 2)  Same CA, same public
key, same subject name, different information in the certificate (e.g.,
alternative names, validity period, CP/CPS)".  I can see how "alternative
names" will work (there are several ways to achieve it), but not how the
relying EE could deal with different validity periods or different CPs or
different CPS.  Each cert has one validity period (if it didn't, how could
the relying EE tell if it was still in play?--use the most distant Not
Before date?  I don't think so!).  Each cert also has it's own CP derived
from the three policy extensions.  And each CA has it's own CPS.  It's hard
enough to write just one CPS (it's a growth legal niche supreme).  Anyway,
all of these last three differences are academic, since they lie way outside
of PKIX compliance.  But you can always try SPKI!!

Bill

> From:	Stefan Santesson [SMTP:[email-masked]]
> Sent:	Wednesday, November 04, 1998 5:19 PM
> To:	Tammy Carter; [email-masked]; [email-masked]
> Subject:	RE: Is certificate renewal a good idea?
> 
> >my question is more along the lines of what a CA should do in cases #1
> and
> #2.
> >> certificate renewal.  I had found this topic conspicuously absent from
> any
> >> of the PKIX drafts and 
> >> had assumed that renewing certificates was considered bad practice.
> Can
> >> someone enlighten 
> >> me?
> >> 
> >>       different information in the certificate (e.g., alternative
> names,
> >> validity period, CP/CPS)
> >>

---

From: "Flanigan, Bill" <[email-masked]>
Date: Thu, 5 Nov 1998 14:21:21 -0500

Interesting.  Does this mean that the same CN would have two certs to choose
from during this six-week period?

> From:	Dwight Arthur [SMTP:[email-masked]]
> Sent:	Thursday, November 05, 1998 1:54 PM
> To:	[email-masked]
> At the National Securities Clearing Corporation we are beginning to face
> renewal requirements. 
> 
	[snip]

> The renewed certificate would be issued as much as six weeks before the
> start of its validity period.
> --------------------------------------------------
> p:(212) 412-8687                     Dwight Arthur
> f:(212) 908-2345        Managing Director: Systems
> b:(917) 646-6682      National Securities Clearing
> [email-masked]        55 Water Street
> http://www.nscc.com        New York, NY 10041-0082
> 
>

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 06 Nov 1998 00:20:45 +0100

Al,

I agree with your definitions.

What you provide is som useful labels which I find sound and useful. I
would encourage labels like these to be defined for different types of
practices. Maybe something for the roadmap ?

One case that seems to be missing is the case where one certificate of one
type is used to apply for another certificate of another type. They may use
same key, different naming attributes, identify different privilages, maybe
issued by different CA:s, but they are both individual statements valid at
the same time. 
In physical life we do this all the time. We may use our ID-card to apply
for a petrol card or a credit card. We use the same key (our signature in
hand writing). Still the context will make clear which certificate to use
in any given occasion. I would not use my ID-card to by petrol and not the
petrol card in the Bank. They are not even cross certified, they are just
individual statements by the issuer according to their policies.

The "Qualified Certificate" may be used in this context to carry the
function of an electronic ID-card, thus may considerably enhance initial
registration to other CA:s such as SET CA:s, elelctronic trade CA:s, helth
care CA:s, other private domain CA:s etc.

But in all this I hope that we don't confuse this with the problem of
defining what is good or bad practice for a particular CA. As long as a
certificate is suitable for its intended usage, it's good parctice. And
what is suitable or not is a pure policy issue which requires a clear
context to be evaluated.

/Stefan

At 03:26 PM 11/5/98 -0500, Al Arsenault wrote:
>In the PKI with which I am familiar (which has been operational for more
>than 3 and 1/2 years now), we use a couple of different terms:
>
>	renewal:  issue a new certificate with the same DN, the same attributes,
>the same key, a different certificate serial number, and a different
>validity period
>
>	update:  issue a new certificate with the same DN, but with one or more
>new attributes, a new key, a different certificate serial number, and a
>different validity period (where here, "attribute" means any field in the
>certificate other than the subject DN, issuer DN, certificate serial
>number, or validity period).
>
>"Renewal" is used when a user is continuing on in the same job.  E.g.,
>certificates are issued for a period of 6 months.  At the end of that time,
>the user is in the same job, at the same place, with the same privileges,
>etc.  We just give the user a renewed certificate, good for another six
>months, because nothing else is changed.  We change the serial number to
>distinguish between the old and new certs - it's the issuer/serial number
>combination that uniquely identifies the certificate.  And, obviously, the
>signature value changes. 
>
>Why use the same key?  Why not - assuming that the useful lifetime hasn't
>expired, it's not a security problem. If the useful lifetime hasn't
>expired, we don't let the cert be renewed.
>
>"Update" is when something else (other than the user's name) has changed -
>the user's access authorizations, privileges, etc. In that case, we revoke
>the old certificate, because the change may have resulted in the loss of
>access, and we want to make sure that the old cert won't work.  We demand a
>new key for the same reason.  (Strictly speaking, you wouldn't have to
>revoke the old certificate if the change resulted in an increase of access
>privileges, but it's administratively easier to just always revoke the old
>cert.)
>
>If the only attribute that changes in an "update" is the user's public key,
>it's called a "rekey", but the same rules apply.
>
>Note that in a renewal, you can have multiple certificates valid for the
>same user at the same time (if you issue the renewal before the old
>certificate expires, which is generally considered to be the smart thing to
>do).  Since the public key's the same (and thus the associated private
>key's the same) it's not a major problem, assuming that the end-entity is
>capable of dealing with the fact that there are two certs for the same user
>in the repository.
>
>				Al Arsenault
>
>
>-- these are my opinions only.  They do not necessarily reflect the
>opinions of my employer, or of any other organization with which I have a
>relationship.
>
>
>
>
>At 01:53 PM 11/5/98 -0500, Dwight Arthur wrote:
>>renewal requirements. In every case we are talking about same CN, same CA,
>>same DN, and different validity period. I would like to say that in all
>>cases we will be seeing a new public key, and we would certainly discourage
>>the idea or re-certifying the same key, but I cannot guarantee that we will
>>never see renewal with the same public key.
>>
>>Two requirements that we consider critical, but not easily fulfilled given
>>the current state of the are, are:
>>- DN in renewed certificate is exactly identical to DN in original
>>certificate.
>>- Start of renewed certificate's validity period is exactly equal to
>>expiration of the original certificate's validity period no overlap no gap.
>>Really?  I always thought it would be validity date.  Of course this would
>>be about 18 months after PKI rollout.
>>
>
>
>
>

---

From: Covey Carlin <[email-masked]>
Date: Fri, 06 Nov 98 09:08:00 MST

It seems to me that cases #2 and #3 are issues that concern the client, but 
case#1
seems to be strictly a registration issue.

case#1:
Since clients will find certificates based upon the DN, it should be 
transparent to the
client whether the same public key appears in another certificate with a 
different DN .
It may matter to the CA, however.  Presumably the CA insists upon proof of 
possession
of the private key when responding to a certification request, to prevent 
someone
hijacking someone else's public key.  The CA may or may not have rules 
concerning
the same user using two different DNs with the same public key.

cases#2 and #3:
The client may need to concern itself with these cases if two certificates 
having the same
CA and same DN are still valid, regardless of whether they have the same 
public key.
If they are encryption certificates and the only difference is the not-after 
date, and both are
still valid, then the client can choose either.  If they are signature 
certificates and both
are still valid and they have the same public key (case#2), then the client 
can pick either.
If the signature certificates have different public keys, then obviously 
only the one that
matches the signature to be verified will be useful.  The client will have 
to concern itself
with the possibility that the first certificate it tries may not work, but 
the second might.

cases#2 and #3 (reprise):
If two valid certificates have the same DN but differ in some other regard 
that is of
concern to the client (e.g. policy OID), the client will have to pay 
attention regardless of
whether the two certificates have the same public key.  The first 
certificate tried may not
have the right attributes, but the second might.
 ----------
From: owner-ietf-pkix
To: ietf-pkix; flanigab
Subject: RE: Is certificate renewal a good idea?
Date: Wednesday, November 04, 1998 12:28PM

Bill,

I hope that you are right that your case #3 is the prevalent case.  However,
my question is more along the lines of what a CA should do in cases #1 and 
#2.
And, should client software be built to support case #2?

See comments below.

        [snip]

        Above.

---

From: "Tammy Carter" <[email-masked]>
Date: Wed, 11 Nov 1998 21:01:12 +0100

Al,

How can a piece of software tell if the key's useful lifetime has expired?  The onus 
for such a check must logically be upon (1) the CA, or (2) the client software.  
[Here I'm assuming that it is unreasonable to expect users to remember when 
the key in each of their certificates was first created.]

It doesn't seem obvious to me that a CA should make the determination.
If a CA kept a database containing tuples of 
<public key, subject name, date of issue>, the CA could find that it had 
issued a certificate with the same public key and the same subject name X
days/months/years ago given only a CSR (or similar request).  This doesn't
seem like a good idea for two reasons: 
(1)  Not all CAs will be able to keep information about every certificate it has
       ever issued and be able to search it in a reasonable amount of time before
       issuing a new certificate.
(2)  In order for a user to determine that the key has passed its useful lifetime,
       they user must try to renew the certificate _with_the_same_CA_ which is not
       always possible.

That means that the client software should do it.  But, I just don't see how the 
client software can keep track either.  Well, unless some state is kept with each
certificate saying when the key was created.  But, then, where is this state stored?
Surely it should be protected at least by a signature....  But, does it belong
in a certificate?

Lack of a good way discover how old the key in a particular certificate is seems an
excellent reason for client software to enforce a new key for each certificate.  If only
to protect naive users from keeping the same key for years because they know no
better or because they can't remember when they last did a rekey.

Tammy Green Carter
[email-masked]

>>> Al Arsenault <[email-masked]> 11-5-98 1:26:12 PM >>>
<snip>

> expired, we don't let the cert be renewed.

<snip>

				Al Arsenault

---

From: Al Arsenault <[email-masked]>
Date: Mon, 16 Nov 1998 08:37:21 -0500

Tammy,

	It's the CA's responsibility to track keys.  Comments in line:

>       issuing a new certificate.

AWA:  Tammy, it's the CA's job to track certificates and do renewals, if
appropriate.  In our system, the CA keeps a database of all certificates it
issued.  Included in each certificate record are things like a copy of the
actual certificate, the date it was originally issued, the key validity
period, how to contact the subject of the certificate,  whether this
certificate has already been renewed, whether this certificate has been
revoked, and some other stuff.  The CA software automatically does the
record creation/update every time the CA takes some action, so the
information is there.  In general, the CA is not allowed to delete records
from the database until they have been "archived" - preserved for long-term
storage via an explicit action. You should only archive records that you
don't actively care about - the certificates have been revoked, or have
expired, or...  So, unless a CA (human being) is being deliberately
malicious or truly imcompetent, there's not a problem searching for and
finding a certficate when a renewal request takes place. 

Renewal can be either pro-active or re-active.  The CA has the capability
to scan the database and find all of the certificates that are about to
expire, say within 30 days or some other window.  The CA can look at these
certs and contact the subjects to see if anything has changed.  If the CA
is satisfied that renewal is appropriate, she can renew the certificate and
send the new one to the user via some appropriate channel - e.g., e-mailing
it, or posting it to a directory.

Alternately, the user can notice that her cert is about to expire, and send
in a renewal request.  The CA will decide whether or not to approve the
request; if it's approved, the CA will do the renewal and send back the new
cert.

>       they user must try to renew the certificate _with_the_same_CA_ which 

AWA:  Only the CA that issued a certificate can renew it.  You as a user
can ask a different CA for a *new* certificate with a public key that's
already in another certificate you have.  That new CA (which may not even
know that the public key is one that's already in a different certificate
you have) will make a decision about whether to issue that new certificate.
 But that's not a renewal, because it changes a field other than validity
period, serial number, or signature value.

>Surely it should be protected at least by a signature....  But, does it belong

AWA:  Again, this is all done at the CA.  We tried not to put any
certificate management tasks on the clients unless we absolutely had to.
With a reasonable database at the CA workstation, it's not a major problem.
 It's not as automated as some customers would like - they'd like the
renewal to be completely transparent - but it works well enough.

>better or because they can't remember when they last did a rekey.

AWA:  If the users/clients want a new key with each certificate, that's
certainly their option.  We support both.  

				Al Arsenault