[standards-jig] Encryption JEP (0027)
stpeter at jabber.org
Wed Dec 11 01:03:04 UTC 2002
Thanks for your interest. Please note that JEP-0027 is Informational and
describes current usage only. Your offer of a new JEP is timely. However,
it would best occur within the XMPP WG since encryption is a requirement
for our IETF efforts. I recently removed the informational OpenPGP content
from our xmpp-core Internet-Draft and what we really need is a new I-D
describing a relatively lightweight but correct protocol for end-to-end
encryption. Care to take a stab at it? You can find out more about the
XMPP WG here:
Jabber Software Foundation
On Tue, 10 Dec 2002, Matt Tucker wrote:
> Hey all,
> The "XML Encryption Syntax and Processing" spec became an official W3C
> recommendation today. You can find it at:
> It would probably be a good idea to consider modifying the encryption
> JEP to use it. The current JEP is at:
> The W3C spec has a number of advantages over the current JEP:
> * It's an official spec that will likely be widely adopted and
> supported by various programming libraries. That should make it easier
> for people to understand and implement.
> * The W3C specification allows for multiple (and arbitrary) encryption
> algorithms. The current JEP only allows PGP. PGP, although popular, is
> not a widely accepted encryption algorithm among those that truly need
> encryption (banks, military, etc).
> * The W3C spec specifies ways to do key exchange, something that's not
> covered in the JEP.
> At a high level, it would probably make sense to support the W3C spec in
> two ways:
> 1) Allow encryption of any element content.
> 2) Provide a <jabber:x:encrypted> block for arbitrary encrypted stuff
> attached to packets. The current use of "jabber:x:encrypted" seems to be
> a a weakness in the current JEP, in my opinion. Why should that element
> *always* be a message body?
> So, a sample encrypted message might look something like the following:
> <message to='person1 at jabber.org' from='person2 at jabber.org'>
> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
> (Note: if you read through the W3C recommendation, you'll find this is
> the simplest possible form since it's using assumed keys rather than
> explicit ones, etc)
> The controversial part of this proposal is that the body section
> contains contains XML and encrypted data, which would not look nice on
> many clients. The current JEP tries to be backwards compatibile for
> clients at the expense of correctness. I consider this to be a bad
> tradeoff for a spec like this, but it will need discussion.
> One thing that might mitigate problems was if the body tag was given an
> optional type attribute (perhaps using MIME types). This would be
> generally useful for many things such as:
> <body type="text/plain">
> <body type="text/html">
> <body type="application/x-java-serialized-object">
> Similarly, there could be a type for encrypted bodies.
> I'm definitely interested in working on the JEP, but wanted to see if
> others had general comments about the discussion above first.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards