Nat, I agree that a JWK containing a private key *could* be encrypted, but
requiring that seems to be overkill, in part, for the reasons that Justin
describes. There are many contexts where it is normal/safe to handle private
key information - just like it's normal/safe to handle plaintext password
values. (Analogously, there are also contexts where this information
should/must be encrypted.) Knowing when private keys should/must be encrypted
seems like a higher-level context-dependent decision.
Justin, per my reply to James, putting the two in the same structure seems to
be existing practice for other APIs. It's certainly the simplest solution. I
don't see that the safety properties would be any different whether there are
"public" and "private" members with sub-members for the key fields, or simply a
flat structure of key members, which is currently what's specified. In both
cases, if there is private key information present, it *must* be appropriately
protected.
Best wishes,
-- Mike
From: Justin Richer [mailto:[email protected]]
Sent: Friday, August 17, 2012 7:14 AM
To: Nat Sakimura
Cc: Mike Jones; Jim Schaad; [email protected]; Harry Halpin;
[email protected]; Karen O'Donoghue
Subject: Re: [jose] JOSE WG request from W3C WebCrypto API
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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
