- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 9 Jul 2012 12:14:00 -0700
- To: public-webcrypto@w3.org
- Message-ID: <CACvaWvbGeAepds8KGUaXS22Jd8mmiHS=x725K+5ZzcZrfy55WA@mail.gmail.com>
Since I'm having trouble with the CVS/HG access to the raw draft, here's the proposed resolution for the ACTION-7 item. In the strawman API, I proposed the following two dictionaries: dictionary Algorithm { DOMString name; AlgorithmParams? params; }; dictionary AlgorithmParams { // Filled in elsewhere }; Along with functions such as CryptoStream encrypt(Algorithm algorithm, Key key) To support easy initialization and the use of JOSE/JWA algorithm identifiers, the proposal is to be updated as (and so forth): CryptoStream encrypt((Algorithm or DOMString) algorithm, Key key) Then the specifications of AlgorithmParameters are updated to indicate the correlation between DOMString and Algorithm For example, in an HMAC specification, we might define the following: DOMString "HS256" is equivalent to the following: Algorithm { name: "HMAC", params: { hash: { name: "SHA256" } } } DOMString "HS512" is equivalent to the following: Algorithm { name: "HMAC", params: { hash: { name: "SHA512" } } } And so forth, translating each of the JWA algorithms into an equivalent Algorithm structure. This means that the following is now valid: var stream = window.crypto.encrypt("ES512", key); var stream = window.crypto.sign("HS512", key); Note that, regardless of the exact method of incorporating JWA/JOSE support, it is highly likely for purposes of interoperability and well-defined behaviour that the WebCrypto specification will need to specify the handling of JOSE algorithms. For example, endianness handling, outputs, etc.
Received on Monday, 9 July 2012 19:14:27 UTC