[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.

--temas






More information about the Standards mailing list