Denis, I'm not necessarily recommending one approach over the other, just raising the
options for discussion. However, I do want to note that IDP can, but obviously need not, be included in a "single big" CRL just as it can be in a CRL DP. The only current component that would be likely be present in such a CRL would be the name if the IDP.
Cheers,
Sharon
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> Sent: Monday, September 10, 2001 10:19 AM
> To: Sharon Boeyen
> Cc: IETF-PKIX
> Subject: 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
> > >
>