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

Electronic Health Certificates Specification

eu-dcc-hcert-spec's Issues

Please provide a base-45 library in Ruby

As the title says, please provide a base-45 library for the programming language Ruby.

Best way to report security issues?

Hello everyone,

if I have found a security risk, which I think would be best addressed at the specification/requirements-level, whom should I contact and how?

I should note, that I'm not part of any development team currently implementing the specification, so I don't have any internal contacts.

Thank you!

Regards,

Jan

Recommended sizes

Recommended sizes for paper Qr not quite clear yet.

Definition of "offline"

offline rules for validation apps as suggested by @dirkx in the mail discussion from 09.04.

• Must be able to verify multiple citizen without any network contact.
• Are required to fetch the latest trust list at least once every 24 hours and no more frequent than every 6 hours*.
• MS should block their verifiers from verification if the trust list is older than 48 hours. But are permitted to continue to run with 'stale' trust lists provided they have taken put adequate measures in place ahead of time to deal with false positives and false negatives which do not unfairly/discriminate citizens.
• Verifiers MUST not fetch a trust list re-actively to a citizen scan*.

Public Key List

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).

Where exactly (Url) can I find the list of PublicKeys to check a payload?

X509 Certificate validity/DGC validity

Discussion on key lifetimes and guidelines on revocation of X509 certificates etc.

proposed rules on validity by @dirkx :

• Rule 0 a certificate needs to be valid when it signs.
• Rule 1 the DSC needs to be valid longer than anything it signs. so the DSC expiry date must be >= than the document it signs.
• Rule 2 the CSCA needs to be valid longer than any DSC it signs.
• Rule 3 if any certificate has a shorter 'key usage period' - then the signature needs placed in that period.

In general you already open/start with the next CSCA well before the previous one runs out (ie. at last date minus your longest DSC/longest valid document).

Develop a URI Scheme for the ZLib/Base45 Representation

I would like to suggest using a URI Scheme to help QR Code readers/verifiers understand what is this QR without having to guess.

Something like:

ZLIB45:<Base45 payload>

or even a

DGC:<Base45 payload>

The idea is to use the URI Schema Type to inform QR readers how to unbundle the rest of the QR. By knowing that this is a ZLIB45, the reader can then unencode, unzip and see the payload.

If accepted, the representation will work nicely with all other QRs (99% of QRs have a URI inside it) and be compatible with most, if not all, QR readers.

Link do spec not working on main page

https://github.com/ehn-digital-green-development/hcert-spec/blob/v105/hcert_spec.md
@dirkx @fredriklj

brainstorming on open issues, especially for verification

During our implementations several issues came up, that we think still need to be defined. I am starting a brainstorming list here, this is not a full list of course:

• Error codes and especially, legally/org. definition what the validator needs to see: We think yes/no will not be enough, since in the minimum sense NO could also mean that the validator has a problem (too long offline e.g.), so there is a technical perspective and of course org/legal (discussion started here: )
• Test cases for everything: @jschlyter started some issues here already https://github.com/ehn-digital-green-development/hcert-testdata/issues, we have initial test cases for faulty codes here: https://dev.a-sit.at/certservice/testsuite
• Clarifications on e.g. validating OIDs in X509 certificates
• Offline definitions for validation apps
• security/privacy: clear awareness for member states and private sector use cases (GDPR, health related data). worry: everyone can read the code, steal it, misuse it for other use cases (privacy, fake usage when no ID card is required)
• Overview on implementations: as started here: #34 to have a clear guidance on stable libs that can be used, or validated code that creates correct codes
• Doable max size of QR-Code: current statement, 1400 bytes
• ** Validity ** of DGCs and X509 certificates and clear definitions for the gateway
• Revocation of the signed certificate: Revocation is currently: remove it from the trust list. This is fine, however comes with one major problem: revoking a signing certificate typically just invalidates the signed documents that were issued after the revocation data. if we remove the certificate from the trust list however, all previous documents will be invalidated (re-issuing all of them would be problematic). Discussion on that needed (many approaches, but we would need to see a direction)

V1 final: RSA

I see two problems with RSA:

• major issue: size, especially when we consider that 2048 keys will start to be phased out in the near future and the recommendation will be to go beyond 3000 bits after 2022 (e.g. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile)
• minor issue: implementation side, it seems that COSE libs do not always implement RSA (ok, this can be dealt with)

What is the reason for putting it back into into the spec?

Can COSE_Sign structure be used for DGC?

This may be a bit of a minor point, but I would like to point it out because it bothered me when I read this specification.

This specification does not explicitly specify the structure of COSE. Specifically, it assumes that the COSE_Sign1 (CBORTag=18) structure can be used, but it is unclear whether COSE_Sign(CBORTag=98) can be used.

In my opinion, it would be better to add a description limiting to COSE_Sign1 for the sake of interoperability.
Alternatively, if it is possible to use both structures, I think that should also be explicitly written.

COSE/CWT/DGC verifier?

