25706 2014-05-14 12:01:40 +0000 Incomplete Key Generation Definitions 2014-10-22 21:17:06 +0000 1 1 1 Unclassified Web Cryptography Web Cryptography API Document unspecified PC All RESOLVED WONTFIX P2 normal --- 1 kelsey.cairns sleevi public-webcrypto virginie.galindo watsonm oldest_to_newest 105953 0 kelsey.cairns 2014-05-14 12:01:40 +0000 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. 105976 1 sleevi 2014-05-14 16:22:17 +0000 (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. 106041 2 kelsey.cairns 2014-05-15 14:24:42 +0000 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]]" 112281 3 watsonm 2014-09-26 17:50:05 +0000 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 ? 113079 4 virginie.galindo 2014-10-14 09:32:13 +0000 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. 113599 5 watsonm 2014-10-22 21:17:06 +0000 Closing per Chair's proposed resolution.