[xmppwg] RE: [standards-jig] Encryption JEP (0027)

Ben Schumacher ben at blahr.com
Wed Dec 11 21:25:52 UTC 2002


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

AFAIK, the answer to your question is no. Its agreed pretty much
universally that there should be some encryption, for privacy reasons,
but no specific requirements have been outlined.

The question I have is this, is this necessary in the initial IETF
drafts? Is this something that couldn't be layered on later? Does the
current protocol have enough flexibility to allow use to easily add-on
XES-based encryption later?

I think that summarizes my feelings on the matter. Comments?

bs.

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
|>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9961eUpoGqensAXIRAuFNAKCUr32LUo3XbeaIO+anLs1538NciwCdGViT
CjohTGNpZSLDxRs8HrRYHjw=
=/LTE
-----END PGP SIGNATURE-----




More information about the Standards mailing list