Subject: Re: Part1 last call comments

From: David Kemp <[email-masked]>
Date: Mon, 26 Feb 2001 16:46:28 -0500 (EST)

> From: "Jim Schaad" <[email-masked]>
> 
> 4. Section 3.3 - Minor point,  in paragraph 4 - This should be "until all
> existing CRLs expires" rather than "until the next periodic CRL update".  A
> CRL may be valid for more than one issue period (i.e. issue every 12 hours,
> expire after 24 hours).

Jim,

I disagree with this proposed change.  CRLs do not expire, they only
have a next scheduled update date.  As section 3.3 paragraph 3 says,
"the meaning of 'suitably-recent' may vary with local policy", and
if one local policy says that CRLs which are issued every 12 hours
don't expire until 24 hours after issue, fine.  A different local
policy, however, might say that the identical CRL expires 13 hours
after issue.

The topic of CRL "expiration" was discussed last year, and I
understand that a PKIX proposal for a new "date-to-check-for-updated-CRL" 
extension is again in preparation.  I agree that it is useful for a CRL
to contain two items of information about CRL updates:

  * the date at which the next scheduled CRL will be issued
  * a CA-suggested date at which applications should consider
      a CRL "expired" and start warning the user.

However, X.509 defines "nextUpdate" as "the date/time by which
the next revocation list in this series will be issued", and
any proposal for a new CRL extension should follow the X.509
definition:

  CRL Field          Purpose
  -----------    -----------------
  nextUpdate     1) next scheduled CRL update
  new extension  2) CA-provided hint for CRL expiration date

instead of following the currently common CA practice of ignoring
the X.509 definition:

  CRL Field          Purpose
  -----------    -----------------
  nextUpdate     1) CRL "expiration" date
  new extension  2) actual next scheduled CRL update

If a new CRL extension is defined, it will eliminate the motivation
for CAs to populate nextUpdate with a white lie as a workaround for
propogation time issues.  The new extension should be defined so
that it eliminates the need for an inaccurate nextUpdate, rather
than perpetuating it.

Regards,
Dave

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 27 Feb 2001 12:43:06 +0100

David Kemp wrote:

> I agree that it is useful for a CRL

_at_ which

> the next revocation list in this series will be issued",

_by_ which

This is not the date _at_ which the next revocation list will be issued, but
_by_which the CRL is garanteed to have been issued.

This garantee covers the case where there's a problem and the
issuance/propagation of the CRL is slightly delayed.

Only after the nextUpdate delay, if the next CRL is not available, this is an
error.

Now stays to be discussed how much CA abuse this opening in the wording of the
standard by setting nextUpdate to 24 hours, when they issue new crl every 12
hours.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 27 Feb 2001 20:31:56 -0800

> -----Original Message-----
> From: David Kemp [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 1:46 PM
> To: [email-masked]
> Subject: Re: Part1 last call comments
>
>
>

Dave,

Would the text "until all currently issued CRLs pass their nextUpdate." be
acceptable to you?  I merely want to reflect that there may be multiple
valid CRLs in existence, and until all of them have passed their nextUpdate
time a cached CRL can validly be expected to be used.

jim