This is a more cross-platform (i.e. non-OpenSSL), standardized way to uniquely identify a public key (of arbitrary type). And it gives a much more sensible way that what is currently being used for SSL keys.
For backwards compatibility, the DIGEST tag is still accepted, and can even be sent alongside the SKI tag (SKI will be preferred if both are sent). It can seamlessly removed in the future, or ignored if both sides support the newer Keyless protocol
(Note: It's feels a bit odd to "downgrade" from SHA-256 to SHA-1, but that was what was standardized on in RFC 5280 §4.2.1.2., and it should be fine as it's not being used for "secure" hash benefits anyway, just as a unique identifier)
grittygrease
commented
9 years ago
This is a more cross-platform (i.e. non-OpenSSL), standardized way to uniquely identify a public key (of arbitrary type). And it gives a much more sensible way that what is currently being used for SSL keys.
For backwards compatibility, the DIGEST tag is still accepted, and can even be sent alongside the SKI tag (SKI will be preferred if both are sent). It can seamlessly removed in the future, or ignored if both sides support the newer Keyless protocol
(Note: It's feels a bit odd to "downgrade" from SHA-256 to SHA-1, but that was what was standardized on in RFC 5280 §4.2.1.2., and it should be fine as it's not being used for "secure" hash benefits anyway, just as a unique identifier)