On Thu, May 28, 2015 at 1: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.
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
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.