Subject: RE: Why is privateKeyUsagePeriod deprecated?

From: Tom Gindin <[email-masked]>
Date: Wed, 30 Jul 2003 11:37:04 -0400

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 Scotson" <[email-masked]>
Date: Thu, 31 Jul 2003 10:31:16 +0100

Hi all,

New to the discussion, but if the objective is to retrospectively verify
that a certificate was not revoked during its validity period (and having
since expired it will not be in the latest CRL created), then surely only
the last CRL issued during the validity period would need to be referenced
?. 

i.e. (and this does NOT take into account any CA products current abilities)
if I want to check that a certificate was still 'valid' up-to its 'notAfter'
date I do not need to know the date, I just send the certificate (or S/N) to
the CA as

 https://www.publicCA.com/status?certificate='serialNumber'

By return I would be given the last CRL that this certificate would have
been listed as revoked in, if in fact it was revoked during its validity
period. (Of course, there is still a window between the last CRL and
expiration of a certificate where I could revoke a certificate, but then we
are talking CRL's here and not real-time status. And I am also assuming the
CA is a good boy and retained records of certificates it has issued...).

This discussion appears to revolve around the question "This certificate has
now expired, but was it ever revoked?, and can I assume therefore that it
was valid at the time of the transaction I am now retrospectively
verifying". This seems to imply that:

A) I did not check the status at the time of transaction (bad), or
B) I have designed a system where I need real-time status but I have not
implemented real-time status (also bad).

I do not see the direct connection with PKUP, which is where the discussion
first began?. My point of view is that a certificate is something you have
whereby you can electronically 'sign/authenticate' something. This is a
facility that you (currently) have to pay for. This is Authentication.
Authorisation is up to the RP to decide, based on whatever information they
feel necessary. If the RP decides to accept an expired certificate so-be-it.
PKUP would make no difference.

Dean.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: 30 July 2003 16:37
To: Dean Adams
Cc: [email-masked]
Subject: RE: Why is privateKeyUsagePeriod deprecated?

        Dean:

                Tom Gindin

        To:     <[email-masked]>
        cc: 

Russ,

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:

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:

> >I was not an author for 2459 or 3280, but my feeling is that we do 
> >not recommend use of PKUP for several reasons:
>
two
says
unless
CA-ordained
ignoring
for
what
a
the
>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
can

---

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

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