Subject: RE: Removing expired certificates from CRLs.....

From: "Tom Gindin" <[email-masked]>
Date: Tue, 11 Sep 2001 09:32:53 -0400

While the rules for extensibility do indeed permit the addition of
individual fields without reference to criticality, I am not sure that they
should do so.  This particular case is an extreme one because the component
which would have been added to the definition is not really critical
itself.  Do we need to add guidance to the standard that components should
not be added to critical extensions without changing the OID unless the new
component's meaning is critical to the meaning of the extension whenever it
is present?

          Tom Gindin

Sharon Boeyen <[email-masked]> on 09/10/2001 01:44:56 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   "'Denis Pinkas'" <[email-masked]>, IETF-PKIX
      <[email-masked]>
Subject:  RE: Removing expired certificates from CRLs.....

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:[email-masked]]
> 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 <[email-masked]>@mail.imc.org on 09/10/2001
> 11:02:03 AM
>
> Sent by:  [email-masked]
>
>
> To:   "'Denis Pinkas'" <[email-masked]>, Sharon Boeyen
>       <[email-masked]>
> cc:   IETF-PKIX <[email-masked]>
> 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:[email-masked]]
> > 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:[email-masked]]
> > > > 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
> > > >
> >
>
>
>

---

From: "Hoyt L. Kesterson II" <[email-masked]>
Date: Wed, 12 Sep 2001 11:28:04 -0700

tom, sharon and i just talked about this. i agree that x.509 could 
use some more clarification in this area, in particular, giving 
guidance when a new extension would be recommended. we have put this 
on the list of discussion topics at the flagstaff meeting the week of 
24 march.

we would probably address it as a defect report and draft text for 
pkix to review.

    hoyt