Electronic Health Certificates

IMPORTANT NOTICE

As of July 1st 2023 the EU DCC project has been handed over to the WHO. The project has therefore been frozen. This repository will be placed into archival mode and will remain available for the foreseeable future, however it will no longer be actively maintained.

Introduction

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

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 based on the ICAO Master List concept with some minor modifications to improve performance and compatibility. At the center of the model is the DGC Gateway and the associated certificate governance. The gateway operates in a B2B model with onboarded countries. Member States are then responsible for publishing their own trust lists publicly on their own national backends.

At its core the trust model consists of a simple, 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).

Revocation is implemented via omission. The Trusted List contains all valid certificates, so revocation is achieved by removing a certificate from the Trusted List.

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:

• javascript
• python3
• Rust

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

• https://www.thonky.com/qr-code-tutorial/alphanumeric-mode-encoding
• https://raw.githubusercontent.com/yansikeim/QR-Code/master/ISO%20IEC%2018004%202015%20Standard.pdf - section 7.44 on page 26

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

• Internet Draft draft-faltstrom-base45

Questions?

See our FAQ for answers to commonly asked questions.

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.