Nolan Eakins makes some good points in reply to my most recent post about end-to-end encryption for Jabber/XMPP. On the list of "things we should have done back in 1999" when Jabber technologies were first being developed, probably the number-one item is always-on encryption. Experience has shown that it's best to bake this stuff in from the beginning (which is what Groove did), not treat it as an afterthought. So we need to think about this problem as if we were developing it from the beginning, even though we're not.
In order to make encryption on by default, all users would need to have a key or cert (which is really just a key with metadata), and the server would need to enforce that. So part of the authentication process would be that you present your public key (or fingerprint to save bytes). The server would then sign your fingerprint (and JID) with its own key and send that token back to you. If you don't provide a key, the server would treat you as unauthorized. (Naturally all servers would have their own keys, and use of keys for server-to-server communications would be enforced as well: no key, no s2s connection, which can be done by following RFC 3920.) Granted, not everyone will have their own keys/certs (Aunt Tillie among them). What to do? Nolan suggests that the server could generate a key for you (simple clients, complex servers). Or a somewhat smarter client could do the job (it's not going to be able to log in without a key anyway). Perhaps this is something that is negotiated during account registration (which probably would not happen via JEP-0077 anymore, unless more fields were required).
Then it seems that all entities would encrypt all the XML stanzas they generate (we assume everyone has keys, after all), including the countersigned token. If you receive a stanza that you can't decrypt because you don't know that entity's public key (say, during the presence subscription handshake), you could send a disco request to the entity's bare JID in order to retrieve the public key, fingerprint, or countersigned token. Naturally you could retrieve the key for a server or component in the same manner.
Open issues include what to do about extended addresses, AMP routing information, and SHIM headers, since they could be used for routing purposes.
Further thoughts welcome. Obviously this is just the beginning of a long discussion. (Perhaps it's best to discuss this on the Standards-JIG list, but I rather like the more measured pace of discussion by blog.)