Re: IANA registry for WebCrypto?

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 22:08:38 UTC