Peter Saint-Andre said the following on 3/1/06 1:59 PM:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1JD Conley wrote:address. Naturally we'll need to clarify this in rfc3920bis, but my question now is: how do existing clients and servers handle this?We do this on the server side with a separate cert for each domain -- even conference, users, and other sub-domains used in s2s. Some client software packages present a warning when certificates aren't correct (domain mismatch, etc) but many do not and just use the certificates for encryption, not authentication.Let's say you are DreamHost, which has offered jabber services for years now. You want to offer secure connections. But you host 50,000+ domains. Are you going to have a separate certificate for each of those domains? Or let's say you are Internet2 and you want to offer XMPP services for all member universities, of which there are several hundred. Here again, are you going to have a separate cert for each domain, or one cert with all the possible virtual hosting domains as CNs and/or id-on-xmppAddr subjectAltNames?
You can only have one common name in a certificate(I think). I don't see what the limit of subjectAltnames is in rfc3280 but you can do wildcards.
Managing 50k private keys would be nuts. Client support for traversing 50k subjectAltNames would be questionable.
Obtaining an intermediate CA(http://www.geotrust.com/products/client_certificates/true_credentials.asp) from someone like GeoTrust or getting a wildcard cert(http://www.geotrust.com/products/ssl_certificates/wildcards.asp) might help. They might want to contact CACert.
So I'm all for each domain having their own certificate. Also the revocation list might be annoying if you have all 50k domains in one cert and you have to add one domain one day and delete a domain the next day...
-Jonathan
smime.p7s
Description: S/MIME Cryptographic Signature
