crypto-ISSUE-14: Representation of raw key material [Web Cryptography API]

crypto-ISSUE-14: Representation of raw key material [Web Cryptography API]

http://www.w3.org/2012/webcrypto/track/issues/14

Raised by: Ryan Sleevi
On product: Web Cryptography API

It is clear from the use cases that there is a desire to access the raw key material associated with this API. For an example, see the thread here: http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0099.html

The question is what form should the raw key material be exposed to the application?

Possible representations include:
- The DER encoding of the ASN.1 structure relevant to the underlying key, exposed as a Uint8Array
  * For example, for an RSA public key, this would be RFC 3447 Appendix A.1.1 ( http://tools.ietf.org/html/rfc3447#appendix-A.1.1 )
- As a custom JSON encoding that uses Uint8Arrays, such as:
  * interface RSAPublicKey {
      readonly attribute Uint8Array modulus;
      readonly attribute Uint8Array publicExponent;
    };
- As a JSON encoding that uses JWK serialization
  * interface RSAPublicKey {
      readonly attribute DOMString modulus;  // base64url encoded
      readonly attribute DOMString exponent;  // base64url encoded
    };

Upsides to ASN.1 DER:
  - Compatible with large swaths of existing applications and APIs
  - Easily extended to support new algorithms' representations
  - Easily forwarded to/from existing cryptographic APIs
Downsides to ASN.1 DER:
  - Parsing ASN.1 is possible, but easy to get wrong

Upsides to custom JSON encoding:
  - "Efficiently" represent large binary data (bigints) without requiring transformation to/from textual form
  - Offers semantically meaningful names for parameters ('modulus', 'exponent') without requiring additional parsing
Downsides to custom JSON encoding:
  - Requires specification of structure for every algorithm
  - Possible to incorrectly implement versioning/extensibility (eg: RSA multi-prime)
  - Requires the browser translate JSON<->ASN.1, moving the ASN.1 dependence into the user agent

Upsides to JWK encoding:
  - Easily serializes/deserializes from JWK
  - Offloads responsibility for algorithm specification to IETF
Downsides to JWK encoding:
  - Requires specification of structure for every algorithm
  - JWK use cases and applicability are not 1:1 Web Crypto API use cases. Possible that algorithms implemented by the Web Crypto API will not ever be exposed as JWKs.
  - Overhead involved with translation to/from base64url encoding.

Received on Monday, 6 August 2012 03:59:20 UTC