Does anyone have an online version where I can drop Base45 to check whether the CWT is correct and the DGC matches the schema?

2D Barcode URL Prefix Proposal

2D Barcode: URL Prefix Proposal

The current design of the 2D barcode ensures efficient data transmission, however, remains obscure to the uninformed end-user. Citizens will likely scan their received barcode with their own smartphone, not necessarily using dedicated wallet apps.

Scanning the 2D barcode with the OS camera as of now has no defined way of dealing with the barcode content.
This could even result in a data leakage towards the app chosen to display the content.

Proposal

Add a URL prefix of the form https://server/path# in front of the base45-encoded JSON object.
The path could be a subpage of the Secretariat's master URL or the national stable URL for bilateral exchange.

Scanning a barcode with a URL prefix always opens the default web browser loading the webpage, without sending content to the server. A web app could then display a user-friendly information page of the barcode content, or even verify the content while ensuring data privacy.

Pros:

• increased transparency/usability of the 2D barcode for the citizen
• avoidance of unintended data leakage

Cons:

• bigger size of the total payload
• additional prefix that dedicated verifying apps would need to strip - analogous to the current HC1 prefix for schema versioning.

Expiry

We currently say:

• The Expiration Time MUST not exceed the validity time in the DSC. The verifier SHOULD check this.

We have the worry that MS get this wrong in the tail of the pandemic - and continue issuing right up to the end of the DSC validity.

We can forego all dates in the DSC -- and only look at 'esp' in claim 4.

We could change this to

• The Expiration Time MAY exceed the validity time in the DSC. The verifier MUST therefore not check this; and ignore any and all DSC Key usage and validity data.

But this has the risk that implementors get it wrong ? So this is about an ops/governance mistake v.s. a implementor mistake.

Country code in issuer-claim

The specification should be clear on the ISO 3166 requirement for the country code in the issuer claim. My suggestion is ISO 3166-1 alpha-2. If you need to match this country code against the C RDN of a certificate the two-letter variant is necessary.

Dart implementation

For the implementation of our mobile apps, we use flutter.
We have ported the necessary missing components to Dart.
It might be useful to link them here.

https://github.com/jeroentrappers/dart_base45
https://github.com/jeroentrappers/dart_cose
https://github.com/jeroentrappers/dart_dgc_validate

List of public keys

Not sure if this is the correct forum, but where can I find all published public keys for verification? Do each participating country publish their public key on their own or is there a list of all published keys for all participating countries?

HCERT file

Are there any recommendations / guidelines on how to create a file containing HCERT data?

We are considering sharing DCCs from Wallet app to third party mobile applications on the same device. Most appropriate option seems to be creating a HCERT file and transporting it via standard OS mechanisms. Besides content of the file we would need to define a file extension, mime type and UTI (iOS / OSX environment).

One option we are considering would be to rely on CBOR file format definition, with .cbor file extension and application/cbor MIME type, Unfortunately, no standard UTI seems to be defined.
Another option could be to define a custom format, e.g. with .hcert file extension, application/hcert MIME type and public.hcert UTI.

Thanks for any pointer / insight.

Definition of DSC is missing in hcert_spec.md (enhancement request)

While reading hcert_spec.md I stumbled upon that the abbreviation "DSC" is not defined/explained anywhere.

The abbreviation "DSC" is first introduced in https://github.com/ehn-dcc-development/hcert-spec/blob/main/hcert_spec.md#333-key-identifier .

I think it is important to decode "DSC" for the less trained reader/user in the terminology section, as it might be mixed up with "DCC", especially when it comes to expiration dates. While the validity/expiration time of the DSC is technically defined, the DCC expiration depends on outcomes in medical research, politics and hence their definition via business rules for each participating nation.

I suggest following additions/enhancements:

https://github.com/ehn-dcc-development/hcert-spec/blob/main/hcert_spec.md#2-terminology
The health certificate container format (HCERT) of this specification is generic, but in this context used to carry the European Digital Covid Certificate (DCC) which is signed with a Document Signer Certificate (DSC) by the respective issuing institution.

Once more in https://github.com/ehn-dcc-development/hcert-spec/blob/main/hcert_spec.md#333-key-identifier :
Due to the shortening of the identifier (for space-preserving reasons) there is a slim but non-zero chance that the overall list of Document Signer Certificates (DSCs)accepted by a validator may contain DSCs with duplicate kids. For this reason, a verifier MUST check all DSCs with that kid.

If you support this enhancement request, and if you accept PRs, I'd be happy to create one.

Thanks in advance for your consideration!

Validation information

two parts that are relevant for the validator:

• details of validation results: YES/NO/VALIDATION ERROR. The last one would indicate that the validator has a problem (e.g. no trust list etc.)
• shown details: not clear, at least it would be the data relevant for ID

Questions:

• legal requirement by EU? or is this something related to member states?
• other requirements for displaying validation errors? is there anything necessary the validator would need to know except from YES/NO/VALIDATION ERROR?

Base45's % symbol leads to automated decoding problems

Take this example: https://github.com/ehn-digital-green-development/hcert-testdata/blob/main/testdata/test1.png

On an Android device, open the Camera app, scan the QR and copy the text. You will get this:

HC1:NCF390:70T9WWWGERKB 4+23GO01TL2X9$S35H99CK4705XK2F3 MGNUF4F3QRCS%VLJC+6BY50.FK8ZKO/EZKEZ96446C56..DX%DZJCH/DYTCEC8PSE9EN.OEWV5K/EM-DY69TVD/.DI3DF.DVKE50EN7L+EDTW5S3E:.DW.CJWEDS8FIA71ANNAV+A3+9269+S9.+9I3DFWE2+8NB8-M86C9:R7*0A.+9GVC*JCNF6F463W5KF6VF6KECTHG4KCD3DX47B46IL6646H*6Z/E5JD�IA74R6646307Q$D.UDRYA 96NF6L/5SW6Y57B$D% D3IA4W5646946846.96XJC$+D3KC.SCXJCCWENF6OF63W5$Q6OF6WJCT3EJ+9%JC+QE1R5ZED+EDKWE3EFX3E$34Z$EXVD-NCiAECAWE1Q582BUVDGECDZCCECRTCUOA04E4WEOPCM8F6�.DA%EOPC1G72A6J+9XG7%UDL57Z1BCgIBMIAO7BLB8RUDG09/IBC48G+8D3TDY8.U5-$RK-B0-DRC99NTLZ3H LPN7D%F-*19*H9ZRT$JMXPHQ9W66$+M.2KEMAX2NR1FO9WQ/A0ZC9$27+KVBA0HT..BK3

It should have been this:

HC1:NCF390:70T9WWWGERKB 4+23GO01TL2X9$S35H99CK4705XK2F3 MGNUF4F3QRCS%VLJC+6BY50.FK8ZKO/EZKEZ96446C56..DX%DZJCH/DYTCEC8PSE9EN.OEWV5K/EM-DY69TVD/.DI3DF.DVKE50EN7L+EDTW5S3E:.DW.CJWEDS8FIA71ANNAV+A3+9269+S9.+9I3DFWE2+8NB8-M86C9:R7*0A.+9GVC*JCNF6F463W5KF6VF6KECTHG4KCD3DX47B46IL6646H*6Z/E5JD%96IA74R6646307Q$D.UDRYA 96NF6L/5SW6Y57B$D% D3IA4W5646946846.96XJC$+D3KC.SCXJCCWENF6OF63W5$Q6OF6WJCT3EJ+9%JC+QE1R5ZED+EDKWE3EFX3E$34Z$EXVD-NC%69AECAWE1Q582BUVDGECDZCCECRTCUOA04E4WEOPCM8F6%E3.DA%EOPC1G72A6J+9XG7%UDL57Z1BC%67IBMIAO7BLB8RUDG09/IBC48G+8D3TDY8.U5-$RK-B0-DRC99NTLZ3H LPN7D%F-*19*H9ZRT$JMXPHQ9W66$+M.2KEMAX2NR1FO9WQ/A0ZC9$27+KVBA0HT..BK3

Google's Camera automatically Percent Decodes the URI on copy, which means any random two-byte hex sequence that has % is incorrectly decoded to a UTF character.

In the example, %96 -> �, %69 -> i, %67 -> g and %E3 -> �

If you try Base45 Decode, because � and � are not ASCII, it doesn't work.

I am not sure what to do about it, but I bet these random encodings can crash many systems out there.

Fraud protection

I hope this is the right place for the issue

Problems

1 - good intent

People try to verify DCCs with their wallet apps. This leads to an unwanted list of all visitors, their DoBs, vaccination status, etc.

2.1 - bad intent

People try to get valid DCCs to participate in events or locations where they are not allowed to join, or to join only with too big of extra effort.

2.2 - super bad intent

People try to get valid DCCs to sell/donate(to harm the system) them on platforms like Telegram or RaidForums.

Solutions

only for problem 1

Add a 'Do not Import' mark on DCCs displayed in the wallet app (wallet apps should get an export feature without this mark).This could look something like this: HC3-dni:payload

for both problems

Old version below

1 certificate is created

1. The normal certificate payload is created (except that you maybe add a "hcversion": "4", to the JSON to prevent fraudulent downgrades) (the payload is everything behind the "HC1:").
2. The server creates a private/public key pair (this used only for this one certificate, it's create new every time) (let's call them certificate keys).
3. The server takes the "Unique Certificate Identifier" and the "public certificate key" and encrypts them together (they need to be encrypted together so they are chained together)
4. The server takes the payload, the encrypted part from 3, the private and public certificate keys and puts it into an QR Code.

2 certificate is processed by the wallet app

1. The wallet app Scans the certificate.
2. If the user shows the code to be scanned by a verifier app, the wallet app does the following things:
3. The app removes the private certificate key from the cert.
4. The app takes the private certificate key to encrypt the end-of-life-date-and-time. Normally it uses the current time + 5mins.

