If the leak is going to happen, it's not going to be on part of the JWK
object or JWK set, it's going to be on the whole thing. Stuffing it into
a sub-object isn't going to make it any safer in practice. If you want
to generate a public key from a public/private pair, you could argue
that it'd be simpler to have an outbound thing filter out just the
".private" sub-object as opposed to having something key-specific, but I
think the latter is actually more robust against different key types
since it enforces a per-type evaluation of what's "public" and what's
"private".
I agree with Mike's contention regarding symmetric keys, below -- it's
tricky though. In the Nimbus-JOSE-JWT implementation of JWK we've taken
the approach of saying that the "public" version of an OctetSequenceKey
is null.
Parallelism on the keying material overall is a good thing though, so
I'd prefer to leave it how it is.
-- Justin
On 08/28/2013 03:40 PM, Mike Jones wrote:
This is a second issue in the issue tracker that I wanted to bring to the
working group’s attention for discussion. My personal view is stated in the
issue tracker comment below.
-- Mike
-----Original Message-----
From: jose issue tracker [mailto:[email protected]]
Sent: Wednesday, August 28, 2013 12:36 PM
To: [email protected]; Mike Jones
Cc: [email protected]
Subject: Re: [jose] #82: Section 6. Encrypted JWK and Encrypted JWK Set Format
#82: Section 6. Encrypted JWK and Encrypted JWK Set Format
Comment (by [email protected]):
This comment is about part A of this issue - the suggestion that private key material within a JWK
be moved into a "private" element. While I understand the motivation for the
suggestion, this doesn't seem like a necessary or particularly useful change. If an
implementation leaks its private or shared key information by disclosing a JWK containing it to a
party not entitled to have it, there's no security difference in whether that information is in a
top-level member or a member of a "private" field. The information will have still been
inappropriately disclosed.
This suggestion is also ambiguously specified. While yes, the "d" elements of elliptic curve and RSA keys
could be moved to be within a "private" structure, what would be done for the "k" element of a
symmetric key? Would that also be moved into a "private" element? (At that point, there would be no
symmetric key information at the top level of the JWK, which seems more than a little odd.)
Finally, I'll note that the specs already clearly delineate public from private fields, through use
of the Parameter Information Class value in the JSON Web Key Parameters registry (with values
"Public" and "Private"). So there should be no confusion which is which.
I therefore recommend that this suggestion be resolved as "wontfix".
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
