[standards-jig] Encryption JEP (0027)

Matt Tucker matt at jivesoftware.com
Tue Dec 10 23:50:53 UTC 2002


Hey all,

The "XML Encryption Syntax and Processing" spec became an official W3C
recommendation today. You can find it at:

http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/

It would probably be a good idea to consider modifying the encryption
JEP to use it. The current JEP is at:
http://www.jabber.org/jeps/jep-0027.html

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'>
  <body>
    <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
     xmlns='http://www.w3.org/2001/04/xmlenc#'>
        <CipherData>
          <CipherValue>A23B45C56</CipherValue>
        </CipherData>
      </EncryptedData>
   </body>
</message>

(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:

 <message>
   <body type="text/plain">
 </message>

 <message>
   <body type="text/html">
 </message>

  <message>
    <body type="application/x-java-serialized-object">
  </message>

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.

Regards,
Matt 




More information about the Standards mailing list