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

Re: crypto-ISSUE-13: Relationship between the W3C Web Cryptography work product and the IETF JOSE WG [Web Cryptography API]

From: Ryan Sleevi <sleevi@google.com>
Date: Fri, 17 Aug 2012 15:03:48 -0700
Message-ID: <CACvaWvaOwgHh_veu_czaRFtcUSJOhc-fg1Di8Xyd6d6xxs86hg@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Web Cryptography Working Group <public-webcrypto@w3.org>
Thanks for highlighting this, Mike.

I think the best way forward for the private key representation is the
adoption of Vijay's proposal for key exporting taking a format. I
imagine that an application could then specify one of the ASN.1
variants (eg: PKCS1, PKCS8) or a JOSE variant (eg: JWK).

My primary concerns with the draft seem to have already been raised in
the IETF (namely that the RSA private key format is lossy - it doesn't
support multiple primes and it doesn't support CRT parameters), so
I'll continue to watch the discussion there. It does highlight the
work I was trying to avoid having here - namely specifying a JSON
representation for ASN.1 structures :)

I think it still lives a gap in the middle - namely, a desire for a
"structured object" representation, which is not JSON, but is
compatible with the structured clone algorithm (
). This would avoid having to have applications base64url
encode/decode exponents, nor worry about the data containing invalid
UTF-16 codepoints (which is a problem when converting base64url ->
DOMString "bytes"). I suppose that's an inherent downside of JWK being
a wire-transfer format, rather than a WebIDL representation format.

On Fri, Aug 17, 2012 at 2:06 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> Since it's relevant to this issue, I wanted to state on this issue thread that I'm trying to work with the JOSE WG to create a JSON private key representation that could be used for the WebCrypto use cases.  See http://tools.ietf.org/html/draft-jones-jose-json-private-key-00 for a first draft, intended to facilitate discussion of this topic among both working groups.
>                                 -- Mike
> -----Original Message-----
> From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
> Sent: Tuesday, August 14, 2012 9:31 AM
> To: 'Wan-Teh Chang'; Ryan Sleevi
> Cc: Web Cryptography Working Group
> Subject: RE: crypto-ISSUE-13: Relationship between the W3C Web Cryptography work product and the IETF JOSE WG [Web Cryptography API]
> Regarding key sizes, I disagree - I think you may have picked the wrong examples for this.
> AES-256 is a different algorithm than AES-128; the key expansion is substantially different. Similarly, the EC curve is not just a matter of key size; it determines the field in which all operations are performed. So I don't think you can have a complete algorithm specification without including these two.
> For other algorithms which are specified in a key-independent way (RSA and RC4 come to mind) it may be possible to have the key size be only an attribute of the key, but I think the above examples show that this is at least an algorithm-specific decision and not something that lends itself to a general rule.
> -----Original Message-----
> From: Wan-Teh Chang [mailto:wtc@google.com]
> Sent: Wednesday, August 8, 2012 7:27 AM
> To: Ryan Sleevi
> Cc: Web Cryptography Working Group
> Subject: Re: crypto-ISSUE-13: Relationship between the W3C Web Cryptography work product and the IETF JOSE WG [Web Cryptography API]
> Among the algorithms defined in
> draft-ietf-jose-json-web-algorithms-05, most "alg" parameter values could be adopted by our low-level API without problem. The only problematic ones seem to be the AES algorithms, such as A128CBC and A128GCM, which specify the key size. In a low-level crypto API, the key size is usually an attribute of the key object as opposed to the algorithm identifier.
> The ECDSA "alg" parameter values such as ES256 and ES384 have a similar problem. The elliptic curve (P-256 or P-384, which determines the key size) is usually considered an attribute of the key object in a low-level crypto API.
> We have to resolve this difference before we can adopt the "alg"
> parameter values defined in draft-ietf-jose-json-web-algorithms-05 -- is the key size (or the curve name for EC keys) an attribute of the key or the algorithm?  It seems awkward to create a special rule in our low-level API to handle the key size/curve info in the algorithm identifier string shorthand.
> Wan-Teh
Received on Friday, 17 August 2012 22:04:16 UTC

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