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

Richard Barnes <rlb@ipv.sx> Thu, 02 October 2014 04:05 UTC

Return-Path: <rlb@ipv.sx>
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 3B0D41A0063 for <jose@ietfa.amsl.com>; Wed, 1 Oct 2014 21:05:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 PMdMcgfuPMUG for <jose@ietfa.amsl.com>; Wed, 1 Oct 2014 21:05:50 -0700 (PDT)
Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B511A0062 for <jose@ietf.org>; Wed, 1 Oct 2014 21:05:49 -0700 (PDT)
Received: by mail-lb0-f171.google.com with SMTP id z12so1539219lbi.30 for <jose@ietf.org>; Wed, 01 Oct 2014 21:05:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ndEY7FUWvjqanDW/tcrAEwSJ0Am5o6oEKS1A8EyI2Qw=; b=asdyG31JHBhna7hdoARywtbJwkBQiXowPcNWWfxZs5ra3L/mXYeeIqpMIux8YQymn+ vUHGY3iuqEn6MV7ceAY5pytO4v9ZR8WRb5sSYpEpMr/I/wMOrgKfZUWYq5bilMWrb5yr I0Ultt+y1U7rvp0A2uNmzX+TpdmHUekWIJuo8xFQNYujQheGiTaTWnTogfvsIL/ceevs jMDKhmiwbegwWfu+zLYVlZS/gRWzQkbtubM6HjTjmg6WRjdeDG5GX42zhKQi2hvPOrdD 4L23s91bTgMiRMXzO7NyYAfiHc7tc0vMhPpruAEhOfvcTmEfE5Nrcul7Qtp8AHoWlI6+ aGgg==
X-Gm-Message-State: ALoCoQm4OpLqJLvmLy6T6kYaipFr50+Gr7ES5FWymEYfijohk2bouYUfsibh43fz3DS3gQzPSPnP
MIME-Version: 1.0
X-Received: by 10.152.234.76 with SMTP id uc12mr59748463lac.50.1412222747575; Wed, 01 Oct 2014 21:05:47 -0700 (PDT)
Received: by 10.25.142.3 with HTTP; Wed, 1 Oct 2014 21:05:47 -0700 (PDT)
In-Reply-To: <0fb901cfddf2$5e21c7d0$1a655770$@augustcellars.com>
References: <20141002023359.19368.17933.idtracker@ietfa.amsl.com> <0fb901cfddf2$5e21c7d0$1a655770$@augustcellars.com>
Date: Thu, 2 Oct 2014 00:05:47 -0400
Message-ID: <CAL02cgQcfVCeCtuZQDEiv4vBM_kW28dS07fqW+zafyuqAQLU2w@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Jim Schaad <ietf@augustcellars.com>
Content-Type: multipart/alternative; boundary=001a11340f12369eeb050468bb0f
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/PkVz_C9yvbtf7gJErxJyK76_Wx0
Cc: "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, "draft-ietf-jose-json-web-key@tools.ietf.org" <draft-ietf-jose-json-web-key@tools.ietf.org>, The IESG <iesg@ietf.org>, "jose@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 04:05:52 -0000

On Wed, Oct 1, 2014 at 11:38 PM, Jim Schaad <ietf@augustcellars.com> wrote:

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

My point is that consumers of JWK *are* going to be interpreting both of
these if present, so there are going to be interop issues if they don't
interpret both of them in the same way.

How about something like the following:
"""
If a JWK includes both a "use" member and a "key_ops" member, then the
fine-grained permissions in the "key_ops" member MUST be consistent with
the coarse-grained permissions in the "use" member:
  * enc: encrypt, decrypt, wrapKey, unwrapKey, deriveKey, deriveBits
  * sig: sign, verify

If the consumer of a JWK encounters an invalid combination of "use" and
"key_ops" (e.g., "sig" and "encrypt"), then it SHOULD reject the JWK as
invalid.
"""

--Richard




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