Re: IANA registry for WebCrypto?

OK, let's up-level a little bit here.  

We're not talking about File object or the One True JSON Encoding.  We're talking about tiny little simple objects to configure an algorithm.  The biggest difference is between BigInt/ArrayBufferView and their serialized forms.  

What JOSE has right now is not perfect.  It's not extensible, and it's poorly laid out.
What WebCrypto has right now is not perfect.  It's too verbose (see other email on 'params').

JOSE might benefit from better encapsulation ({name: "PBKDF2", iterations: "..."}). 
WebCrypto might benefit from some shortcuts ("HMAC-SHA-256").

This is not a huge degree of compromise.  I was just hopeful that folks would be open to trying to find a mutually agreeable solution.  Would it help if I proposed something concrete?

--Richard





On Jan 18, 2013, at 5:08 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Fri, Jan 18, 2013 at 1:57 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>>> Richard,
>>> 
>>> It's very clear from both charters that JOSE and WebCrypto are
>>> separate projects, separate efforts, and seek to meet a separate set
>>> of goals. While there is some commonality, I strongly object to the
>>> suggestion that they are at all related in purpose enough to derive
>>> value from sharing algorithms.
>>> 
>>> In all the people I've talked to who have expressed interests or use
>>> cases for this API, not a single person has expressed any interest in
>>> JOSE. It's certainly clear that the use of JWE, JWT, JW*, JWK, while
>>> certainly possible through this API, are NOT the sole intended
>>> consumers.
>>> 
>>> At it's core, JOSE is a wire format. The WebCrypto API is an API. No
>>> amount of rechartering in either WG is going to change this reality.
>>> The decisions made should best reflect their intended purposes and use
>>> cases, and should not be arbitrarily and unnecessarily joined.
>>> 
>>> It does not make any sense to me whatsoever to have an API definition
>>> handled through an IANA registry nor through a wire representational
>>> form, especially one as inefficient (for *Web Apps*) and
>>> programmer-unfriendly as JOSE.
>>> 
>>> JOSE MUST make decisions that best reflect its' design requirements -
>>> including efficient URL representation - while the WebCrypto API MUST
>>> make decisions that best reflect users' and authors' needs - which
>>> extend well beyond JOSE. There is an inherent incompatibility in these
>>> MUSTs - a point I well understood that we'd previously reached
>>> consensus on, as reflected in the decisions on ISSUE-13.
>> 
>> 
>> 
>> 
>> Ryan,
>> 
>> I can't agree that WebCrypto and JOSE are as separate as you claim.  WebCrypto needs to represent crypto constructs in JavaScript, JOSE in JSON; the difference in concept is only really serialization.  If we don't coordinate, we're going to have duplication.  These babies are inherently conjoined.
> 
> No. That's not the difference in concept.
> 
> For example, no matter how creative JOSE tries to get, it will never
> be able to *efficiently* represent a File object in JSON.
> 
> JSON as a wire format is very, very different than native JavaScript
> objects, and while you can certainly go from a JSON into an object
> that retains some semblance, we should not be conflating the two.
> 
>> 
>> As far as the need for JW* from users, the lack of interest is not actually that surprising.  It's a network effect thing.  Right now, everyone you're trying to talk to is speaking some ancient ASN.1 language that your JS has to interoperate with.  If JOSE lives up to its charter, it should be a web-friendly replacement for things like CMS and PKCS12, so that future applications can not have to deal with ASN.1.  The trick for WebCrypto is to be able to support the legacy stuff while also looking forward.
> 
> I disagree on the network effect thing - but I certainly didn't come
> here to bash JOSE.
> 
>> 
>> We do agree, however, that the current JOSE specs are developer-hostile, especially in the web environment.  It prioritizes wire compactness over developer utility in the worst possible way.  That's a major flaw in a JOSE, and a discussion that we should have over there.
>> 
>> Maybe I'm the only one who's fantasizing about a world where building secure apps is actually straightforward, with JOSE as a secure object format instead of CMS, and WebCrypto for the processing instead of platform APIs.  But I think that's the world we should be trying to build here, and we shouldn't be stopped by the failings of our current *draft* specs.
>> 
>> --Richard
> 
> The API should remain neutral. Which was the conclusion of ISSUE-13. I
> don't object to JOSE for high-level, and have certainly been trying to
> evangelize it if only to explain why some of the security decisions of
> the API have been intentionally deferred to the protocol and
> representational forms, but I think it's a much more serious misstep
> to imply one is inherently superior or the future.
> 
> JOSE is simply not an alternative to ASN.1 nor an alternative to other
> representational forms. While it may be convenient, again, the use
> cases that JOSE sets out to solve are not in line with the use cases
> that this API tries to solve. No matter how much fantasizing happens,
> you're not going to see a world where SSH is suddenly replaced with a
> JOSE-based form, nor are you going to see XMLDSig suddenly disappear
> in favour of the one true JOSE form.
> 
> Again, I'm quite supportive of JOSE solving the problems it attempts
> to solve, but I firmly believe, as I have always asserted, that we're
> talking a square peg in a round hole when it's suggested that JOSE and
> WebCrypto have significant enough overlap that all users of WebCrypto
> should be gated on JOSE's needs.
>

Received on Friday, 18 January 2013 23:15:33 UTC