Subject: RE: Why is privateKeyUsagePeriod deprecated?

From: Sharon Boeyen <[email-masked]>
Date: Mon, 21 Jul 2003 14:08:21 -0400

Just want to voice agreement and support for David Chadwick's views on this
:-)

-----Original Message-----
From: David Chadwick [mailto:[email-masked]]
Sent: Monday, July 21, 2003 1:29 PM
To: David A. Cooper
Cc: Peter Gutmann; [email-masked]
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: [email-masked]
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

*****************************************************************

---

From: "Montpetit, Daniel" <[email-masked]>
Date: Mon, 21 Jul 2003 21:44:35 -0400

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:[email-masked]]
Sent: Monday, July 21, 2003 13:29
To: David A. Cooper
Cc: Peter Gutmann; [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?

for
conforming
cert
been

Peter

David Cooper wrote

David

---

From: <[email-masked]>
Date: Tue, 22 Jul 2003 15:09:24 GMT

>Given that this isn't going to change, it would seem that some  
>guidance for 
>users would be useful here.  Since neither (1) nor (2) can be  
>altered, what 
>would be needed is a simple extension, found in signing certs,  
>containing a 
>date to which the cert can still be used for signature-checking  
>beyond the 
>obvious notAfter value.  This could be written up as a short one-page 
>application note, no more (well, a bit more once you add all the usual 
>boilerplate and whatnot). 
>

---

From: <[email-masked]>
Date: Tue, 22 Jul 2003 20:24:56 GMT

Sorry, my latest mail was incomplete.

From my point of view, the PKUP is a strong extension for CA certs.

The certs issued by a CA can be verified during the overall CA cert 
validity time.
The CA extensions will show when it will be necessary to renew the CA 
cert because of the private key, and which is the maximum period of 
validity time for final certs (notAfter field of a final cert will 
never be exceeding notAfter CA)

Kind regards,

Diego.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 24 Jul 2003 02:55:56 +1200

=?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]> writes:

>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.

That would make it a CMS issue, which doesn't seem right.  It's the cert
that's expired, not the CMS signature.  In other words it doesn't matter what
sort of signing attributes you stick in the signature, the problem is that as
far as the cert-checking code is concerned, the cert has expired and is
therefore no longer allowed to be used.

Peter.

---

From: Tom Gindin <[email-masked]>
Date: Wed, 23 Jul 2003 12:58:17 -0400

Peter, I'd codify what they're doing as follows:

    The validity period for a certificate is the period of time from 
notBefore
    through notAfter, inclusive.  When an RP is validating the signature 
on a 
    document which claims to have been signed or produced at a given past 
time,
    the RP SHOULD proceed with the verification of the signature if that 
time
    is within the validity period even though the time of verification is 
outside
    it.  If the RP requires authoritative proof either of the time at 
which the 
    document was signed or of the certificate's not having been revoked, 
it MAY
    reject the signature.

        Note that TSP deals with only one of the two conditions in the 
MAY.

Tom Gindin
I/T Architect - Security
IBM Business Consulting Services - Public Sector
Phone (301) 803-3460

[email-masked] (Peter Gutmann)
Sent by: [email-masked]
07/22/2003 09:32 AM

        To:     [email-masked], [email-masked]
        cc:     [email-masked]
        Subject:        Re: Why is privateKeyUsagePeriod deprecated?

Stephen Kent <[email-masked]> writes:

>I was not an author for 2459 or 3280, but my feeling is that we do not
>recommend use of PKUP for several reasons:

But those are mostly just hypothetical objections.  At the moment we have 
two
inescapabable facts:

1. CAs issue certs based on a 1-year billing cycle, and nothing anyone 
says
   will change that.  No CA will issue a cert with a 20-year lifetime, 
unless
   it's for its own CA certs.

2. Users need to use certs to validate signatures at n times the 
CA-ordained
   lifetime.  In the abscence of any mechanism to do this, they are 
