Left or right side of SHA256 for KID ?

ehn-dcc-development / eu-dcc-hcert-spec

Electronic Health Certificates Specification

363 stars 40 forks source link

Left or right side of SHA256 for KID ? #5

Closed dirkx closed 3 years ago

dirkx commented 3 years ago

Should we use the term left or right perhaps? Pros and cons for the choice between left and right:

Left: Have been the de-facto way to do it in the internet-standards world ever since RFC 2104 (1997) I believe?
Right: Some C# library apparently wraps hashes into an ASN.1 structure which adds data on the left of the hash?

jschlyter commented 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.

jschlyter commented 3 years ago

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.

dirkx commented 3 years ago

Will make the latter change.

jschlyter commented 3 years ago

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.

jschlyter commented 3 years ago

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 (KIDs)

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.