For the uses in the existing specs, the term “Thumbprint” is well established.
For instance,
http://msdn.microsoft.com/en-us/library/windows/desktop/aa376544(v=vs.85).aspx,
describing the “Certificate.Thumbprint property”, is exactly what our X.509
SHA-1 Certificate Thumbprint (x5t) value is.
I don’t think John was suggesting reopening naming for any of the existing
specs, only possibly for the new spec.
--
Mike
From: jose [mailto:[email protected]] On Behalf Of Kathleen Moriarty
Sent: Saturday, January 24, 2015 12:07 PM
To: John Bradley
Cc: Jim Schaad; [email protected]
Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint
Sent from my iPhone
On Jan 24, 2015, at 2:47 PM, John Bradley
<[email protected]<mailto:[email protected]>> wrote:
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.
And would require an update to all of the drafts in the RFC editor queue to
replace the name. That's doable, but we'll need to be careful.
Kathleen
John B.
On Jan 24, 2015, at 3:39 PM, Jim Schaad
<[email protected]<mailto:[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
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
