browser vendors and CAs agreeing on high-assurance certificat es

Ian G iang at systemics.com
Sat Dec 24 12:27:58 EST 2005


Ben Laurie wrote:
> Ian G wrote:
...
>>http://wiki.cacert.org/wiki/VhostTaskForce

>>(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?

Certainly they *can* share a cert.  But a cert
speaks to identity - at the human level the cert
is supposed to (by some readings) indicate who
the site is purporting to be and in some scenarios,
there are people who think the cert actually
proves that the site is who it claims to be.

So regardless of the technical details of the
underlying software (complex, I grant), websites
SHOULD NOT share a cert.

(by capitals I mean the RFC sense, not the shouting
sense.)


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

If browsers don't know what is available on the
server, they send a Hello message that asks for
what protocol versions and ciphersuites to use.
This is the SSL v2 message, just in case.... so
to rectify this situation we need to get all
the browsers distro'd with SSL v2 turned off by
default.  The shorthand for this is "SSL v2 must
die..."  Thankfully, they did decide to do just
that at last month's browser pow-wow.

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list