Mike, You have said that you think that doing this as JOSE structures would be useful. It is not clear to me that there is actually a use case defined here that bears that out.
Who is responsible for building and encrypting (or decrypting and parsing) the structure? Are we suggesting that the private keys be exported in the clear and it is up to the JOSE developer to encrypt them or are we saying that it is up to the WebCrypto system to do this on behalf of the JOSE developer? If we say it is the JOSE developer, then this introduces lots of places where the private keys will be handled insecurely - if nothing else from just hanging around in memory until they get cleaned up. If we say that it is the WebCrypto system that does this, then we are saying that we don't really care what the format of the private key blobs is internally, we just need to know how to deal with them from the scripting side - which would be as a blob of some type (either a binary blob or a string blob). Finally, how much do we want this to be a portable method of doing key transport? All of the browsers currently have a method of doing an import and export of an ASN.1 private key blob. What is the additional benefit that you think would be obtained from the WebCrypto side from having a second format that all of the browsers would need to support, but which might not have the same level of support from various operating systems and key devices? Would this then lead to scripters needing to have two different sets of import/export code depending on what the internal structure was and potentially needed to switch between the two structures? I think it makes sense to allow for the use of JOSE public keys since that is being passed in the message structure itself. I don't believe that it makes a great deal of sense at this point in time to have a private key structure defined. Jim > -----Original Message----- > From: Mike Jones [mailto:[email protected]] > Sent: Thursday, August 16, 2012 8:49 AM > To: Harry Halpin; Jim Schaad; Karen O'Donoghue; [email protected] > Cc: [email protected] > Subject: RE: JOSE WG request from W3C WebCrypto API > > Thanks for writing, Harry and WebCrypto WG. > > 1) About private keys, given the WebCrypto use case, I personally think it > would be valuable for JOSE to define a JSON private key representation. To > make this concrete, I would propose the private key representations > specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key. > You'll see that doing this is very simple; it just defines two additional > members for the JWK structure for representing the private parts of Elliptic > Curve and RSA keys. This could either remain a separate spec from JWK/JWA > or be merged in, at the working group's preference. > > I had previously agreed with the position that it was not necessary for JOSE > to define private key representations because we didn't have a use case for > it. However, as I see it, the W3C WebCrypto API use case changes things. > Better for JOSE to be responsive to WebCrypto and add this simple > extension, either as a new spec or in the existing specs, than to leave this > undone, and have it potentially be an area where otherwise standards- > compliant implementations diverge, and where JSON-only solutions are not > possible. > > Finally, I'll note that the JOSE charter > http://datatracker.ietf.org/wg/jose/charter/ does not preclude defining > private key formats. (It simply requires the definition of public key formats > and is silent on the topic of private keys.) > > 2) I agree on the likely need for WebCrypto support ASN.1 for backwards > compatibility in some cases (just as the JOSE specs allow the use of X.509 > certificates). However, I believe it would be a shame to preclude JSON-only > solutions by not supporting key import/export in JWK format, where such > solutions make sense. > > 3) It appears to me the JWK format is stable. I believe the JWS format is > stable as well. The JWE format has known changes that will be applied > shortly, based upon working group discussions at IETF 84 in Vancouver two > weeks ago. Some JWA changes will occur that are part of the JWE changes. I > don't anticipate significant changes after that. (Making these changes is my > highest priority as JOSE editor. I'm hoping to have drafts out containing them > by the end of August, which hopefully fits well with the WebCrypto > schedule.) I write all of the above with the caveat that the working group is, > of course, free to change things as they see fit. > > I look forward to a productive discussion of this coordination request in both > working groups. > > Best wishes, > -- Mike > > P.S. If you prefer, a HTML-formatted version of the private key spec is > available at http://self-issued.info/docs/draft-jones-jose-json-private- > key.html. I also blogged about this draft specification at http://self- > issued.info/?p=816. > > -----Original Message----- > From: Harry Halpin [mailto:[email protected]] > Sent: Sunday, August 12, 2012 8:03 AM > To: Jim Schaad; Karen O'Donoghue; [email protected]; Mike Jones > Subject: JOSE WG request from W3C WebCrypto API > > [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] > > JOSE Chairs, > > The Web Cryptography Working group has noted that the API requires some > access to raw key material, and the issue of whether or not to use JWK or > ASN.1 as the default format came up. Two issues have come out that we'd > like to know the answer to: > > 1) JWK does not define a private key format. Does the JOSE WG plan to > support a JOSE-format for private keys? If so, when? Or 'maybe'? > > 2) While we'd like encourage the use of JOSE over ASN.1, it seems like for > backwards compatibility having some level of ASN.1 support would be useful > and we *need* a format that allows key material (both private and > public) to be exported. Folks seem to leaning towards ASN.1 as a default > format in the low-level API, and having JWK as a format that can be built on > top of that in a possible high-level API. Would that be OK? > > 3) How stable do you believe the JOSE formats are right now? Do you think > they are stable enough now we can reference them in our API draft at end of > August? If not, when? The W3C would like to and plan to use these formats > where possible. > > Feel free to forward this by JOSE WG for discussion. We'd like an answer > before we send our document to FPWD at end of August. > > cheers, > harry > > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
