Re: Hashes, names, and normalization

On Thu, Mar 13, 2014 at 5:13 PM, Richard Barnes <rlb@ipv.sx> wrote:

> We've got a couple of KeyAlgorithm interfaces that specify hashes by
> KeyAlgorithm, namely in HmacKeyIdentifier and RsaHashedKeyAlgorithm.  While
> I like recursion as much of the next guy, this seems like it leads to
> ambiguity for the web developer, since there's not a canonical form for
> specifying hashes in this way.
>

The canonical way is a KeyAlgorithm. I'm not sure I understand your remark.


>
> Could we just replace the KeyAlgorithm with a DOMString that names the
> hash?  It seems like that would only become an issue if we had parametrized
> hashes that we wanted to use with HMAC/RSA-PKCS1.  I'm not aware of any
> such hashes that we have use cases for right now.
>

Originally, it was an Algorithm (back in the day) because of attempting to
allow full parameterization (eg: reflecting the SPKI definitions as well as
the PKCS#11 definitions). For example, specifying mgf1 vs some other MGF,
or specifying an MGF alg that was different from the seed alg. These were
all parameterized options.


>
>
> (And if we were envisioning { name: "SHA-X" }, that's just excessive.)
>

See below.


>
> In WebIDL terms:
>
> [NoInterfaceObject]
> interface RsaHashedKeyAlgorithm : RsaKeyAlgorithm {
>   // The name of the hash algorithm that is used with this key
>   readonly attribute DOMString hash;
> };
>
> [NoInterfaceObject]
> interface HmacKeyAlgorithm : KeyAlgorithm {
>   // The name of the inner hash function to use.
>   readonly attribute DOMString hash;
> };
>
> (Oh, and by the way, the [NoInterfaceObject] directive is missing from
> HmacKeyAlgorithm in the current ED.)
>
> --Richard
>

The risk here being that it doesn't align with the specification (for PSS
or OAEP), doesn't align with the data storage format (for PSS-OAEP).

We also know that Keccak, at least, has a variety of parameters, for which
NIST is still tuning. There has been some suggestion that as it becomes
SHA-3, there will continue to be run-time tunable options. It remains to be
seen whether that will be expressed through symbolic name (eg:
SHA-3/256/x/y) or if it will be SHA-3/256 with params (x, y)

Your proposal creates a degree of impedence mismatch that the current
KeyAlgorithm interface avoids.

Now you/we can say we don't care about that use case, and that's perfectly
reasonable. But I do want to make sure the design rationale and risks to
future compat are understood before we toss it out.