[19410] in cryptography@c2.net mail archive
Re: browser vendors and CAs agreeing on high-assurance certificat
daemon@ATHENA.MIT.EDU (Eric Rescorla)
Sat Dec 24 12:00:09 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
To: Ben Laurie <ben@algroup.co.uk>
Cc: Ian G <iang@systemics.com>, leichter_jerrold@emc.com,
pgut001@cs.auckland.ac.nz, cryptography@metzdowd.com,
jamesd@echeque.com, smb@cs.columbia.edu
Reply-To: EKR <ekr@rtfm.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 24 Dec 2005 08:51:20 -0800
In-Reply-To: <43AD647E.2020606@algroup.co.uk> (Ben Laurie's message of "Sat,
24 Dec 2005 15:08:46 +0000")
Ben Laurie <ben@algroup.co.uk> writes:
> Ian G wrote:
>> Ben Laurie wrote:
>> ...
>>>> Hopefully over the next year, the webserver (Apache)
>>>> will be capable of doing the TLS extension for sharing
>>>> certs so then it will be reasonable to upgrade.
>>>
>>>
>>> In fact, I'm told (I'll dig up the reference) that there's an X509v3
>>> extension that allows you to specify alternate names in the certificate.
>>> I'm also told that pretty much every browser supports it.
>>
>> The best info I know of on the subject is here:
>>
>> http://wiki.cacert.org/wiki/VhostTaskForce
>>
>> Philipp has a script which he claims automates
>> the best method(s) described within to create
>> the alt-names cert.
>>
>> (The big problem of course is that you can use
>> one cert to describe many domains only if they
>> are the same administrative entity.)
>
> If they share an IP address (which they must, otherwise there's no
> problem), then they must share a webserver, which means they can share a
> cert, surely?
Actually, the big problem if you run a virtual hosting server
is that every time you add a new virtual domain you need a new
cert with that domain in it. And that applies even if you put
all the names in one cert.
Really, the ServerHostName extension is better.
>> What we really need is for the webservers to
>> implement the TLS extension which I think is
>> called "server name indication."
>>
>> And we need SSL v2 to die so it doesn't interfere
>> with the above.
>
> Actually, you just disable it in the server. I don't see why we need
> anything more than that.
The problem is that the ServerHostName extension that signals
which host the client is trying to contact is only available
in the TLS ClientHello.
-Ekr
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
