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

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