Re: [jose] AD review of draft-ietf-jose-jwk-thumbprint-04

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 21 April 2015 17:48 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 763C21A8ABD for <jose@ietfa.amsl.com>; Tue, 21 Apr 2015 10:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 HYhsDzSHxnCv for <jose@ietfa.amsl.com>; Tue, 21 Apr 2015 10:48:31 -0700 (PDT)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89A61B2A1E for <jose@ietf.org>; Tue, 21 Apr 2015 10:48:29 -0700 (PDT)
Received: by layy10 with SMTP id y10so156954813lay.0 for <jose@ietf.org>; Tue, 21 Apr 2015 10:48:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XRJbafGPJhsHXwo9iLr12JtTXNgNyCKVeZ73Po7op04=; b=YIugOOTUsW/PGBsHciMSZL7E6khvlfXNe7ffzq4bRteNOkCwDCUAQxAXLGMOGvRFy1 rkGKYn9MDojznA8CVgOJoR/aYpUqXhacPCXeR1wHF8fGId+3UIsPak+2aPM7PX1sNUer nJZG5UE9gIjDVTdfzpWi6AvYkciUSs33JDa9cGk9H7f1PDatiFZxjug6SE9c93ctE/zl IuHF02nBuelpZIJp0tHz5sZ2tJ2Hgvg+5rSbm3CIQG1DvTVHbtf5MnNpPooROs0hfget trIa0TpuQy7JMmke8IBA82jtdfPHbO8VD2KJvDKIGOGgL0y6hSqx1X4iCxl8h9EbtJw4 L6ag==
MIME-Version: 1.0
X-Received: by 10.112.148.101 with SMTP id tr5mr21682988lbb.0.1429638508188; Tue, 21 Apr 2015 10:48:28 -0700 (PDT)
Received: by 10.112.11.199 with HTTP; Tue, 21 Apr 2015 10:48:28 -0700 (PDT)
In-Reply-To: <BY2PR03MB4423DD1A72C5FAA71BC6AF8F5EF0@BY2PR03MB442.namprd03.prod.outlook.com>
References: <CAHbuEH4UfvUJtRE8Nj3vQv2B+yGKjPqi10+vSZoTvE4KYu79og@mail.gmail.com> <CAHbuEH7ns7+bc-CZROtta5OHOLizg1+b7PBn=RmBsRx5WNnX3Q@mail.gmail.com> <BY2PR03MB442D069E5BD81B2FF64467DF5EF0@BY2PR03MB442.namprd03.prod.outlook.com> <CAHbuEH4tEOgAprVokd4ki+RKP1gjGWq3ij25Qps4HR13Jb-rvA@mail.gmail.com> <00b101d07c59$bbd24e80$3376eb80$@augustcellars.com> <BY2PR03MB4423DD1A72C5FAA71BC6AF8F5EF0@BY2PR03MB442.namprd03.prod.outlook.com>
Date: Tue, 21 Apr 2015 13:48:28 -0400
Message-ID: <CAHbuEH6aB7+JGAFUepf4qN7a3P0G1+oGBfn5BH=k80bK-TEkUQ@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="047d7b3a898c7018a205143fa70f"
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/EwbWB2gKV58wcVE-pLFrLojQ7Us>
Cc: Jim Schaad <ietf@augustcellars.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] AD review of draft-ietf-jose-jwk-thumbprint-04
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: Tue, 21 Apr 2015 17:48:34 -0000

Hi Mike,

On Tue, Apr 21, 2015 at 1:43 PM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

>  Jim, I assumed that her uses of JWT were typos for JWK.
>
Yep, thanks.

>
>
> Kathleen, thanks for clarifying what you found confusing.  I’ll think
> about it some more, but my initial reaction is that the name “JWK
> Thumbprint” is appropriate because it specifies a thumbprint computation
> over a JWK representation of a key.  Even if, per Section 3.4, the key
> didn’t start life as a JWK, the thumbprint computation specified creates a
> JWK representation of the key and hashes it.  Hence “JWK Thumbprint”.  I’ll
> think some more, particularly when revising the introduction and
> definitions, about how to make this clearer.
>

