PKIX does not disallow (strongly) the privateKeyUsagePeriod extension. SHOULD NOT is used so the inclusion is only "not recommended" but allowed. The strong words (MUST NOT) apply to the criticality.
I agree with David A. Cooper that a timestamp is (most of the time) required.
Assuming you want to include some watch reading when validating signatures and that your relying party agreement allows it ;-).
Further assuming both a notBefore and notAfter value are present:
You can reject signatures generated before the notBefore is reached using your watch.
The timestamp requirement is obvious in situations where the usage period is over and you rely on a still valid verification key. Reading your watch won't help.
The timestamp is required DURING the usage period because the signature might have been generated BEFORE the usage period started.
Assuming only a notBefore value is present: The timestamp requirement applies once the notBefore time is reached.
Assuming only a notAfter value is present: The timestamp requirement is only essential after the private key expires
In the book "planning for PKI" Russ Housley and/or Tim Polk state that since TSA's are not readily available, the extension has little utility.
All of the above implies that the privateKeyUsagePeriod extension is for use by the RP. The extension could have some utility to (well behaved) private key holders by specifying when they can use the key.
RFC 3280 states:
The private key associated with the certificate SHOULD NOT be used to sign objects
before or after the times specified by the two components, respectively.
Notwithstanding the use of SHOULD NOT instead of MUST NOT, (well behaved) private key holders are the best placed to comply with this requirement.
Daniel Montpetit
-----Original Message-----
From: David Chadwick [mailto:d.w.chadwick@xxxxxxxxxxxxx]
Sent: Monday, July 21, 2003 13:29
To: David A. Cooper
Cc: Peter Gutmann; ietf-pkix@xxxxxxx
Subject: Re: Why is privateKeyUsagePeriod deprecated?
"David A. Cooper" wrote:
>
> Peter Gutmann wrote:
>
> >PKIX disallows (strongly) this extension, but without giving any reason for
> >it:
> >
> > This extension SHOULD NOT be used within the Internet PKI. CAs conforming
> > to this profile MUST NOT generate certificates that include a critical
> > private key usage period extension.
> >
> >I've now run into several PKI users (including fairly large ones like
> >government departments and large corporations) who resort to ignoring the cert
> >expiry date in order to get around this restriction, since they have a
> >requirement to validate signatures long after use of the private key has been
Peter
the original idea in X.509 was to allow a certificate expiry date to be
significantly after the private key usage period to allow for signature
verification long after signatures could no longer be created. thus both
times are useful.
David Cooper wrote
> 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.
this is obviously not true. If I recieve a signed message BEFORE the
private key usage period has expired, I KNOW that the signature is time
valid. I dont need a TSA to tell me that. I can read my watch. I can
then add my own time stamp and signature and stick it in my archives, if
I am so concerned about time.
> Without this ability, the relying party can not verify that the
> signature was created before the end of the private key usage period, if
> the signature is being verified after the end of the private key usage
> period. If relying parties can not make use of the information, then
> there is no reason to include it in the certificate.
>
This is a illogical leap that has been taken. Just because there is a
very small time period during which a signer can validly use his private
signing key, but the RP cannot receive it and validate it before the
private key usage period expires, is no reason to state that the RP can
not make use of the information. If 1% (or less) of the time is
unusable, it is no reason to discard 99% of the time (or more) that is
usuable. Anyhow, any good PKI would have replaced the user's signing key
long before the private key usage period had expired.
> Of course, there is no reason that one can not discontinue use of a
> private key before the expiration of the corresponding certificate even
> if there is no indication in the certificate of when use of the private
> key is supposed to end. Is there any reason that the PKI users you
> mention need to include this information in the certificate? 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?
This is a good point, and a work around for not using the private key
usage period. But like all policy, we can not record it in the cert, or
we can record it in the cert. The tendency with X.509 has been to record
as much of the policy as possible and that is automatically checkable in
the cert. So this argues for keeping and using the private key usage
period
David
> Why does the
> private key usage period need to be specified in the certificate (except
> perhaps indirectly by mentioning it in the certificate policy)?
>
> Dave
--
*********************************************************
Leaders of the world's richest nations meet in Cancun on September 10th
2003. Oxfam is presenting them with a petition to make trade fair. Be
sure your voice is heard. Sign the 'Big Noise' petition to make trade
fair at:
http://www.maketradefair.com/go/join/?p=omf1
*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351 Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@xxxxxxxxxxxxx
Home Page: http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************