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, 6 August 2012 04:12:25 UTC