[Bug 26411] New: Caller can't force JWK to be distinguished as public or private key

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26411

            Bug ID: 26411
           Summary: Caller can't force JWK to be distinguished as public
                    or private key
           Product: Web Cryptography
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Web Cryptography API Document
          Assignee: sleevi@google.com
          Reporter: sleevi@google.com
                CC: Michael.Jones@microsoft.com, public-webcrypto@w3.org,
                    rlb@ipv.sx

As far as I can tell from
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-6.3 ,
there is no format restrictions/requirements on JWKs and the use of the "d"
parameter.

That is, while an RSA JWK with the parameters (n, e, d) is a RSA private key,
it contains all of the necessary details to also be an RSA public key.

However, at an API layer, the caller cannot indicate simply that they wish for
a JWK to be imported as a public or private key. Instead, that's inferred,
based on the presence of a "d" parameter (
https://dvcs.w3.org/hg/webcrypto-api/raw-file/ee10c81e1141/spec/Overview.html#rsassa-pkcs1-operations
)

This prevents the following use case:
Using a single object/buffer, import a JWK as both a public and private key,
thus using one message to represent a 'full' keypair (tuple).

For the importKey operation, the caller can easily mask out the "d" from the
dictionary supplied to importKey, and thus 'force' WebCrypto to treat it as a
public key. However, no such option exists for unwrapKey.

This problem exists somewhat for PKCS#8 as well (e.g. an RSAPrivateKey
structure from RFC 3447 contains the necessary fields for an RSAPublicKey, see
http://tools.ietf.org/html/rfc3447#appendix-C ).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 22 July 2014 21:37:04 UTC