[SSL Observatory] Number of CAs

Daniel Kahn Gillmor dkg at fifthhorseman.net
Thu Dec 8 14:17:21 PST 2011


On 12/08/2011 04:36 PM, Adam Langley wrote:

> 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.

This makes sense to me, but sending two separate intermediate certs
seems to violate the TLS spec:

   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.

https://tools.ietf.org/html/rfc5246#section-7.4.2

It seems like it would be worthwhile to amend the TLS spec if that MUST
isn't really a MUST.

> On Thu, Dec 8, 2011 at 4:24 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net> 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?
 [...]
> 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.)

OK, i see how this is different from a truncated trust path.   But this
is not corroborative certification of the EE certificate.  It's
corroborative certification of Foo CA.

So the administrator of example.com is still left with the necessity of
getting a certificate from exactly one CA.

Thanks for the pointers,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.eff.org/pipermail/observatory/attachments/20111208/7db01e9f/attachment.sig>


More information about the Observatory mailing list