- From: Ryan Sleevi <sleevi@google.com>
- Date: Fri, 17 Aug 2012 16:52:24 -0700
- To: Mike Jones <Michael.Jones@microsoft.com>
- Cc: Web Cryptography Working Group <public-webcrypto@w3.org>
On Fri, Aug 17, 2012 at 4:37 PM, Mike Jones <Michael.Jones@microsoft.com> wrote: > 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 With multi-prime RSA, it's only known at time of generation - there is still a single public exponent. It can be used when there needs to be a trade-off between speed and security - using multiple primes can reduce the effective security, but offer noticeable speed improvements. [1] RFC 3447 A.1.2 , which defines the PKCS#1 RSAPrivateKey structure, details how both the CRT parameters and multi-primes can be represented. [1] http://www.imperialviolet.org/2011/04/09/multiprime.html [2] http://tools.ietf.org/html/rfc3447#appendix-A.1.2 > > -----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:52:52 UTC