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
