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. > 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. There are ways of achieving the same result without a critical IDP too: just include subordinate CAs for each batch of serial numbers. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
