On 14-06-2010 21:19, Dr. Stephen Henson wrote:
On Mon, Jun 14, 2010, Jakob Bohm wrote:
Note to list: I am aware of at least one public CA (TDC OCES) who (at least
planned to) split
their CRL into smaller parts, each covering only revocations for a range of
certificate serial
numbers. The certificates themselves then contained/contain different CRL
download URLs
depending on the serial number.
[snip]
* I don't know if this CA practice is fully standards compliant, but it
exists in the real world,
As long as the appropriate extensions are included in the CRLs this is fine.
The CRL for example would have a critical issuer distribution point extension.
That way implementations that don't support IDP will reject the CRL due to
an unhandled critical extension.
I don't know if the CA I mentioned (it is being phased out in favor of
something
very bad) includes that extension, but in general, this would work so
badly with
other X.509 clients that it would be a complete no-go. Specifically, a
naive
X.509 implementation unaware of this extension might work in its absence but
would fail miserably in its presence.
I have also heard a rumor (unconfirmed), that *any* CRL extensions (even
those
not marked critical) requires a CRL format unsupported by many clients
and thus
useless to public CAs.
Besides, there is another reason why a CA might have multiple CRLs that
all need
to be checked: Occasionally, revocations with specific reasons get their own
CRL.
So in general, the safe option for an X.509 client is:
1. If for any reason it has multiple valid CRLs available for a CA,
check ALL
of them, unconditionally. Only if a CRL explicitly supersedes another
should
its presence prevent checking of that other CRL.
The OP seems to describe a crazy reversed logic: If the first valid CRL
checked does not revoke a certificate, no other CRL is checked, in other
words "not-found-in-first-try=stop-searching". (Of cause Mozilla's logic
is much worse: Never download CRLs, never update expired CRLs, don't tell
user).
2. If a certificate in its ordinary CRL download URL extension lists a URL
different from the URL from which a cached CRL was obtained, download that
CRL too, without overwriting cached CRLs from other URLs, in other words:
Use standard HTTP caching rules except that the HTTP timestamps and cache
durations are superseded by the timestamps and expiry dates within the
CRLs themselves. Of cause any http code to obtain CRLs should go through
an application callback, which might legitimately decide not to
"phone home" or to use an alternate transport mechanism.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