3 certificate is processed by the verifier app

1. The verifier app Scans the qr code.
2. The app decrypts the part from 1.3 and checks if the signature is correct.
3. The app takes the public certificate key from there, decryptes the end of life date and checks if it's later then this date.
4. The app checks the normal things (with the data from 1.1).

Old version:
When the certificate is created, the server creates a private/public key pair. The public key + the signature of the certificate get encrypted by the privat key of the server. The private key and the encrypted(public key + signature) are added at the end of the DCC.When the certificate is now scanned by a wallet app, and the wallet app should show the DCC, the wallet app encrypts an end of life date (like five minutes later or so) + the dcc (without the encrypted public key + private key of course). The app now adds the encrypted public key to the end like this:

HC4-dni:certificate-private-key-encrypted(end of life date + dcc) + server-private-key encrypted(certificate public key + signature)

An verifyer app now encrypts the certificate public key, uses it to decrypt the rest of the dcc, checks the end of life date and checks if the signature matches the dcc.
There should be a secure way to store that it's a HC4 (to prevent downgrades by fraudster), Like another key pair or something added to the payload.

Repository with test QR and corresponding public keys

For testing purposes we propose to create a repository where each member state can put examples of their generated QR codes with the corresponding keys. This way we can easily test and validate that we can interprete each of these codes correctly in our application.

Who can set this up?

Be specific about tagging of Cose_Sign1 and CWT

During interop-testing we have run into a few possible interop-problems.

Section 4.2 of RFC8152 states the following:

The structure can be encoded as either tagged or untagged depending on the context it will be used in.

In my meaning our context is clear, and there is no need for a tag. However, other implementations even require the tag. We should be specific in the spec. about this.

Next, section 6 in RFC8392 states:

How to determine that a CBOR data structure is a CWT is application dependent. In some cases, this information is known from the application context, such as from the position of the CWT in a data structure at which the value must be a CWT. One method of indicating that a CBOR object is a CWT is the use of the "application/cwt" content type by a transport protocol.

This section defines the CWT CBOR tag as another means for applications to declare that a CBOR data structure is a CWT. Its use is optional and is intended for use in cases in which this information would not otherwise be known.

I read this that our spec. should explicitly point out that no CWT CBOR tag should be used.

Clarify KID and maybe refer to public key instead of cert

The spec doesn't clearly state what the kid refers to. In the Kotlin implementation it seems to refer to the shortened SHA-256 digest of the DSC.

Also, instead of referring to a DSC digest, you can increase the flexibility by referring to a public key digest (i.e. the key within the DSC). This allows for extending the validity of an existing DSC without invalidating existing HCERTs. This can reduce the impact of mistakes and increase security with shorter lived DSCs. You'd simply reuse the existing key pair to create a new DSC. If you want to explicitly invalidate existing HCERTs you can still generate a new key pair.

Remove Trusted List Format and replace it with simple certificate requirements

The section for "Trusted List Format" should be removed and handled in a separate document in all aspects that deals with international exchange of certificates and the format of the certificate data.

The major reason is that it would

1. hold up this specification in an unnecessary way as this is still a matter of discussion related to the DGC gateway
2. Verifiers dealing with this specification will probably not deal with certificates from the DGC gateway directly, but they will probably be served with a map of certs indexed under its kid from a national infrastructure service. So from the verifiers perspective, this is out of scope.

What the verifier needs is simply a short list of certificate content requirements.
I propose to change the current certificate requirements in the following way:

• Remove key identifier requirements and replace it with:
  • DSC certificates MUST contain an Authority Key Identifier matching the signer Subject Key Identifier if the DSC certificate is not self signed.
• Remove private key usage period requirements
• Add: MAY include extended key usage extension which MAY serve to limit the scope of the DSC key holder. Other specificatoins MAY define extended key usage identifiers relevant for use with DSC certificates. In the absence of an extended key usage extension, the key is unconstrained and MAY be used to sign all relevant hcert documents.

Update Keyword boilerplate

The current specification use an old IETF boilerplate. I suggest moving to the current version:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 (RFC2119) (RFC8174) when, and only when, they appear in all capitals, as shown here.

clarify header priority for KID

In https://github.com/ehn-digital-green-development/hcert-spec/blob/main/hcert_spec.md#333-key-identifier you describe that the KID may be present in both, the protected and the unprotected header and that Verifiers MUST accept both options.

I would suggest to add If both options are present, the Key Identifier in the protected header MUST be used., to prevent confusion and unwanted differences between implementations.

Left or right side of SHA256 for KID ?

Should we use the term left or right perhaps? Pros and cons for the choice between left and right:

• Left: Have been the de-facto way to do it in the internet-standards world ever since RFC 2104 (1997) I believe?
• Right: Some C# library apparently wraps hashes into an ASN.1 structure which adds data on the left of the hash?

iPhone Camera App adds unexpected %20 encoding

