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

[Phillip Hallam-Baker <[e-mail]>]

On Thu, May 28, 2015 at 1:04 PM, Stephen Farrell <[e-mail]>
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.


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.