Subject: Re: Why is privateKeyUsagePeriod deprecated?

From: [email-masked] (Peter Gutmann)
Date: Wed, 23 Jul 2003 01:32:33 +1200

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: Russ Housley <[email-masked]>
Date: Tue, 29 Jul 2003 11:56:11 -0400

Peter:

On one hand I agree, but on another I do not.

I agree that signatures need to be validated after the certificate expires.

The algorithm in RFC 3280 allows the certificate to be validate with 
respect to a date other than today.  The date that ought to be input 
requires a trusted time that the signature was applied.  Of course, PKIX 
has developed a protocol to provide such a time stamp.

An archive of the revocation information is not routinely offered by 
CAs.  How do we make that happen?

Russ

---

From: "Dean Adams" <[email-masked]>
Date: Tue, 29 Jul 2003 21:37:02 +0100

Russ,
	Surely, merely finding some way to ensure that a CA archives CRLs is not
enough.  Some way has to be provided to allow client applications to
discover where the appropriate CRL to be checked, can be found.

Some possible options for consideration:
1) the first CRL that was published after the
   expiry date of the client cert being checked
2) the location of a fully maintained complete CRL
   containing all history with regard to revoked certs
   that were issued from a particular CA certificate

I'm sure there are other options too, but in any case some means of
communicating this info to the client application needs to be defined.
Perhaps some certificate extension similar to "Freshest CRL" that instead
denotes "FullHistory CRL" would be appropriate?  That (or something in
Authority Info Access) might provide a solution for (2).  Not sure how you
might go about providing a solution for a (1) type of approach, without
getting overly complicated.

Dean Adams

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Russ Housley
Sent: 29 July 2003 16:56
To: [email-masked]
Cc: [email-masked]
Subject: Re: Why is privateKeyUsagePeriod deprecated?

Peter:

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Jul 2003 19:56:50 -0400

Dean:

There are many options.  A standard method for CAs to make this information 
available is very desirable.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 30 Jul 2003 10:02:24 +0200

Russ and Dean,

> Dean:
> 
> There are many options.  A standard method for CAs to make this 
> information available is very desirable.

No new extension is necessary, nor desirable.

>> Surely, merely finding some way to ensure that a CA archives 
>> CRLs is not enough.  Some way has to be provided to allow client
 >> applications to discover where the appropriate CRL to be checked,
 >> can be found.

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.

Denis

>> Authority Info Access) might provide a solution for (2).  Not sure how 
>> you might go about providing a solution for a (1) type of approach, 
 >> without getting overly complicated.
>>
>> Dean Adams
>>
>> >But those are mostly just hypothetical objections.  At the moment we 
>> have
>> two
>> >inescapabable facts:
>> >
>> >doesn't affect validTo/validFrom, and (b) users at least have some 
>> guidance
>> as

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Jul 2003 09:45:10 -0400

At 10:02 +0200 7/30/03, Denis Pinkas wrote:
>>>Surely, merely finding some way to ensure that a CA archives CRLs 
>>>is not enough.  Some way has to be provided to allow client
>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.
>
>Denis

I think a better characterization here is that CAs are not required 
to archive CRLs based on X.509 or PKIX standards. Various national or 
(in the U.S.) state laws relating to digital signatures may impose 
this requirement, or an organization operating a CA may choose to 
archive CRLs.  The statement you made is just a bit too strong to be 
correct :-)

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 31 Jul 2003 09:30:09 +0200

Steve,

(...)

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

> I think a better characterization here is that CAs are not required to 
> archive CRLs based on X.509 or PKIX standards. Various national or (in 
> the U.S.) state laws relating to digital signatures may impose this 
> requirement, or an organization operating a CA may choose to archive 
> CRLs.  The statement you made is just a bit too strong to be correct :-)

We are both incorrect. :-)

CAs usually archive CRLs in order to prove that they behaved correctly in 
case of an audit or in case of a dispute with relying parties. They may use 
the archives to demonstrate that they behaved correctly.

They are not required to provide an on-line service to these archives, which 
are very seldomly used. For that reason, we are not going to define a 
protocol to access that archived information.

Denis

---

From: "Dean Adams" <[email-masked]>
Date: Thu, 31 Jul 2003 12:12:16 +0100

Hi Denis,
> the archives to demonstrate that they behaved correctly.

So let me get this straight - The primary use of long term aaccess to
historical certificate status information is to protect the CA, not to
protect an RP ? ;-)
Some of us are also trying to provide a service to users that they actually
find useful and helpful.  I don't like to be put in the position of
effectively telling users "Look - we told you back in the year XXXX that
this certificate was revoked - you should have remembered" ;-)

> protocol to access that archived information.

H'mm - not required - please excuse my ignorance of how such things come
about. How do we decide on what is and what is not required?  Do we have any
market requirements input to the PKIX process?  How was it decided that
warranty extensions, permanent identifiers, logotypes for instance - were a
requirement - yet providing assistance in the long term verification of
signatures - was not.  I'm not being critical of these other efforts - I'm
genuinely curious.

	Regards
	Dean

---

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Jul 2003 09:53:56 -0400

At 9:30 +0200 7/31/03, Denis Pinkas wrote:
>>to archive CRLs based on X.509 or PKIX standards. Various national 
>>or (in the U.S.) state laws relating to digital signatures may 
>>impose this requirement, or an organization operating a CA may 
>>choose to archive CRLs.  The statement you made is just a bit too 
>>strong to be correct :-)
>
>CAs usually archive CRLs in order to prove that they behaved 
>correctly in case of an audit or in case of a dispute with relying 
>parties. They may use the archives to demonstrate that they behaved 
>correctly.
>
>They are not required to provide an on-line service to these 
>archives, which are very seldomly used. For that reason, we are not 
>going to define a protocol to access that archived information.
>
>Denis
>
>>Steve

I think we are now mostly in agreement.  Whether a WG defines a 
protocol for access to these archived CRLs is probably beyond the 
scope of PKIX's charter, given the IESG's desire for us to wrap up 
our current work items, so someone else will get to decide whether 
they want to pursue the matter.

Steve