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

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

On 2015-06-01, 9:23 AM, "John Bradley" <ve7jtb@ve7jtb.com> wrote:

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