I found an annoying issue with the Base45 encoding. Scanned with the iPhone Camera App and selecting the unusable data to copy copies the data, but encodes all Spaces as %20 for some reason. I checked the actual bytes in the QR Code and they are spaces.

Compression header

Verifiers MUST check of the presence of a valid ZLIB/Deflate header (0x78, 0xDA) - or proceed without this step when absent.

Do we require best compression, or does any compression level work? My examples has 0x78 0x9c

What happens with the vaccination certificate ones the validity time has passed?

Your Question

• Documentation File: https://github.com/ehn-digital-green-development/hcert-spec/
• Line / Paragraph: https://github.com/ehn-digital-green-development/hcert-spec/blob/main/hcert_spec.md#61-hcert-signature-validity-time
• Question: What happens with the vaccination certificate ones the validity time has passed? How can a user renew the certificate? Must a doctor renew it?

Is the spec defining a Universal Public Certificate resolver?

In other words, can a verifier unpack a new HC1 payload realize the signature is unknown and call a resolver to automatically find, download, and install the referenced certificate chain and use it to verify the payload?

Behaviour of verifier when there are zero usage policy identifiers

In A.4 of the spec it is stated that:

The SC may contain an extended key usage extension with zero or more key usage policy identifiers.

What should the verifier do when the extended key usage extension exists but contains zero key usage policy identifiers?

Algorithm support

As in the discussion with @dirkx, we fully agree that some recommendation on secure cryptographic algorithms (and min. key lengths) needs to be taken (SOGIS; BSI, NIST etc. whatever fits best in the European context).
However, I strongly believe that this is not enough. If we just go for the min. recommendations and allow to exceed them, we will have compatibility issues since all readers will not support all algorithms (e.g. EDDSA is not supported everywhere). Also, certain key-sizes/algorithms will not work due to QR-code size (RSA, but maybe even 512 bit hashes with ECC).
COSE already limits the algorithms to practically: https://www.iana.org/assignments/cose/cose.xhtml#algorithms, reading the spec, I extract:

• various RSA variants (not an option)
• ECDSA with NIST curves (not sure if anything larger than 256 bits can be really used), no other curves
• EDDSA (not really sure how wide the support here already is) (for JWS this is not supported by all libs)

So practically, not much else than ES256 remains feasible (maybe ES384 or even ES512 if the size permits it).

What are your thoughts about this?

EU Digital COVID Certificates: When governments move fast and break things

On 20 May 2021 the EU commission reached a provisional agreement on the issuance of the 'EU Digital COVID Certificate'––previously referred to as a 'Digital Green Certificate'. As The Institute for Technology In The Public Interest, we are deeply concerned about the short and long term implications of this Regulation.

The certificate is being introduced at great speed under the auspices of public health at a moment of urgency and vulnerability on all levels, be it the level of the state, political institutions such as the EU, collectives, businesses and individuals.

Whilst we recognize the vulnerabilities produced by the COVID-19 pandemic, in this bugreport we outline some of the serious issues that the implementation of the 'EU Digital COVID Certificate' raises. We think it is necessary that the EU commission undertake an 'impact assessment', a step which was dangerously omitted in the record time that the proposed EU Digital COVID Certificate Regulation was agreed upon by the different EU institutions. Our aim in this bugreport is to make a start with defining impact areas, with the hope that other concerned groups and individuals will further extend it.

What is the EU Digital COVID Certificate?
The EU Digital COVID Certificate depends on the establishment of a digital token that links to an individual, 'a holder'. It is proof of either vaccination status, testing status or whether someone has recovered from COVID-19. Setting up a digital token requires infrastructural support, which connects digital with administrative infrastructures. Such an infrastructure is needed to digitally issue certificates and ensure authenticity of each certificate. The certificate can be carried on a mobile device or as a paper document. It makes it possible for different 'verifiers', such as public authorities, travel operators, venue owners or organizers of gatherings, to establish whether the certificate is authentic; if it belongs to the 'holder'; and if it carries the value necessary for entering a space, participating in an activity, or crossing a border. For the verification to happen in a rapid manner, the certificate uses a QR-code signed by the authorities. This means the 'verifier' needs to use a digital device, such as a smart mobile phone or QR code reader, to confirm the veracity of the certificate.

We argue that the implementation of these different steps represents a shift towards administrative-infrastructural regimes. Regimes that are made possible by digital infrastructure and their operational logics––with significant short and long term consequences.

Re-purposing e-health infrastructure for managing freedom of movement digitally

Many public health systems in Europe are not fully digitized. However, the introduction of the digital certificate catapults them into the realm of digital administration on a scale never implemented before.
This shift to administrative-infrastructural regimes implies the reorganization of public health, as it changes the trust and power relations between relevant actors and stakeholders. The proposed system goes far beyond digitizing health records and existing workflows, because it introduces a system through which "certificates" can be used to manage every day activities, specifically freedom of movement. Public health authorities are typically not responsible for setting policies and running digital operations which regulate people's movements. In addition, digital infrastructures can come to reconfigure or even break public institutions, as exemplified in the way journalism and publishing succumbed to the rise of social networks like Facebook. What impact does it have on the public health system, its objectives and responsibilities, to be repurposed in a digital environment for the issuance and verification of certificates? What mechanisms are in place to capture and respond to the potential risks of digital transformation of public health institutions at this scale and speed?

