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.
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] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/jose
> <https://www.ietf.org/mailman/listinfo/jose>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
