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

On 2014-12-05 03:02, Jason Proctor wrote:
> dear fellow cryptos,
>
> i yesterday joined the web crypto WG, and today tried to post to public-webcrypto. my request was denied on the grounds that i'm not a WG member. is there a latency to joining WGs?
>
> and then it occurred to me that my post might be more suitable here. post follows.
>
> --
>
> i'm new to the W3C and don't really understand the mechanisms and procedures, and what with the web crypto API recommendation around the corner, i realise that this message may well be very late to the game. apologies in advance for any faux pas i may commit along the way.
>
> i've been using crypto APIs for a long time, and so when i recently discovered the API, i thought i would try to essentially make standards-compliant web-hosted versions of some of my applications. this is an account of the issues i ran into along the way, which raise some questions that i humbly hope the community can perhaps address.
>
> 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.
>
> however, the simple act of wrapping this key in a simple (ie easily derived from consecutive numbers) AES key effectively removed the usage restriction. this creates an odd dichotomy, where if *i* write the wrapping code, it's not allowed, but presumably the API has its own special import mechanism that bypasses usages.
>
> (a similar situation occurs with private keys and the decrypt usage. i can get around that with wrapping, too, but experience has taught me to do my own wrapping, especially in heterogenous environments - which is not allowed here)
>
> another significant issue i ran into was that RSAES-PKCS1 is no longer supported. this is unfortunate as there are a lot of such keys around. it would have been nice if the API let me import such keys and then export them as something "better", but the API seems to conflate keys and key encoding.

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

>
> and the last issue (for now, grin) is that it seems i can make an RSA pair for encrypt/decrypt or sign/verify but not both. really? i remember the bad old days in pre-Bouncy Castle JCE, where i had to have both RSA and DSA keys due to similar artificial restrictions.
>
> thanks for listening, and any help with these issues. if this isn't the right place, then please advise.
>
> best regards
> Jason
>