Subject: RE: Is certificate renewal a good idea?

From: Robert Moskowitz <[email-masked]>
Date: Wed, 04 Nov 1998 10:11:20 -0500

At 08:31 AM 11/4/98 -0500, Flanigan, Bill wrote:
>> 
>> 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)
>> 
>	Actually, the most prevalent case is likely to be:
>	3) Same CA, different public key, same CN
>
Really?  I always thought it would be validity date.  Of course this would
be about 18 months after PKI rollout.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

---

From: "Dwight Arthur" <[email-masked]>
Date: Thu, 5 Nov 1998 13:53:44 -0500

At the National Securities Clearing Corporation we are beginning to face
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.
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: Eric Murray <[email-masked]>
Date: Thu, 5 Nov 1998 12:26:42 -0800 (PST)

> start of its validity period.

Perhaps I'm missing something, but this doesn't seem that hard to me.
Just send a copy of the old certificate along with the renewal
request  (and something signed with the corresponding private key)
for the CA to use to fill in the Subject and calculate
the new Validity from.

However, what happens if a user signs a message with the old cert/key
right before it expires, and the new cert has a new key?  Then the
recipient of the signed message can't verify it because the certificate
has expired.  Unless your protocol has a way to deal with this, I'd
suggest overlapping Validity periods and/or using KeyUsagePeriod to
restrict the use of the private key to a shorter period than the cert is
valid for.

-- 
Eric Murray          N*Able Technologies                    www.nabletech.com
(email:  ericm  at the sites lne.com or nabletech.com)     PGP keyid:E03F65E5

---

From: Al Arsenault <[email-masked]>
Date: Thu, 05 Nov 1998 15:26:12 -0500

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.

---

From: "Dwight Arthur" <[email-masked]>
Date: Sun, 8 Nov 1998 07:58:26 -0500

I have a couple of questions:

1. You state "If the useful lifetime hasn't expired, we don't let the cert
be renewed .." I assume that if the useful key life _has_ expired you do not
letit renew. But what do you do then? Are you implying that the entire
account history associated with this person should be abandoned and the
person treated as a brand new contact? This seems to present a security
hole.

2. If you allow renewals with the same key for the duration of the key's
useful life, why not just set the certificate validity to the key's useful
life? What's the benefit of expiring and renewing if not to force a new key?
If you are pushing full CRL's I understand that expiration gives an
opportuinity to purge the CRL. But there are other ways to manage this,
perhaps less costly and certainly less of a burden on the subject.
(Examples, OCSP, delta CRL)
--------------------------------------------------
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

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]] On Behalf Of
Al Arsenault
Sent:	Thursday, November 05, 1998 3:26 PM
To:	Dwight Arthur; [email-masked]
Subject:	RE: Is certificate renewal a good idea?

				Al Arsenault

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 08 Nov 1998 09:25:55 -0500

>(Examples, OCSP, delta CRL)

But delta CRLs do not address the size of the CRL which impacts processing
time and total size.  These are issues for silicon implementations.

Reasonable expire dates also address the nature of people NOT to notifiy
that they have moved to other jobs or died....

Robert Moskowitz
ICSA

---

From: Al Arsenault <[email-masked]>
Date: Tue, 10 Nov 1998 08:00:56 -0500

In reply to Dwight Arthur's first comment:

>let it renew. But what do you do then? Are you implying that the entire 

AWA:  yes, I apologize for the typo. If the key's useful lifetime has
expired, a certificate CANNOT be renewed.  At that point, the certificate
must at be "updated." (Remember that updating means that the key is
replaced, and if no other attributes are changed, we just call this a
"rekey" operation.)  No, we don't get rid of the account history.  We just
add a new record to our CA's database with the new certificate and relevant
information, and tie it to the old record, which we keep.  (You can't get
rid of the old record until you've taken the explicit step of 'archiving' it.)

>that they have moved to other jobs or died....

AWA:  That's a good summary.  Basically, setting the certificate validity
period shorter than the useful key lifetime allows us to manage a couple of
logistics issues.  First, for many of my customers, the longest we can
count on anybody being in one job under normal circumstances is three
years.  It's usually less than that; often, incumbency is on the order of a
few months.  And, no matter how many processes you want to institute about
check-out sheets and notifying all of the cognizant authorities when
somebody quits/transfers/gets fired, a few are going to slip through the
cracks because humans make mistakes.  The CA is just not going to be
notified a certain percentage of the time when people leave the
organization, and the farther away the CA/RA are from the users, the higher
that percentage is.  Setting a shorter certificate validity period makes
the default behavior "better" in that it requires the user to take a
positive action to retain access, rather than having access continue for a
couple more years unless something is explicitly revoked.  (One of the
sections I always try to read in any vendor's CP/CPS is the section on
revocation, loss of access, etc.  Most CA vendors are smart enough to cover
their tails; they say something like "if the user should no longer have
this certificate and you don't explicitly notify us to revoke the cert,
nothing that happens afterward is our fault."  That limits their liability,
but it doesn't help enforce security.)

As Bob points out, the second advantage is that you can control CRL size.
Since we don't use delta-CRLs in our system, the overall length of the CRL
that gets shipped around the system is a concern. Since a revoked
certificate is on the CRL until after it expires, having all certificates
good for three years can lead to a large CRL if you have to revoke a big
group of certificates.  Having shorter certificate lifetimes constrains the
size of the CRL to some degree.  Even if the CRL does get huge at one time
because of the revocation of a large group of certificates for some reason,
we can limit the amount of time the CRL is huge.

As Bob also points out, even if we did use delta-CRLs, size would still be
a problem.  We wouldn't necessarily be worried about sending multi-megabit
CRL files, because they'd be broken into pieces.  But, the end-entities
still have to reconstitute the entire CRL from the base and delta lists,
and the entire thing has to be stored and checked.  For some of the devices
we're required to support, that can potentially be a problem.

							Al Arsenault