Growing public private interdependencies entrenched in an essential infrastructure

While any vaccine or test can be written into a certificate, not any test or vaccine will fulfill the requirements for freedom of movement. By virtue of regulating which test and which brand of vaccine can allow the holder of the certificate to enter a space, participating in an activity, or cross a border, the EU Digital COVID Certificate will act as a powerful gatekeeper between private partners, governments and the public. How is the growing interdependency between public and private agents being kept in check that is part and parcel of this essential infrastructure?

Policing will bleed further into daily life

Since the data in the QR code is available in the clear, this infrastructure has no built-in constraints for who can verify the certificate. Since certificate checks can be expected not only at the border but could be easily implemented for entering a workplace, a demonstration or a classroom, it introduces new forms of policing into every day life. This set up facilitates conditions of vigilantism through the everyday management of citizen movement, optimisation, population flow and control. It also potentially demands teachers, health-workers, shopkeepers and protest organisers act as if they were police. What mechanisms are in place to limit random checks? What legal and complaint procedures are foreseen to address grievances? How to ensure that rather than supporting freedom of movement, the digital token becomes a tool to restrict movement of people as they go about their daily life?

The expansion of borders

As argued above, the implementation of the certificate will further intensify technologies of the existing border regime into everyday life, also at places that are far from geographical borders. It extends the force of the state, which will no doubt add to histories of inevitable inequalities and asymmetries of such bordering regimes. The EU itself has a terrible track record when it comes to border regimes, human rights and global inequities. What is being done to prevent the certificate from further contributing to racist, classist systems, to a multi-tier society and increasing levels of violence at ever expanding borders? How does the regulation consider people from outside of EU and the way their human rights might be affected by the introduction of digital certificates?

A neverending infrastructure

The recent renaming of the certificate from a generic 'Green Digital Certificate' into 'EU Digital COVID Certificate', seemingly limits its scope to the COVID pandemic. But as we know from the USA PATRIOT Act that was introduced short after 9/11 and never fully retracted, or anti-terrorism measures in France that were extended five times, once in place––when dependencies are created, "crisis measures" risk becoming permanent. Although the Regulation has attempted to address this concern by including a clause that deals with rollback by stating that it "should be lifted as soon as the epidemiological situation allows", this does not guarantee it is just a temporary measure. With multiple industries and countries depending on the relaxation of the lock downs, and technology companies of all sizes entangled in this digital-administrative-infrastructure, what force will it take to remove it? Is the 12 month sunset clause still valid when the COVID-19 pandemic has not been overcome by that point? What prevents its application be resumed in case of another pandemic due to an outbreak of SARS-CoV-2, a variant thereof, or similar infectious diseases with epidemic potential?

Shifting grounds

The fact that this certificate is in essence digital, makes it possible to introduce regular updates. This will make the infrastructure responsive to changing understandings of the effectivity of vaccines, and new test methods to be integrated. The Regulation limits clearly what can be certified: vaccine, test result, and recovery, but it does not regulate what policies can be applied based on checking the information carried on the certificate. The policy determines whether a given vaccine or test is sufficient for movement, or whether there are exceptions or updates to policies that should be applied. The certificate is promising to not discriminate between recovery, vaccination or a negative test. How is the equivalence between the three, vaccination, testing and proof of recovery maintained? Who decides what prevails or what happens when scientific insight changes?

This bugreport ended up in the Github repository of the Digital COVID Certificate, because we have not found another platform to place it. The promise of a timely digital solution for re-establishing freedom of movement before the start of the summer holidays has erased the space for due diligence and public consultation. Given the concerns we raised above, and those raised by many other people and institutions, we are concerned that instead of a benign and 'safe' way out of a difficult situation, the EU Digital COVID Certificate will do immediate and long-lasting damage, especially since it is being rolled out as nationalism and fascism are on the rise in the EU and elsewhere.

We urge people in different communities, movements, professions, and institutions to consider extending the questions above, because absent of public consultation, and considering the potential impacts listed above, our main questions are: Can we afford this digital-administrative-infrastructure? Can we allow it? Is it really an option?

The Institute for Technology in The Public Interest,

Miriyam Aouragh
Nishat Awan
Gwendolin Barnard
Yasmine Boudiaf
Seda Gürses
Clareese Hill
Helen Pritchard
Femke Snelting
Eric Snodgrass
Cassandra Troyan
Magdalena Tyżlik-Carver

Validation suite

As previously discussed we see the need for a validation suite (*) identifier based on the following rationale:

