The rationale for having the encrypted keys were because I thought that the main use case were to transfer keys from one system to another, while it stays within a system, hopefully we can use platform supplied storage mechanism and key store.
Now, your use case is different. You want to use the JWK private key stored in the local file system to sign or encrypt messages. For that, I agree it is turtles all the way. System implementers needs to be careful on how the process authentication is done when allowing the access to the key file is done though. =nat via iPhone On Aug 17, 2012, at 11:15 PM, Justin Richer <[email protected]> wrote: Nat, how would you store the private key that you encrypted the private key with? And what key would you use to encrypt your private-key-encrypter key? It's turtles all the way down, and not in a good way. I personally really like having a parallel format to JWK for private keys, and I even asked (off list) for this feature about six months back. My use case was simple, and still valid: I have a server that takes in a configuration file with all kinds of already-sensitive information, like database passwords and admin user lists. I would love to be able to put my public and private keys in there without dropping to an ASN.1 structure. I realized that with JWK, I could store my public keys, but didn't have any place to put the private keys. At the time, we punted and went with a container-native certificate store with self-signed certificates, but this setup remains overkill and a bad fit for what we actually care about, the keys. But in order to get the keys, we had to generate a self-signed cert with a fake certificate authority and junk metadata just to fit the format. A JWK/JPK structure (to coin an acronym for the soup) would be able to handle this quite nicely, and it parallels what the WebCrypto WG is after, from what I gather. It would be fairly easy to add support for shared HMAC secrets in the same format as well. However, I do agree with one point that was brought up: I don't necessarily like putting the two in the same structure. I think it's quite *functional* this way, but it seems like it could cause a problem like the private bits getting leaked. On the other hand, this feeling could be a case of premature intuition-based optimization [1], so I'm not sure how much credence to give it. -- Justin [1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/ On 08/16/2012 10:26 PM, Nat Sakimura wrote: Thanks Mike. Would it not be a good idea to mandate that private key file must be encrypted? As far as I remember, one of the reason for not producing private key format was from the fear that developers leave the exported keys in a insecure manner. Thoughts? Nat On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones <[email protected]>wrote: > 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 > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ jose mailing [email protected]https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
