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

From: Sharon Boeyen <[email-masked]>
Date: Mon, 10 Sep 2001 13:44:56 -0400

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: "Michael Myers" <[email-masked]>
Date: Mon, 10 Sep 2001 14:27:37 -0700

All,

I think a unique extension creates the least impact.

More broadly though, what's really bothering me is my sense that we're
backing into the notion of a 1-1 between CRLs and online status mechanisms.

Assume an environment that both publishes CRLs and offers OCSP-based
services against the same set of certificates.  What if:

a) The CA receives a revocation request at T1;

b) A database state variable is flipped at T1+N;

c) An OCSP request is received at T1+N+M;

d) An OCSP response is transmitted at T1+N+M+K;

e) Yet the next CRL cycle won't run (i.e. the cron
   job won't fire) until T1+X where X >> (N+M+K).

Thus relying parties are enabled to pick and choose between CRLs or OCSP
depending on how it might benefit their argument for remedy under digital
signature laws.

Thoughts, anyone?

Mike

Michael Myers
t: +415.819.1362
e: mailto:[email-masked]
w: http://www.traceroutesecurity.com g

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 12 Sep 2001 09:34:39 +0200

> depending on how it might benefit their argument for remedy under digital

Some validation policies, like Signature policies are able to say whether
CRLs or OCSP responses shall be used.

As an example see: draft-ietf-smime-espolicies-01.txt

EnuRevReq  ::= ENUMERATED {
	clrCheck	(0), 
                   --Checks must be made against current CRLs
		   -- (or authority revocation lists (ARL))
	ocspCheck	(1), -- The revocation status must be checked
                  -- using the Online Certificate Status Protocol 
                  -- (OCSP),RFC 2450.
	bothCheck	(2),	
                  -- Both CRL and OCSP checks must be carried out
	eitherCheck	(3),	
                  -- At least one of CRL or OCSP checks must be
                  -- carried out
	noCheck		(4),	
                  -- no check is mandated
	other		(5)		
                  -- Other mechanism as defined by signature policy 
                  -- extension
	  }

If either CRL (i.e.clrCheck) or OCSP (i.e. ocspCheck) is mandated, then
there is no conflict between the two mechanisms.

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 12 Sep 2001 10:30:59 -0700

Denis,

What are your thoughts on the timeliness characteristic between OCSP and
CRLs?

Mike

Michael Myers
t: +415.819.1362
e: mailto:[email-masked]
w: http://www.traceroutesecurity.com

> Sent: Wednesday, September 12, 2001 12:35 AM
> To: Michael Myers
> Cc: IETF-PKIX

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 13 Sep 2001 10:30:38 +0200

Michael,

> What are your thoughts on the timeliness characteristic between OCSP and

Well ...

I must admit that the definition of the archive cutofff (section 4.4.4) from
RFC 2560 has always been very strange for me, since it defines a time
interval rather then an absolute time. I read several times the text and
could not figure out how in practice it would be used.

The text talks about a retention interval without saying explictly to which
event it is relative to.

Is it the time interval beyond the notAfter date from a certificate ? 
The text does not say so.

In addition, the text is talking, as an example, of a retention interval of
7 years (!) whereas in the context of that thread we are only talking of
about a month.

If I had to define from scratch the extension I would simply define an
absolute date (e.g. called ExtendedRevocationInformationDate, quite a
long name, but explicit) that could directly override the notAfter field
from the Validity field of a certificate. This would mean that this
extension allows to know until when the revocation information is
maintained. It is not directly related to the produceAt time. The only
condition is that, when it is present, it is always later than produceAt.

This is a problem because, if I understand correctly RC 2560, we have the
following equation:

ArchiveCutoff = producedAt - retention interval.

I do not see a clear relationship between these two concepts. 

Unless you see one, it would mean that an extension different from
ArchiveCutoff would be necessary for OCSP responses so that we can have
identical concepts for CRLs and OCSP responses.

Thanks for raising the question.

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 13 Sep 2001 11:25:44 -0700

Denis,

Thank you for your consideration of historic aspect of digital signatures.
I'm sure more work remains to be done in this area.  I for one however
remain more concerned of our broad assumptions regarding the use of periodic
CRLs as the basis for aperiodic OCSP-based services that deliver on-demand
class timeliness.  Several systems-level issues are under-explored in this
context.  Within closed environments there might exist data exchange
mechanisms that are fully responsive to the security requirements CRLs
satisfy but do so in a means that enables not only the timely inter-domain
exchange of revocation status, but validation status as well.

Mike

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Thursday, September 13, 2001 1:31 AM
> To: Michael Myers
> Cc: IETF-PKIX

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 13 Sep 2001 15:53:03 -0400

Mike,

To understand the broad assumptions more clearly, can you clarify the
distinction you see between "periodic" information and "on-demand class
timeliness" information?

An RFC 2560 OCSP response contains a "producedAt" field.  Is there any
specific time beyond which a consumer should consider an OCSP response
produced at a certain time to be stale or potentially replayed?

1. If not, what prevents the consumer from relying on out-of-date
"on-demand class" information?  Why would that prevention mechanism
not be equally applicable to CRLs that were produced immediately upon
each update to the revocation database?

2. If there is a specific timeliness requirement, why would periodic
CRLs generated more frequently than the requirement not be considered
to have "on-demand class timeliness"?

In other words, there are three possible signing strategies:
timer based (periodic), revocation event based, and query based.
There are two response data structures: CRL and OCSP.
Each of the two data structures can be generated using each of
the three signing strategies.

If you have some particular system-level issues, they would seem
to be more related to the choice of signing strategy than
the choice of data structure.  For any meaning of "on-demand", and
for every choice of partition size (number of in-scope certificates
per response), a CRL can be as timely as, and is definitely much
smaller than, the equivalent OCSP request and response.  What issues
do you see that could not be solved most efficiently by using CRLs
in a manner different from the traditional infrequent-update,
big-partition mode?

Dave