Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)

"Jim Schaad" <ietf@augustcellars.com> Thu, 02 October 2014 03:41 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A8B1A005E; Wed, 1 Oct 2014 20:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aICFRApmf7XA; Wed, 1 Oct 2014 20:41:13 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8F51A005A; Wed, 1 Oct 2014 20:41:13 -0700 (PDT)
Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id A924938F08; Wed, 1 Oct 2014 20:41:12 -0700 (PDT)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Richard Barnes'" <rlb@ipv.sx>, "'The IESG'" <iesg@ietf.org>
References: <20141002023359.19368.17933.idtracker@ietfa.amsl.com>
In-Reply-To: <20141002023359.19368.17933.idtracker@ietfa.amsl.com>
Date: Wed, 1 Oct 2014 20:38:44 -0700
Message-ID: <0fb901cfddf2$5e21c7d0$1a655770$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIgq7eoql4biEyUw+dKWaWWQvbAG5t6jICQ
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/e9UIAi9Uu_FCUs-IZIea4FSi8_I
Cc: jose-chairs@tools.ietf.org, draft-ietf-jose-json-web-key@tools.ietf.org, jose@ietf.org
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 02 Oct 2014 03:41:17 -0000


-----Original Message-----
From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, October 01, 2014 7:34 PM
To: The IESG
Cc: jose-chairs@tools.ietf.org; draft-ietf-jose-json-web-key@tools.ietf.org;
jose@ietf.org
Subject: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33:
(with DISCUSS and COMMENT)

Richard Barnes has entered the following ballot position for
draft-ietf-jose-json-web-key-33: Discuss

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 4.3.
"The "use" and "key_ops" JWK members SHOULD NOT be used together."
Did the WG discuss how these could combine?  What was the outcome of that
discussion?  This could be an important point for interoperability.  For
example, WebCrypto enforces them both, so it will break if it gets a key
with "use" and "key_ops" set to inconsistent values.
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#rsa-pss
-operations

[JLS] The set of values in use and key_ops do not have the same granularity.
This means that if you use both, you will be granting things in use that are
not granted in key_ops.  This was discussed by the group.

Section 8.
"[TBD]@ietf.org"
This needs to be populated before approval.  I don't know what's customary
here, but "jose@ietf.org" is an obvious candidate.

[JLS] If this is going to be an IANA moderated list, then it should be
filled in by IANA at the time of publishing and not now.  I believe that was
the original intent.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1.1.
The pointer for BASE64URL should be to JWS.  One level of indirection,
please :)

Section 4.
It might be worth being explicit (here or elsewhere):
"A JWK MUST NOT contain algorithm-specific members for key type other the
one specified in its "kty" attribute."

Section 4.1.
"cryptographic algorithm family used with the key"
"... such as "RSA" or "EC"."

Section 4.7.
"base64 encoded ([RFC4648] Section 4 -- not base64url encoded) DER"
It seems unpleasant for implementations to have to support two flavors of
base64, especially since this doesn't use PEM directly.  Did the WG discuss
just using BASE64URL?

Section 9.1.
It might help here to note that technologies like PKIX and JWT can allow
relying parties to verify the provenance of a key and binding of attributes
to it.


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose