- From: Jason Proctor <jason@mono.hm>
- Date: Fri, 5 Dec 2014 12:26:30 -0800
- To: public-webcrypto@w3.org
- Message-ID: <CALQanAKyucm5eapufWOKdONEzXmJLu7=ZEsNFm3ZUokVUw5_HQ@mail.gmail.com>
dear fellow cryptos, 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. (a reply on the comments list advised me of a workaround involving removing the key_ops and ext properties from the JWK structure, pre-import. this presumably simulates a key from the outside world, but it has the opposite effect - i can import for encrypt but not decrypt this way. also it does seem a little odd that hacking the JWK structure is required for roundtripping with different usage ramifications.) 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. 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
Received on Friday, 5 December 2014 20:26:59 UTC