From: jose [mailto:[email protected]] On Behalf Of John Bradley
Sent: Saturday, January 24, 2015 11:47 AM
To: Jim Schaad
Cc: [email protected]
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint
You are correct that because we are only calculating the hash over the public
key, what we are doing is closer to SKID than a thumbprint.
One important difference is that skid is only required to be unique, and id
not necessarily calculable based on the public key.
[JLS] There is no requirement for EE certificates that the value be unique.
That requirement is only CA certificates. This is really just a key
identifier for the holder of the key. Uniqueness of the values for each owner
over all of its keys is helpful for the key owner, it makes no difference for
the person referencing the key on the other end. They need to be able to deal
with conflicts in all cases.
RFC 3280 recommends using one of two methods to calculate it, but the SHOULD
allows for wiggle room.
(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits).
(2) The keyIdentifier is composed of a four bit type field with
the value 0100 followed by the least significant 60 bits of the
SHA-1 hash of the value of the BIT STRING subjectPublicKey
(excluding the tag, length, and number of unused bit string bits).
If the skid definition of RFC 3280 had a MUST instead of a SHOULD then it would
be closer.
The reason we used the term thumbprint is that likely it would be used for a
similar purpose as a thumbprint.
I guess what we have is something in between the two.
If calling it a “Public Key ID” rather then a thumb print then that is probably
worth discussion.
I suspect that the naming is going to be easier to sort out than the questions
raised around the serialization of the input to the hash function.
John B.
On Jan 24, 2015, at 3:39 PM, Jim Schaad <[email protected]> wrote:
I am wondering why this needs to be tagged as a thumbprint. Is there a reason
why this draft should not be presented as – here is a way to compute a kid
value for a key that will produce a unique value. This would be similar to how
the computations are presented in PKIX for the subject key identifier extension.
Jim
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
