Re: Algorithm procedure descriptions

As mentioned on the bug, I don't think this will work. Consider PSS's
inputs, for example.

For any 'generic' definition of inputs, you're essentially at best saying
"Pass the params down to the next layer".

A fair comparison of where "linking to a spec and providing a table" is
insufficient is the ECDSA specification -
https://dvcs.w3.org/hg/webcrypto-api/raw-file/737e12c5ad33/spec/Overview.html#ecdsa-operations-
which deals with integers and bitstrings and thus conversions and
ordering is necessary to be specified.

Further complicated by the fact that the signing steps themselves depend on
the named curve being used. For example, Curve25519 would *not* reference
X9.62 (nor would it be usable for sign/verify), and the ECDHE computation
would be different as far as references go (SEC1 vs Curve25519), even if
they yield the same external results.

So I agree algorithms need specifications, I agree we should reference as
much as possible existing specifications, but I don't think a table-based
approach is sufficient.

I also find the reference to RFC3447 (eg: as proposed in the bug) to be
confusing with respect of determining how the hash is computed. What if
there are additional parameters to the hash that need to be mapped from the
algorithm dictionary? What about potential polyfill/extension points? It's
insufficient to suggest we provide M as the input, since the first step of
RFC 3447, Section 8.2 is to encode, as per section 9.2, which requires
defining the hash function.


On Mon, Jan 27, 2014 at 7:53 PM, Richard Barnes <rlb@ipv.sx> wrote:

> That seems useful to me.  For well known things, it might seem a bit
> pedantic.  But it seems like a good precedent to set for new things that
> might come along that might be less clear on first look.
>
> --Richard
>
>
>
> On Monday, January 27, 2014, Mark Watson <watsonm@netflix.com> wrote:
>
>> I provided an example in the bug, as requested.
>>
>>
>> On Mon, Jan 27, 2014 at 9:12 AM, Mark Watson <watsonm@netflix.com> wrote:
>>
>>> All,
>>>
>>> I just filed this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24410
>>>
>>> I think we need to get this one done before LC.
>>>
>>> ...Mark
>>>
>>
>>