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

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 18:04:33 +0100

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 May 2015 18:38:07 -0400

> fairly trivial difference.

I will agree with Stephen in part, disagree in part and propose the
compromise already discussed in the OpenPGP list that I wrote
up this week

https://tools.ietf.org/html/draft-hallambaker-udf-00

I could not get agreement on using the PKIX KeyInfo format as the basis for
the key fingerprint because it turns out that an OpenPGP key fingerprint is
actually more of a fingerprint of a Key binding, there is OpenPGP info in
there and it is necessary to the function.

So I carefully designed UDF to allow it to be used to support PKIX KeyInfo
blobs, OpenPGP key blobs or anything else that has a MIME content type and
do it efficiently.

Lets say you have a fingerprint and you know it is of a key but not whether
it is OpenPGP, PKIX or JOSE. With my scheme you can check each possibility
casewise very simply without resort to content type sniffing. Just hash the
keyblob you have and then see if hashing the result concatenated with each
of the three content type identifiers in turn produces a match. If not,
either you don't have the key you thought you did or you don't understand
it.

OK so some minor irritation under the hood. But the payoff is that we can
make all of these look exactly the same to the user.