ANNEX I

In Annex I to Implementing Decision (EU) 2021/1073, the following section 9 is added:

‘9. REVOCATION SOLUTION

9.1. DCC Revocation List (DRL) Provision

The Gateway shall provide endpoints and functionality to hold and manage the revocation lists:

9.2. Trust Model

All connections are established by the standard DCCG trust model by the NBTLS and NBUP certificates (see certificate governance). All information is packed and uploaded by CMS messages to ensure the integrity.

9.3. Batch Construction

9.3.1. Batch

Each revocation list shall contain one or multiple entries and shall be packed in batches which contain a set of hashes and their metadata. A batch is immutable and defines an expiration date which indicates when the batch can be deleted. The expiration date of all items in the batch must be exactly the same – meaning that batches must be grouped by expiry date and by signing DSC. Each batch shall contain a maximum of 1 000 entries. If the revocation list consists of more than 1 000 entries, multiple batches shall be created. Any entry may occur in at most one batch. The batch shall be packaged into a CMS structure and signed by the NBup certificate of the uploading country.

9.3.2. Batch Index

When a batch is created it shall be assigned a unique ID by the gateway and shall be automatically added to the index. The index of batches is ordered by the modified date, in ascending chronological order.

9.3.3. Gateway Behaviour

The gateway processes revocation batches without any changes: it can neither update nor remove, nor add any information to the batches. The batches are forwarded to all authorised countries (see chapter 9.6).

The gateway actively observes the expiration dates of batches and removes the expired batches. After the batch is deleted, the gateway returns an "HTTP 410 Gone" response for the deleted batch URL. Therefore, the batch appears in the batch index as "deleted".

9.4. Hash Types

The revocation list contains hashes that can represent different revocation types/attributes. These types or attributes shall be indicated in the provisioning of the revocation lists. The current types are:

Type Attribute Hash Calculation SIGNATURE DCC Signature SHA256 of DCC Signature UCI UCI (Unique Certificate Identifier) SHA256 of UCI COUNTRYCODEUCI Issuing Country Code + UCI SHA256 of Issuing CountryCode + UCI

Just the first 128 bits of the hashes encoded as base64 strings are put into the batches and used to identify the revoked DCC (1).

9.4.1. Hash type: SHA256(DCC Signature)

In this case the hash is calculated over the bytes of the COSE_SIGN1 signature from the CWT. For RSA signatures, the entire signature will be used as input. The formula for the EC-DSA signed certificates is using the r value as an input:

SHA256(r)

[required for all new implementations]

9.4.2. Hash type: SHA256(UCI)

In this case the hash is calculated over the UCI string encoded in UTF-8 and converted to a byte array.

[deprecated (2), but supported for backwards compatibility]

9.4.3. Hash type: SHA256(Issuing CountryCode+UCI)

In this case CountryCode encoded as a UTF-8 string concatenated with the UCI encoded with a UTF-8 string. This is then converted to a byte array and used as input to the hash function.

[deprecated2, but supported for backwards compatibility]

9.5. API Structure

9.5.1. Revocation Entry Provisioning API

9.5.1.1. Purpose

The API delivers the revocation list entries in batches including a batch index.

9.5.1.2. Endpoints

9.5.1.2.1. Batch List Download Endpoint

The endpoints follow a simple design, returning a list of batches with a small wrapper providing metadata. The batches are sorted by date in ascending (chronological) order:

/revocation-list

Verb: GET

Content-Type: application/json

Response: JSON Array

{ ‘more’: true|false, ‘batches’: [{ ‘batchId’: ‘{uuid}’, ‘country’: ‘XY’, ‘date’: ‘2021-11-01T00:00:00Z’ ‘deleted’: true | false }, .. ]

}

Note: The result is limited by default to 1 000. If the flag ‘more’ is set to true, the response indicates that more batches are available for download. To download more items the client must set the If-Modified-Since header to a date no earlier than the last entry received.

The response contains a JSON array with the following structure:

Field Definition more Boolean Flag which indicates that there are more batches. batches Array with the existing batches. batchId https://en.wikipedia.org/wiki/Universally_unique_identifier country Country Code ISO 3166 date ISO 8601 Date UTC. Date when the batch was added or deleted. deleted boolean. True if deleted. When the deleted flag is set, the entry can be finally removed from the query results after 7 days.

9.5.1.2.1.1. Response Codes

Code Description 200 All ok. 204 No content, if “If-Modified-Since” Header content has no match.

Request Header

Header Mandatory Description If-Modified-Since Yes This header contains the last downloaded date to get just the newest results. On the initial call the header should be the set to the ‘2021-06-01T00:00:00Z’

9.5.1.2.2. Batch Download Endpoint

The batches contain a list of certificate identifiers:

/revocation-list/{batchId}

