Re: Hashes, names, and normalization

TL;DR: I'm OK with keeping it as-is.

On Thu, Mar 13, 2014 at 9:58 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
> 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.
>

You're right.  I was thinking of the Algorithm side of the hierarchy, where
SHA-256 could be either {name:"SHA-256"} or "SHA-256".  Since it's
KeyAlgorithm, it'll always be (the moral equivalent of) {name: "SHA-256"}.



>
>
>>
>> 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.
>

I think Keccak is near enough that it's worth keeping this open to allow
options to be explicit.

--Richard