[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Removing expired certificates from CRLs.....
Sharon,
> Tim, I like this proposal because of its simplicity and given all the
> other variable ways we have to set up CRLs, I suspect this, combined with
> them, gives more than enough flexibility. Does this need to be a new
> extension on its own? It could be, or it could be added as an additional
> parameter to the IDP extension. That might be even simpler - thoughts?
As implictly said in my e-mail from this morning, I am in favour of an
independant extension, so that we do not mandate the use of IDP to have that
additional feature. In other words, if the extension were part of IDP, a
single big CRL could not benefit of that advantage.
Denis
> As for the different groups, if there is going to be a new extension of
> this sort, I'd like it to be added to 509 and profiled by PKIX, if
> possible. If the PKIX groups reaches consensus on what they want quickly
> enough, that input can be submitted on behalf of PKIX to the 509 meeting
> later this month. The timing is very good this time.
>
> Cheers,
> Sharon
>
> > -----Original Message-----
> > From: Tim Polk [mailto:tim.polk@xxxxxxxx]
> > Sent: Friday, September 07, 2001 5:20 PM
> > To: Denis Pinkas; Tom Gindin
> > Cc: IETF-PKIX
> > Subject: Re: Removing expired certificates from CRLs.....
> >
> >
> >
> > Denis, Tom, et al.
> >
> > As one of several independent originators of the idea,
> > (Ambarish Malpani is
> > another), I thought I ought to weigh in as well. I had something
> > *considerably* simpler in mind. If a CRL includes revocation
> > information
> > for certificates that have expired, a relying party should be able to
> > determine that automatically.
> >
> > I would suggest a noncritical CRL extension with a single
> > value of type
> > GeneralizedTime. The ASN.1 syntax would be
> >
> > ExpiredCertsOnCRL ::= GeneralizedTime
> >
> > As usual with PKIX times, we would require time Zulu with
> > seconds (even if
> > zero).
> >
> > The semantics for the extension would be as follows:
> >
> > The scope of a CRL containing this extension is
> > extended to include
> > certificates that expired at the exact time specified in the
> > extension or
> > after that time. If limitations in the CRL's scope are specified (by
> > either reason codes or by distribution points), that applies
> > to expired
> > certificates as well.
> >
> > IMHO, we shouldn't make the scope of a CRL different for expired and
> > unexpired certificates. This is a simple idea - let's keep
> > it that way!
> >
> > BTW, folks were wondering why this hasn't been pursued in
> > PKIX. This idea
> > has been floated a couple of times, but no one was really ready to
> > implement it. We needed to concentrate on the core functionality. I
> > floated the idea again at one of the meetings (in San Diego?)
> > and Ambarish
> > said he'd had the same idea and wanted to pursue it. I asked
> > him to delay
> > any new work in this area until the son-of-2459 is approved by the
> > IESG. (Neither of us realized what a long delay we'd agreed to...)
> >
> > Thanks,
> >
> > Tim Polk
> >