W3C home > Mailing lists > Public > public-webcrypto@w3.org > January 2015

[Bug 27774] New: The KDFs either shouldn't allow importing unextractable keys, or should support exportKey()

From: <bugzilla@jessica.w3.org>
Date: Tue, 06 Jan 2015 22:31:32 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-27774-7213@http.www.w3.org/Bugs/Public/>

            Bug ID: 27774
           Summary: The KDFs either shouldn't allow importing
                    unextractable keys, or should support exportKey()
           Product: Web Cryptography
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Web Cryptography API Document
          Assignee: sleevi@google.com
          Reporter: ericroman@google.com
                CC: public-webcrypto@w3.org

There is currently an awkward interaction for how import/export works for the
KDFd (PBKDF2, HKDF, Concat-KDF):

 * You can importKey(extractable=true), however the exportKey() operation is
not supported. So in truth you can never actually export these keys. It is less
then ideal to accept extractable=true during import, but create a key which is
effectively unextractable.

 * You can unwrapKey() for the KDFs (because they support the importKey()
operation), however the converse is not true (you cannot wrapKey() because
exportKey() is unsupported). It is strange that you could unwrap something
(perhaps created directly using encrypt()), but cannot directly wrap it. (If
you wrap will get NotSupportedError)

I think the most consistent behavior would be to simply define exportKey()
operation for these algorithms. Let callers specify extractable=false if they
want to forbid extractability, and keep the API working in a predictable

Alternately maybe extractable=true should be forbidden during key import.
However that feels kludgey in its own way.

Other suggestions?

You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 6 January 2015 22:31:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:31:34 UTC