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 organizations
Don't at least ejabberd and prosody have support for per-domain certs? That sounds like what you're looking for. > 2. xmpp-dna appears that it will be complicated to understand and/or > implement > > 3. xmpp-delegate would be perfect if we had DNSSEC or some out of band > method of assuring the accuracy of DNS > > 4. using mismatched or self-signed certificates shows warnings to users, but > most clients have been developed to make it easy for users to bypass the > warnings. > > Given these alternatives, #4 seems to be the pragmatic solution. > > Jesse > > -- > Jesse Thompson > Division of Information Technology, University of Wisconsin-Madison > Email/IM: [email protected] > > -- viq
