Subject: Re: [jose] Last Call: <draft-ietf-jose-jwk-thumbprint-05.txt> (JSON Web Key (JWK) Thumbprint) to Proposed Standard

From: John Bradley <[email-masked]>
Date: Mon, 1 Jun 2015 13:23:09 -0300

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 <[email-masked]> 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
>> [email-masked] mailing lists by 2015-06-11. Exceptionally, comments may be
>> sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: "Preibisch, Sascha H" <[email-masked]>
Date: Mon, 1 Jun 2015 17:46:20 +0000

For me that sounds reasonable. I think it can go forward as it is.

On 2015-06-01, 9:23 AM, "John Bradley" <[email-masked]> wrote:

>I understand Stephen¹s issue.
>
>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.,
>> [2] 
>>https://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-05#section-5
>> 
>>

---

From: Edmund Jay <[email-masked]>
Date: Tue, 2 Jun 2015 00:04:48 +0000 (UTC)

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 <[email-masked]>
 To: Stephen Farrell <[email-masked]> 
Cc: [email-masked]; [email-masked] 
 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

Regards
John B.

---

From: Matias Woloski <[email-masked]>
Date: Tue, 2 Jun 2015 20:14:54 -0300

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 <[email-masked]> 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 <[email-masked]>
> *To:* Stephen Farrell <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *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
>