[standards-jig] Encryption JEP (0027)

Peter Saint-Andre stpeter at jabber.org
Wed Dec 11 01:03:04 UTC 2002


Hi Matt,

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:

http://www.jabber.org/ietf/

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php

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:
> 
> 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 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 




More information about the Standards mailing list