Re: Why is privateKeyUsagePeriod deprecated?

[Tom Gindin <tgindin@xxxxxxxxxx>]

        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





pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)
Sent by: owner-ietf-pkix@xxxxxxxxxxxx
07/22/2003 09:32 AM

 
        To:     d.w.chadwick@xxxxxxxxxxxxx, kent@xxxxxxx
        cc:     ietf-pkix@xxxxxxx
        Subject:        Re: Why is privateKeyUsagePeriod deprecated?




Stephen Kent <kent@xxxxxxx> 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.