On Thu, Dec 8, 2011 at 4:24 PM, Daniel Kahn Gillmor <[email protected]> wrote: > Can explain how the existing X.509+TLS infrastructure allows a site > operator to publish true multiple trust paths (i.e. corroborative > certification) of an EE certificate? I would be very excited to learn > this, because it would reduce one of the pressures on browser vendors to > retain unreliable CAs in their default root stores.
X.509 validation, in browsers(*) at least, works by starting at the leaf certificate and working up, using any means possible. (*) 'browsers' means common browsers. More minor clients may be stricter. There are, of course, limitations on the set of possible paths: Issuer and Subject names must match and Authority Key Id will be used where possible. But it does mean that incomplete chains can be accepted (by downloading the needed intermediates via AIA) and that the constructed path may include versions of certificates that were not sent by the server (if an intermediate or root has been reissued.) So, if a server sends a leaf certificate followed by the intermediates for two separate chains, then browsers will be able to figure it out if one of the roots has been revoked. But, since the leaf's Issuer is fixed, both chains need a certificate with a matching Subject. The Issuer of that certificate, however, may vary. Given a representation of a certificate "Subject -> Issuer", consider a server that sends: example.com -> Foo CA Foo CA -> Root 1 Foo CA -> Root 2 A browser will figure out a good path, even if only one of "Root 1" and "Root 2" is trusted. (Indeed, CryptoAPI can return all the possible paths.) Cheers AGL
