browser vendors and CAs agreeing on high-assurance certificat es

[Ben Laurie]

Ian G wrote:
> 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.

I don't see why not - the technical details actually matter. Since the
servers will all share a socket, on any normal architecture, they'll all
have access to everyone's private keys. So, what is gained by having
separate certs?

I do agree that the process by which the additional names get added to
the main cert needs to reflect ownership of the name, but that's a
different matter.

And I'm not claiming, btw, that this mechanism is better than the server
name extension. However, I don't believe its as broken as some are claiming.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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