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] <mailto:[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] <mailto:[email protected]>]
Sent: Sunday, August 12, 2012 8:03 AM
To: Jim Schaad; Karen O'Donoghue; [email protected]
<mailto:[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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
