Re: delta CRLs - NR assumptions

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

Denis Pinkas wrote:
> 
> The use of nextUpdate is the core of the debate, because the text in PKIX-1
> does not say what kind of use shall be done of that information by a relying
> party. The basic question is whether this information should be used :
> 
>    1) to make sure that a CRL is usable for a time T, or
>    2) to make sure that a CRL is not usable for a time T.
> 
> Unless PKIX-1 provides some guidance the debate will continue for ever.

Yes.  My position is that there are two purposes for certificate validation,
realtime and non-realtime, and that a CA can provide one cert/CRL series that
satisfies both purposes for a variety of clients.  A specific RP client,
however, must make a decision to accept a certificate using validation
rules appropriate to that client's purpose.

For realtime validation, the client can say "I have a CRL issued at time T,
and my security policy allows me to assume that a certificate which was
not revoked at time T has a sufficiently (for this purpose) small chance
of being revoked at time T+e".  e is the client's caching interval, and T+e
can be less than, equal to, or greater than nextUpdate (*).

For high-value transaction validation, the client can (and I argue SHOULD)
say "I have a CRL issued at time T.  My security policy requires me to confirm
that the certificate was not revoked at time T, and forbids me from accepting
a probabilistic guess that the certificate will not be revoked between
T and T+e".


(*) I agree that if a client has a cache interval of less than the CRL
publication
period, reliably satisfying that client's needs requires secure distribution
points and transmission channels which are outside the PKIX model.  My point
is that those extra-PKIX measures can in theory be provided to "special" clients
without creating any incompatibility with pure PKIX clients or requiring any
changes to the PKIX untrusted distribution model.  In practice, it would be
easier to up the frequency of CRLs until the most demanding client's needs
are met, and forget about trusted distribution.  Whether a CRL per minute
is realistic or not depends on the application; use 15 minutes as the extreme
example if you prefer.


> > Non-realtime transactions (including those subject to
> > dispute resolution) don't need nextUpdate either;
> > they just need any CRL with thisUpdate after the transaction commit time.
> 
> Certainly not. A relying party has to take a decision to accept or reject a
> signature at a time T. If a signature is deemed valid at time T, then no
> other information, according to the verification rules, should change this
> condition.

The verification rule "Signature valid at time T requires a CRL with
thisUpdate >= T" satisfies your requirement.  No rule requiring the CA to
guess the future (e.g., a rule involving nextUpdate) can satisfy it.

> > Any business process
> > that doesn't require positive acknowledgement before committing high value
> > resources is flawed.
> 
> Yes.
> 
> > Thinking along the lines of "cacheable/valid until nextUpdate" is therefore flawed.
> 
> You provide no evidence to support that sentence.

Positive acknowledgement is by definition not probabilistic.  The entire purpose
of this discussion is to reach general agreement that when a transaction is
"committed" (becomes difficult to roll back, in the sense of a database
two-phase-commit), no information should come along later that would cause
doubts about the validity of the transaction.  The CA can at time T have high
confidence that a certificate is not revoked at time T.
The CA can have no confidence, only a statistical belief, that a cert which
is not revoked at time T=thisUpdate will still not be revoked at time
nextUpdate.

For realtime purposes, the RP's or the CA's statistical belief is good enough.
For some other purposes, it is not.

PKIX should recognize both cases in its validation rules, and if we want
to say something in the security considerations, it should be that a CRL
is an assertion by the CA concering revocation status at time thisUpdate.
Revocation status at any later time (<, =, > nextUpdate) is at best a
guess, and a CRL is explicitly NOT an assertion by the CA concerning
revocation status at any time T > thisUpdate.  NextUpdate is merely a
promise to publish another CRL by a certain time.

Dave