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: Ryan Sleevi <sleevi@google.com>
Date: Wed, 9 Jul 2014 12:45:19 -0700
Message-ID: <CACvaWvb4WFgF0=CJAj6VT5pxWLNHmgD6vUx1SGZLQRLOfeH99w@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Wed, Jul 9, 2014 at 12:33 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 7/9/14, 3:16 PM, Ryan Sleevi wrote:
>> This is covered in
>> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/
>> spec/Overview.html#algorithm-normalizing
>> ("if alg is an IDL object -> if member is nullable")
> I don't believe it is.
> Specifically,
> 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.

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.

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')

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?

> 2)  Per these steps, if member is nullable and present and the value is
>     null, the value is left as-is.
but the prose assumes the value will be an ArrayBuffer.  Does this spec
> I do agree the ArrayBufferView case is covered by <https://dvcs.w3.org/hg/
> webcrypto-api/raw-file/tip/spec/Overview.html#concept-
> clone-CryptoOperationData>, though that section should make it clear that
> it's the canonical (I presume) ArrayBuffer.prototype.slice that's used to
> do the copying.

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.

The choice of ArrayBuffer.prototype.slice was to reflect the ES6 language,
, which is what it defines the canonical type as (e.g. it doesn't use a
%Foo%.prototype.slice notation like TypedArray)

> Now that I've read this normalizing section, I have a few other comments
> on it too:
> * "If alg is an IDL object:" is a bit confusing; people might think it
> means "object defined in IDL", which is not the intent.  It should either
> link to http://heycam.github.io/webidl/#es-object or just drop the "IDL"
> part.


> * I'm not sure why we're returning Error instances from the "normalize an
> algorithm" steps instead of just throwing them as exceptions.  The latter
> will do the right thing because WebIDL will convert them to rejected
> promises, and seems a lot less confusing.
> -Boris
Received on Wednesday, 9 July 2014 19:45:47 UTC

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