[standards-jig] new security JEP

Thomas Muldowney temas at box5.net
Sat Jun 8 18:46:04 UTC 2002

Sorry I didn't get these out yesterday like I thought I would but life
got hectic.  We found out that our child to be is a boy =)

Anyway, I finally got around to reading JEP31 a couple more times, I
probably need to read it a few more but here are some more comments. 
Largely related to XES and your old replies below.

On Thu, 2002-05-09 at 10:12, Paul Lloyd wrote:
> 1) One motivation here is for the protection of XML docs in a session
> environment rather than an atomic document environment.

I believe the XES does a fair job of allowing for a more session based
environment by allowing for encryption on a per element, element content
and cdata basis.  To further that it has the semantics for key agreement
that would prove beneficial to a session based system.

> 2) Another motivation is to avoid excess public key operations.

I believe XES does fairly well in this regard with it's key agreement
semantics and key wrapping.

> 3) The canonicalization work done by the W3C should prove valuable and be
> incorporated wherever possible.

Definatley agree

> 4) XKMS should be a fine way for implementations to deal with appropriate key
> management issues.
> Fundamentaly, I wish to propose creating and adopting an optimized protocol
> for the IM environment and its content, and this protocol should be based on as
> many appropriate standards as possible. Furthermore, one aspect of optimized must
> address issues of performance, scalability, and ease of use.
> Hopefully, with that said, our views and goals WRT to protecting Jabber
> conversations are not too dissimilar.

XKMS scares me due to it's heavy reliance on SOAP still.  While that
might be OK if we have JabberSOAP or something along those lines, it
still scares me =)

> > 3.3.4 Specifies that cryptographic operations over character strings
> > must be carried out over the UTF-16 encoding of the string. I am curious
> > why UTF-16 and not UTF-8. We generally handle strings as UTF-8
> > currently. UTF-8 frees us from some byte ordering concerns and are more
> > efficient to store. Cryptographically, a UTF-8 string tends to have more
> > entropy than an equivalent UTF-16 string. Finally, it would just make my
> > life easier to use UTF-8.
> Your points are well taken; all that's needed is a canonicalization mechanism.
> My suggestion of UTF-16 is largely arbitarary.
> Also, the cryptographic implications of UTF-16 are the reaosn I did not
> include any stream ciphers in the first proposal.
> Finally, I support anything that makes a person's life easier.

I agree with the UTF-8 argument by Mike Lin.  If we wanted to support
servers and components as end points they'd have to start doing UTF-16.

> > These points aside, the protocol thusfar is well thought out and
> > elegantly designed, accompanied with lucid commentary and clear
> > explanation. My complements to the author.
> Thanks!

Overall it seems everyones goals are definitely along the same vein.  A
few general thoughts and questions.  First, did I miss a list of
suggested algorithms somewhere?  I understand it's a framework, but we'd
probably need to look at a base requirement.  Next, a curious thought I
had while typing this up, is it at all possible to do your negotiation
_in_ XES?  It seems like it might be possible, and that could
potentially allow for more comfort from some people such as myself. 
Just a thought.  I'll continue reading the JEP over and over and grasp
it further, but overall I like it a lot.  I'm just concerned about not
follwing the w3 position that is a Canidate Recommendation state.


More information about the Standards mailing list