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

n-sakimura <n-sakimura@nri.co.jp> Mon, 02 September 2013 03:01 UTC

Return-Path: <n-sakimura@nri.co.jp>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D863911E82DE for <jose@ietfa.amsl.com>; Sun, 1 Sep 2013 20:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.089
X-Spam-Level:
X-Spam-Status: No, score=-0.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em+OTuUf12jN for <jose@ietfa.amsl.com>; Sun, 1 Sep 2013 20:01:50 -0700 (PDT)
Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C54511E80D2 for <jose@ietf.org>; Sun, 1 Sep 2013 20:01:49 -0700 (PDT)
Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs02.index.or.jp (Postfix) with SMTP id D268F196862 for <jose@ietf.org>; Mon, 2 Sep 2013 12:01:45 +0900 (JST)
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea03.index.or.jp (unknown) with ESMTP id r8231jju013398 for <jose@ietf.org>; Mon, 2 Sep 2013 12:01:45 +0900
Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.3/Switch-3.3.3) with ESMTP id r8231jbn013882; Mon, 2 Sep 2013 12:01:45 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.3/Switch-3.3.0/Submit) id r8231jDn013881; Mon, 2 Sep 2013 12:01:45 +0900
X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf21a.index.or.jp ([172.100.25.19]) by nrims00b.nri.co.jp (Switch-3.3.3/Switch-3.3.3) with ESMTP id r8231jTE013873 for <jose@ietf.org>; Mon, 2 Sep 2013 12:01:45 +0900
Received: from 127.0.0.1 (127.0.0.1) by m-FILTER with ESMTP; Mon, 2 Sep 2013 12:01:45 +0900
Message-ID: <5223FF8E.1@nri.co.jp>
Date: Mon, 02 Sep 2013 12:01:34 +0900
From: n-sakimura <n-sakimura@nri.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: jose@ietf.org
References: <4E1F6AAD24975D4BA5B16804296739436B7FBEA6@TK5EX14MBXC283.redmond.corp.microsoft.com> <521E552B.6060100@mitre.org> <CAOKiTbvnNka5jkY97ezyieGKhi_7WvnL6oEXTZNeWYzGWdEP+A@mail.gmail.com>
In-Reply-To: <CAOKiTbvnNka5jkY97ezyieGKhi_7WvnL6oEXTZNeWYzGWdEP+A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------070407030007060002050102"
X-MailAdviser: Ver1.3.3
Subject: Re: [jose] FOR WG DISCUSSION: #82 part A - Possibly changing representation of private JWK fields
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2013 03:01:56 -0000

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


-- 
Nat Sakimura (n-sakimura@nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
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.