search

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

Electronic Health Certificates Specification
363 stars 40 forks source link

V1 final: KID #32

Closed asitplus-pteufl closed 3 years ago

asitplus-pteufl commented 3 years ago

Currently the spec. says the following about the KID: The Key Identifier is not a security-critical field. For this reason, it MAY also be placed in an unprotected header if required. Verifiers MUST accept both options.

Why do we need to have two variants? Would it be enough to have one dedicated place?

jschlyter commented 3 years ago

Where the kid parameter may be put is specified by COSE, RFC 8152, and is explicitly allowed in both the unprotected and protected headers. Since we believe that implementors will use a generic COSE library to parse the CWTs, falling back to standard COSE semantics reasonable.

asitplus-pteufl commented 3 years ago

@jschlyter thx for the clarification, however unfortunately we are not there yet to have working COSE libs, e.g. for SWIFT we had to do this by hand (CBOR was not ready either, there are four libs but all had different problems). If we need it due to the COSE standard, than its fine, but then we would need to make sure to have testsets for the different KID versions. This would be good practice anyways, however due to fact that we probably need to improvise on COSE libs, we need to be more careful.

jschlyter commented 3 years ago

I agree, we test vectors produce such test vectors. Tracking this via https://github.com/ehn-digital-green-development/hcert-testdata/issues/10.

dirkx commented 3 years ago

Where the kid parameter may be put is specified by COSE, RFC 8152, and is explicitly allowed in both the unprotected and protected headers. Since we believe that implementors will use a generic COSE library to parse the CWTs, falling back to standard COSE semantics reasonable

I have put this in fallback in all code where I spotted it was missing - with the protected one always 'winning' from the unprotected if they would both be set.

Dw.