Re: Part1 last call comments

[David Kemp <dpkemp@xxxxxxxxxxxxxx>]

> From: "Jim Schaad" <jimsch5@xxxxxxxx>
> 
> 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