Closed dirkx closed 3 years ago
As discussed before, I strongly suggest we use the leftmost just as any other truncated hash. Adjusting to implementation issues in some language just because they mix ASN.1 encoded data with raw content is the wrong way to go IMHO.
One should also note that the kid encoding is only important when constructing the trusted list (TL) as long as the TL includes the kid. Validators only needs to match the kid in the hcert aginst the kid on the TL and does not need to know about the wrapping.
Because of this reason I suggest the kid is not not discussed further in the CWT claims section of the draft, but only in "Appendix B". It is not part of the hcert encoding scheme at all, it is a pure key conversion function. The trusted list for my hcert testdata explicitly lists the kid for this reason.
Will make the latter change.
Will make the latter change.
Good, but I also believe we should still use the first 8 bytes for standard truncated hash reasons. There are no (to me) known truncation schemes for hashes that does otherwise.
Proposed text below. Perhaps @Razumain can provide a good normative reference to how the fingerprint is calculated; it's a plain hash over the certificate in DER format, but a reference to a RFC would be useful.
The key identifier (kid) is calculated when constructing the list of trusted list of public keys from DSC certificates, and consists of a truncated (first 8 bytes) SHA-256 fingerprint of the DSC.
Note: Verifiers does not need to calculate the kid based on the DSC certificate and can directly match the key identifier in issued health certificate with the kid on the trusted list.
Should we use the term left or right perhaps? Pros and cons for the choice between left and right: