[Standards-JIG] The Great Encryption Debate

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Thu Aug 11 20:24:09 UTC 2005

On Thursday 11 August 2005 11:48 am, Peter Saint-Andre wrote:
> We need to define one or more methods for passing around keys in-band
> (naturally people could also use out-of-band methods, some of which may
> be more secure than others). I like the general form of David Chisnall's
> proposal to re-use existing contact lists, but we'd need to define that
> more fully. Other options are to settle on one or more root certificate
> authorities, which might include setting up the JSF as a CA for the XMPP
> network or including JIDs in certificates received from CAcert and other
> CAs.

I think in the end we're going to want to have several options here.

At the very least, I think we need easy trading of keys.  Publish your key, 
and let others fetch it.  And that's it.  For X.509 and OpenPGP, which 
already have existing trust models, this would be sufficient.

Then there's the idea of making up a new trust model that works by forming 
trust chains via rosters and what not.  This is where Jabber could shine, as 
it offers us capability that prior designers of web-of-trust systems simply 
didn't have.

> I have not
> seen much enthusiasm for RFC 3923 (especially given the dependency on
> non-existent CPIM parsers), nor for JEP-0027. Does anyone want to write
> a proposal that uses xmlenc?

Well, a number of clients have implemented JEP-0027.  You don't hear about it 
much lately because there haven't been many new serious client efforts.

I'm am still interested in object security.  In most cases it is sufficient 
enough (see JEP-0027), but also it is simpler to program, and simpler to 
deploy, particularly for signing.  Imagine a Jabber announcing service that 
wants to broadcast signed news items.  So while I do plan to implement 
JEP-0116, I think object security is worthwhile as well, and so I 
additionally plan to implement RFC 3923 (CPIM grumbling aside).

However, I also find it annoying having two ways to do the same thing.

Here's a thought that just popped into my head: What if we used object 
security only for signing, and then used session security for all encryption 
needs?  Since the primary benefit of object security seems to be signing, 
this could reduce the overlap between the two concepts.  Moreso if we can use 
the object signing to bootstrap the session encryption.

The only downside I see to this arrangement is that you wouldn't be able to do 
simple object encryption, but it might be worth it in the interest of 
eliminating overlap.


More information about the Standards mailing list