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

From: Antonio Lioy <[email-masked]>
Date: Wed, 05 Sep 2001 13:48:09 +0200

Nada Kapidzic Cicovic wrote:
>
> Ryan,
>
> Some years ago we at Entegrity also had similar discussion. We were
> positive CRLs were not to contain the information about the expired
> certificates, until we came across some industry CA CRLs containing
> information about all revoked certificates. We then looked into 2459
> (draft in those days) and X.509 text and came to the conclusion that
> deleting info about expired certificates from a CRL is only an option.
>
> I am not sure what was the intention of the original authors of X.509
> (perhaps Sharon and Hoyt know more about it), but the current industry
> practice seems to be a mixture of both approaches.
>
> My personal opinion is that keeping all revoked certificates info in
> CRLs brings more problems than benefits. However, it is questionable
> whether PKIX needs to take a vote for one approach or the other.
>
> In any case I would suggest that the text of 2459 be modified so that
> it has a MAY (or a MUST) consistently in all places where deleting
> expired certificates revocation info from CRLs is mentioned. The
> current text only brings confusion, as you have already pointed out.

I vote for MAY (rather than MUST) because it is largely a matter of the
CA: if there are few revoked certificates, there is no benefit in
deleting them from the CRL once they expire, but - on the countrary - if
they are deleted, this can cause problems to applications.
For example, let us suppose that I receive today a document signed two
years ago with a cert currently expired, and I want to check the
revokation status of the related certificates at the signature time.
If I retrieve the current CRL, it might not contain the cert (if it was
revoked) due to the CA policy of deleting from the CRL the expired
certificates.
So, how can I retrieve the first CRL issued after signature time? it
seems to me that there is no provision for such a request in neither
OCSP nor CMP, so many CAs do not delete expired certs from CRLs to avoid
this problem. Therefore, I think that PKIX should permit this kind of
behaviour and not force CA into a mode of operation that can cause
application problems.

Just my 2c.

Antonio Lioy

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 05 Sep 2001 11:38:28 -0600

Ryan,

If you (the relying party) trust that the CA will be around for that long, and that the CRL records will be available if and when you need them, even if for a reasonable fee, then you can trust either the CA or some kind of a trusted repository to provide this function. Or if you are a true paranoid, you can archive them yourself, along with the document in question, together with all of the necessary timestamps and other corroborating evidence.

In either case, the primary reason for having a certificate validity period in the first place was to avoid an ever-increasing CRL list.  The other factors, including a sunset-clause type of renewal requirement in lieu of active status monitoring by the CA, and the concomitant opportunity for an ongoing yearly revenue stream, were nice to have also.

So there is no reason why expired CRLs can't be removed one publication cycle after the certificate has expired, and they should.  But they can't be removed immediately, because they might have been revoked one microsecond prior to expiration, and before the next scheduled CRL has been published.

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software

>>> "Flynn, Michael" <[email-masked]> 09/05/01 11:02AM >>>
Ryan,
 
Ryan wrote::
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
 
At least regarding removing expired certs from CRLs, I would think that
non-repudiation can be satisfied by keeping the old CRLs in back up storage
for some length of time.  That time being how far back in time a contract
dispute might go; ten years, twenty?   So long as you could get them off
tape for the lawyers to look at the legal process would be satisfied, they
don't need to be online forever.  
 
Michael
 
-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Tuesday, September 04, 2001 8:50 PM
To: IETF-PKIX
Subject: Removing expired certificates from CRLs.....

I was speaking with Peter Williams today about the removal of expired
certificates from CRLs; I have always been under the belief that this
behavior was optional, I vaguely remembered reading text in 2459 along those
lines; additionally I know of several commercial CAs that do not remove the
expired certificates from their CRLs. Peter on the other hand was under the
impression that it was a mandate to remove CRLs; he too remembered reading
text in 2459 to support is position.
 
