Skip to content

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

main
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Code

Latest commit

 

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
 
 
 
 
 
 
 
 
 
 

CC BY 4.0

Electronic Health Certificates

This repository contains a proposal for encoding and signing the Electronic Health Certificate (HCERT), as a candidate to be adapted and adopted by eHealth authorities and other stakeholders as they see fit.

Specification

The current authoritative version is tagged as releases in this repository.

Overview

overview

Requirements and Design Principles

The following requirements and principles have been used when designing the Electronic Health Certificate (HCERT):

  1. Electronic Health Certificates shall be carried by the holder and must have the ability to be securely validated off-line (using strong and proven cryptographic primitives).

    Example: Signed data with machine readable content.

  2. Use an encoding which is as compact as practically possible whilst ensuring reliable decoding using optical means.

    Example: CBOR in combination with deflate compression and QR encoding.

  3. Use existing, proven and modern open standards, with running code available (when possible) for all common platforms and operating environments to limit implementation efforts and minimise risk of interoperability issues.

    Example: CBOR Web Tokens (CWT).

  4. When existing standards do not exist, define and test new mechanisms based on existing mechanisms and ensure running code exists.

    Example: Base45 encoding per new Internet Draft.

  5. Ensure compatibility with existing systems for optical decoding.

    Example: Base45 encoding for optical transport.

Trust model

The trust model is currently under development. It is assumed to be a health-specific version of the ICAO Master List concept (see also https://www.who.int/publications/m/item/interim-guidance-for-developing-a-smart-vaccination-certificate) that is both health and COVID-19 specific.

The core of the trust model consists of a simple (at this time, one layer deep) list of Country Signing Certificate Authorities (CSCA) that sign Document Signer Certificates (DSC). These are then used to sign the aforementioned digital health certificates (HCERT).

The trusted keys which will be used by verifiers are published in a list which includes all public keys together with issuer metadata. The keys which from time to time are used to sign the HCERTs and should be trusted are included on the Trusted List. There are no CAs or other intermediate parties

involved in the validation process in the verifier. If a CSCA'ss public keys appear in the list - they are only there to facilitate the creation of the trusted list of public keys itself. They are not used during verification of an HCERT (as this is generally offline -- and purely based on the trusted list of that day).

Known Implementations

Multiple implementations are available via the "European eHealth network - digital green development coordination" GitHub repository.

Highly simplified JSON/CBOR/COSE/Zlib/Base45 pipelines:

Base45

Qr and Aztec code have a specific, highly efficient, method for storing alphanumeric characters (MODE 2/0010). In particular compared to UTF-8 (where the first 32 characters are essentially unused; and successive non-latin characters lose an additional 128 values as the topmost bit needs to be set).

Details of this "11 bits per two characters" encoding can be found at

For this reason, the industry generally encodes these in base45. A document for this de-facto standard is in progress:

Contributions

Contributions are very welcome - please generate a pull request or create an issue.


This work is licensed under a Creative Commons Attribution 4.0 International License.

CC BY 4.0