Bug 27473 - Explicit salts for the algorithm formerly known as HKDF

[mwatson2]

Bug 27473:

Pre-CR, I've just removed this Editorial Note. I assume we should address this during CR when we'll know if explicit salts are supported in terms of interop.

---

Editorial note

The definition of HKDF allows the caller to supply an optional pseudorandom salt value, which is used as the key during the extract phase. If this value is not supplied, an all zero string is used instead. However, support for an explicit salt value is not widely implemented in existing APIs, nor is it required by existing usages of HKDF. Should this be an optional parameter, and if so, what should the behavior be of a user agent that does not support explicit salt values (is it conforming or non-conforming?)

[mwatson2]

This is referenced by PR #16.

[mwatson2]

Blocked on #27

[mwatson2]

The HKDF algorithm introduced by #27 requires an explicit salt to be provided.

Options for closing this issue:

1. No action (explicit salt must always be provided)
2. Make the salt optional (the RFC defines what to do in the case it is not provided)
3. Remove the salt altogether (the RFC defines what to do in this case)

The OP indicates that support for explicit salts is not widespread. If we opt for no action, implementations which do not support explicit salts will be non-compliant.

[jimsch]

The original pull request was changed from having the salt be optional to making it required. Not having salt the salt as an option is a really bad idea.

Take action 1.

[engelke]

The test assumes that the salt is required, and checks that an error is thrown if it is missing. Chrome at least seems to enforce that properly.

[mwatson2]

In that case, we can close this issue without changes.