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

I think you're over-interpreting my statement here - it was not as fully-fleshed-out a proposal as this. The point I was trying to make was much more limited - that it would be great if, where possible, new JSON formats stuck to the same field names as the existing ASN.1 modules. This would avoid creating lots of new names for the same things, and perhaps even simplify the task of creating new JSON types in future, as practice would establish a "natural" way of doing this.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Tuesday, August 14, 2012 12:47 PM
To: Vijay Bharadwaj
Cc: Mitch Zollinger; public-webcrypto@w3.org
Subject: Re: crypto-ISSUE-14: Representation of raw key material [Web Cryptography API]

On Tue, Aug 14, 2012 at 11:41 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com> wrote:
> 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.

Why not UInt8Arrays ( from
http://www.khronos.org/registry/typedarray/specs/latest/ ), which allow arbitrary access to the bytes without having to en/decode from some intermediate form.

And while JS doesn't support 2048 bit integers, it still requires specifying what the contents of these bytes are. It would seem required to specify the content octets are encoded in two's compliment form, but just look at how much specification X.690 (07/2002) has to specify this (Section 8.3)

Without specifying something like X.690, we'd need to specify exactly how each ASN.1 -> JSON conversion behaves, and what's worse, is that it can lead to inconsistent behaviours. If there are no "rules"
governing how an ASN.1 INTEGER type is convered to a JS type, then it seems just as likely that custom algorithms may expose Blobs, others may expose as ArrayBufferViews (pre-read Blobs), and others still may describe it as UInt8Arrays.

I can certainly see the argument made for JWK conversions, when possible. I have a harder time trying to understand a general ASN.1 -> JSON conversion facility, and an even harder time trying to re-define these formats wholly independent of their ASN.1 counterparts, as unfortunately JWK tends to do. I understand why this is necessary for JWK - since you can't exactly wire-transfer a Blob over websockets - but it does lead to an even more limited and expensive representation.

I wonder if the raw key material should only be accessed via the Import/Export functionality, and that the Import/Export functionality specifies the format, as Vijay proposed. Types which have direct JWK equivalents can be used, whereas types that have no JWK counterparts would not be exported in JSON form.

>
> -----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.ht
>>> m
>>> 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 Monday, 27 August 2012 09:56:14 UTC