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

Mitch> 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?

Sorry, I meant to say hex encoding, not base64, but the idea is the same.

The n and e fields would just be the big-endian integer in hex-encoding. In theory it is an integer so doesn't need encoding, but AFAIK JS doesn't support 2048-bit integers so hex encoding is my way of working around that. If you can think of a better way to support arbitrary-sized integers in JS, I'd be happy with that too.

-----Original Message-----
From: Mitch Zollinger [mailto:mzollinger@netflix.com] 
Sent: Monday, August 13, 2012 5:56 PM
To: public-webcrypto@w3.org
Subject: Re: crypto-ISSUE-14: Representation of raw key material [Web Cryptography API]

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?

Mitch

>
> -----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.htm
>> l
>>
>> 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 18:41:54 UTC