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 12:37 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 7/9/14, 3:34 PM, Ryan Sleevi wrote:
>
>> Regarding how to treat null, yes, we should treat it the same way
>> AES-GCM handles an empty additionalData
>>
>
> I would actually recommend dropping nullability here altogether, unless
> there's some sort of back compat need.  Missing should be treated as empty,
> ArrayBuffer and ArrayBufferView should be copied as already in the spec,
> null should just throw.
>
> -Boris
>
>
Well, this was intentional, because the desire to specify algorithm
normalization in a manner that is independent of per-algorithm
sub-specifications. That is, a generic algorithm defined entirely by the
Web IDL types.

If we go the route of dropping nullability, some new way for expressing
that some fields, of some dictionaries, are optional.

The goal of algorithm normalization (in it's original form, and now
rewritten form) was to avoid the need to prosaically check your inputs on
the algorithm-specific invocation; the generic algorithm normalization will
have already validated that all inputs are sane and valid.

Put differently, we want to allow some fields to be optional ("not
present"), and want a way for algorithm normalization to know, purely by
IDL, whether it's OK for something to be "not present". Since all
dictionary members (in Web IDL) are optional-by-default, nullability was
hijacked as this signal. Otherwise, I'd potentially see needing to express
during algorithm registration the set of members that MUST be present in a
given dictionary, so that algorithm normalization can ensure the set of
members are present post-normalization, and pre-algorithm specific
invocation.

If that makes any sense.