RE: Part1 last call comments

[David Kemp <dpkemp@xxxxxxxxxxxxxx>]

Hi Jim,

Thanks for pointing out that I misread your proposal, focusing on
the "expires" instead of the "all CRLs".

As long as there is a statement in 2459bis that CRL expiration is a
matter of local policy, and applications MUST make provision for the
fact that the next CRL will not be available precisely at nextUpdate,
then I don't have a problem with your original proposal "until all
existing CRLs expire."  A more precise wording might be "until the
application considers all existing CRLs to have expired", but that
would be redundant if 2459bis contains an unambiguous statement that
different applications *will* have different caching policies (different
definitions of "CRL expiration").

Section 3.3 says: "If a revocation is reported now, that revocation
will not be reliably notified to certificate-using systems until the
next periodic CRL is issued".  In the case where more than one CRL is
in scope for a particular certificate (for example a deltaCRL series
and a less-frequently-issued full CRL series, or overlapping partitions
with different dates), it is again a local application policy whether
to consider its local cache valid until the most fresh source has an
update, until the least fresh source has an update, or even beyond the
point where all sources have had an update (treat a CRL as valid for 24
hours even though a new one was issued after 12 hours).

So "until the next periodic CRL is issued" is correct for applications
which start trying to update their cache at nextUpdate of the freshest
in-scope CLR series.  "...until all currently issued CRLs pass their
next update" is correct for applications which start trying to update
their cache only when the last (least fresh) in-scope CRL passes
nextUpdate.  Note that neither of these statements is correct if CAs
populate nextUpdate with an inaccurate value.

If all applications were configured to require the absolute latest info
(i.e. no application used a CRL cache), then revocation will be
reliably notified even before the next periodic CRL (i.e. if you cache
CRLs exactly as you cache OCSP responses and the CA issues unscheduled
CRLs on revocation events, you will get revocation info from CRLs as
fresh as you would get it from OCSP).

And if some applications are configured to cache CRLs for 24 hours
and the CA issues them every 12 hours, then revocation won't be
reliably notified even after the next periodic CRL is issued.

So the statement in 3.3 doesn't mean much: certificate-using systems
will be reliably notified sooner than, exactly when, or later than
the next periodic in-scope CRL depending on the specific certificate-using
system's caching policy.  PKIX can't require all applications to use
the same caching policy; the freshness/bandwidth/response-time/availability
tradeoffs are different for different certificate-using applications.

In summary, I no longer disagree with what you originally proposed, but
I don't agree with it either, since neither the current wording nor the
proposed change is generally true but each is sometimes true.  Any
statement regarding "reliably notified" must be made within the context
of a specific CRL caching policy.  My goal is to nail down one piece of
jello in this revocation picture:  PKIX CAs MUST populate nextUpdate
with the true time of the next scheduled CRL, and applications have to
handle the propogation/caching/reliance issues.

Regards,
Dave



> > > 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.
> >
> 
> 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