Re: [jose] #82: Section 6. Encrypted JWK and Encrypted JWK Set Format

"jose issue tracker" <trac+jose@trac.tools.ietf.org> Wed, 28 August 2013 19:36 UTC

Return-Path: <trac+jose@trac.tools.ietf.org>
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 5F80B11E81A8 for <jose@ietfa.amsl.com>; Wed, 28 Aug 2013 12:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.597
X-Spam-Level:
X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 i0HXhbclAI-h for <jose@ietfa.amsl.com>; Wed, 28 Aug 2013 12:36:23 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8052E11E8178 for <jose@ietf.org>; Wed, 28 Aug 2013 12:36:23 -0700 (PDT)
Received: from localhost ([127.0.0.1]:43754 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+jose@trac.tools.ietf.org>) id 1VElXP-0007AR-Q5; Wed, 28 Aug 2013 21:36:19 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: jose issue tracker <trac+jose@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-jose-json-web-key@tools.ietf.org, michael.jones@microsoft.com
X-Trac-Project: jose
Date: Wed, 28 Aug 2013 19:36:19 -0000
X-URL: http://tools.ietf.org/jose/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/jose/trac/ticket/82#comment:1
Message-ID: <076.da1dfff95c3b86aed21c470c179142d6@trac.tools.ietf.org>
References: <061.ed2dc15f379477074fd266a8f9af62ba@trac.tools.ietf.org>
X-Trac-Ticket-ID: 82
In-Reply-To: <061.ed2dc15f379477074fd266a8f9af62ba@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-key@tools.ietf.org, michael.jones@microsoft.com, jose@ietf.org
X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: mbj@microsoft.com
Resent-Message-Id: <20130828193623.8052E11E8178@ietfa.amsl.com>
Resent-Date: Wed, 28 Aug 2013 12:36:23 -0700
Resent-From: trac+jose@trac.tools.ietf.org
Cc: jose@ietf.org
Subject: Re: [jose] #82: Section 6. Encrypted JWK and Encrypted JWK Set Format
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 28 Aug 2013 19:36:24 -0000

#82: Section 6. Encrypted JWK and Encrypted JWK Set Format


Comment (by 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".

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-jose-json-web-
  ietf@augustcellars.com |  key@tools.ietf.org
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  json-web-    |     Version:
  key                    |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://tools.ietf.org/wg/jose/trac/ticket/82#comment:1>
jose <http://tools.ietf.org/jose/>