So we each pulled out the RFC and found that we were both right!
Specifically both sections 3.3 and 8.6.2.2 have text on this subject:
 
3.3  Revocation
When a certificate is issued, it is expected to be in use for its entire
validity period.  However, various circumstances may cause a certificate to
become invalid prior to the expiration of the validity period.
 
...
 
An entry is added to the CRL as part of the next update following
notification of revocation. An entry may be removed from the CRL after
appearing on one regularly scheduled CRL issued beyond the revoked
certificate's validity period.

8.6.2.2 Issuing distribution point extension
This CRL extension field identifies the CRL distribution point for this
particular CRL, and indicates if the CRL is limited to revocations for
end-entity certificates only, for authority certificates only, or for a
limited set of reasons only. The CRL is signed by the CRL issuer's key- CRL
distribution points do not have their own key pairs. However, for a CRL
distributed via the Directory, the CRL is stored in the entry of the CRL
distribution point, which may not be the directory entry of the CRL issuer.
If this field is absent, the CRL shall contain entries for all revoked
unexpired certificates issued by the CRL issuer.
 
...
 
The distributionPoint component contains the name of the distribution point
in one or more name forms. If this field is absent, the CRL shall contain
entries for all revoked certificates issued by the CRL issuer. After a
certificate appears on a CRL, it is deleted from a subsequent CRL after the
certificate's expiry.

Although section 8.6.2.2 is specifically in regards to CRLdps, any
difference between full CRLs and CRLdps in this case I feel would be an
arbitrary one. 
 
Now logically it makes sense to remove certificates that are expired from
CRLs to control size, yes this has a negative point specifically it prevents
CRLs from being used as a non-repudiation source; but this is mute due to
many other issues.
 
That being the case I think; and I believe Peter would agree the correct
thing to do is to remove these expired/revoked entries from the CRL. 
 
The question now is what is the PKIX stance on this matter?
 
Ryan M. Hurst
ValiCert, Inc.
 
"It may roundly be asserted that human ingenuity cannot concoct a cipher
which human ingenuity cannot resolve."
-Edgar Allan Poe

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 05 Sep 2001 11:53:08 -0700

Apologies --

	Looks like I jumped to an assumption in regards to the origin of the
8.6.2.2 text I quoted, apparently it did not come from 2459; instead it came
from x509 v4. That being the case I guess that 2549 is not inconsistent as I
originally stated.

That being said shouldn't these two sources be consistent?

Ryan

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2001 6:22 AM
To: Nada Kapidzic Cicovic
Cc: Ryan Hurst; IETF-PKIX
Subject: Re: Removing expired certificates from CRLs.....

Nada,

Which text are using using ? In son-of-RC2459 there is no section 8.6.2.2.
as you indicate.

Please be more specific on the exact sentence that you think is not
appropriate in son-of-RC2459 and which exact change you would like to be
done.

Denis

> >Nada and Ryan,
> >At the very beginning, when ISO started the work, non-repudiation was not
> >considered, but only authentication and data origin authentication.
> >
CRLs
> > > brings more problems than benefits. However, it is questionable
whether
> > > PKIX needs to take a vote for one approach or the other.
> > >
it
> > > has a MAY (or a MUST) consistently in all places where deleting
expired
> > > certificates revocation info from CRLs is mentioned. The current text
only
> > > brings confusion, as you have already pointed out.
> >
> >In all the sentences that have been extracted below, I could not find a
> >place where a change would be necessary. So I believe that the current
text
> >is OK : it tells how long revoked certificates MUST be kept in a CRL but
> >does not forbid to maintain them longer. I agree that maintaining them
too
> 
> The text in 8.6.2.2 does not mention the possibility of leaving the
expired
> certificates identifiers in CRL. The last extracted sentence is very
> explicit in requiring removal of revocation info for expired certificates.
> 
> >long would be a problem because of the increasing size of the CRL, hence
why
> >CRL information should be captured when still available, in case a
> >non-repudiation service is supported.
> 
> I could not agree more. Perhaps DPV/DPD work could include such
guidelines.
> 
> >We could add is a recommendation like: "Certificates identifiers
> >for certificates that contain the NR bit in the KeyUsage extension field
> >SHOULD be maintained in a CRL a few days or weeks after they have
expired."
> >
> >However, it seems rather late to add such a sentence, since we passed
IETF
> >last call. I leave the issue to the editors ...
> 
> You are right. Since the document has already progressed this far, it may
> not be worth making additional modifications.
> 
> Nada
> 
> >Denis
> >
> >
> > > Nada
> > >
> > > At 08:49 PM 9/4/01 -0700, Ryan Hurst wrote:
> > >
> > > > behavior was optional, I vaguely remembered reading text in 2459
along
> > > > those lines; additionally I know of several commercial CAs that do
not
> > > > remove the expired certificates from their CRLs. Peter on the other
hand
> > > > was under the impression that it was a mandate to remove CRLs; he
too
> > > > remembered reading text in 2459 to support is position.
> > > >
> > > >
> > > >
> > > > validity period.  However, various circumstances may cause a
certificate
> > > > to become invalid prior to the expiration of the validity period.
> > > >
> > > >
> > > >
> > > > ....
> > > >
> > > >
> > > >
> > > > limited set of reasons only. The CRL is signed by the CRL issuer's
key-
> > > > CRL distribution points do not have their own key pairs. However,
for a
> > > > CRL distributed via the Directory, the CRL is stored in the entry of
the
> > > > CRL distribution point, which may not be the directory entry of the
CRL
> > > > issuer. If this field is absent, the CRL shall contain entries for
all
> > > > revoked unexpired certificates issued by the CRL issuer.
> > > >
> > > >
> > > >
> > > > ....
> > > >
> > > >
> > > >
> > > > The distributionPoint component contains the name of the
distribution
> > > > point in one or more name forms. If this field is absent, the CRL
shall
> > > > contain entries for all revoked certificates issued by the CRL
issuer.
> > > > After a certificate appears on a CRL, it is deleted from a
subsequent
> > > > CRL after the certificate's expiry.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Now logically it makes sense to remove certificates that are expired
> > > > from CRLs to control size, yes this has a negative point
specifically it
> > > > prevents CRLs from being used as a non-repudiation source; but this
is
> > > > mute due to many other issues.
> > > >
> > > >
> > > >
> > > >      "It may roundly be asserted that human ingenuity cannot concoct
a
> > > >      cipher which human ingenuity cannot resolve."
> > > >      -Edgar Allan Poe
> > > >
> > > >

---

From: "Flynn, Michael" <[email-masked]>
Date: Wed, 5 Sep 2001 12:12:26 -0700

Ryan,
You wrote, "However CRL validity windows commonly overlap; so determining
how would some one know (without CRLNumbers which most CAs do not include
yet) if they had them all?"
 
That is a good point.
 
Michael
 
-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]]
Sent: Wednesday, September 05, 2001 12:02 PM
To: 'Flynn, Michael'; Ryan Hurst; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....

Michael -
            In regards to storing all generated CRLs for n period of time to
address the non-repudiation issues; yes this would deal with the problem.
However CRL validity windows commonly overlap; so determining how would some
one know (without CRLNumbers which most CAs do not include yet) if they had
them all? Additionally the process of looking at ALL CRLs and determining
which one is the "most recent" match would be an expensive one.
 
For these reasons it would be "nice" if CRLs were only used by servers and
contained all revoked certificates; but this means that clients would not
want to use CRLs due to the expense associated with acquiring the recent
CRL.
 
I believe the overall goal of CRLs was not to deal with NR, but to instead
have a simple mechanism to distribute bulk "current" revocation information
to the broadest set of clients. For this reason; I think its best to remove
the expired certificates and deal with NR through another mechanism,
probably service based.
 
