[standards-jig] Encryption JEP (0027)

Thomas Muldowney temas at box5.net
Wed Dec 11 01:53:14 UTC 2002


The old jep 31 had some work done on the topic.  Paul was going to
update it with regards to XES, but I haven't heard from him in a while.

http://www.jabber.org/jeps/jep-0031.html

--temas


On Tue, Dec 10, 2002 at 08:43:45PM -0500, Matt Tucker wrote:
> Peter,
> 
> I'd be happy to participate in the process. Have there been any
> discussions about the goals/requirements of an encryption protocol? I
> browsed through the xmppwg list archives and didn't find anything (based
> on message subjects).
> 
> Regards,
> Matt
> 
> > -----Original Message-----
> > From: standards-jig-admin at jabber.org
> > [mailto:standards-jig-admin at jabber.org] On Behalf Of Peter Saint-Andre
> > Sent: Tuesday, December 10, 2002 8:03 PM
> > To: standards-jig at jabber.org
> > Subject: Re: [standards-jig] Encryption JEP (0027)
> > 
> > 
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20021210/1d8dcf46/attachment.sig>


More information about the Standards mailing list