No I wasn't suggesting opening up the other does in any way. John B.
Sent from my iPhone > On Jan 24, 2015, at 5:12 PM, Mike Jones <[email protected]> wrote: > > 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]> 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]> 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
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