ignoring
   the cert expiry time.  In other words, out of necessity, they're making 
the
   following change to RFC 3280:

    The validity period for a certificate is the period of time from 
notBefore
    through notAfter, inclusive.  When used with signing certificates,
    implementations SHOULD NOT pay any attention to the notAfter date.

Given that this isn't going to change, it would seem that some guidance 
for
users would be useful here.  Since neither (1) nor (2) can be altered, 
what
would be needed is a simple extension, found in signing certs, containing 
a
date to which the cert can still be used for signature-checking beyond the
obvious notAfter value.  This could be written up as a short one-page
application note, no more (well, a bit more once you add all the usual
boilerplate and whatnot).

Now CAs can still decide not to issue certs like that, but (a) they can't
justify it by claiming it screws up their standard cert cycle because it
doesn't affect validTo/validFrom, and (b) users at least have some 
guidance as
to what to do, which is better than the current situation where all they 
can
do is ignore parts of the standard on an ad hoc basis.

Peter.

---

From: <[email-masked]>
Date: Thu, 24 Jul 2003 09:58:45 GMT

>Suppose that the certificate was issued to Bob at Acme Corp.  On 30 
>November2004, Bob was fired because it was discovered that he had been
>misappropriating office supplies.  It is suspected that he has 
>initiated and
>signed a number of EDI transactions in connection with his nefarious 
>scheme.
>

But the private key can't be used beyond on 30 June 2004.
After this time, Bob will have a new cert that will be
revoked.

>My point is this:  from what I can see, usage of the extension really
>doesn't buy you anything.  In order to accurately assess whether the
>transaction was valid at the time of signing, and assess that long 
>after the
>fact, you have to archive so much extra information that I don't see 
>whatpain is caused by the fact that the certificate has expired by 
>then. It's
>not clear to me what if anything you do differently because you have
>information directly tied to the certificate - e.g., it was revoked 
>monthslater. It doesn't save much in the way of processing to have 
>any such
>information directly tied to the certificate, versus tied to some other
>piece of information you had to archive.
>

I think that  

1) The PKUP allows to extent the signature verification by the cert 
period, 
   because the reason of revocation is discovered later and have an 
affect 
   on the validity period of the private key. But:
   1.1) The reason could be discovered after the cert period
   1.2) The gap between the private key notAfter and the cert notAfter 
have
        to be related with the lifetime of the signed document.

2) An end entity cert is a signed document issued by a CA with a 
lifetime.
   It falls on the 1.2. If the CA cert has the PKUP, the end entity 
certs
   issued within the private key CA lifetime would be verified (chain 
and CRL)
   within the validity period of the CA cert.

Kind regards,

Diego Fernandez

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 24 Jul 2003 14:40:15 +0200 (MEST)

I am not sure that a relyaing party can always assume 
that a signing device is not cheating concerning the
key usage period, i.e., to determine whether the
key has be used before the PKUP end. 

The certificate validation procedures do not
imply in any case that a PKUP is checked, and
signature validation procedures are ... where are
they?

IMO, a useful PKUP is for the signing device as
Greg Chodov inidicates to inform the signer at least that

' You signature key is not to be supposed anymore, 
  if you insist signing with it, the relying parties
  may not be able to validate it before expiration of
  the cert. '

Whether the signer device allows to sign anyway or
not is another question. 

Without a PKUP, a nice user agent may indcate in
a global way: 'You cert is going to expire in n days',
but since this information is part of a policy,
the delays may be different, ...

Peter

Digital signatures are for authentication in space, not in time.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 26 Jul 2003 16:39:49 +1200

Stephen Kent <[email-masked]> writes:

>Also, when we have SCVP in place, it make explicit provision for asking the
>"was it valid then" question, which would address this problem.