After reading every ones posts on this topic, I guess I do not think we
should mandate the removal of the entries; we may wish recommend this be
done though. This of coarse is a mute point due to the last-call already
taking place ;)
 
Ryan
 
-----Original Message-----
From: Flynn, Michael [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2001 10:03 AM
To: 'Ryan Hurst'; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....
 
Ryan,
 
Ryan wrote::

Michael
 
-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]]
Sent: Tuesday, September 04, 2001 8:50 PM
To: IETF-PKIX
Subject: Removing expired certificates from CRLs.....

3.3  Revocation
 
....

 
 
....

 

 
Ryan M. Hurst
ValiCert, Inc.

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 05 Sep 2001 12:02:07 -0700

Michael -

 
 
Ryan
 
-----Original Message-----
From: Flynn, Michael [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2001 10:03 AM
To: 'Ryan Hurst'; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....
 
Ryan,
 
Ryan wrote::

Michael
 
-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]]
Sent: Tuesday, September 04, 2001 8:50 PM
To: IETF-PKIX
Subject: Removing expired certificates from CRLs.....

3.3  Revocation
 
....

 
 
....

 

 
Ryan M. Hurst
ValiCert, Inc.

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 05 Sep 2001 12:05:10 -0700

Thanks Sharon -
 
            I guess both documents are consistent now; I must have had an
older copy of X509. Sorry for any confusion I caused; and thanks for the
great participation in the discussion ;)
 
Ryan
 
-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2001 10:36 AM
To: 'Flynn, Michael'; 'Ryan Hurst'; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....
 
I suspect some of the PKIX text was never updated to reflect the successful
ballot on the X.509 defect report that fixed this in the base X.509 text.
The approved TC for the defect (DR 204) corrected this problem by making the
following changes to X.509 (97).

Clause 12.6.3.1
 
In the first sentence following the ASN.1, delete "unexpired"
 
Add the following as a new second sentence in the first paragraph following
the ASN.1
 
"After a certificate appears on a CRL, it may be deleted from a subsequent
CRL after the certificate's expiry."

Cheers,
Sharon
 
-----Original Message-----
From: Flynn, Michael [mailto:[email-masked]]
Sent: Wednesday, September 05, 2001 1:03 PM
To: 'Ryan Hurst'; IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....
Ryan,
 
Ryan wrote::

Michael
 
-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]]
Sent: Tuesday, September 04, 2001 8:50 PM
To: IETF-PKIX
Subject: Removing expired certificates from CRLs.....

3.3  Revocation
 
....

 
 
....

 

 
Ryan M. Hurst
ValiCert, Inc.

---

From: Ambarish Malpani <[email-masked]>
Date: Fri, 07 Sep 2001 14:36:06 -0700

Hi Denis, Tom,
    What I would recommend we add to CRLs, is something similar
(or the same) as the ArchiveCutoff extension in OCSP. If a CA
added that to a CRL, it would be easy for a responder to add it
in responses.

It is unclear to me that there is a huge benefit to CAs to go
through the trouble of retaining only signing certs in the CRL
and not the others.

Regards,
Ambarish

Denis, since you are bcc-ing the X.509 group, could you please
also forward this message to that list?

