Re: delta CRLs - NR assumptions

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

David,

> > If a CA indicates that it MAY issue emergency CRLs at any time (for some
> > scope or reason), then a cache for that CRL should not be used. In this way,
> > the client will always try to fetch the latest CRL, ... but will have no
> > guarantee that he ever got the latest.
 
> The client, not the CA, should determine the client's caching policy.

True, but what the client can do is dependent from what the CA does.

> And given a CA with a specific practice (emergency CRLs yes/no,
> deltas yes/no), different clients may use different caching policies.
> One client may check for emergency CRLs at a specific interval, and
> a different client may check for them at a different interval, without
> even needing to know if the CA ever issues them.  And one client may
> use deltas and another client may not use them even when both clients
> are validating certs from the same CA.
> 
> Realtime clients can eliminate the impact of denial of service by
> fetching CRLs through a secure pipe.  

 .. if such a secure pipe is available, which is not an assumption of the
X509 model, nor the PKIX model. 

> If a connection is established
> to the distribution point, then the client is guaranteed that it has
> that DP's latest CRL.  If the fetch times out, then the client
> can either refuse to validate certs or proceed, at risk, using a
> cached CRL.

Once again, if a secure pipe is available. This also means that if a
replication mechanism has been used to feed the server under query, secure
pipes for the replication of the revocation information shall also be used.
Then trust should also be placed in the managers of the replica servers.
This is quite a long chain of trust that the X509 model has *not* assumed.
 
> > Finally, when CRLs are used for supporting non repudiation, since one goal
> > of non repudiation is to solve disputes, we had better to have non
> > conflicting information from the same authority while using the same
> > revocation mechanism.
 
> If there were an accepted business standard for NR, then that standard
> would surely take into account all available evidence.  As Tom Gindin says,
> dispute resolution will take place long after the next CRL has been
> issued - if two parties present what you call "conflicting" CRLs, there
> is still no conflict.  The judge will know that the cert was revoked at
> time T (where T is between thisUpdate of one CRL and thisUpdate of the
> other CRL) 

No. The judge will have to use the same rules that are supposed to be
followed by the verifier to settle a decision. Unless these rules are
clearly stated, no decision can be taken. Hence why these rules have to
exist. So the basic question is : what are the rules to be used by a
verifier to make sure that the certificate was not revoked ? These rules
must be clearly stated and not conflicting. 

> and will overturn or let stand a transaction according to all
> the facts known at the time of adjudication.  Proof of clock
> synchronization is a far bigger issue here than whether or not a CA
> issues emergency CRLs.
 
> > A few words in the security considerations section would certainly be
> > appropriate. If you agree in principle, I would be happy to provide them.
> 
> I don't believe "a few words" can do justice to the topic of NR :-).
 
> Linking a CA's issuance of emergency CRLs to whether some clients might
> use CRLs in support of NR is an entirely unnecessary complication.  You
> create the complication yourself by believing that CRLs are "valid" until
> nextUpdate. 

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.

> Purge this notion from your mind and instead focus on clients'
> freshness requirements.  The highest value real-time irrevocable transactions
> (e.g., disclosure of confidential information, execution of a critical signed
> applet, etc.) will require the freshest available information regardless of
> what nextUpdate says.  

There is no guarantee that the freshest information can ever be obtained.
See above the problem of denial of service where, in case of a problem, the
responsibilities will be undetermined between the CRL Issuer and the
managers 
from the replicas where the CRLs are stored.

> Non-realtime transactions (including those subject to
> dispute resolution) don't need nextUpdate either; 

So why does PKIX-1 mandate it ?

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

> 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.
 
> For low-value purposes, some clients may choose to accept a CRL until
> nextUpdate or even well beyond.  

Yes.

> If a CA issues a CRL every minute, 

Do you really see this situation as realistic ?

Denis

> there
> is no reason to force every client to fetch that often when caching for
> an hour might be quite sufficient for the purpose at hand.
> 
> Dave
> 
> > Denis