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

[Stephen Farrell <[e-mail]>]

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
> [e-mail] mailing lists by 2015-06-11. Exceptionally, comments may be
> sent to [e-mail] 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.
> 
> 
> 
>