ISSUE-14: Representation of raw key material

Representation of raw key material

State:

CLOSED

Product:

usability for Web Crypto API

Raised by:

Ryan Sleevi

Opened on:

2012-08-06

Description:

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.

Related Actions Items:

• ACTION-32 on Ryan Sleevi to Propose text/API to the mailing list to address ISSUE-14 - due 2012-08-20, closed

Related emails:

1. Re: [Bug 24963] Export Key with "jwk" operations should return a JWK, rather than an ArrayBuffer (from watsonm@netflix.com on 2014-03-12)
2. Re: [Bug 24963] Export Key with "jwk" operations should return a JWK, rather than an ArrayBuffer (from sleevi@google.com on 2014-03-11)
3. Re: [Bug 24963] Export Key with "jwk" operations should return a JWK, rather than an ArrayBuffer (from ap@webkit.org on 2014-03-11)
4. Re: [Bug 24963] Export Key with "jwk" operations should return a JWK, rather than an ArrayBuffer (from ap@webkit.org on 2014-03-06)
5. Re: [Bug 24963] Export Key with "jwk" operations should return a JWK, rather than an ArrayBuffer (from watsonm@netflix.com on 2014-03-06)
6. Re: [Bug 24963] Export Key with "jwk" operations should return a JWK, rather than an ArrayBuffer (from sleevi@google.com on 2014-03-06)
7. Re: [Bug 24963] Export Key with "jwk" operations should return a JWK, rather than an ArrayBuffer (from watsonm@netflix.com on 2014-03-06)
8. Re: [Bug 24963] Export Key with "jwk" operations should return a JWK, rather than an ArrayBuffer (from sleevi@google.com on 2014-03-06)
9. RE: crypto-ISSUE-14: Representation of raw key material [Web Cryptography API] (from Vijay.Bharadwaj@microsoft.com on 2012-08-28)
10. Re: crypto-ISSUE-14: Representation of raw key material [Web Cryptography API] (from sleevi@google.com on 2012-08-27)
11. RE: crypto-ISSUE-14: Representation of raw key material [Web Cryptography API] (from Vijay.Bharadwaj@microsoft.com on 2012-08-27)
12. [W3C Web Crypto WG] functional features list in draft API and issue tracker (from Virginie.GALINDO@gemalto.com on 2012-08-22)
13. Re: [W3C Web Crypto WG] functional features list in draft API and issue tracker (from sleevi@google.com on 2012-08-21)
14. [W3C Web Crypto WG] functional features list in draft API and issue tracker (from Virginie.GALINDO@gemalto.com on 2012-08-21)
15. Re: New Editor's Draft (from sleevi@google.com on 2012-08-17)
16. RE: crypto-ISSUE-14: Representation of raw key material [Web Cryptography API] (from Michael.Jones@microsoft.com on 2012-08-17)
17. Re: crypto-ISSUE-14: Representation of raw key material [Web Cryptography API] (from sleevi@google.com on 2012-08-14)
18. RE: crypto-ISSUE-14: Representation of raw key material [Web Cryptography API] (from Vijay.Bharadwaj@microsoft.com on 2012-08-14)
19. RE: New Editor's Draft (from Vijay.Bharadwaj@microsoft.com on 2012-08-14)
20. Re: crypto-ISSUE-14: Representation of raw key material [Web Cryptography API] (from mzollinger@netflix.com on 2012-08-13)
21. RE: crypto-ISSUE-14: Representation of raw key material [Web Cryptography API] (from Vijay.Bharadwaj@microsoft.com on 2012-08-13)
22. Re: New Editor's Draft (from sleevi@google.com on 2012-08-09)
23. crypto-ISSUE-14: Representation of raw key material [Web Cryptography API] (from sysbot+tracker@w3.org on 2012-08-06)
24. New Editor's Draft (from sleevi@google.com on 2012-08-05)
25. Re: crypto-ISSUE-14: Representation of raw key material [Web Cryptography API] (from sleevi@google.com on 2012-08-05)

Related notes:

Display change log