Subject: Re: Why is privateKeyUsagePeriod deprecated?

From: [email-masked] (Peter Gutmann)
Date: Tue, 22 Jul 2003 22:59:07 +1200

"David A. Cooper" <[email-masked]> writes:

>It is my understanding that use of this extension was deprecated since,
>unless signed messages are timestamped by a trusted time stamping service,
>there is no way of determining when a message was signed. 

But the same thing applies to the overall cert validity time (as opposed to
just the PKUP) as well.  This doesn't seem like a very valid reason.

>Is there any reason that the PKI users you mention need to include this
>information in the certificate?  

Yes, because they want to use the signing key (relatively) short-term, but be
able to verify sigs using the public portion years after the private portion
has been retired/destroyed/lost/whatever.

>If there is a need to verify signatures for up to 7 years after the signature
>was generated, why not just institute a policy that all subscribers must
>rekey 7 years before the expiration of their certificates?  

Because it's unlikely that the CAs are going to modify their 1-year billing-
cycle-driven renewal process to handle long-term signing over 10- or 20-year
periods (and conversely I can't imagine users going through the hassle and
expense of re-certifying a bunch of keys year in year out just so someone else
can verify their sigs).  In any event the users don't want to keep the keys
around forever, they want to use the private keys for x amount of time but
still allow verification of the sigs generated with the keys 5x or 10x or 20x
later.

Peter.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 22 Jul 2003 17:49:38 +0200

> has been retired/destroyed/lost/whatever.

Again I'm astonished to see this discussion here. It shows like other 
discussed topic how much disagreement is here about very basic topics.

Personally I see no use of PKUP extension. How long signatures created with 
a private key associated with a PKC can be validated should not be specified 
in a public-key certificate. The more natural solution to me is to specify 
this in the policy and cryptographic protocol used for signing the message.

Ciao, Michael.

---

From: "Gregory S. Chudov" <[email-masked]>
Date: Wed, 23 Jul 2003 21:04:56 +0400

> this in the policy and cryptographic protocol used for signing the
message.
It's NOT about signatures validity. It's about private key policy.
Unfortunately, this very useful extension becaume a victim
of misinterpretaion of it's purpose.

In practice, the private key does have a validity period, which is often
shorter
than the validity of a corresponding certificate.
The key, which is used for too long, has very high probability to become
lost,
forgotten, compromized in any other way, so this period is normally small -
a year or less.
While the certificate can last for many years.
Without this extension, we can only tell the person not to forget
to get a new certificate and dispose of his old private key
within given period of time.
Using this extension, we can force a person to do this,
because this policy is written right there, in his certificate.

CA can grant him a certificate with a simple condition:
he MUST destroy his public key before it expires.
If he forgot about his key, and did not notify CA
that the key was destroyed, well, that means the
key is potentialy compromised and certificate should be revoked.

What do you do with your credit card, when it expired?
Throw it to the trash can? No, you return it to the bank.

Certificate expiration time is like a bumper for a train.
Bumper makes sure the train doesn't do too much damage,
if the brakes are broken. But the normal situation
is when the train stops normally, never reaching the bumper.

PrivateKeyUsagePeriod is like those breaks, it is a normal way
to stop using a key when it's time.

Good luck,
Greg Chudov.

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 23 Jul 2003 13:18:30 -0700

>Throw it to the trash can? No, you return it to the bank.

Interesting.  But this assumes you can safely return the card ("bank" may 
be 2000 miles away) and here at least I doubt banks would accept the 
practice.  We are simply admonished to destroy the card upon its 
expiration, usually accomplished by slicing it into pieces.  I suppose the 
numbers could be retrieved, but a lot of folks toss old statements in the 
trash as well.

You really return it to the bank?

The point here, though, is that cert-lifes are relatively short precisely 
because of concerns with continued key security.  This makes the certs "act 
like" private key usage limiters, when they are properly "key-to-owner" 
binding limiters.

In the strictest usage, one might refuse to validate a signature today if 
today is beyond the cert expiration, even though the document asserts the 
signature took place earlier (how to know w/o trusted timestamp)?  But as 
Peter points out, this is a real limitation on certificate utility, 
broached by most.

Cheers!  ____tony____

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900