On 2/23/2010 3:28 AM, viq wrote:
On Mon, Feb 22, 2010 at 9:26 PM, Jesse Thompson <[email protected]> wrote:On 2/22/2010 12:43 PM, Peter Saint-Andre wrote:On 2/22/10 11:27 AM, Jesse Thompson wrote:We might as well stick with this clusterf*ck until xmpp-dna or xmpp-delegate is implemented.Oh, and even then you're going to require a certificate, no? The point of DNA or _xmpp-delegate or whatever solution the XMPP WG comes up with is to handle the case of delegation (e.g., Google Apps is hosting my domains) or the case of adding multiple domains to an existing connection via attribute certificates. And the attribute cert stuff is going to require a lot of man hours -- new features in OpenSSL or the like, an admin-friendly and open-source tool to generate attribute certs because otherwise it will be really hard, best practice docs, READMEs, etc. Who is going to do all that work? TANSTAAFL, folks.Yes, we're stuck with a bunch of crappy alternatives: 1. wildcard certificates won't match all virtual domains and also don't match the vcards/conference components within subdomains, introduce security risks if the private keys are exposed, and can be difficult to obtain for many organizationsDon't at least ejabberd and prosody have support for per-domain certs? That sounds like what you're looking for.
The problem is that it doesn't scale well for XMPP hosting providers. We host 250 domains. We haven't enabled them all for XMPP because of these types of issues.
If XMPP requires matching certificates for every domain (and every component of each domain) it puts the individual XMPP hosting providers in the position of doing the function of a certificate authority in order to keep customer certificates up to date. They have to provide forms (with secure authentication) for allowing customers to upload/update certificates and keys. They have to build processes to automatically install certificates and keys into the XMPP server configuration. They have to send out reminder notices of certificates that are about to expire. Basically, they have to do everything that a CA is responsible for, minus the key generation part.
I'm not interested in running a [mutated] certificate authority. Jesse -- Jesse Thompson Division of Information Technology, University of Wisconsin-Madison Email/IM: [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
