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

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
>>
>>
>