Verb: GET

Accepts: application/cms

Response:CMS with Content

{ ‘country’: ‘XY’, ‘expires’: ‘2022-11-01T00:00:00Z’, ‘kid’:’23S+33f=’, ‘hashType’:’SIGNATURE’, ‘entries’:[{ ‘hash’:’e2e2e2e2e2e2e2e2’ }, ..]

}

The response contains a CMS including a signature which must match to the NBUP certificate of the country. All items in the JSON array contain the following structure:

Field Mandatory Type Definition expires Yes String Date when the item can be removed. ISO8601 Date/Time UTC country Yes String Country Code ISO 3166 hashType Yes String Hash Type of the provided entries (see Hash Types) entries Yes JSON Object Array See Table Entries kid Yes String base64 encoded KID of the DSC used to sign the DCC. If the KID is not known then the string `UNKNOWN_KID` (excluding the `) can be used. Notes:

— Batches shall be grouped by expiry date and DSC – all items shall expire at the same time and have been signed by the same key.

— Expiry time is a date/time in UTC because EU-DCC is a global system and we must use an unambiguous time.

— The expiry date of a permanently revoked DCC shall be set at the expiry date of the corresponding DSC used to sign the DCC or at the Expiration Time of the revoked DCC (in which case the used NumericDate/epoch times shall be treated as being in the UTC time zone).

— National Backend (NB) shall remove items from their revocation list when the expiration date is reached.

— NB may remove items from their revocation list in the case that the kid used to sign the DCC is revoked.

9.5.1.2.2.1. Entries

Field Mandatory Type Definition hash Yes String First 128 bits of the SHA256 hash encoded as a base64 string

Note: The entries object contains currently just a hash, but to be compatible with changes in the future an object was chosen, instead of a json array.

9.5.1.2.2.2. Response Codes

Code Description 200 All ok. 410 Batch gone. Batch can be deleted in the national backend.

9.5.1.2.2.3. Response Headers

Header Description ETag Batch ID.

9.5.1.2.3. Batch Upload Endpoint

The upload is done over the same endpoint via POST Verb:

/revocation-list

Verb: POST

Accepts: application/cms

Request: CMS with Content

ContentType: application/cms

Content:

{ ‘country’: ‘XY’, ‘expires’: ‘2022-11-01T00:00:00Z’, ‘kid’:’23S+33f=’, ‘hashType’:’SIGNATURE’, ‘entries’:[{ ‘hash’:’e2e2e2e2e2e2e2e2’ }, ..]

}

The batch shall be signed using the NBUP certificate. The Gateway shall verify that the signature was set by the NBUP for the given country. If the signature check fails then the upload shall fail.

NOTE: Every batch is immutable and can’t be changed after uploading. It can be deleted, though. The ID of every deleted batch is stored, and an upload of a new batch with the same ID is rejected.

9.5.1.2.4. Batch Delete Endpoint

A batch can be deleted over the same endpoint via DELETE Verb:

/revocation-list

Verb: DELETE

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

{ ‘batchId’: ‘...’

}

or, for compatibility reasons, to the following endpoint with the POST verb:

/revocation-list/delete

Verb: POST

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

{ ‘batchId’: ‘...’

}

9.6. API Protection/GDPR

This section specifies measures for the implementation to comply with the provisions of the Regulation 2021/953 as regards to the processing of personal data.

9.6.1. Existing Authentication

The Gateway currently uses the NBTLS certificate to authenticate the countries connecting to the Gateway. This authentication can be used to determine the identity of the country connected to Gateway. That identity can then be used to implement access control.

9.6.2. Access Control

To be able to lawfully process personal data the Gateway shall implement an access control mechanism.

The gateway implements an Access Control List combined with Role Based Security. In that scheme, two tables shall be maintained – one table describing which Roles can apply which Operations to which Resources, the other table describing which Roles are assigned to which Users.

To implement the controls required by this document, three Roles are required, and that is:

RevocationListReader

RevocationUploader

RevocationDeleter

The following endpoints shall check to see if the User has the Role RevocationListReader; if they do then access shall be granted, if they do not then an HTTP 403 Forbidden shall be returned:

GET/revocation-list/

GET/revocation-list/{batchId}

The following endpoints shall check to see if the User has the Role RevocationUploader; if they do then access shall be granted, if they do not then an HTTP 403 Forbidden shall be returned:

POST/revocation-list

The following endpoints shall check to see if the User has the Role RevocationDeleter; if they do then access shall be granted, if they do not then an HTTP 403 Forbidden shall be returned:

DELETE/revocation-list

POST/revocation-list/delete

The Gateway shall also provide a reliable method whereby the administrators can manage the Roles that are linked to the Users in such a way as to reduce the chance of human errors whilst also not burdening the functional administrators.’