This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25706 - Incomplete Key Generation Definitions
Summary: Incomplete Key Generation Definitions
Status: RESOLVED WONTFIX
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ryan Sleevi
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-14 12:01 UTC by Kelsey Cairns
Modified: 2014-10-22 21:17 UTC (History)
3 users (show)

See Also:


Attachments

Description Kelsey Cairns 2014-05-14 12:01:40 UTC
For the AES algorithms and HMAC, the key generation step does not go into any more detail than "generate a key." If there is some intended method to generate a key, it should be specified. Similarly, if the underlying mechanism is intentionally unspecified I think it would be good to clearly state that somewhere. A quick search didn't yield anything and the discussions in the section on random number generation (including the note that the random number generator should not be used for keys) were also not helpful.
Comment 1 Ryan Sleevi 2014-05-14 16:22:17 UTC
(In reply to Kelsey Cairns from comment #0)
> For the AES algorithms and HMAC, the key generation step does not go into
> any more detail than "generate a key." If there is some intended method to
> generate a key, it should be specified. Similarly, if the underlying
> mechanism is intentionally unspecified I think it would be good to clearly
> state that somewhere. A quick search didn't yield anything and the
> discussions in the section on random number generation (including the note
> that the random number generator should not be used for keys) were also not
> helpful.

Can you please provide suggested wording?

Including a normative reference on SP800-133 is undesirable, as it state's clearly in Section 5 that the RBG should be a FIPS-approved one, which historically tend to be be weaker in terms of security guarantees. Further, it also uses terminology identical to the spec with respect to key generation.

Can you explain any concrete concerns about where the language choice here affects interoperability? Can you explain any concrete concerns about the implementation that are not, in and of themselves, quality of implementation issues?

On "quality of implementation" issues, we've counted things such as the quality of the primality test, the number of bits of entropy, the constant-timedness of the operations - all things which, from a black box perspective, do not change the output or interoperability of implementations, and thus are security concerns with respect to the User Agent, and not to the specification as a whole.
Comment 2 Kelsey Cairns 2014-05-15 14:24:42 UTC
No interoperability issues with this one. The biggest concern to me is that it seems I could make an implementation that created completely non-random keys and still be API compliant. I get that we don't want to constrain implementations to anything specific, but maybe it would be reasonable to specify a lower bound on entropy? I think even a moving target is better than nothing, like "no worse than /dev/urandom."

This bug is also an ease of use thing stemming from looking over the spec the other day with someone who's going to try an implementation and being asked "what do they mean?" when it came to one of the general key generation steps. I would have liked to be able to give a definitive answer from the spec, but I couldn't find one.

My suggestion would be a blurb in the Terminology section along the lines of:

"The phrase "generate key," when no further specification is given, is meant to allow implementers flexibility in the choice of random number generator. However an entropy source should be used that is [at least as good as.. [choose your reference, make sure there's some kind of metric for comparison]]"
Comment 3 Mark Watson 2014-09-26 17:50:05 UTC
Are there any further opinions on this one ?

Any objections to the suggestion for a (informative?) recommendation in comment 2 ?

What should the reference be ?
Comment 4 virginie.galindo 2014-10-14 09:32:13 UTC
In order to progress towards exit to Last Call for the Web Crypto API, the chair suggests the following resolution for that bug. 

Resolution : Bug RESOLVED as WONTFIX. Based on the fact that this request is about giving guidance to implementers and users (and not adding a feature) combined with the fact that no reference related to robust random generation can be pointed to and agreed on. 

If none objects before the 20th of Oct @20:00 UTC, this resolution will be endorsed.
Comment 5 Mark Watson 2014-10-22 21:17:06 UTC
Closing per Chair's proposed resolution.