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.
_______________________________________________
woes mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/woes
