Re: Security section of draft-ietf-pkix-opp-ftp-http

[John_Wray@xxxxxxxx]

dpkemp@missi.ncsc.mil (David P. Kemp) wrote:

>Carl Ellison has a colorful description of CRLs which are not
>required by the verifier: wandering anti-matter which may or
>may not happen to collide with the revoked certificates in
>time to prevent them from being used.  PKIX should not
>encourage the "statistical revocation" approach, and should
>point out the dangers of using it, as Paul has done in his
>Security Considerations text.

>Mike left out the obvious solution to the problem: just don't do it.
>PKIX does not prohibit CAs from issuing CRLs before the nextUpdate of a
>prior CRL, but the policy of individual CAs should take into account
>the trustworthiness and reliability of the distribution mechanism when
>deciding how to set nextUpdate and whether to ever issue interim CRLs.
>The no-brainer approach is to assume that revocation distribution is
>completely untrustworthy and expire the revocation information often
>enough that there is no motivation to issue interim information.

You can't really avoid doing it.  If a CA issues CRL[n] which expires at
time T, when is it supposed to issue CRL[n+1]?  At time T?  If so, then end
systems won't have any valid revocation lists from time T until after
whatever propagation delay the CRL distribution mechanism imposes (which
may be dependent on directory replication schedules, HTTP proxy caching
policy or any number of other things, many of which are outside the control
of either the CA or the end-system).  So a CA really is forced to issue
CRL[n+1] at some time before the previous CRL is set to expire.  So during
that period, an end-system will have some uncertainty as to whether it has
the absolute latest CRL.  But this is only a problem if verifiers have
unrealistic expectations regarding what CRLs offer.

The thisUpdate and nextUpdate fields should be viewed as a policy statement
by the CA that certificates revoked after the thisUpdate time may still be
verifiable by some end systems until nextUpdate.  That doesn't prohibit the
CA from issuing an updated CRL earlier, particularly if it knows that a
compromise has occurred (indeed, I would expect a CA to do so - it
corresponds to the real world concept of making a good-faith attempt to
notify subscribers to the CA of the compromise).  It simply means that it
can't provide any assurance that the new revocation list will supersede the
current one for all end-systems until after the current CRL's nextUpdate.

John