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

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 21:06:47 UTC