Re: [jose] Last Call: <draft-ietf-jose-jwk-thumbprint-05.txt> (JSON Web Key (JWK) Thumbprint) to Proposed Standard
Matias Woloski <matiasw@gmail.com> Tue, 02 June 2015 23:15 UTC
Return-Path: <matiasw@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3621B3202; Tue, 2 Jun 2015 16:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no
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 OSf4-ZfAlC5Y; Tue, 2 Jun 2015 16:15:15 -0700 (PDT)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 8E1B21B3201; Tue, 2 Jun 2015 16:15:15 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so98823891igb.1; Tue, 02 Jun 2015 16:15:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A2ozaNVcjDU6uMhKYzcrYc7mC5kUVekJUzSaajKbbHw=; b=dLyE3mUuVzB2qNUiC2Tp5Uoh4qKjMELAwhBOgkYc/c/vWf+rDIKjJgmyiRmxNwGv4e wSnWzeudhFfSmDJXU382lE3/jeE0e7d1fF2prJ9rJGR4OKd3Zzd6CyuexTGBHIrIK7gw RrXAcHKoEBMQX84SLC8VhHT9I/L3ch7MqEw1rMaV2bGdVZdO4M99qA3WeIBrtryNWxhB 2FRkRg5JFeKHQEDIfPfaZ+onSnXehUPFUMaZlXz8PkRyObtRfvu0CJ9R3gLqqxxL1Xkt 69qYJvPfwGJ5kw9l+Z1PGWpgO4XnsDbSbyrccWFYFWNlerGQ8yE5XHe4CsMM1axVShZN tmrg==
X-Received: by 10.50.30.105 with SMTP id r9mr23522727igh.11.1433286914912; Tue, 02 Jun 2015 16:15:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.124.70 with HTTP; Tue, 2 Jun 2015 16:14:54 -0700 (PDT)
In-Reply-To: <1253769260.3060317.1433203488263.JavaMail.yahoo@mail.yahoo.com>
References: <F515B0C8-A2E0-454E-B0E1-0E984B9FA31B@ve7jtb.com> <1253769260.3060317.1433203488263.JavaMail.yahoo@mail.yahoo.com>
From: Matias Woloski <matiasw@gmail.com>
Date: Tue, 02 Jun 2015 20:14:54 -0300
Message-ID: <CAK+KdNUsarKkCkxvN1_sUYCsfrudFs0j4srbpJM-gcpX7qzSOQ@mail.gmail.com>
Subject: Re: [jose] Last Call: <draft-ietf-jose-jwk-thumbprint-05.txt> (JSON Web Key (JWK) Thumbprint) to Proposed Standard
To: Edmund Jay <ejay@mgi1.com>
Content-Type: multipart/alternative; boundary="e89a8f64277a6cba900517911ddb"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/b4LoYw2RzsCD8dDZY6YA1Q08w2o>
X-Mailman-Approved-At: Wed, 03 Jun 2015 09:06:01 -0700
Cc: John Bradley <ve7jtb@ve7jtb.com>, "ietf@ietf.org" <ietf@ietf.org>, "jose@ietf.org" <jose@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2015 23:15:18 -0000
Agree with the simplicty. From an implementer perspective, this is very easy to implement. Doing sha256 and order the elements (or create a jwk with the right order) is as simple as it can gets. On Mon, Jun 1, 2015 at 9:04 PM, Edmund Jay <ejay@mgi1.com> wrote: > I agree with John. I think the spec is fine as is, for generating a keyid > for a simple jwk. > Adding hash input bytes for keys that may or may not have other uses will > add additional/unnecessary complexity. > > > ------------------------------ > *From:* John Bradley <ve7jtb@ve7jtb.com> > *To:* Stephen Farrell <stephen.farrell@cs.tcd.ie> > *Cc:* ietf@ietf.org; jose@ietf.org > *Sent:* Monday, June 1, 2015 9:23 AM > *Subject:* Re: [jose] Last Call: <draft-ietf-jose-jwk-thumbprint-05.txt> > (JSON Web Key (JWK) Thumbprint) to Proposed Standard > > I understand Stephen’s issue. > > However this is intended to be a simple way to generate a keyid value > based on a JWK. > > I think the document as is accomplishes that. > > If we want to generate a keyid based on the SubjectPublicKeyInfo format > from x.509 people should be able to do that based on the existing specs. > > We did drop the jkt member from the spec a while ago based on feedback. > > Based on some of the discussion on creating a thumbprint from a SPKI there > may be a need for better documenting > how to do that. A number of the proposals discussed for doing it without > full processing only worked for some key-types., > however that should be a separate spec. > > I think this one is ready to go. > > Regards > John B. > > > > > > On May 28, 2015, at 2:04 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> > wrote: > > > > > > Hi, > > > > I have one comment on this that I did raise with the WG (the > > thread starts at [1] but the subject lines diverged so it's > > not so easy to follow). At the end of that I think I was > > correctly judged to be in the rough within the WG. I'm > > raising it again now as a last-call comment (and wearing > > no hat) as the issue is really about doing the same thing > > in multiple protocols/WGs, so this could be a case where > > IETF consensus maybe ought win over WG consensus, depending > > on whether folks working on other protocols care or not. > > (And I'm not sure if they do.) > > > > Note that if the draft as-is turns into an RFC it will not > > be the end of the world, so I'd only expect that a change > > would be done if there're a load of people who agree that > > changing is beneficial for some actual use-case they have > > or may have in future. (In other words, I really don't > > expect this change to happen and I do not want it to > > happen on purely theoretical grounds, but I wanted to > > check just in case;-) > > > > So my issue is:... > > > > We have a bunch of other protocols (DANE, CoAP and more) > > in which we use a hash of a public key. In most of those with > > which I'm familiar we use the SubjectPublicKeyInfo format > > from x.509 as the input bytes to the hash function. Doing > > so ensures that a hash generated in one protocol/application > > could in principle be meaningful in others, even if that's > > not a very common thing to want. Note that using that structure > > does not imply anything about using x.509 or asn.1 really as > > pretty much all crypto APIs (or maybe all) provide you with > > a way to extract public keys in exactly that form regardless > > of whether you care about x.509 or anything related to > > that kind of PKI. (So please let's not have the "I hate > > asn.1/x.509/whatever" argument again:-) > > > > This draft defines it's own peculiar input bytes to the > > hash function and even notes that there's no really good > > reason for that difference:-) [2] > > > > I think this would be better if it supported the use of > > hash input bytes that are the same as are used elsewhere. > > > > But, as I said before, the world won't end if this becomes > > an RFC and we have to do another one later on with that > > fairly trivial difference. > > > > Cheers, > > S. > > > > [1] https://www.ietf.org/mail-archive/web/jose/current/msg04954.html > > [2] > https://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-05#section-5 > > > > > > On 28/05/15 17:40, The IESG wrote: > >> > >> The IESG has received a request from the Javascript Object Signing and > >> Encryption WG (jose) to consider the following document: > >> - 'JSON Web Key (JWK) Thumbprint' > >> <draft-ietf-jose-jwk-thumbprint-05.txt> as Proposed Standard > >> > >> The IESG plans to make a decision in the next few weeks, and solicits > >> final comments on this action. Please send substantive comments to the > >> ietf@ietf.org mailing lists by 2015-06-11. Exceptionally, comments may > be > >> sent to iesg@ietf.org instead. In either case, please retain the > >> beginning of the Subject line to allow automated sorting. > >> > >> Abstract > >> > >> > >> This specification defines a method for computing a hash value over a > >> JSON Web Key (JWK). It defines which fields in a JWK are used in the > >> hash computation, the method of creating a canonical form for those > >> fields, and how to convert the resulting Unicode string into a byte > >> sequence to be hashed. The resulting hash value can be used for > >> identifying or selecting the key represented by the JWK that is the > >> subject of the thumbprint. > >> > >> > >> > >> > >> The file can be obtained via > >> https://datatracker.ietf.org/doc/draft-ietf-jose-jwk-thumbprint/ > >> > >> IESG discussion can be tracked via > >> https://datatracker.ietf.org/doc/draft-ietf-jose-jwk-thumbprint/ballot/ > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > >> > >> > >> > >> > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > >
- Re: Last Call: <draft-ietf-jose-jwk-thumbprint-05… Stephen Farrell
- Re: Last Call: <draft-ietf-jose-jwk-thumbprint-05… Phillip Hallam-Baker
- Re: [jose] Last Call: <draft-ietf-jose-jwk-thumbp… John Bradley
- Re: [jose] Last Call: <draft-ietf-jose-jwk-thumbp… Preibisch, Sascha H
- Re: [jose] Last Call: <draft-ietf-jose-jwk-thumbp… Edmund Jay
- Re: [jose] Last Call: <draft-ietf-jose-jwk-thumbp… Matias Woloski