Re: [jose] FOR WG DISCUSSION: #82 part A - Possibly changing representation of private JWK fields

I agree with Justin that the motivation for the breaking change seems pretty hypothetical to me.  Besides, a new standard key type only tends to be introduced every decade or so, so it *really* wouldn’t be that hard to update the hypothetical key filtering software to correctly filter new key types when needed, should such software ever be written.  It’s not like the set of “kty” values is a fast-moving target.

                                                                -- Mike

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Wednesday, October 02, 2013 7:25 AM
To: Jim Schaad; jose@ietf.org
Subject: Re: [jose] FOR WG DISCUSSION: #82 part A - Possibly changing representation of private JWK fields

I think that the argument below is misleading -- why kind of hypothetical key parsing or filtering program is going to read a JWK that doesn't know the key types it's parsing out? I'm still not seeing the value in having things split out. From my vantage, it seems to be a fairly arbitrary syntax decision, and at this point I'd really rather not change syntax on stuff I'm already using on a daily basis.

 -- Justin
On 10/01/2013 08:38 PM, Jim Schaad wrote:
There is an argument below that it would be more robust to make any filter software know what is public and what is private since that enforces a per-type evaluation.  However I would argue that this is a problem for any new key type that is published after such filter software is done.

The program which is creating the JWK object is going to know what is public and what is private because it must have been updated in order to export the correct fields for the new key type.  However the filter code may not have been updated to understand this new key type and therefore has no ability to know what is public and what is private unless it was also programmed to do a registry lookup in the IANA registry to figure this out.  Even then it would be unable to deal with private key types.

By placing all private fields in a private object, the filter program would always be able to correct do the filtering and make sure that private key material is not published as it would, by definition, be in a single object which is easily identified.  This means that a server would not need to reject any new key types that it does not understand when trying to make sure that private information is not published.

To me this is more robust than not having this indicated by the exporter functions.

This is similar to what is done today in the ASN.1 case.  The ASN.1 structure description is different between the public key and the private key structures for those things you know about.  This makes it easy to do the decode on the public key and ensure that nothing exists that shouldn’t.  It is not possible for us to do a filter based just on the public fields since there are other elements that exist in the JWK object which have nothing to do with the key value.  I would not advocate having both a public and a private member object since that would be slightly ridiculous.

Jim

From: jose-bounces@ietf.org<mailto:jose-bounces@ietf.org> [mailto:jose-bounces@ietf.org] On Behalf Of n-sakimura
Sent: Sunday, September 01, 2013 8:02 PM
To: jose@ietf.org<mailto:jose@ietf.org>
Subject: Re: [jose] FOR WG DISCUSSION: #82 part A - Possibly changing representation of private JWK fields

+1 Coming in late, all of what I had to say has already been said.

(2013/08/31 8:01), Naveen Agarwal wrote:

+1 Agree with Mike and Justin's comments.

On Wed, Aug 28, 2013 at 12:53 PM, Justin Richer <jricher@mitre.org<mailto:jricher@mitre.org>> wrote:
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:trac+jose@trac.tools.ietf.org<mailto:trac%2Bjose@trac.tools.ietf.org>]
Sent: Wednesday, August 28, 2013 12:36 PM
To: draft-ietf-jose-json-web-key@tools.ietf.org<mailto:draft-ietf-jose-json-web-key@tools.ietf.org>; Mike Jones
Cc: jose@ietf.org<mailto:jose@ietf.org>
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 michael.jones@microsoft.com<mailto:michael.jones@microsoft.com>):

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
jose@ietf.org<mailto:jose@ietf.org>
https://www.ietf.org/mailman/listinfo/jose

_______________________________________________

jose mailing list

jose@ietf.org<mailto:jose@ietf.org>

https://www.ietf.org/mailman/listinfo/jose

--

Nat Sakimura (n-sakimura@nri.co.jp<mailto:n-sakimura@nri.co.jp>)

Nomura Research Institute, Ltd.

Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は

、申し訳ござӓ

 6;|

14;せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。

PLEASE READ:

The information contained in this e-mail is confidential and intended for the named recipient(s) only.

If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.

_______________________________________________

jose mailing list

jose@ietf.org<mailto:jose@ietf.org>

https://www.ietf.org/mailman/listinfo/jose