Right, but as with timestamping the penetration of this is going to be minimal
enough that it won't help most people who need to do long-term signature
verification, which is why the paragraph would provide useful guidance to
those who don't have TSP/SCVP/etc.

Peter.

---

From: Tom Gindin <[email-masked]>
Date: Sat, 26 Jul 2003 21:42:35 -0400

If this is likely to become official, I think the last sentence 
needs more work in order to let RP authors know what they should do, as 
well as what they may.
If the RP requires authoritative proof of the time at which the document 
was signed, it SHOULD reject the signature unless the signature itself is 
referenced by a time-stamped document signed by a certificate which has 
not expired, especially a time stamp created by a TSA (see RFC 3161).  If 
the RP requires authoritative proof of the certificate's not having been 
revoked, it SHOULD NOT consider the absence of an expired certificate from 
a CRL which would otherwise cover it as evidence that the certificate was 
not revoked unless the CRL was issued prior to the expiration of the 
certificate.

                Tom Gindin

Stephen Kent <[email-masked]>
07/25/2003 01:45 PM

        To:     [email-masked] (Peter Gutmann)
        cc:     [email-masked], Tom Gindin/Watson/IBM@IBMUS, 
[email-masked], [email-masked]
        Subject:        Re: Why is privateKeyUsagePeriod deprecated?

At 21:02 +1200 7/25/03, Peter Gutmann wrote:
>Tom Gindin <[email-masked]> writes:
>
notBefore
on a
time,
>   the RP SHOULD proceed with the verification of the signature if that 
time is
>   within the validity period even though the time of verification is 
outside
>   it. If the RP requires authoritative proof either of the time at which 
the
it MAY
>   reject the signature.
>
>That works for me.  Russ, any chance of getting this added to 
bride-of-3280?
>Peter.

Peter,

Also, when we have SCVP in place, it make explicit provision for 
asking the "was it valid then" question, which would address this 
problem.

Steve

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 28 Jul 2003 19:21:00 +1200

"Al Arsenault" <[email-masked]> writes:

>This brings up what is to me an interesting question:  exactly what service
>do you think you're providing with this signature validation long after the
>fact, 

Compliance with legal/contractual requirements.  To given another example of
this, I know of applications where the PKI software reads old stored CRLs off
disk and checks the cert against them before every use because that's what the
standard requires.  It's complete bollocks, they're just going through the
motions for form's sake, but that's what the standard requires, so that's what
they do (the standard doesn't say "You must perform a sensible revocation/
validity check", it just says "You must check certs against a CRL", so that's
what happens, even if it's one issued a month ago, and the cert has already
been checked against it 873 times before).

>and why do you think it's important?

See above.

>I can only think of about three reasons why one would want to do a signature
>validation months after an order was signed:
>
>  - as part of a business audit;
>  - as part of a dispute resolution process (e.g., a non-repudiation issue)
>  - because one's business processes were REALLLLY slow, and it just takes
>    that long to process an order.

You forgot:

  - Because the standard/law/trading agreement says you need to do this in
    order to be compliant.

Peter.

---

From: Tom Gindin <[email-masked]>
Date: Mon, 28 Jul 2003 19:21:14 -0400

Bonny:

        I am afraid that I don't understand your point, at all.  If the 
PKUP is present in the signer's certificate and is inside the validity 
period, the simplest rule for deciding whether the signature time is 
legitimate for that certificate is:
a)      If a time is specified in the signed object, that time must be 
within PKUP and the current time must be within the validity period.
b)      If no time is specified in the signed object, the current time 
must be within PKUP. 

        If the PKUP is not present, retrospective validation requires that 
the rules on validity time be relaxed in roughly the manner I specified in 
my earlier message.  Let me give a simple example:
1       Joe has a credit card which expires on 7/31/2003, with a 
certificate tied to it and expiring on that same date.
2       Joe buys a music CD over the Internet today (7/27), signing the 
order with the key corresponding to the certificate in step 1.
3       The CD reaches Joe on 7/31.
4       Joe dislikes several songs on the album, and decides that he 
shouldn't pay.
5       Joe claims that he didn't order the CD, when his final billing 
statement comes on 8/3.

        Now how does the credit card company get the signature and 
