For me that sounds reasonable. I think it can go forward as it is. On 2015-06-01, 9:23 AM, "John Bradley" <ve7jtb@xxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxx mailing lists by 2015-06-11. Exceptionally, comments may >>>be >>> sent to iesg@xxxxxxxx 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@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/jose >