search

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

Electronic Health Certificates Specification
363 stars 40 forks source link

Key Usage Policy Identifiers #37

Closed asitplus-pteufl closed 3 years ago

asitplus-pteufl commented 3 years ago

unless there is a deeper rationale behind those OIDs, which is not defined in the text, I would drop them. If there is rationale, the text would still need to explain this rationale and also define rules for validators.

related to #33

Razumain commented 3 years ago

I actually feel that there is a loss in completely dropping the extended key usage. It is the only constraining mechanism we have in case we want to signal that a document signer is authorised to provide only some types of certificates.

If you remove these identifiers, I would at least want to replace it with some general text for the use of extended key usage and how to process it such as:

"The DSC may contain an extended key usage extension with one or more key usage policy identifiers that constrain the types of HCERTs this certificate is allowed to verify. In absence of any key usage extension, this certificate can be used to validate any type of HCERT. Other documents MAY define relevant extended key usage policy identifiers used with validation of HCERTs."

dirkx commented 3 years ago

Same situation in NL - we will parse them centrally, centrally managing what we trust and only provided our verifiers in the field with a excerpt of exactly what they need.

dirkx commented 3 years ago

Wise indeed to make that a MUST, or at least a SHOULD (as this is really something for domestic policy on a per member state basis) — and possibly essential given the ICOA and WHO stated assumptions of these trust spheres overlapping.

dirkx commented 3 years ago

Sugest we close this PR as we got comments from the experts - and I will make a new one with that taken into account as well.