Subject: [woes] Why the trail of WOES

From: Sean Turner <[email-masked]>
Date: Mon, 28 Mar 2011 10:21:35 +0200

Personally, I think that the format question is not the one we should be 
focusing on.  There's some smart people involved in this space and I 
have no doubt that in the end it'll be fine.*,**  Granted it seems that 
there are two camps I've talked to: one camp is like duh of course we 
need this and the other camp is like why on earth do we need this at 
all. So....

(being selfish here)  What I need to know is why this is needed.  I 
don't want to rat hole on all use cases, but I'd like to have some of 
them articulated on the list so everybody can get on the same page. 
Assuming the plan would be to go for WG eventually, then answering this 
will also help an AD explain to other IESG members who will no doubt ask 
why one of the other 3-4 solutions out there (for some value of out 
there) can't be used.

I've heard a couple of things like ASN.1 sucks, XML Dsig/Enc sucks, 
there are no "good" tools for either, and there's no access to the 
"goodies" in browsers.

Why is doing this going to take over the Web application space?  Is the 
next generation of coders just going to dump it and say JSON' is better 
(i.e., this isn't a NIH kind of thing).

(I might have this all wrong so please correct me if I'm wrong) My 
understanding is that in a client-server scenario (understand that this 
work will likely also support server-to-server comms), the client/sever 
will exchange these messages, the client is provided the JavaScript to 
process the message (including algorithms) and that this exchange is 
probably done over a TLS protected link.  Is the javaScript signed or 
are we going to rely on the TLS protected link?  If it's signed, then 
does it verify back to a trust anchor in the browser?  I guess I'm 
pulling at this thread because there's all this wonderfully FIPS 
evaluated crypto code in Mozilla and IE (and presumably Chrome/Opera at 
some point) being used for TLS and now we're going to instead use some 
other code.  Has anybody actually asked whether an API could be 
developed to access the crypto, ASN.1, cert handling, etc?

Looking forward to figuring this all out.

spt

* I'd note that personally, I'd prefer

** I'd note that as RFC 5406 points out:

  Security protocols are very hard to design; rolling out a new one
  will require extensive theoretical and practical work to confirm its
  security properties and will incur both delay and uncertainty.

For me this translates to profiling something that we already understand 
as opposed to doing something completely new.