Re: AlgorithmIdentifier in encrypt/decrypt/sign/verify operations

All,

Does anyone have an opinion on this ? Ryan, you usually have an opinion ;-)

I wonder now if the AlgorithmIdentifier to encrypt/decrypt/sign/verify
should be replaced by a separate OperationParams dictionary, so we can be
very clear about which parameters need to be specified for the operation.
The AlgorithmIdentifier and AlgorithmParameters are always part of the Key
being used and do don't need to be repeated as a method parameter.

On the HMAC point, is the choice of hash an algorithm parameter or an
operation parameter ?

...Mark

On Wed, Mar 27, 2013 at 6:10 PM, Mark Watson <watsonm@netflix.com> wrote:

> This may be related to ISSUE-12 and apologies again if this has been
> discussed before - it is coming up now frequently in implementation
> discussions.
>
> In the encrypt/decrypt/sign/verify operations, two AlgorithmIdentifier
> objects are provided as input, one as an explicit parameter and one which
> is associated with the Key object (and appears as the Key.algorithm
> attribute). Presumably it is an error if the "name" member of the
> dictionary does not match (after normalization), though I am not sure if
> this is clearly specified.
>
> In some cases, it is specified that the params member will have different
> types in these two places (I'm assuming that the Key.algorithm attribute
> takes the value that was provided to generateKey). For example for AES-CTR,
> the params in Key.algorithm contains the key length and params in
> encrypt/decrypt contains the IV.
>
> But for other cases things are very unclear. For example, for HMAC, the
> same AlgorithmParameters type is used, containing the hash algorithm. In
> this case it seems completely redundant to provide the same object twice to
> the sign/verify call (once in the method parameters and again in the
> Key.algorithm attribute).
>
> Am I missing something ? Does anyone else find this confusing ?
>
> I think the confusion could be resolved by
> (i) replacing the AlgorithmIdentifier argument to
> sign/verify/encrypt/decrypt with AlgorithmParameters.
> (ii) for HMAC, the params provided to sign/verify must be null, as the
> hash algorithm should have been provided when the Key was
> created/imported/unwrapped
>
> As a side note, I believe that to generate a HMAC key we need to specify
> the key length. At least according to FIPS 198-1 the key, K, can be of any
> length. So, either we require in WebCrypto that it is a particular length
> (say, the same size as the hash function), or we need a length parameter to
> generateKey for HMAC.
>
> ...Mark
>