Re: posting to public-webcrypto, and a user report

It works fine for me, I imagine there is a problem with your code.

On Fri, Dec 5, 2014 at 11:58 AM, Jason Proctor <jason@mono.hm> wrote:

> gents, thanks for all the comments.
>
> i'm using very recent Chrome and Firefox - behaviour is identical.
>
> in my experience, changing the export format has not altered the import
> behaviour. i just verified again that generating an RSA-OAEP key pair for
> encrypt and decrypt, then exporting the public key as SPKI, results in a
> key which is usable for decrypt only on import.
>

If you export as "spki" then you must re-import as "spki".
The only type of RSA-OAEP key you can create in this case is a public key,
with either 'encrypt' usage or 'wrapKey' usage.
What you are describing is not possible in Chrome.


> AFAKI, SPKI doesn't include usage constraints (after a quick read of the
> wiki page) and so i'm not really clear where the API is getting its clues
> on usage enforcement.
>
> IMHO, if i delete the key_ops and ext properties from the JWK pre-import,
> then that should allow all usages.
>

As previously mentioned, I expect you are passing a JWK containing a "d"
member.
Look at the rejection reason to understand why the input is not accepted.


> as it is, the constraints are swapped compared to leaving the properties
> in there. IMHO again, given that this is a public key, usages should not
> apply. what damage can i do with a public key?
>
> in my application, i need to encrypt with public keys and decrypt with
> private keys - a common usage that is somehow exactly the case the API
> tries to prevent.
>

Encrypt with public key, and decrypt with private key is precisely what the
WebCrypto spec allows for.


> there's no confusion in the steps taken or the API calls i'm using - and
> indeed if i adopt the wrapping approach, the application works fine. my
> point is that i shouldn't have to wrap at all in the public key case, and i
> should be able to do my own wrapping (i need compatibility with other
> crypto APIs) in the private key case. in general, i suppose, i'm disputing
> the need for the usage concept.
>
> my regret here is not somehow finding out about the crypto API WG long
> before now. as it is, i suspect that it's too late to change any behaviours.
>
> best regards
> Jason
>
>
> On Fri, Dec 5, 2014 at 11:26 AM, Eric Roman <ericroman@google.com> wrote:
>
>> On Fri, Dec 5, 2014 at 11:23 AM, Eric Roman <ericroman@google.com> wrote:
>>
>>> What WebCrypto implementation are you using for your tests?
>>>
>>> (1) It should be easy to accomplish what you want using the "spki" or
>>> "pkcs8" key formats.
>>> If you export the RSA-OAEP key as "spki" then the algorithm identifier
>>> will be set to the generic rsaEncryption, and there will be no key usages
>>> enumerated in the output.
>>> You are free to re-import this for any RSA algorithm, using any key
>>> usages.
>>>
>>> (2) The same thing can be accomplished with JWK. Following export you
>>> will need to delete the "alg" and "key_ops" members of the exported JWK (as
>>> they restrict it to a particular algorithm and key usages respectively)
>>>
>>> (3) I suspect the actual problem you are hitting with regards to usage
>>> is that you are trying to import a private key with the 'encrypt' usage,
>>> and vice versa import  public key using the 'decrypt' usage.
>>>
>>> When using the "jwk" format, you CANNOT import a private key as a public
>>> key (even though it contains all of the public key properties). A private
>>> key is identified by having a "d" member on the JWK. f you want to import
>>> for RSA-OAEP from JWK with the 'encrypt' usage then you will need to delete
>>> the "d" member from your JWK private key.
>>>
>>>
>> Arguably the spec could be changed to simplify this -- if the usages make
>> it clear the intent is to import a public vs private key, then do the right
>> thing. Which could allow importing a public key given "pkcs8" formatted
>> data, or "jwk" formatted data that describes a private key.
>>
>>
>>> Cheers
>>>
>>> On Fri, Dec 5, 2014 at 9:39 AM, Jason Proctor <jason@mono.hm> wrote:
>>>
>>>> On Fri, Dec 5, 2014 at 2:44 AM, Anders Rundgren <
>>>> anders.rundgren.net@gmail.com> wrote:
>>>>
>>>>>  On 2014-12-05 03:02, Jason Proctor wrote:
>>>>>
>>>>>
>>>>>  the main issue i ran into was related to (surprise) usages. if for
>>>>> example i generate an RSA key pair, and happily encrypt and decrypt with
>>>>> it, then export the public key, then i instantly lose its encryption
>>>>> capability. this was a surprise, to say the least -- this is a *public* key
>>>>> we're dealing with.
>>>>>
>>>>>
>>>>> Hi Jason,
>>>>> it seems that in practice (deployment-wise) there are only plain RSA
>>>>> encryption keys.  I have managed importing like this:
>>>>>
>>>>>     var encryption_key = {kty:'RSA',  alg:'RSA-OAEP-256',
>>>>> n:'yz1k8Hbi5aTE4t...ZrHNTQAfvw', e:'AQAB'}
>>>>>     var asym_alg = {name: 'RSA-OAEP', hash: {name: 'SHA-256'}};
>>>>>     crypto.subtle.importKey('jwk', encryption_key, asym_alg, true,
>>>>> ['encrypt']).then (function(public_key) {
>>>>>     crypto.subtle.encrypt(asym_alg, public_key, data).then
>>>>> (function(encryped_data) {
>>>>>
>>>>> Cheers,
>>>>> Anders
>>>>>
>>>>>
>>>> hi Anders,
>>>>
>>>> thanks for your response.
>>>>
>>>> partial success. i exported a public key to JWK, then removed the
>>>> key_ops and ext properties so as to mirror your structure. i can now import
>>>> the public key for *encrypt* but not *decrypt*, which is the opposite of
>>>> the situation i had before.
>>>>
>>>> so to make this work i would have to persist two differently exported
>>>> public keys, which is not a disaster, i suppose :-) but this mechanism does
>>>> seem little arbitrary.
>>>>
>>>> i could almost understand this if the API enforced public key import
>>>> and export via certificates, but i don't see any cert support at all! :-S
>>>>
>>>> best regards
>>>> Jason
>>>>
>>>>
>>>
>>
>