eu-digital-green-certificates / dgc-overview Goto Github PK
View Code? Open in Web Editor NEWThis repository provides an overview over the EU Digital Green Certificates (DGC) project.
License: Apache License 2.0
This repository provides an overview over the EU Digital Green Certificates (DGC) project.
License: Apache License 2.0
In the guidelines on the certificate governance (section 4.1.1), it is stated that Elliptic Curve "SHOULD BE" used. It is stated that RSA-PSS "SHOULD NOT" be used. At the moment, our PKI does not support either algorithm. We do support RSA-PKCS#1. Can we use RSA-PKCS#1 for the DSC-certificate? It is not explicitely stated for the DSC-certificate. For the other certificates (upload, TLS, DSCA) it is stated that you can use RSA-PKCS#1. Is it also allowed for the DSC-certificate?
Can the DSC-certificate contain an extended key usage "1.3.6.1.5.5.7.3.2" (clientAuth)?
I am trying to figure out if there is a way for third party apps & services to validate the QR codes?
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
The TLS client cert does not need SubjectAlt/CN a RSN with the FQDN or IP.
As it is used client side.
Is there an offical database to download offical public keys from EU states? Or how is it possible to get the public keys?
I'm trying to decode the certificates in Elm (compiles to JavaScript in the browser). I can read the data fine, but don't know where to look for
any pointers?
GitHub provides this service for free for open source repos
The document should stress the surveillance risks if OCSP endpoints are used (and in the same vein stress that CRLs should be applied centrally).
My company represents some non-EU countries that need to be able to validate digital health certificates from many countries, including EU countries. I am happy to see that your code is available on GitHub, but I don't see how the architecture allows for non-EU countries or other 3rd parties to validate EU certificates. Can someone please share some information on this?
From what I understand, we would need access to the trust list. Can this be obtained without a trusted gateway node, outside of the "circle of trust" ? Such countries have no requirement to issue certificates, just to validate them, so need to be able to read the trust list, without being able to upload certificates.
Hope to hear back!
Morten Jorgensen
Travizory Border Security
I want to setup a reverse proxy https for DGCG to make DGC_GATEWAY_CONNECTOR TLS
My local DGCG run on: http://localhost:8080/trustList
How to build DGC_GATEWAY_CONNECTOR_ENDPOINT=https://dgc-gateway.example.com
I tried my best with nginx or envoy but still cannot config success.
Is there anyone can help me with?
Hope & wait
Rgds,
We use a private PKI (not publicly trusted) to supply the certificates.
For example, our TLS-certificate will be not be self-signed, but will be signed by our own Issuing Certificate Authority (part of our private PKI).
The certificate of this Issuing Certificate Authority is signed by our Root Certificate Authority (part of our private PKI).
The certificate of this Root Certificate Authority is self-signed. Is this supported?
Do we give you the entire trust chain when supplying the certificates?
https://github.com/ehn-digital-green-development/hcert-spec/issues
There are multiple issues that have been open prev. in the hcert-spec repository regarding open topics for validation guides etc.
I would like to ask whether there's some kind of certificate revocation list that's exchanged in the EU gateway alongside with the list of Public Keys.
And if it's not the case (which is what I've read in a discussion in the repo of the italian verifier app) I would like to ask the reasoning behind this, as it seems like a pretty important feature.
Are there privacy concerns maybe?
I am currently looking at all the certificates that we need to generate as based on the guide within this repo.
Let us start with the CSCA using a Self Signed Root CA which we could create ourselves.
I am having trouble to fill in all the gaps of how exactly the Root CA must be created, the NBcsca, etc...
Example of what i'm doing:
Generate the private key of the root CA:
openssl genrsa -out rootCAKey.pem 4096
Generate the private key of the root CA:
openssl req -x509 -sha256 -new -nodes -key rootCAKey.pem -days 3650 -out rootCACert.pem -subj "/C=XX/ST=State/L=City/O=My Organization/OU=My Department/CN=My Root CA"
Create a NBcsca
openssl req -x509 -newkey rsa:4096 -keyout key_nbcsca.pem -out cert_nbcsca.pem -days 1460 -nodes -subj "/C=XX/ST=State/L=City/O=My Organization/OU=My Department/CN=XX DGC CSCA 1"
Export public key to Java Keystore
keytool -importcert -alias dgci_nbcsca -file cert_nbcsca.pem -keystore nbcsca.jks -storepass somesecurekeystorepassword
I think I'm missing passwords in these steps above, which think is the problem...
As per the issuance service applciation.yaml specification:
issuance:
dgciPrefix: dgci:V1:DE
keyStoreFile: certs/test.jks
keyStorePassword: dgca
certAlias: edgc_dev_ec
privateKeyPassword: dgca
countryCode: DE
I need a keyStorePassword
which is specified above as somesecurekeystorepassword
, however, i'm missing the privateKeyPassword
A full list of openssl commands to depict exact steps would be most helpful, better yet, a bash/sh script to accompany it would really help people get over the bumps and complexities on creating the certificates with the right specifications from the start, leading to a much smoother rollout for Europe.
Section 4.5 of certificate-governance.md is insufficient. The current text says:
Beware that self-signed certificates should also contain the key usage Certificate signing (keyCertSign), so that OpenSSL can verify the (self) signature of the certificate.
As we learned during the dry-run, this is not a SHOULD, but a MUST. Or has this changed to just be a recommendation?
In case this is a MUST, then I would also recommend to lift this into the table above
Field | Value |
---|---|
Subject | cn=<non-empty and unique common name>, o=<Provider>, c= <Member State of the NB> |
Key Usage | digital signature (at minimum) keyCertSign (If the certificate is self signed) |
Extended Key Usage | client authentication (1.3.6.1.5.5.7.3.2) |
Note: that the requirement is really in error as there is no support for the requirement of keyCertSign in any of the open standards of PKI, but if this key usage is required any way due to how current tools work, then it should be made mor clear.
An example that highlights the contradiction is the following requirement from RFC 5280:
The keyCertSign bit is asserted when the subject public key is used for verifying signatures on public key certificates. If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (Section 4.2.1.9) MUST also be asserted
That is: A certificate with keyCertSign set, MUST be a CA, which is not true for the TLS client. But I'm really not trying to change this requirement at this point, just making sure it is is clearly stated. Some comment on this contradiction may however be in place.
Hello,
we would like to integrate the validation into our gastro software so that our staff does not need to use their personal smartphones with the "CovPassCheck" app.
Are there publicly available trust stores or is there a publicly available URI where one can obtain the public key to a given kid from a given issuer or something like a JWKS?
Being forced by government regulations to grant access to indoor venues only for tested or vaccinated people, we would prefer an easy way to check the official digital vaccination certificates of the guests.
Kind regards,
Alex
Most commercial CAs will not be able to issue KUFs that are this strict. Cut them some slack.
There's an article in the ZDF (https://www.zdf.de/nachrichten/politik/corona-digitale-impfausweise-100.html german) which talks about "massive security flaws" in the digital green pass. I think all the flaws criticised there, except the possibility of getting hacked, are also in the paper pass. I thought there should be a clarification, cause this implicates, that the digital certificate is so much worse than the paper pass. (Sorry didn't found a better way to contact an official.)
I think the published scheme has some problems:
This issue is based around the closed issue #7, even though it is closed it is not solved.
The TAN second-factor is quite redundant. It would only make sense if the DGC standard only allows for digital certificates; paper versions of the QR code would not be allowed.
However, currently a bad actor can use a DGC, the only thing stopping them from getting past health checkpoints is the mismatched ID details on the passport or any other type of ID being used. I understand the TAN is being used to stop people from having multiple digital copies of a DGC but I'm not sure how that would help user's protect their DGC; it just makes the digital on-boarding less user friendly. If we are to make digital certificates secure we must have another process in place to generate the certificates.
Maybe we should only allow generation of paper certificates based on information the user should have. This could be a flow like the following:
Considerations of this approach:
The presentation of dDGCs will still be QR codes adding another signature and expiry on top will not be heavy. I understand this is quite different to the current flow but this is the only way we can make sure the certificates are more secure and uses the technology we have better. We should not allow our mobile devices to be just a glorified storage medium with a screen. We need to leverage their real time capabilities to provide a more secure presentation interface, hence the usage of dDGCs.
This organisation contains a Fork of the JSON Schema repository from the eHealth network, pointing to an outdated draft version of the schema.
This fork should be updated to the version 1.0.0, so that member states have a common view on the current implementation baseline.
Hey everyone,
first of all thanks for this awesome work in such a short time.
To verify all the different codes we need access to a global trust list.
Of course only to access the public keys.
We found one list for Austria, but this list looks more like a test list.
But using this list we are able to verify code for Austria but cant verify other countries.
Maybe I did get something wrong or why is the trust list not public accessible.
The public keys are no sensitive information.
https://dgc.a-sit.at/ehn/cert/listv2
https://dgc.a-sit.at/ehn/cert/sigv2
https://dgc.a-sit.at/ehn/
relevant issues:
ehn-dcc-development/hcert-kotlin#28
eu-digital-green-certificates/dgc-participating-countries#10
thanks and best regards
Julian
Hi all, not sure where to put this question.
I just wanted to bring this thread to your attention. Maybe this would be a better place to address some of it's questions therein.
The current HC1-scheme doesn't support documenting a vaccination process using two different vaccines, and those who are vaccinated using a single dose vaccine as their primary vaccination and a single jab of a two dose vaccine for their booster can't differentiate if their Health Certificate is a "fully vaccination" using the two dose vaccine or a "single dose + booster (a single jab of a two dose) vaccination".
I am myself vaccinated using the COVID-19 Vaccine Janssen, and had a single jab of Spikevax in november, and my EUDCC is portrayed as a 2/2 Spikevax, the same as a fully vaccination using Spikevax.
According to this article, the EU will introduce a 9 month validity for the "fully vaccinated" and require a booster vaccine for continued travel using the EUDCC beyond the 9 month validity period, and this can have some travel complications in the case presented above.
My suggestion is to introduce a standard of how the boosters should be portrayed in the scenario above, and I think of two solutions:
Regarding section 5.1, 5.2 in the Guidelines on Technical Specifications for DGCs, Volume 4, European DGC Applications, v1.3
I am unsure, if I understand the DGC installation process in the Wallet App correctly, especially the planned use of a TAN via SMS (or on paper) to move a test result from an e-mail (or paper) into the app.
I assume the following:
So, the protection offered by the TAN requirement is somewhat limited, as the data to display is already transmitted to the user and only the installation in the app is a bit more difficult.
I think it is useful to only allow one installation of the DGC in the official wallet app by registering the installation's public key with the backend and only allow registration for a limited time after issuing the certificate as planned. The wallet app should inform the user that the DGC can only be installed in one wallet before registering the DGCI with the backend.
This would help against the "normal" DGC reuse attempts, like forwarding a test result email to a friend, or trying to scan the QR code from the wallet of another person.
But I don't understand the benefit of a second factor in this situation. Maybe I have missed something important?
Hello!
Where we can find a list of the production Urls of the different national DGC Servers (public key Apis) for testing purpose?
We are developing a Windows C# WPF green pass checker application, and we just found the Sweden Url (https://dgcg.covidbevis.se/tp/trust-list)?
Thanks a lot.
Hello,
I'd be interested in knowing, if data encoded within the QR code is not only signed using a digital signature, but also encrypted?
Or in other words: Is it possible for a 3rd party app to read the data in these QR codes?
And as a followup-question: Is it possible for a 3rd party app to use the EU certificate gateway to retrieve the public certificates required for verification of the dig. signature?
Thank you and best regards,
I have been asked by one of my customers to write a custom DCC verification service. Here are TONS of information, but the "verification guide" is empty (https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/validation-guide.md).
It's also not clear how to obtain access to the test gateway (and later acceptance and production). I created an issue here: eu-digital-green-certificates/dgc-participating-countries#13 (comment)
For any information I would be very grateful!
ios 15.1 is already out, in this update apple is accepting covid vaccination cards natively but only if it is in the SMART Health Card format.
https://support.apple.com/en-us/HT212752
https://smarthealth.cards/
This will make the vaccine card holder experience much nicer, because they will be in a centralized place.
I kindly suggest to implement this.
Thanks.
I came across https://www.npmjs.com/package/covid-certificate-parser with which we will be able to decode/parse a QR code with recovery/vaccination information offline.
What I am unable to understand is, how can I make use of DGC API/Service to validate/decode a QR code and check the authenticity of the QR code.
Is it possible? Does DGC provide some public APIs where a private company can connect to validate the authenticity of the QR code?
From this document,
https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-value-sets_en.pdf
Result of the test
Q1) On Result of the test, Can we assume, Not detected is negative and Detected positive ?
Q2) On Type of the Test, Can we get the more information of Test ? like name, type of test for common people understandable ?
The Dockerfiles for verfiier/businessrule components use the adoptopenjdk image (specifically adoptopenjdk:11-jre-hotspot) which seems to be unmaintained since 01/08/2021
This image is officially deprecated in favor of the eclipse-temurin image, and will receive no further updates after 2021-08-01 (Aug 01, 2021). Please adjust your usage accordingly.
They recommend το switch over το eclipse-temurin
If its possible we would like to have common wallet/verifier apps for different member states to have one registration with Google/Apple. Usually it takes a lot of time to register app and it might be easier to have one app with localisation for different countries/languages.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.