Re: IANA registry for WebCrypto?

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

Received on Friday, 18 January 2013 21:12:37 UTC