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

Are there actual uses of multiple primes or is this of only theoretical interest?  If it's used, can you point me to a data structure used to represent them that I can mimic?

As for the CRT parameters, is there an existing representation you can point me to for RSA private keys with CRT parameters that I could mimic?

				Thanks again,
				-- Mike

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Friday, August 17, 2012 3:04 PM
To: Mike Jones
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]

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 ( http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data
). 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 23:37:38 UTC