W3C home > Mailing lists > Public > public-webcrypto@w3.org > March 2014

Re: Hashes, names, and normalization

From: Ryan Sleevi <sleevi@google.com>
Date: Thu, 13 Mar 2014 18:58:06 -0700
Message-ID: <CACvaWvbgHemx1ZrT3r7jLNJjtopgySDZVF1FtKzrKQPPcKh5Cw@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
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.
Received on Friday, 14 March 2014 01:58:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:02:41 UTC