Thanks,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> Sent: Friday, September 07, 2001 5:32 AM
> To: Tom Gindin
> Cc: IETF-PKIX
> Tom,
> I still believe that this discussion is more appropriate, at 
> this time, to
> X.509 currently rather than PKIX. So I have bindly copied the X.509
> discussion list. Having said that, making sure that PKIX 
> members agree with
> the proposal cannot hurt.
> 
> > I would argue for SHOULD for that extension rather than 
> MUST, but its
> > presence can hardly hurt if it is non-critical.  
> 
> I believe that we basically agree. When this extension is 
> present, then it
> is non critical.
> 
> > BTW, I hadn't read your note when I composed mine.  
> > Now, what is the proper syntax for this extension, which 
> could be named 
> > "RevokeRetention"?  Here are some possibilities:
> 
> > 1    Assume that all usage types have either no retention 
> or the same one.
> >   A simple syntax for this would be:
> >      RevokeRetention ::= SEQUENCE  {
> >           basicUsages    KeyUsage OPTIONAL,
> >           extUsages      SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
> >           incExpsAfter   GeneralizedTime
> >      }
> 
> Since in practice, I would expect a policy where all 
> certicates having DS or
> NR set are kept one month longer, this seems sufficient.
> 
> > 2    Assume that usage types may have different non-null retentions.
>     A slightly less simple syntax for  this would be:
> >
> >  RevokeRetention ::= SEQUENCE OF UsageRevokeRetention
> >
> >    UsageRevokeRetention ::= SEQUENCE   {
> >      CHOICE {
> >        basicUsage     INTEGER, 
>                         -- 0-based bit offset from KeyUsage definition
> >        extUsage       OBJECT IDENTIFIER,
> >     }
> >      incExpsAfter     GeneralizedTime
> >    }
> 
> I would prefer:
>  
>         basicUsage     BIT STRING  rather than
>         basicUsage     INTEGER
> 
> 
> We could also have a simpler syntax:
> 
> RevokeRetention ::= SEQUENCE OF UsageRevokeRetention
> 
>     UsageRevokeRetention ::= SEQUENCE  {
>         incExpsAfter     GeneralizedTime,
>         basicUsage       BIT STRING                      OPTIONAL, 
>         extUsages        SEQUENCE OF OBJECT IDENTIFIER   OPTIONAL
>     }
> 
> If some dates are different but some dates are common to 
> various types of
> certificates, this can save some entries. 
> 
> > Naturally, any revocation matching a specified usage would 
> be expected
> > to be retained on the CRL if the certificate expiration 
> time is after
> > "incExpsAfter", but not otherwise.  Furthermore, do you think
> > extendedKeyUsage should be omitted?
> 
> For completness, since X.509 is a framework, extendedKeyUsage 
> should be
> there. PKIX can then decide to keep it or leave it in its profile.
> 
> Now, suppose we do this, this is fine for CRLs. How should an 
> OCSP server
> behave whether or not expired certificates are kept longer 
> than strictly
> mandatory ? RFC 2560 is rather vague on that topic.
> 
> Denis
> 
> 
> >           Tom Gindin
>

---

From: Ryan Hurst <[email-masked]>
Date: Fri, 07 Sep 2001 17:42:50 -0700

Yes --
	Sorry I have not been in this conversation the past couple of days;
Ambarish keeps me busy ;)

	I have seen several ideas in regards to this extension; but I was
thinking of something much simpler (more like what Tim has recommended) An
extension that would be just like the ArchiveCutOff extension in OCSP.

	ArchiveCutOff ::= GeneralizedTime

My 2c,

Ryan

-----Original Message-----
From: Tim Polk [mailto:[email-masked]] 
Sent: Friday, September 07, 2001 2: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: "Tom Gindin" <[email-masked]>
Date: Sat, 8 Sep 2001 08:09:39 -0400

Denis:

     Given what the other proponents of a mechanism like this one are
suggesting, I think my second alternative will be considered
overcomplicated anyway.  They don't seem to want to enforce multiple dates
for retention.  The only reason for separate retention dates which I can
think of is to allow NR to have a multi-year retention while DS (say) has a
week or two, and if NR relying parties check for revocation information
periodically and stop after the date of the signature, they won't have a
problem.

          Tom Gindin

Denis Pinkas <[email-masked]> on 09/07/2001 08:32:14 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   IETF-PKIX <[email-masked]>
Subject:  Re: Removing expired certificates from CRLs.....

Tom,

I still believe that this discussion is more appropriate, at this time, to
X.509 currently rather than PKIX. So I have bindly copied the X.509
discussion list. Having said that, making sure that PKIX members agree with
the proposal cannot hurt.