I'm fine with the term "JWK Thumbprint" if it is clearly defined and used
consistently.  It's just not clear to me that it is a "Key fingerprint" as
well since required fields of the JWK are included in addition to the key.
In that respect, it is more like a certificate fingerprint that includes
the key and attributes of a certificate, but I understand it is a JWK
Thumbprint.

Thanks,
Kathleen

>
>
>                                                             Thanks again,
>
>                                                             -- Mike
>
>
>
> *From:* Jim Schaad [mailto:ietf@augustcellars.com]
> *Sent:* Tuesday, April 21, 2015 10:37 AM
> *To:* 'Kathleen Moriarty'; Mike Jones
> *Cc:* jose@ietf.org
> *Subject:* RE: [jose] AD review of draft-ietf-jose-jwk-thumbprint-04
>
>
>
> Kathleen,
>
>
>
> Some of you message is confusing me.  You keep referring to JWT in it.
> Are you doing this as JW Token or JW Thumbprint?  JWT is currently
> “reserved” for the token and thus it is being confused.   Can you clarify?
>
>
>
> Jim
>
>
>
>
>
> *From:* jose [mailto:jose-bounces@ietf.org <jose-bounces@ietf.org>] *On
> Behalf Of *Kathleen Moriarty
> *Sent:* Tuesday, April 21, 2015 8:48 AM
> *To:* Mike Jones
> *Cc:* jose@ietf.org
> *Subject:* Re: [jose] AD review of draft-ietf-jose-jwk-thumbprint-04
>
>
>
> Hi Mike,
>
>
>
> On Tue, Apr 21, 2015 at 11:22 AM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>
> Hi Kathleen,
>
>
>
> Thanks for taking the time to review the draft and write up today’s and
> yesterday’s comments.  Replies inline below…
>
>
>
> *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Kathleen
> Moriarty
> *Sent:* Tuesday, April 21, 2015 7:47 AM
> *To:* jose@ietf.org
> *Subject:* Re: [jose] AD review of draft-ietf-jose-jwk-thumbprint-04
>
>
>
> Another thing has been bugging me since reading the draft yesterday and
> I'm not sure if this was discussed in the WG or not.  There appear to be
> differences in how a JWT thumbprint is described in the draft.  I'd like to
> see if we can work this out before progress the draft into IETF last call.
>
>
>
> The definition is not entirely clear.
>
> Section 3 clearly states that the required members of the JWT are part of
> the thumbprint.
>
> Section 3.2.2, although the subtitle makes the point that this is about
> why optional members are not included, the following sentence appears:
>
>    The JWK Thumbprint value is a
>
>    digest of the key value itself -- not of additional data that may
>
>    also accompany the key.
>
>
>
> 3.2.2 was included in response to earlier review comments by Jim Schaad.
> It’s there to motivate the particular choices made.  Is there some way in
> which you find 3 and 3.2.2 to be inconsistent?  3 is a positive statement
> about what’s included and the sentence in 3.2.2 that you quoted above is a
> negative statement about what’s not included, but that is consistent with
> the positive statement.  The negative statement is included to help readers
> understand the reasoning.  Is there some way in which you found it
> confusing or misleading?  Is there a particular change you might suggest to
> alleviate your concern?
>
> [JLS] And I didn’t complain but it did not do a good job of what I asked
> it to do.
>
>
>
> It is confusing.  Is this a thumbprint of the JWT or just the key?  If
> it's just the key, it should be called a Key thumbprint.  If it is of the
> JWK members that includes a key, I'm fine with this being the "JWK
> thumbprint".  If it's just of the key, the quoted sentence above is fine,
> but if the JWK required members are included and it's not just the key, you
> have conflicting statements.
>
>
>
>
>
> Section 3.4 - Why is this allowed?  If it's not in JWT format, it is some
> other kind of thumbprint. You are essentially creating a JWK to have the
> key and required members I am assuming, but that's not clear and this text
> could leave interoperability challenges.
>
>
>
> 3.4 points out that the draft specifies a mathematical computation over a
> key value, which can be performed on any key.  It’s stating what’s
> possible, more than what’s stating what’s allowed.  Yes, you’re right that
> you’d be creating a JWK representation of the key value to create the
> thumbprint.  If a thumbprint of the key is needed, this may be a reasonable
> choice in some application contexts.
>
>
>
> Again, is this a "Key Thumbprint" or a "JWK Thumbprint".  The draft needs
> to be consistent and use the correct term depending on what type of
> thumbprint this is.  I'm assuming JWK Thumbprint, that is kind of similar
> to a certificate thumbprint in that it's over a full set of data and not
> just the key (JWK or certificate in the case of X.509).
>
>
>
> I hope that further clarifies why I find the text confusing.
>
>
>
>
>
> Thanks,
>
> Kathleen
>
>
>
> On Mon, Apr 20, 2015 at 3:23 PM, Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com> wrote:
>
> Hi,
>
>
>
> Thanks for your work on draft-ietf-jose-jwk-thumbprint-04.  This is the
> last one, right?  Great job getting through the JOSE work!
>
>
>
> I read through the draft and have mostly editorial comments that I'd like
> to see if we can fix.
>
>
>
> Section 2:
>
> The definition needs some tweaking:
>
>
>
>  JWK Thumbprint
>
>       The digest value for a key that is the subject of this
>
>       specification.
>
>
>
> "the subject of this specification" should not part of text for a
> definition.  The definition needs to clearly explain the term without
> having to read the whole specification.  Can you suggest something else?
>
>
>
> Karen relayed text from Jim to me that I like and that will be used to
> improve the definition.  It was:
>
>
>
> “This document defines a method for computing a hash value over a JSON Web
> Key structure.  The document describes what the subset of fields in a key
> to be used are, the method of creating a canonical form for those fields
> and how to convert the resulting UNICODE string into a byte sequence
> appropriate for hashing.”
>
>
>
> That helps to improve the abstract and introduction, thank you.  How about
> the definition of JWK Thumbprint?  It should not include things like "this
> specification" or "this document".  It should be a stand alone definition.
>
>
>
> Section 4:
>
>
>
> Can you break this sentence into 2:
>
> However, if new JWK members are defined that use non-ASCII member
>
>    names, their definitions should specify the exact Unicode code point
>
>    sequences used to represent them, particularly in cases in which
>
>    Unicode normalization could result in the transformation of one set
>
>    of code points into another under any circumstances.
>
>
>
> OK
>
>
>
> Can you get rid of the parens around the second sentence?
>
>    Use of escaped characters in JWKs for which JWK Thumbprints will be
>
>    computed should be avoided.  (Use of escaped characters in the hash
>
>    input JWKs derived from these original JWKs is prohibited.)
>
>
>
> OK
>
>
>
> Can you reword this sentence/paragraph?  I had to read it multiple times.
> While I understand what you are saying, it could be easier to read.
>
>    While there is a natural representation to use for numeric values
>
>    that are integers, this specification does not attempt to define a
>
>    standard representation for numbers that are not integers or that
>
>    contain an exponent component.  This is not expected to be a problem
>
>    in practice, as the required members of JWK representations are not
>
>    expected to use numbers that are not integers.
>
>
>
> OK
>
>
>
> General comment, the use of long sentences and frequency of parens make
> the draft more difficult to read.
>
>
>
> Thanks for pointing this out.  I’ll try to keep this in mind.
>
>
>
> Great, thanks!
>
> Kathleen
>
>
>
> Thanks!
>
>
>
>                                                             Thanks again!
>
>                                                             -- Mike
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>



-- 

Best regards,
Kathleen