certificate validated on 8/4 or 8/5, or during a court case?  Even if the 
revocation evidence has been preserved in a way similar to sections 
4.4-4.6 of the "technr" draft, including time-stamping, the validation 
needs to be run after the validity period has expired.

        In this instance, using a PKUP whose end date is the expiration 
date of the credit card while putting the certificate validity end date a 
year or more after that would avoid these complexities.  In general, using 
PKUP seems to reduce the need for retrospective validation.  AFAIK, that 
is its main use.

                Tom Gindin

"bonny joy" <[email-masked]>
Sent by: [email-masked]
07/27/2003 08:20 PM

        To:     [email-masked], [email-masked]
        cc:     [email-masked]
        Subject:        RE: Re: Why is privateKeyUsagePeriod deprecated?

Dear Steve

The PKUP does operate as you note, but the cert validity period is still 
present, and in the presence of the PKUP extension, this field is 
reinterpreted to state that after the notAfter date, the cert may no 
longer 
be used to verify any signature, period.  That too is part of the reason 
for 
not encouraging use of PKUP, i.e., the need to reinterpret the cert 
validity 
field.

This is my view

The certificate can be used to verify the signature during the certificate 

validity period irrespective of the PKUP  , for this reason certificate 
validity period should be present

The signature should not be generated after or before  the PKUP, since the 

private key validity period is different from the certificate validity 
period , this field should be present

So why does a certificate processing part should get confused by seeing 
the 
2 fields , those 2 fields are meant for different purposes, First check 
the 
signature has been created at the valid period ,then check the validity of 

the certificate. In the case of NR the validity of the certificate is not 
having any impact ,since the thrust is on PKUP.

Regards Bonny

_________________________________________________________________
They are beautiful. They are in danger. 
http://server1.msn.co.in/Slideshow/BeautyoftheBeast/index.asp Our 
four-legged friends.

---

From: <[email-masked]>
Date: Wed, 30 Jul 2003 08:07:32 GMT

Dean,

Just one thought of mine

>
>Some possible options for consideration:
>1) the first CRL that was published after the
>  expiry date of the client cert being checked

But when a cert is revoked, it is held in the CRL 
until the cert reaches the expiry date.
Maybe it'd be better by the before CRL to the first

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 30 Jul 2003 11:19:22 +0200 (MEST)

> Dean:
> 
> There are many options.  A standard method for CAs to make this information 
> available is very desirable.
> 
> Russ
> 
"Since we now have streets, everybody should use a car." 

"Since we now have a door under video surveillance, you
 need to keep the tapes forever and keep them available
 fot 100 years."

Last year at the ISSE someone said: "Digital signature protect you
in space but not in time." 

IMO the fact that you one has a time parameter as an input for a
certificate validation should not be misunderstood as a 
requirement that all values should be allowed or the
information corresponding to that date need to be available,
e.g. a CRL corresponding to that period. 

Isn't creating a digital signature which is not 
almost immediately presented to some relying or attesting party 
a profound misunderstanding of cryptographic techniques?

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 30 Jul 2003 23:21:08 +1200

Denis Pinkas <[email-masked]> writes:

>CAs do NOT archive CRLs today. They do not need to archive CRLs tomorrow.
>Relying parties (or verifiers) need to capture the CRLs when available (as
>well as the OCSP responses when doing the first validation). Archiving this
>information is then their concern.

Hmm, are you saying that every RP will be required to repeatedly contact the
CA to obtain an arbitrarily large number of arbitrarily large CRLs and store
them for an arbitrarily long amount of time on the off chance that they need
one of them in the future?  Sounds like another one of these PKI-meets-reality
disconnections...

Peter.