> I would argue for SHOULD for that extension rather than MUST, but its

I believe that we basically agree. When this extension is present, then it
is non critical.

> Now, what is the proper syntax for this extension, which could be named

> 1    Assume that all usage types have either no retention or the same
one.
>           incExpsAfter   GeneralizedTime

Since in practice, I would expect a policy where all certicates having DS
or
NR set are kept one month longer, this seems sufficient.

I would prefer:

If some dates are different but some dates are common to various types of
certificates, this can save some entries.

> Naturally, any revocation matching a specified usage would be expected
> to be retained on the CRL if the certificate expiration time is after

For completness, since X.509 is a framework, extendedKeyUsage should be
there. PKIX can then decide to keep it or leave it in its profile.

Now, suppose we do this, this is fine for CRLs. How should an OCSP server
behave whether or not expired certificates are kept longer than strictly
mandatory ? RFC 2560 is rather vague on that topic.

Denis

---

From: Sharon Boeyen <[email-masked]>
Date: Mon, 10 Sep 2001 11:02:03 -0400

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

> Sent: Monday, September 10, 2001 10:19 AM
> To: Sharon Boeyen
> Cc: IETF-PKIX
> 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
> > 
> > > Sent: Friday, September 07, 2001 5:20 PM

---

From: "Tom Gindin" <[email-masked]>
Date: Mon, 10 Sep 2001 12:24:32 -0400

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

---

From: Ryan Hurst <[email-masked]>
Date: Mon, 10 Sep 2001 12:24:24 -0700

Sharon -
            I would rather see this as a separate extension, traditionally
you will only see IDPs in partitioned CRLs and since this would be
independent of that it seems simpler to keep it separate.
 
Ryan

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Monday, September 10, 2001 7:10 AM
To: 'Tim Polk'; Denis Pinkas; Tom Gindin
Cc: IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....
 
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 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 
> From: Tim Polk [mailto:[email-masked] <mailto:[email-masked]> ]

---

From: Ryan Hurst <[email-masked]>
Date: Mon, 10 Sep 2001 15:44:54 -0700

Michael --
	Your point that there is not necessarily a 1-1 relationship is
valid, however it is not uncommon for a responder to receive its revocation
information from CRLs and in this case there could be such a relationship.

Additionally since the overall goal in this case is the same for both OCSP
and CRLs; why not just use them same model to solve the problem? 

Ryan

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Monday, September 10, 2001 2:28 PM
To: IETF-PKIX
Subject: RE: Removing expired certificates from CRLs.....

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: Ambarish Malpani <[email-masked]>
Date: Thu, 13 Sep 2001 10:53:43 -0700

Hi Denis,
    The ArchiveCutoff text is a little difficult to understand,
but is correct I believe.

The way I think about it, the response is saying that "as long
as your certificate didn't expire before the date specified in
the ArchiveCutoff field, the status reflected in this response
is correct". Conversely, if your certificate expired before the
ArchiveCutoff date, it might have been revoked before expiry, but
I am not saying anything about that status.

The equation you have derived is absolutely correct and this is
exactly the semantics that I was expecting from the CRL extension
we are talking about.

Do we agree?

Regards,
Ambarish

> Sent: Thursday, September 13, 2001 1:31 AM
> To: Michael Myers
> Cc: IETF-PKIX
> Michael,
> > Denis,
> > What are your thoughts on the timeliness characteristic 
> between OCSP and
> > CRLs?
> 
> 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
> 
> > Mike
> > 
> > Michael Myers
> > t: +415.819.1362
> > w: http://www.traceroutesecurity.com
> > 
> > > Sent: Wednesday, September 12, 2001 12:35 AM
> > > To: Michael Myers
> > > Cc: IETF-PKIX
> > > 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
> > >
> > >
> > > > Mike
> > > >
> > > > Michael Myers
> > > > t: +415.819.1362