[standards-jig] Fw: JEP-102 XMPP Seccurity extension
jean-louis.seguineau at antepo.com
Fri Jul 4 18:14:57 UTC 2003
This the original first comment I received from temas (hope your feeling
better), that I have not yet been able to address properly.
One thing though, temas was already hinting at the JEP being too binding,
and I can assure you that this is far from what I intended to convey. After
all XMLEnc and XMLDsig are meant to be applied to any XML element, and when
I describe the JEP as being a framework, I really meant that apart from
certain mandatory packet structure (like in the key exchange part) the way
other XMPP stanzas were to be encoded was pretty much left to the
implementer. It is obviously not what is understood by the first commenters,
and I can trace that to my redaction style. I such conditions, I could do
with some help in that respect. Temas, in view of the draft you had started
working on, would you like to co-author JEP102 ?
----- Original Message -----
>From: "Thomas Muldowney" <temas at box5.net>
To: <jean-louis.seguineau at antepo.com>
Sent: Thursday, June 26, 2003 3:00 PM
Subject: JEP-100 Comments
> Hey! I'm really glad to see this JEP, I just wish I had known about it
> sooner because I've been writing a nearly identical JEP! I would love
> to chat about it more, unfortunately I haven't been able to subscribe to
> you (some gabber2 bug I need to fix). So I'll send you a list of some
> initial knee-jerk reactions and we can go from there.
> Here are my current notes I was just starting to JEP:
> Mostly section 4.1 is where I wrote out a lot of what I was thinking.
> The first thing that jumps out at me is, I feel the xmlenc spec should
> be further embraced and used for many different elements. Examples 4-8
> show all the different ways I feel it could be used, not specific to
> <message> either. Take your register usage, for example, why not
> negotiate the session before even requesting the register? Then any
> Mallories would never even be able to see that you are actually doing a
> register, it could be an auth, or anything else allowed at that stage.
> To take that further I was pondering a super encryption definition so
> that I could send a message encrypted to the server with a payload that
> is encrypted to the final destination. That isn't fully worked out
> Next, I was looking to do a seperate JEP that would define public key
> exchange either via Jabber using the w3's key definitions or using SI.
> I hadn't really decided on which, but I felt it needed to be outside of
> the Key Agreement exchange for cacheing and size reasons. The presence
> examples you use are interesting.
> I'm confused by Section 7. What keys are being transported there? Is
> this a general symmetric key transport mechanism?
> In my reading I missed discussion on the length of a negotiated
> session. My assumptions are that it lasts until explicitly ended, or
> the other user goes offline. This presents the issues with sending
> messages. They need to be accompanied by rules to state they shoudl
> never go offline (JEP-79 Message Delivery Semantics). If an offline
> message is needed then it could be done by generating a random key for a
> chosen algorithm (probably a MUST algorithm so that it is known to be
> supported if the other side says they support the overall JEP), the key
> is used to encrypt the message, the key is then transported with the
> message using one of the public key transport layouts defined in XMLEnc
> such as RSA. Obviously there's more to it, but that's a quick overview
> of what I and some others discussed.
> Some other tidbits such as using JEP-20 feature negotiation in the
> actual exchanges seemed appropiate, as I did in my examples.
> This is the first stuff that comes to mind and I'd love to discuss it
> all much deeper and get a solid solution.
More information about the Standards