Re: Removing expired certificates from CRLs.....

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Sharon,

> Denis, sorry for the display problem - I cut and pasted the text
> from the actual TC - next time I'll try to remember not to do that :-)
 
> Actually, I'm second-guessing the value of the extension. I think it is
> generally the case that good key management would have the signing key
> rolled over long before the expiry date of the verification certificate 
> so hopefully the chances of a signature being applied "just" before a
> certificate expired would be slim/none. 

It is true that I get my next (Visa) credit card (valid two years) 
one month in advance, but nothing prevents me to use it, until the very 
last day of its validity period.

> If that is true, then original validation would be happening before 
> the certificate expired. If the RP needs to be able to argue
> that the signature was good at that time, it shouldn't be relying 
> on a future CRL at the time they need to do that defence because
> there may not be one available, regardless of whether it contains 
> this extension or not (CAs go out of business, their policy of CRL 
> issuance may have changed etc). If the RP needs to be able to defend 
> the validation, it would need to retain the evidence from the time 
> of original validation, including a timestamped copy of the signed 
> document, CRL that was valid at the time of verification etc.

If the CRL includes the information, then it is usable, otherwise it is not.
When a CA goes out of business, it should have previously taken provisions
to transmit the task of providing certificate status information to another
authority. As an example ETSI TS 101 456 states:

"The CA shall have an arrangement to cover the costs to fulfil these minimum
requirements in case the CA becomes bankrupt or for other reasons is unable
to cover the costs by itself.

c) The CA shall state in its practices the provisions made for termination
of service. This shall include:
 
 - notification of affected entities,
 - transferring the CA obligations to other parties,
 - how the revocation status of unexpired certificates that have been issued
   will be handled."

Denis
 
> Sharon
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> > Sent: Thursday, September 06, 2001 10:12 AM
> > To: Sharon Boeyen
> > Cc: 'David A. Cooper'; IETF-PKIX; Hoyt Kesterson (E-mail)
> > Subject: Re: Removing expired certificates from CRLs.....
> >
> >
> >
> > Hi Sharon,
> >
> > Glad to see back on the PKIX mailing list for a short while. :-)
> >
> > > David I do remember some discussion of a new extension but
> > > don't recall the reason why it wasn't pursued - do you remember?
> >
> > > With the 509 meeting coming up in just a couple of weeks,
> > > if we reach consensus that it would be useful to add either
> > > a new extension or a new component to the IDP extension to indicate
> > > that a CRL includes revocation notices for expired certs,
> > > we could probably add it to the 509 WD at that meeting.
> >
> > At this time it is more an X.509 discussion, rather than a
> > PKIX discussion.
> > Anyway, I would support in principle the idea for X.509.
> >
> > The information could be placed either in the certificate or
> > in the CRL.
> > Placing it in the CRL has the advantage of not overloading
> > the certificate,
> > so this solution should be better. So, if the information is
> > placed in the
> > CRL, then the CRL should say something like: certificates
> > which have the
> > keyUsage bits set to XXXX are maintained on the CRL Y weeks after they
> > expire.
> >
> > One of the main benefits is the following: you receive an
> > e-mail while on
> > holidays. The signature was done just before the certificate
> > expired, but
> > the e-amil was opened after it expired. With this additional
> > feature it
> > would be possible to know by fetching the current CRL whether
> > the e-mail was
> > signed legitimately.
> >
> > > I believe there is value in allowing expired certs to remain
> > > on CRLs, but certainly it should be an optional feature as
> > > it is not needed in all environments.
> >
> > True.
> >
> > Regards,
> >
> > Denis
> >
> > > Cheers,
> > > Sharon
> >
> >
> > BTW: my Netscape 4.7 browser is unable to display your
> > message correctly.
> > Next time, please use plaintext.
> >