[standards-jig] Re: JEP-0102

Thomas Muldowney temas at box5.net
Thu Jul 3 17:21:05 UTC 2003


Jean-Louis can you forward my email to you to the list?  I dont' have 
access to the box that sent it right now.

Personally, I'm in love with this JEP.  I was in the process of writing 
something _very_ similar and Jean-Louis beat me to it.  I sent him my 
laundry list and I want to work with him to make it more readable to the 
  encryption, xmlenc, whatever neophyte.  One of my big concerns is the 
lack of any element encryption, and I think that it can be solved 
easily.  Hopefully Jean-Louis can forward my email and see my examples.

About the key exchange, reread xmlenc.  XMLEnc does not have any actual 
_online_ key agreement or key exchange.  I think the use in this JEP is 
pretty well done, but might need some minor alterations.

Overall I'm super excited, for anyone that's having major issues reading 
through this, thing secsh and Jabber.  That's very much what this is. 
It's a vital piece to Jabber, and I can't wait to use it!

--temas


Matt Tucker wrote:
> Hello all,
> 
> This JEP was originally seen on the security jig mailing list and I made 
> some comments there that may be good to discuss again here.
> 
> As outlined in my email below, I still have two major concerns with this 
> JEP:
> 
>  1) I believe that arbitrary packets should be encryptable, which this 
> JEP does not allow.
>  2) I think the key exchange in this JEP is too complex. XMLEnc provides 
> a simpler mechanism, or perhaps key negotiation should be broken off 
> into a seperate JEP so that those that already have a PKI can use the 
> encryption but not the key exchange in this JEP.
> 
> Regards,
> Matt
> 
> --------------------------------------------------------
> 
> Hey all,
> 
> There is lot of interesting content in the JEP. I'm very impressed with 
> Jean-Louis's thoroughness! My comments so far:
> 
>  * Secret key negotiation is fairly complex, as demonstrated by the fact 
> that most of the JEP is devoted to it. I'd be curious to know why secret 
> keys were pursued rather than just relying on public/private key 
> encryption like S/MIME, etc does. I think there is the potential for a 
> massively simplified spec if key exchange is as simple as sharing public 
> keys. Clients are then free to trust the public key certs if they desire 
> (using root CA's, etc).
> 
>  * The approach taken by the JEP is to attach encrypted content as extra 
> information, such as:
> 
> <message from="initiator at domain" to="responder@ domain" id="msg-0">
> <body>
> The real body is protected.
> </body>
> <x xmlns="xmpp:security">
> <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
>     Type="http://www.w3.org/2001/04/xmlenc#Element">
>   <CipherData>
>     <CipherValue>ad5Anasd4</CipherValue>
>   </CipherData>
> </EncryptedData>
> </x>
> </message>
> 
> This is not quite the "standard" XMLEnc approach from what I can tell by 
> reading the spec. Instead, encryption simply replaces with standard xml 
> stanzas with an encrypted form. So, a message packet might look like:
> 
> <message from="initiator at domain" to="responder@ domain" id="msg-0">
> <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
>     Type="http://www.w3.org/2001/04/xmlenc#Element">
>   <CipherData>
>     <CipherValue>ad5Anasd4</CipherValue>
>   </CipherData>
> </EncryptedData>
> </message>
> 
> The decryption step is essentially a form of packet pre-processing then 
> -- the message would look like a normal message packet after being 
> decrypted. From an implementation perspective, this often means 
> dynamically modifying the DOM of the XML sub-packet on the fly. In fact, 
> this is how all the XMLEnc libraries are implemented that I've seen.
> 
> I think this "pre-processing decryption" approach will be a requirement 
> for any e2e spec. Otherwise, it will be impossible to encrypt arbitrary 
> packet information. For example, let's say one want so encrypt an IQ 
> packet (something not covered by the Antepo spec but that is an e2e 
> requirement as far as I know).
> 
> Given the following IQ packet:
> 
> <iq>
>   <query xmlns='jabber:iq:time'>
>     <utc>20020910T17:58:35</utc>
>     <tz>MDT</tz>
>     <display>Tue Sep 10 12:58:35 2002</display>
>   </query>
> </iq>
> 
> The Antepo spec would have no possible way to encrypt this. However, if 
> we use a pre-processing approach the encrypted packet looks like:
> 
> <iq>
> <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
>     Type="http://www.w3.org/2001/04/xmlenc#Element">
>   <CipherData>
>     <CipherValue>ad5Anasd4</CipherValue>
>   </CipherData>
> </EncryptedData>
> </iq>
> 
> After it's decrypted, it looks like a normal IQ and is passed to the 
> standard XMPP packet parser.
> 
> Thanks,
> Matt
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig





More information about the Standards mailing list