Re: IANA registry for WebCrypto?

On Fri, Jan 18, 2013 at 1:12 PM, Richard Barnes <rbarnes@bbn.com> wrote:
> This is important, so I'll say it up front:
>
> JOSE is not written in stone.  It is a working draft, just like the WebCrypto spec.
>
>
> On Jan 18, 2013, at 3:49 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> On Fri, Jan 18, 2013 at 12:19 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>>> On Jan 18, 2013, at 2:56 PM, Harry Halpin <hhalpin@w3.org> wrote:
>>>
>>>> On 01/18/2013 08:53 PM, Richard Barnes wrote:
>>>>> Another way to solve this would be to kick the algorithm ID specification over to JOSE.  ISTM that it would be a good idea in general for the two groups to use the same algorithm identifiers.
>>>>
>>>> I believe that was already discussed and there were two different levels of abstractions re ciphersuites/defaults. That is, I think, still the case. Is it not?
>>>>
>>>> Regardless, I'll bring that option up with the Security ADs and see if we can find a quick way to solve this.
>>>
>>>
>>> I don't think that's really accurate.  There aren't any defaults in JOSE either.  The main differences are:
>>>
>>> 1. JOSE provides some short names for combinations of algorithms
>>>
>>> WebCrypto: { name: "HMAC", params: { hash: "SHA-256" } }
>>> JOSE: "HS256"
>>
>> Let's be clear: JOSE *only* provides short-names for combinations.
>>
>> It does NOT provide an extensible syntax that say, WebCrypto, ASN.1,
>> PKCS#11, CNG, CDSA, CryptoAPI, or others do.
>
> You say this as if it's final, finished, forever.  It's not; it's a working draft just like WebCrypto.
>
> Even if all JOSE wants is short names, I think there would be benefit in documenting how they expand to WebCrypto IDs.
>
>
>
>> JOSE is intended for wire representation.
>> WebCrypto is intended for API consumption.
>
> Of course, JOSE object ultimately get consumed by APIs, so this is not really a distinction.  JOSE algorithm identifiers ultimately have to get mapped to something that goes into an API.
>
>
>> I thought we already hashed all of these discussions out and agreed
>> that there was consensus to NOT go with JOSE's approach.
>>
>>>
>>>
>>> 2. JOSE stores algorithm parameters outside the algorithm field (all of the information is still there)
>>>
>>> WebCrypto: { name: "AES-GCM", params: { iv: /* ArrayBufferView */ } }
>>> JOSE: { enc: "A128GCM" }.[base64(iv)]
>>
>> This, to me, is unacceptable. This *forces* all parameters to be
>> copied AND transformed, while ArrayBufferView, by definition, allows
>> this to be done without copying parameters.
>>
>> Further, this creates a series of edge cases like attempting to use
>> A256GCM with a 128-bit AES key.
>
> I actually agree (let's have "AGCM" :) ).  But that argues for fixing JOSE, not for cutting off the conversation.  It would actually be great to have this sort of comment on the JOSE list; I'll agree with you there too.
>
> Just to emphasize again: JOSE is not written in stone.  It is a working draft, just like the WebCrypto spec.
>
> Can we at least try to work together?
>
> --Richard

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.

Received on Friday, 18 January 2013 21:28:46 UTC