Subject: RE: Why is privateKeyUsagePeriod deprecated?

From: Tom Gindin <[email-masked]>
Date: Fri, 1 Aug 2003 07:26:13 -0400

Dean:

        It doesn't seem that the IESG really wants us to define a protocol 
for this.  My assumption was that while a "FullHistoryCRL" in your sense 
is not normally maintained and expensive either to create or download, 
there is such a thing as a past CRL which would merely need to be 
archived.  Any client application doing historic verification and 
retrieving CRL's would need a lot of new code anyway, since no standard 
for that exists.  I think the date is a better filter for the retrieval of 
a past CRL than the certificate.
        The X.509 standard does require that CA's supporting an NR service 
archive CRL's, presumably for historic verification if needed (see note 2 
of X.509v4 section 7.3 or of X.509v3 section 11.2).  However, there is no 
protocol or standard technique for retrieving those CRL's.
        OCSP RP's may need to do archiving in any case for evidence 
preservation.  I don't see how a historic OCSP query would work except off 
a CRL.

                Tom Gindin

"Dean Adams" <[email-masked]>
07/31/2003 06:42 AM

        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     <[email-masked]>
        Subject:        RE: Why is privateKeyUsagePeriod deprecated?

Tom,
                 Apologies for my delayed response - unfortunately I am 
working on multiple
PKI deployments and only have limited opportunity to keep up with these
emails.

I appreciate your comments, but I think that I didn't explain myself 
clearly
enough.  The "FullHistory CRL" suggestion listed as being a (2) style of
approach was meant to contain all certs that have ever been revoked under 
a
particular CA cert.  Therefore, no parameters would be necessary - you 
would
be guaranteed to be able to establish if a particular client cert had ever
been revoked, and when.  Not sure if this suggestion is a winner, since 
for
very large and long term deployments, this CRL could be very large.  On 
the
other hand, only RPs that are verifying signatures on docs or transactions
after the cert has expired, would need to pull this down.  It would never 
be
needed for authentication activities, or for the period when the cert is
still valid.

Your discussion of parameters being supplied is probably a better approach
from a network performance perpective, since it provides a way for the RP
client application to be able to specify more tightly what revocation
information it is interested in, by perhaps supplying a date as a 
parameter
(as you suggest), or by presenting the client cert being verified and
letting the CA determine (by whatever means it decides to use) if the cert
had been revoked and when - then communicating that info back to the RP.
This is the tyoe of approach I meant to hint at in the list item (1).

Unfortunately, any work in this area would seem to require a change to
client applications.

If we want PKI to be able to service the signing and long term 
verification
of documents and transactions, we need some way of allowing an RP to be 
able
to get certificate status information, for a long time after the 
certificate
expired.  I cannot agree with Denis that it is the obligation of each RP 
to
archive such material for possible future use.  This is not user friendly,
and is in any case impractical for the vast majority of simple 
consumer-type
users who may be required to verify signatures over an extended period and
who (even if they did archive CRLs) may not be able to so if they somehow
lose the archived CRL (unless we also wanted to impose disaster revovery
requiremts on each simple consumer-type user).  Lets remeber that the I in
PKI is infrastructure - make provide the services that people need to be
able to carry on their normal lives without becoming computer wizards.

                 Regards
                 Dean

>         Dean:
>
>         I don't see how a full history CRL location would work without a
> parameter for the effective date.  FreshestCRL doesn't need such a
> parameter.  If we assumed that we want an "archivedCRL" accessMethod in
> AIA, how would the accessLocation represent the effective date 
parameter?
> I assume that it's appropriate for such an accessMethod to use HTTP or
> HTTPS.
>         An example of the URL for the actual query (for about now) would
> be:
>         https://www.publicCA.com/archivedCRL?date=200307301530Z
>         An RP actually using this feature would be able to construct the
> query by substituting the effective time into the URL.  I also would ask
> if we need variants of this for "last CRL not later than" and "first CRL
> not before".
>
>                 Tom Gindin
>
>
>
>
>
> "Dean Adams" <[email-masked]>
> Sent by: [email-masked]
> 07/29/2003 04:37 PM
>
>
>         To:     <[email-masked]>
>         cc:
>         Subject:        RE: Why is privateKeyUsagePeriod deprecated?
>
>
>
>
> 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:
>
> 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
>
> At 01:32 AM 7/23/2003 +1200, Peter Gutmann wrote:
>
> >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: "Dean Adams" <[email-masked]>
Date: Fri, 1 Aug 2003 16:34:21 +0100

Hi Tom,
	I agree with all that you say.  I suppose that given the IESG position as
reported by Steve, then any further discussion on this topic would perhaps
be fruitless.

	Dean

> [mailto:[email-masked]]On Behalf Of Tom Gindin
> Sent: 01 August 2003 12:26
> To: Dean Adams
> Cc: [email-masked]