W3C home > Mailing lists > Public > public-webcrypto@w3.org > July 2014

Re: Spec for RSA-OAEP doesn't say what to do for null or missing or array buffer view labels

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 09 Jul 2014 16:09:37 -0400
Message-ID: <53BDA181.4070409@mit.edu>
To: Ryan Sleevi <sleevi@google.com>
CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On 7/9/14, 3:45 PM, Ryan Sleevi wrote:
>     1)  Per step 12.1.2 if member is nullable and is not present then it's
>          left as "not present".  The fact that this is based on nullability,
>          seems like a bug to me, by the way.
> Can you clarify? Step 12.1.1 handles the "not present" case.

12.1.1 only applies to non-nullable members.

> To make sure I follow:
> All dictionary members can be "not present", but for the specs purpose,
> any dictionary member listed in an algorithm dictionary, that isn't
> optional/nullable (aka ?) MUST be present.

I think this conflation of "nullable" and "optional" is not a good idea, 
though it's a common mistake people coming from C/C++ make with Web API 
design.  If you just want a non-optional dictionary member, you should 
throw if it's "not present".  Things should be nullable only when you 
explicitly want to allow JS null as a valid value that doesn't trigger 
an exception, not because you want to indicate that they're allowed to 
be missing.

One option, by the way, is to make sure we have default values available 
for all the things you want to allow to be missing, using those default 
values in dictionaries as needed, and then "not present" will just cause 
exceptions, since it will mean there was no default value.

> 12.1.2 handles the case where it's optional/nullable. If a field is
> optional/nullable, and not present, it doesn't get set on
> normalizedAlgorithm. If it is present, and null, then
> normalizedAlgorithm is set to the null value (rather than 'not present')

Yes, agreed.

> The concern is that the prose for label doesn't handle things the same
> as AES-GCM's prose for additioanlData (present and not null), right?

Yes, exactly.

> Can you recommend language that would satisfy this? ES6 does not
> (AFAICT) refer to these built-ins as "Canonical", hence the desire to
> find appropriate language.

ES6 calls these "initial values", I believe.  See e.g. the table at 
(which is also how the rest of the spec refers to these things; by the 
names defined in that table).

> The choice of ArrayBuffer.prototype.slice was to reflect the ES6
> language,
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-arraybuffer.prototype.slice
> , which is what it defines the canonical type as (e.g. it doesn't use a
> %Foo%.prototype.slice notation like TypedArray)

I'm not sure I follow the distinction.  The spec section you're pointing 
to defines the initial value of ArrayBuffer.prototype.slice....

Received on Wednesday, 9 July 2014 20:10:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:23 UTC