Re: Root certificates in server certificate chains

Sending root cert makes sense for Trust model based on computed probabilities - which does not exist today
except in research papers.

The idea is - you verify as much as practical, and decide how much you trust the requester regarding his request.

E.g. consider two questions: "can I use your phone?" and "can I use your car?"

Oh, and the current trust model has little room for root cert as a part of the transmitted chain. Although - a
home-grown CA, a bunch of pals establishing a  TLS-protected Web chat site...? No need to get VeriSign
involved... Why not? 

--
Regards,
Uri

----- Original Message -----
From: Marsh Ray [mailto:marsh <at> extendedsubset.com]
Sent: Tuesday, August 31, 2010 09:56 PM
To: Matt McCutchen <matt <at> mattmccutchen.net>
Cc: 1.41421 <at> gmail.com <1.41421 <at> gmail.com>; tls <at> ietf.org <tls <at> ietf.org>
Subject: Re: [TLS] Root certificates in server certificate chains

On 08/31/2010 07:09 PM, Matt McCutchen wrote:
> The following is my understanding.  Others should feel free to disagree
> or correct me.
>
> On Tue, 2010-08-31 at 22:30 +0000, 1.41421 <at> gmail.com wrote:
>> The standard (RFC 5246, sec. 7.4.2) says that a server certificate
>> chain may include, as the last entry in this chain, the root
>> certificate that is to be considered the ultimate trust anchor as far
>> the server certificate is concerned. What would prevent an attacker
>> from inserting a Certificate message of its own during the handshake,
>> containing a totally bogus root certificate?
>
> Like any other tampering with the handshake, this would cause the
> Finished check to fail.

Not if the attacker is successful in getting the client to accept his 
proposed root certificate.

>> Actually, doesn't this render the whole idea of authentication of the
>> remote useless?

Sure, if the client is willing to accept it.

>> How can one make sure that a root certificate received
>> in a certificate chain is genuine?

Perhaps the client already trusts that root cert or key? If so, why even 
bother to send it?

>> But, in this case, why allow the server to include a root certificate
>> in the certificate chain in the first place?
>
> Perhaps as a hint to clients that might decide they wish to add that
> certificate as a trust anchor, possibly after further research?

To make it easier for users to "Permanently store this exception"?  :-P

- Marsh
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls