Re: IANA registry for WebCrypto?

On Jan 23, 2013, at 11:24 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Wed, Jan 23, 2013 at 7:43 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>> To try to direct this to a more concrete proposal for what would go in an "algorithm identifier" document / registry:
>> 
>> -----BEGIN STRAW-MAN-----
>> 1. An algorithm identifier is a JavaScript dictionary of the same general form defined in the current WebCrypto spec.  Entries in the dictionary may be JSON types or ArrayBufferViews.
>> 
>> 2. Algorithm identifiers may be serialized/deserialized by applying JSON encoding/decoding, with Base64 encoding/decoding applied to fields that contain ArrayBufferViews.
>> 
>> 3. Algorithms may have "short names" that represent an algorithm identifier with some fixed parameters.  The expansion of short names must be specified in a separate document.
>> 
>> 4. Define the following registries:
>> 4.1. Algorithms: names, parameters, spec reference
>> 4.2. Algorithm short names: name, spec reference
>> -----END STRAW-MAN-----
>> 
>> This is basically the WebCrypto spec (1, 4.1) with some bits about how to play nice with serialization and abbreviation (2, 3, 4.2).  The function of the "short names" part is to make explicit the connection between shorter on the wire identifiers and API identifiers, so that developers don't have to figure it out on their own.
>> 
>> I don't care if this document gets written in the IETF or W3C, as long as it's common to WebCrypto and JOSE.  I would be happy to edit it.
>> 
>> --Richard
> 
> And now, added to the registry proposal, is a proposal for
> 1) JOSE parallelism (which was previously resolved)
> 2) An attempt to provide a wire-level encoding for all API parameters
> (by attempting to define a "toJSON" / "fromJSON" function for WebIDL /
> web native objects)

This does not have to be part of the API.  As long as the format is specified, you can trivially implement the format in JS.


> 3) Create an API where all sorts of weird or ambiguous combinations of
> parameters must be handled, and which makes error handling ambiguous,
> at best,
> 
> eg: { 'iv': 'foo' }
> 
> a) Did the author intend for the IV to be the octets corresponding to
> the US-ASCII representation of the string 'foo'?
> b) Did the author intend for the IV to be the octets corresponding to
> the UTF-16 representation (eg: DOMString) of the string 'foo'?
> c) Did the author make a mistake and treat a byte sequence as a string?
> d) Or is that a base64 encoded string 'foo' that should be decoded?

As long as the fields are typed (as they are in the current spec), then there's no ambiguity about how to parse the fields.  For example, if 'iv' has type ArrayBufferView (as in the current spec), then the answer is (d) above.  If it doesn't decode properly, that's a decoding error.

And again, this logic doesn't have to be in the API (although it would be convenient!), it can be done in JS.

The *only* work this would imply for a UA developer is to implement short name expansion (4.2), which is just a lookup table.

--Richard

Received on Thursday, 24 January 2013 16:05:26 UTC