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 24834 - KDF algorithms should support "raw" import / export
Summary: KDF algorithms should support "raw" import / export
Status: RESOLVED FIXED
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-02-27 02:09 UTC by Mark Watson
Modified: 2014-10-07 04:23 UTC (History)
0 users

See Also:

Attachments

Description Mark Watson 2014-02-27 02:09:46 UTC 
Otherwise there is no way to get the secret key in there.
Comment 1 Ryan Sleevi 2014-02-27 02:36:26 UTC 
Are you suggesting this is true for "all" algorithms?

It doesn't apply for example to PBKDF2.
Comment 2 Mark Watson 2014-09-22 17:39:04 UTC 
I believe this is addressed in the current Editor's draft.
Comment 3 Ryan Sleevi 2014-10-07 02:47:27 UTC 
I'm still shaky on this in the Editor's Draft.

Using PBKDF2, which as I noted in Comment #1 as being problematic, the current ED ( https://dvcs.w3.org/hg/webcrypto-api/raw-file/dbdc7abe4e32/spec/Overview.html#pbkdf2 ) does not adequately describe what the contents of the Key are on a Raw import.

Arguably, these concerns apply to Generate Key as well, but I think it highlights the need for specificity regarding "raw" inputs. Is the input a user password as a sequence of UTF-8 bytes? What if the import data contains invalid UTF-8 data - how does a UA process it (compared with generateKey, for which the UA can be assured no invalid data exists?)
Comment 4 Mark Watson 2014-10-07 04:23:44 UTC 
(In reply to Ryan Sleevi from comment #3)
> I'm still shaky on this in the Editor's Draft.
> 
> Using PBKDF2, which as I noted in Comment #1 as being problematic, the
> current ED (
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/dbdc7abe4e32/spec/Overview.
> html#pbkdf2 ) does not adequately describe what the contents of the Key are
> on a Raw import.

I don't understand the concern. PBKDF2 as described in the referenced RFC takes as input a password, P, which is an octet string. In the generate case, this octet string is created by encoding the text-input password in UTF-8. In the import key case it is the raw bytes of the keyData Array supplied in the method call.

We should say 'contents of keyData' with a link to the 'contents of an ArrayBuffer'.

> 
> Arguably, these concerns apply to Generate Key as well, but I think it
> highlights the need for specificity regarding "raw" inputs. Is the input a
> user password as a sequence of UTF-8 bytes? What if the import data contains
> invalid UTF-8 data - how does a UA process it (compared with generateKey,
> for which the UA can be assured no invalid data exists?)

There's nothing in the PBKDF2 reference that I saw that says the password has to be UTF-8 - it just says 'octet string'.