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

On Wed, Jul 9, 2014 at 3:45 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
> 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?
>

Yes.  I think we need something in Section 24.4 of the same form as the
AES-GCM text
"Let additionalData be the contents of the additionalData member of
normalizedAlgorithm if present and not null and the empty octet string
otherwise."

=> "Let label be the contents of the label member of normalizedAlgorithm if
present and not null and the empty octet string otherwise."



>
>
>> 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,
> 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)
>
>
>>
>> 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.
>
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26300
>
>
>>
>> * 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
>>
>>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26301
>
>
>
>