Regardless of criticality, the rules for extensibility allow additional components
to be added to existing extensions without changing the OIDs. However, I hadn't
considered the criticality issue and in fact the IDP extension can only be set to
critical, so that probably makes it not the most desirable place to add this. A new
extension is probably a better way to go. Thanks for bringing up the criticality issue.
Sharon
> -----Original Message-----
> From: Tom Gindin [mailto:tgindin@xxxxxxxxxx]
> Sent: Monday, September 10, 2001 12:25 PM
> To: Sharon Boeyen
> Cc: 'Denis Pinkas'; IETF-PKIX
> Subject: RE: Removing expired certificates from CRLs.....
>
>
>
>
> Sharon:
>
> Like Denis, I'm in favor of a separate extension,
> especially since I
> think that excluding revocations of encryption certificates
> from retention
> is a good idea. Using the IDP makes it very advisable that
> the syntax be
> trimmed. Also, since the IDP is recommended to be critical
> by both X.509
> and PKIX, wouldn't we have to reassign its OID if we're
> adding fields to
> the syntax, even in a way that is backwards compatible? If
> so, that would
> more than neutralize any advantage to be gained by reusing a
> well-known
> extension.
>
> Tom Gindin
>
>
> Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx>@mail.imc.org on 09/10/2001
> 11:02:03 AM
>
> Sent by: owner-ietf-pkix@xxxxxxxxxxxx
>
>
> To: "'Denis Pinkas'" <Denis.Pinkas@xxxxxxxx>, Sharon Boeyen
> <sharon.boeyen@xxxxxxxxxxx>
> cc: IETF-PKIX <ietf-pkix@xxxxxxx>
> Subject: RE: Removing expired certificates from CRLs.....
>
>
> 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
> > > >
> >
>
>
>