Re: [jose] gen-art telechat review of draft-ietf-jose-json-web-key-33

Scott Brim <> Tue, 30 September 2014 19:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 08B101A8888; Tue, 30 Sep 2014 12:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hBi_KS2ckTmv; Tue, 30 Sep 2014 12:59:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F23891A885A; Tue, 30 Sep 2014 12:59:04 -0700 (PDT)
Received: by with SMTP id vb8so6326529obc.35 for <multiple recipients>; Tue, 30 Sep 2014 12:59:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=s61kk/MCJoUDUmAuTZnwASDzeVJVX55Kf5FfvHCFbY8=; b=fAhFiI0zvxtOWO8rWfqFUJDQcAtIZ3dfsVYKXbpFJa/tRXiQXC17kD6q+kAy2uCOdH UR0eubANYSEN5bdTEtayu1t45XWH9aGBl32Qfl5xetvaIdnMSP6ygsovmKm1jqHvCtPh Y8/E3CGvG//Kig1VVYfaocdjPGOcVuStboT4JzFuzhoNc6P+W3tHIFvtTvLT7fPqrAoo x7O4qpoMjw7ahZtK299kwyjY+XxiGQs2T5mjE9jixAJeYluYoG/+uyQZBhiK33TBl/JN RFg3nQ8MZ2lM6jvbZ+ROR8Ee5Aqwx1upgY55Qys02g4JgrcnH7NysbMwlKqPZtd4lm4P Dd3g==
X-Received: by with SMTP id tl4mr49925825oeb.57.1412107144471; Tue, 30 Sep 2014 12:59:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 30 Sep 2014 12:58:44 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Scott Brim <>
Date: Tue, 30 Sep 2014 15:58:44 -0400
Message-ID: <>
To: Mike Jones <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 30 Sep 2014 13:16:11 -0700
Cc: "" <>, gen-art <>, "" <>
Subject: Re: [jose] gen-art telechat review of draft-ietf-jose-json-web-key-33
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Sep 2014 19:59:07 -0000

On Tue, Sep 30, 2014 at 2:29 PM, Mike Jones <> wrote:
> Minor issues:
>   More than once it is said that members that are not understood
>   should or must be ignored. Wouldn't this depend on context? Couldn't
>   there be uses of the data structure where a negative reply would be
>   needed if something is not understood, so the sender can adapt?
> This language is present so that extensions carrying additional information
> can be added in a non-breaking fashion.  You’re right that, in theory, a
> “must-understand” capability could be added for particular fields, as was
> done for JOSE header parameters in
> but in practice, no working group member has come forward saying they are
> aware of an application that needs this for key representations.  Rather,
> the working group’s thoughts were that multiple keys would be present in a
> JWK Set, some of which might not be understood, but those that are
> understood would be used.  This might be the case, for instance, when an
> entirely new key type (not RSA, Elliptic Curve, or Symmetric) is invented
> and added at some point in the future.
> Do you have a specific example in mind that requires a “must-understand”
> capability for key representations?

I don't do keys (this is gen-art, where reviews are often done by
experienced generalists, not experts in the field), so it doesn't do
any good asking me for text :-). Now that I think about it, I don't
need what I'm looking for to be in this draft -- it could be in the
larger context. Essentially it has to be possible (not required) for
there to be some kind of feedback from whoever receives this to
whoever sent it. That can be in the surrounding protocol.

>   In Section 4.3, you give the general principle that multiple
>   unrelated key operations shouldn't be specified for a key, and give
>   an example. Since this is a security issue of unknown magnitude (the
>   future isn't here yet), what do you think of removing uncertainty by
>   being more exhaustive in the principles and/or examples?
> This is a “SHOULD NOT” rather than a “MUST NOT” because there are existing
> use cases in which the same RSA key is used for both signing and encryption.
> I’m not an expert in the underlying cryptography, but it’s my understanding
> that this is quasi-OK for RSA because both RSA signatures and RSA encryption
> actually are based on an RSA encryption operation, and so what appears to be
> using a key being used for unrelated operations actually isn’t under the
> covers, in this particular case.  However, if you want to supply additional
> proposed security considerations text on this issue (or possibly even
> better, cite pertinent security considerations text in an existing RFC that
> we could reference), that would be appreciated.

OK, it seems the boundaries are clear to you and implementors who will
read the RFC, which is all I ask.

Thanks ... Scott