[Bug 26465] Algorithm normalization doesn't allow arbitrary operations for AlgorithmIdentifier fields

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26465

--- Comment #3 from Mark Watson <watsonm@netflix.com> ---
Ok, I am missing a layer. We need to be a able to associate operations with
member values *inside* the target dictionary type, not with the target
dictionary type itself.


(In reply to Mark Watson from comment #0)
> Our algorithm normalization rules assume that the target Dictionary type is
> dependent on the ( algorithm name, operation ) pair.

In the algorithm normalization rules, we start with the [[supportedAlgorithms]]
associative container, which maps from the operation to an aliasesAndAlgorithms
associative container which contains an "algorithms" entry which is an
associative container, which maps from algorithm names to a single leaf value
which is an IDL Dictionary type.

Aliases aside, this maps from a pair ( algorithm name, operation ) to an IDL
Dictionary type which is the target type for the normalized algorithmIdentifier
value.

> 
> Algorithm normalization is invoked recursively for member entries of
> AlgorithmIdentifier type.

If we find a member, X, of the target IDL type which has type
AlgorithmIdentifier, we recursively invoke the algorithm normalization
algorithm. The input to this is the algorithm identifier value itself (X) and
an operation value.

> The name to be used is just the value specified in
> the input data, but the operation is "hard-coded" in the specification as
> follows:
> - if the type is HashAlgorithmIdentifier, then "digest"
> - otherwise, use the same value as the outer normalization

Step 12.5 in section 2.4.5 defines the rules for the operation value to be
used. The only options are "digest" or the same as the original value.

So, for example, if I am performing a 'sign' operation then any parameters to
this of type AlgorithmIdentifier (or subclass) are normalized with operation
name 'sign' or 'digest' depending on whether the the type is a
HashAlgorithmIdentifier or not.

> 
> This seems restrictive. 

Because I cannot have an member in an algorithm identifier that identifies an
algorithm to be used with an operation other than 'digest' or the same as the
outer algorithm identifier.

Suppose I have a new signature algorithm which must be parameterized by the
identity and parameters of an encryption algorithm which is somehow used in the
signature process.

Dictionary NewSignatureAlgorithm : AlgorithmIdentifier
{
   AlgorithmIdentifier enc;
}

example:

{ name : "NewSignature", enc: { name : "AES-GCM" } }

I need enc to be normalized with operation set to "encrypt", not "sign".

> 
> I suggest that the "leaf" values in the [[supportedAlgorithms]] structure be
> changed from just a type to a ( type, DOMString? ) pair,

Instead of the values of the associative container found at the "algorithms"
member of the associative container at the "sign" member of
[[supportedAlgorithms]] being just an IDL type, they would be a pair ( type,
DOMString? ).

To make it more abstruse we could say this is another associative container
with members "type" and "operation".

Here I made a mistake in the proposal, we need to associate operations with
values *inside* this target type. Instead of a DOMString we could do one of the
following:

- a container which mirrors the structure of the target type, specifying for
each AlgorithmIdentifier member what the operation is to be used to normalize
it (would need to support members which are themselves Dictionaries).
- a container which maps from sub-types of AlgorithmIdentifier to the operation
name, so that extension specifications can define that
NewHashAlgorithmIdentifier should use "digest" and EncryptAlgorithmIdentifier
should use "encrypt" etc.

Of course this is not needed for any dictionary member which is not an
AlgorithmIdentifier (which was the reason for the nullability before).

> with the rule that
> the DOMString must be non-null if and only if the type is or is derived from
> AlgorithmIdentifier.
>
> Then this would be the operation used for recursive
> invokation of algorithm normalization.
> 
> The 'define an algorithm' procedure and the invokations of it would need
> amending as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 30 July 2014 02:56:05 UTC