- From: <bugzilla@jessica.w3.org>
- Date: Tue, 22 Jul 2014 21:37:02 +0000
- To: public-webcrypto@w3.org
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