• the processing details will change in the future, maybe even at the beginning if certain aspects need to be changed after the initial trial-runs
• an app which reads the qr-code should (at best) immediately identify which validation chain to follow to get data processing right
• such a suit-ID would be needed on a very high-level. e.g. as defined prefix of the BASE45 data within the QR-Code, at this level the app can easily decide on the required process
• content: maybe country code (I think this was also mentioned by @dirkx) and some version ID. e.g. AT01, where the version ID fully defines the complete validation chain, the country code has no specific reason right now, but could be important if some country-specific issues arise (which are not desirable, but still it could help to address them). The version ID would then indicate the full-suite of processes and other parameters that are required to fully validate the document.
• Val.Suite format: if we assume the BASE45 notation and avoid special chars of BASE45, we still would have 36 chars (A-Z and 0-9), resulting in 36*36 suites, which will be more than sufficient.

Example can already be seen in our COSE chain on https://dev.a-sit.at/certservice

(*)
with "validation suite" I am referring to the whole process chain and details required for validating/creating a document (e.g. JSON->CBOR->COSE->ZLIB->BASE45) and the associated details (e.g. key-id within the COSE header, Trust-list format etc.)

Discussion:

• Opinion of the other members
• Location of such a suite (proposal: prefix of BASE45 data)
• Suite-Format: Country-code? length of version ID
• processes, parameters covered by suite, but basically the suite ID would be linked to the complete specification of a chain

self signed DSC ?

We currently allow for self signed DSCs by stating that

• the CSCA has to sign the DSC
• The DSC and CSCA can be indentical

Allowing effectively signatures from private keys in X.509 certs (that we do not use in the trust list at all) that has CA:TRUE.

This is a compromise that makes the barrier to entry really low - while still keeping the ICAO concept alive.

We currently say in README.md:

If CSCAs 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 a HCERT (as this is generally offline -- and purely based on the trusted list of that day).

I think that should be:

A CSCAs public keys can only appear on the list if it is _also_ submitted as a DSC key. Otherwise the CSCA are _only_ used to facilitate the creation of the trusted list of public keys itself. And not included on that list. They are not used during verification of a HCERT (as this is generally offline -- and purely based on the trusted list of that day).

Alternative approach to use of QR codes

A large amount of the mechanism proposed appears to be motivated by the desire to compress the certificate itself to fit in a QR code.

While this allows for offline verification of the certificate, this constraint introduces a substantial restriction on the data presented. It is not possible to incorporate a picture of the subject, etc. etc.

An alternative approach is to use a QR code to link to data on a remote site. While such an approach would have been wildly impractical in 2000, network provision is now sufficiently ubiquitous to make it practical. If the Internet is down, most airports will be down and down hard in any case.

The other objection to this approach is that Web servers containing health credential data in plaintext would be a major privacy concern violating HIPPA, GDPR, etc. etc. Fortunately, a QR code can be used to express both a locator and a decryption key as described in the Mesh UDF-EARL approach:

https://www.ietf.org/archive/id/draft-hallambaker-mesh-udf-12.html

In this scheme, the QR code still serves as a bearer token permitting access to the data but the data itself is no longer constrained in size. This provides for a much wider ranger of authentication approaches with different privacy properties.

For example, Alice gets her COVID shot and CDC certificate with her name and dates of vaccinations, her passport and driving license. She visits a credential issuance authority which provides her with multiple accreditations for use in different circumstances:

1. Vaccination information + Photograph of Alice
2. Vaccination information + Driving license number
3. Vaccination information + Passport number + country of issue

Alice can use the first credential to gain access to a store or other public space without disclosing her name, date of birth or other information. She can use the second for circumstances such as access to a place of employment where a stronger identity assertion is required. She can use the third for international travel.

Having relaxed the size constraint, it would be rather more appropriate to build on top of SAML which was originally based on TAXI which was designed for this exact purpose.

Possible leak of private keys

On various groups (Telegram mainly) are circulating several forged Green Pass with valid signature, I attach two here.

<< image redacted - available from the security team >>

<< image redacted - available from the security team >>

I verified with my application and found that these two certificates are signed with the keys corresponding to these two public keys:

