- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Wed, 06 Nov 2013 05:27:17 +0100
- To: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
Dear list, I'm _not_ proposing a change, I'm just going to describe another approach to this issue which I have selected for _my_ work FWIW. It started with RSA versus EC key algorithms that seemed unnecessary quirky since RSA keys are expressed in bits while EC keys (typically) are expressed as curve names. Due to this RSA keys were converted into names as well like rsa.1024 and rsa.2048. EC curves are plentiful and with different origin which made a tag logical as well like ec.nist.p256 and ec.brainpool.p256r. Key generation can also take an opaque parameter blob holding data such as RSA exponents. This would in this scheme require that the algorithm ID has an extension like rsa.2048.exp To make the thing more "webish" the IDs were stuffed in a base URI. Quite a bunch of other algorithms like HMACSHA* already have URIs assigned to them and these have (so far) been kept. The opaque parameter should hopefully be sufficient to cover for anything unexpected although it may not be entirely pretty. The overarching idea is maintaining the same algorithm ID and parameter stuff the whole way down into the key-container to not have to translate them back and forth. Since the scheme I'm working on can't use PKCS #11 and friends anyway, there is no compatibility issue :-) Anders
Received on Wednesday, 6 November 2013 04:27:49 UTC