Re: IANA registry for WebCrypto?

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.

JOSE is intended for wire representation.
WebCrypto is intended for API consumption.

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.

>
>
> In both cases, the net semantic content is the same.  Honestly I think both sides could benefit from aligning; the end result might be less verbose than the current WebCrypto syntax, and more clearly constructed than the current JOSE syntax.
>
> --Richard

Received on Friday, 18 January 2013 20:50:10 UTC