On 15-06-2010 13:10, Dr. Stephen Henson wrote:
On Tue, Jun 15, 2010, Jakob Bohm wrote:
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.
Without the extension it is vulnerable to a CRL substitution attack.
That's the idea of critical extensions: if you don't support the feature you
reject the CRL instead of giving a misleading result.
But rejecting the CRL means either A) Rejecting all valid certificates (not
acceptable to users, they will turn off any and all security to avoid
this) or
B) Accepting all revoked certificates (as if there was no CRL). Either
consequence is *worse* than the risk of substitution attacks. Therefore any
competent CA designer will not do this.
Substitution attacks can be avoided without Incompatible Dead Pie-in-the-sky
extensions by: 1) Using https URLs for certificate downloads, and/or
2) checking that all the CRLs are different in the client code (trivial).
This is the real world of X.509: Many of the additional mechanisms
dreamed up
by the ivory-tower people who write the official standards are just
impossible
to use due to widely existing software or certificates, and developers just
have to deal with this fact if they want to provide actual security for
real people.
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.
Partitioning by reason code can also be done using IDP.
Consider also the following scenario. A PKCS#7 signed data structure can be
self contained and include any certificates and/or CRLs needed to validate the
signature offline or at some time in future when an expired certificate might
be removed from the CRL. With no secure binding between certificate and CRL
again a substitution attack is possible.
Bundling CRLs with the signatures they are supposed to check is not done
in most real world scenarios. It is an insecure option in the original
S/MIME protocols which now exists only as a syntax for distributing CRLs
etc. using the same ASN.1 structures also used for messages.
This option is always insecure because it makes it trivial to bundle a
slightly-old CRL with a signature made using a freshly compromised
certificate. If you really need to check an independently timestamped
signature against a historic CRL, use the first CRL issued *after* the
signature, not a CRL issued *before* the signature with a validity
period straddling the signature timestamp.
It is also worth noting that some of the CAs that actually delete
expired certificates from their CRLs make an active effort to handle
compromised certificates differently from those that remained
uncompromised for their entire lifetimes. The details vary, though
one *possible* mechanism is to issue a long-lived CRL (valid until
root expiry) of expired previously-compromised certificates once per
year before removing those certificates from the main CRL, but this
would hit the openssl bug which is the subject of this thread.
There are ways of achieving the same result without a critical IDP too: just
include subordinate CAs for each batch of serial numbers.
But this would have had to be done *before* issuing the certificates,
and time travel is not implemented yet.
So these kinds of CRLs exist in the real world, and the current openssl
non-checking behaviour is *insecure* and *broken*.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
