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

I agree and would also like to see ASN.1 supported in some form.

Personally, I think many things would be easier if we had a simple facility to translate ASN.1 constructs to JSON based on the module. For instance, consider the module for an RSA public key from RFC 3447:

RSAPublicKey ::= SEQUENCE {
          modulus           INTEGER,  -- n
          publicExponent    INTEGER   -- e
}

Perhaps if I could take an RSA public key in ASN.1 DER format and do something like:

rsaPubKey = asn1.RSAPublicKey.fromDER(keyInDEREncoding);

which would result in:

rsaPubKey = { modulus: n_as_base64_encoded_octet_string, publicExponent: e_as_base64_encoded_octet_string };

and similarly in reverse, then many of the debates we're having around ASN.1 would be moot.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Sunday, August 5, 2012 9:12 PM
To: Web Cryptography Working Group
Cc: Zooko Wilcox-OHearn
Subject: Re: crypto-ISSUE-14: Representation of raw key material [Web Cryptography API]

On Sun, Aug 5, 2012 at 8:59 PM, Web Cryptography Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
> 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.
>
>
>

My personal preference is to see ASN.1 used, in that it represents the most widely-implemented form, both in terms of protocols (TLS, S/MIME,
PKIX) and in terms of cryptographic libraries (rare is the API that requires you to explicitly specify modulus and exponent).

JWK seems inappropriate for the API specification, as it is geared towards serialization of JOSE-specific keys. For example, under the current JWK/JWA specifications, serializations are only defined for ECC and RSA keys. Additionally, the complete forms are not specified - for example, how to serialize RSA private keys, or how to serialize multi-prime RSA public keys.

My gut is that the primary use case for raw key material is for symmetric algorithms (eg: AES) or for derived key 'secrets' (such as the DH negotiated secret), so that they can be used to polyfill algorithms/implement custom/unsupported algorithms. I'm not sure how much 'low-level' detail is needed for such applications.

Received on Monday, 13 August 2012 14:59:44 UTC