W3C home > Mailing lists > Public > public-webcrypto@w3.org > August 2012

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

From: Mitch Zollinger <mzollinger@netflix.com>
Date: Mon, 13 Aug 2012 17:56:20 -0700
Message-ID: <5029A234.2020906@netflix.com>
To: <public-webcrypto@w3.org>
On 8/13/2012 7:58 AM, Vijay Bharadwaj wrote:
> 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.

I like making things easier to play with in JS & JSON.

I'm curious, though: what would the base-64 decoded byte array for each 
of n_as_base64_encoded_octet_string & e_as_base64_encoded_octet_string 
be? ASN.1 DER encoded OCTET_STRINGs?


> -----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 Tuesday, 14 August 2012 00:56:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:25 UTC