kid: 53FOjX/4aJs=
key: <EllipticCurvePublicNumbers(curve=secp256r1, x=59224424711316661084877973301841821584140021680113528472675651838972371380627, y=54841068689176540860306147861276004028606373898471432794562118907413910993957>

kid: HhkeqvrtQ0U=
key: <EllipticCurvePublicNumbers(curve=secp256r1, x=58474994431552591028397454866551462597403245555156280299836700796569353760692, y=94160389532428263599765213184431546448511972729790083405292977908540518398962>

There is the possibility that a database of private keys is compromised and this may ends up in a break of the chain of trust in the Green Pass architecture. I am not sure to who this should be reported, so I write this here.

V1 final: KID

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?

Allow vac-certs nested in COVID-Tests

Allow the nesting of (parts of) an vaccination cert in an Test-Cert. The reason for this is, that for example in Germany there are 2G+-rules, which means ((vaccinated && tested)||(recovered && tested)), so have to show your vaccination/recovered AND you're tested cert, so it would be cool, to only show on cert.

Solution 1

Just put two certs in one code. (Big QR-Code size needed)

Solution 2

The testing site scans you're vac-cert, sends it to the signer, and the signer adds parts of the vac-cert to your test cert (relatively small QR-Code needed)

V1 final: Key Usage Policy Identifiers

They are indicated as MAY, do they need to be checked by validators if present? If not, what is the rationale of defining them?

Relax requirement for country code of issuer

The latest version of the DCC schema now allows organization identifiers where we future expected a ISO 3166-1 alpha-2 country code (for example UNHCR). So we should re-phrase the requirement that we currently have for the iss claim.

Specifications link in readme is broken

on the page https://github.com/ehn-digital-green-development/hcert-spec under specifications thee link given as below is. broken - https://github.com/ehn-digital-green-development/hcert-spec/blob/v105/hcert_spec.md

It could be for main branch - https://github.com/ehn-digital-green-development/hcert-spec/blob/main/hcert_spec.md

Integrate with IATA Travel Pass

IATA is currently working on alternative framework that would allow Airlines to read and validate Medical informations on the same specs that Digital Green Certificate would deliver.

At the current stage seems that IATA would provide an End two End application and an integration option for Airlines to favor seamless experience.

More information can be found here: https://www.iata.org/en/programs/passenger/travel-pass/

At the time of writing some airlines seems already to have start the integration process but Technical Specifications seems to don't be publicly available.

V1 final: clarification for HC1

further explanation of the prefix would be necessary:

Is this in the sense of the validation suite we proposed (#9)? Meaning, that the validator app could read this and know which processing chain to use. e.g. HC1 refers to the current version, HC2 would refer to a modified scheme, where we made necessary changes to the processing schemes (anything, e.g other compression, DIDs as KIDs, other defined cryptographic algorithms?)

spam message

Someone claims the keys are not stolen. Run this then...

HC1:NCFOXN%TSMAHN-H/RCMPQ5GE5I00H9GBH3QNAD6.LQLX85ZS GJTSJ4NKP1HCV4XUA2PSGH.+H$NI4L6F$S-N1FYBRR1$Q1+GOF+P$HQPHQHTQ.SQ6$PUKRN95404.W7UX4795LKDYPWGO+9AZDOHCRL35IWMSDOP7OQ+M70AK$8 96XY4SBLU96:/6N9R%EPL8RY9DOA60-K.IA.C8KRDL4O54O4IGUJKJGI0JAXD15IAXMFUGSHGRKMXGG6DBYCBMQN:HG5PAHGG8KES/F-1JW-K%B3A9ENO4B-S-O4-G1FD/U47HAE1MI4OE0G1:HHD4AB874MM-6B:HKJSQ.TAG3CR1638W9AV88G64PB4VHRY2EK03NFJL4M10KP3AT2VK LT5GGFV85I010W2ZXJSBTMFW+KM2T8-CXR32BMF7RAEAYKMWHE/NH UP4SNGENEWUY97 -3YM0.HAM:D:00ZY35XRT1100MFKWEWYHKCZIZJ0CAQYIKOZIZJ0DAQCDQGAE62ORR7HL0POYQCGMGBBEQFCBCDCT4VYFQZEPYFXK69ZRV9T8IY6NWAYEJF0VXVKNFCG/X9UIG5HFWRPEDW2EPW00S1K83I3900:919FUCKYOUALLGPSUPPORTERS9IKM24N21AW7ZUR2L013300EUISGOEINGDOWNNAZZYFUCKERS666I3AK96XYR01300STOREMYCODEMUTHERFUCKERANDGOTOHELLI5340XRT09SHUZVB33IR0IPUTAVIRUSHERE83H73KFI280I23KL0YRZT91Y0WITHLOVEFROMHA1PWEOXCI/QXRLOZKN0LM03I2RWT0Z

Originally posted by @Maxmontgelas in https://github.com/ehn-dcc-development/hcert-spec/discussions/105#discussioncomment-1573490

Overview on implementations

mentioned in the chat today: we startet to collect the available implementations in a Google Docs document (for now RO).
the idea is to:

• collect all the information on demo implementations, libraries etc. to help implementors but also to identify gaps (unsupported platforms, lack of quality etc.)
• identify the state of those libs in terms of quality, maintenance, features for the DGC use case etc.

ideas are welcome on where to maintain that for now (GITHUB list would be obvious but probably not so good for an overview), since it would be quite helpful to have many collaborators there who bring in information (not sure if I am brave enough to make it public editable)?

https://docs.google.com/document/d/11XnEBTECtbRv6n27OJg5ZYLxfg9DpQfCH0NpfZMDuzE/edit?usp=sharing

Consider text-based transport encoding

Wouldn't the specification be more complete if a text based trasport encoding would be specified suitable for cut and paste operations and for trasport in text based applications such as e-mail, SMS, chats or similar?

Even if this is not the typical use, I would not completely rule out certain situations where a person is asked to provide a text-representation, e.g. through remote interaction with a help-desk.

Simple Base64 encoding of the binary data would probably suffice.