Subject: NR and Private Key Usage Period

From: [email-masked]
Date: Fri, 20 Aug 1999 12:12:21 -0400

Today, Private Key Usage Period is recommended against by RFC 2459 (section
4.2.1.4).  Given that most of the scenarios for NR require that certificates be
valid at the time when a signature is to be checked by a third party, which may
be long after the object is signed, shouldn't Private Key Usage Period be used
with NR certificates?

     A possible new wording would be:
     The Private Key Usage Period extension should only be present in
certificates which possess a keyUsage extension with the nonRepudiation bit of
that extension set.

     Similar, but weaker, arguments would apply to permitting this extension
when the keyCertSign bit is set as well, since certificates may also be valid
for a long time.

          Tom Gindin

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 21 Aug 1999 05:21:47 +1200 (NZST)

[email-masked] writes:

>4.2.1.4).  Given that most of the scenarios for NR require that certificates 
>be valid at the time when a signature is to be checked by a third party, 
>which may be long after the object is signed, shouldn't Private Key Usage 
>Period be used with NR certificates?

It's needed not just with NR certs but with any certs (although it's 
especially necessary with NR certs) - typically you want to be able to sign 
now, but have the signature valid for a much longer time than the lifetime of
the private key.  What was the rationale behind deprecating PKUP?  I seem to
remember grumbling about this some time ago, I don't recall anyone being able
to provide any convincing argument for deprecating PKUP in RFC 2459.

Peter.

---

From: [email-masked]
Date: Fri, 20 Aug 1999 14:54:00 -0600

Tom,

Unless I read your message too quickly, to my way of thinking 
you have this exactly backwards.  The Private Key Usage
period was supposed to be shorter than, not longer than the
certificate validity.

If the current definition of NR means anything at all (which
isn't clear), then I would submit that it PROBABLY means that
that the signature is intended to endure and still be considered
valid long AFTER the certificate has been expired, or even 
been revoked, so long as it can be established that it was valid
at the time of signing, e.g., with OCSP, CRLs plus notarized timestamps,
Papal archives, or whatever.

There is virtually no reason I can think of why the Private Key Usage
should extend beyond the expiration date of the certificate -- 
that just increases the risk of compromise with no concomitant
benefit.

What the Private Key Validity period should do, and the reason why 
I am still opposed to deprecating it, is to set a time after which a signature
which was apparently created using a key that was supposedly zeroized
should be looked at with considerable scepticism, to say the least.

(For those who may have tuned in late -- the fact that a certificate has 
expired or even been revoked does NOT ipso facto mean that the 
signature is not legally binding -- it just means that it may be
more difficult to prove.)

Assuming that keys and certificates are relatively inexpensive, but that
validation of a signature once the certificate has expired is considerably 
more expensive than during the validity period (because of the 
additional archiving, etc., required), then from the user's perspective
what he would like to do is use short-lived keys and long-lived certificates.

Ignoring cryptanalytic attacks, zeroizing a key is the surest possible 
way of protecting against a key compromise. So if a key management 
system provides a way to automatically schedule a key for destruction
(or at least to remind the user to destroy it), that would be a Good Thing.

Once the key has been zeroized, from the user's perspective, and especially
from the Relying Party's perspective, the longer the certificate lifetime, the 
better, since during the validity period it isn't necessary to have all of the 
time stamped archives -- you can just query the CA to see whether 
the key is still valid..  But from the CA's perspective, of course, this 
isn't too good, because it increases the size of the CRL's.

Regards,

Bob

(P.S. -- this is a beta version of GroupWise 5.5 with S/MIME support.  
If anyone notices anything wrong with the format, etc., please let 
me know so we can fix it.)

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> <[email-masked]> 08/20/99 10:12AM >>>

          Tom Gindin

---

From: [email-masked]
Date: Fri, 20 Aug 1999 17:49:02 -0400

[email-masked] on 08/20/99 04:54:00 PM

To:   "[email-masked]"@e1.ny.us.ibm.com, [email-masked]
cc:
Subject:  Re: NR and Private Key Usage Period

Tom,

[Tom Gindin]   You did read it too quickly, because I didn't say which of the
two periods was longer - I thought everybody understood that.  The idea was that
a certificate which was created with a private key usage period shorter than the
certificate validity would be usable for NR signatures only until the PKUP
expired, but that those signatures could be checked against CRL's until the
certificate itself expired.  It is true that X.509 section 11.2 has a note which
might require archiving of expired CRL's, but they wouldn't be available online
and the note's wording is fairly unhelpful: "If a non-repudiation of data
service is dependent on keys provided by the CA, the service should ensure that
all relevant keys of the CA (revoked or expired) and the timestamped revocation
lists are archived and certified by a current authority."  The emphasis on
CA-provided (not CA-certified) keys here might make this note inapplicable to
the case where the NR keys are generated by end-user clients.  This wording is
from the June 1997 version, and perhaps it has been replaced by something which
more obviously binds CA's which certify externally generated keys as NR ones.
If it hasn't been replaced, it should be.

[Tom Gindin]   This argument only applies to signing certificates, especially
NR, right?

Regards,

Bob

Robert R. Jueneman
Security Architect

          Tom Gindin

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 21 Aug 1999 09:56:39 +1200 (NZST)

[email-masked] writes:

>There is virtually no reason I can think of why the Private Key Usage should 
>extend beyond the expiration date of the certificate -- that just increases 
>the risk of compromise with no concomitant benefit.

There is one reason, but it's pretty specialised: You may want your private 
decryption key to stay around for a few days after the public portion has gone
to bignum heaven in order to allow messages in transit over the expiry time to
be decrypted.  This is probably easier than trying to juggle overlapping 
expiry dates for certs.

Peter.

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 20 Aug 1999 16:40:57 -0600

Tom,

I think we are in violent agreement.

WRT to the PKUP of something other than a signing key, and in particular
and encryption (key exchange) key, I tend to regard the required life
of such keys as effectively infinite, at least if I ever want to be able to read 
my own mail in the future.  (Of course, in-house counsel who would like everyone
to trash all of their e-mail messages immediately after reading them, so that 
they don't end up as evidence in a Tobacco suit might disagree.)

BTW, your reply was interesting, since your mail package apparently 
included all of the original attachments, including my certificates, my 
.vcf file, and the original smime.p7s attachment containing my signature!

Your message showed up as with a  "signature not verified -- the message 
may have been tampered with" warning, with the certificate being mine.
Thanks for the nice test case!

What mail package are you using, including version and rev. level?

Bob

>>> <[email-masked]> 08/20/99 03:49PM >>>

Tom,

Regards,

Bob

Robert R. Jueneman
Security Architect

          Tom Gindin