Re: PROPOSAL for ISSUE-12: Should the API distinguish between algorithm and operation parameters?

On Mon, Apr 22, 2013 at 2:06 PM, Mark Watson <watsonm@netflix.com> wrote:
> http://www.w3.org/2012/webcrypto/track/issues/12
>
> Based on the discussion and assuming the acceptance of the proposal in
> ISSUE-42 (http://www.w3.org/2012/webcrypto/track/issues/42), I propose the
> following:
>
> 1) Define a new dictionary, OperationParameters:
>
> dictionary OperationParameters {
> };
>
> 2) Change the first parameter of encrypt(), decrypt(), sign(), verify() to
> be of type OperationParameters
>
> 3) Change the base class of the following dictionaries to be
> OperationParameters
>
> RsaSsaParams
> RsaPssParams
> RsaOaepParams
> EcdsaParams
> AesCtrParams
> AesCbcParams
> AesGcmParams
>
> 4) Decide whether the hash is a property of a HMAC Key or an operation
> parameter and then either
> 4.1) (hash is a property of the HMAC Key): remove HmacParams from the
> sign/verify rows of the table in 19.12.2, or
> 4.2) (hash is an operation parameter): change the base class of HmacParams
> to be OperationParameters and define new HmacKeyGenParams as follows:
>
> dictionary HmacKeyGenParams : Algorithm {
>   // The length, in bits, of the key.
>   [EnforceRange] unsigned short length;
> };
>
>
> ...Mark

Mark,

It seems wrong to couple the HMAC discussion into the discussion about naming.

Am I correct in stating that this proposal is done purely on cosmetic
grounds - that is, there is no technical basis or reason for this
change?

This does introduce further complexity in defining if and how
normalization occurs for operation params - requiring a definition of
a second set of processing functions - so I would like to understand
what benefits (if any) this proposal has.

Cheers,
Ryan

Received on Monday, 22 April 2013 22:46:24 UTC