eu-digital-green-certificates / dgca-validation-service Goto Github PK

Revoking Leaked Certificates

I know that this is very likely the wrong place to ask, but my government is not responding to my question.

I have collected a list of 20-30ish valid certificates, simply by using the Google image search. Is there any way to report them so that they can be invalidated? I have not found any information online.

Read more:
https://twitter.com/m33x/status/1456625655194456066
https://twitter.com/m33x/status/1460168026125393920

Thanks for a quick reply, and sorry for the SPAM!

Best,
Maximilian

The validation result type is currently set to "Cryptographic" and others. The type should be set to "Technical", "Traveller Acceptance" etc. defined in the spec. Within the details part of the validation result, the details to the error can be inserted.

The access token contains an extra field for "category" which checks during the validation special rules, parameters etc. Please add an "category" interface which can be enhanced by additional functional. The first default implementation can be left empty.

We are currently planning major changes to the Validation Services within the confines of the Tech IOP.

This unfortunately means that only a small number of stakeholders have a chance to contribute to the process, which increases the chances of any changes being optimal.

This can be avoided by adopting a process of having open Request for Comments. This process is followed by Smart Health Card, and most other open source projects, resulting in a much better end result for everyone.

Please take over the BTP Keyprovider pattern from the issuance service to get the keys from btp keymanagement.

Describe the bug

When setting up the service on a windows machine, Docker won't find a Dockerfile in the temp directory

[+] Running 0/1
 - backend Error                                                                                                   2.1s
[+] Building 0.0s (2/2) FINISHED
 => [internal] load build definition from Dockerfile                                                               0.0s
 => => transferring dockerfile: 2B                                                                                 0.0s
 => [internal] load .dockerignore                                                                                  0.0s
failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount887106246/Dockerfile: no such file or directory

Steps to reproduce the issue

Install JDK 11, Maven and Docker on a Windows machine. Follow the installation process.
Error occurs on docker-compose up

Technical details

• Windows 10 Home (19042.1415)/Windows 11 Pro (22000.376)
• Docker Engine v20.10.11
• jdk 11.0.2
• apache-maven 3.8.4

Additional context

Tested on two different Windows machines

Currently in the code, is just static strings, but we should replace it by localized strings. For this purpose the transmitted language from the validation access token conditions should be use.

The identity service supports not fragments. The route /identity#ValidationEncKey-1 should return the JSON of this one key.

Hello ,

when i try to start the project with docker, i get the error in object on spring, specifically:

Error creating bean with name 'fixAccessTokenKeyProvider': Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: wrong format for access keys env variable: DGC_ACCESSKEYS, expect: 'kid1: publicKey1'

Do you know why?

Thanks

In the spec was a version header defined. Please add it to the routes (except the identity route)

Please add the automatic open api generation as in gateway:

https://github.com/eu-digital-green-certificates/dgc-gateway/tree/main/.github/workflows

To manage the Validation Endpoint better, please add a service definition to the identity document, which contains the url for the validation. The content of this definition should be configurable over environment variables/ymls or similiar.

The valueset values should be checked as well in the structural check. This is a new check(verifiers does it not) to ensure that the right values are set. A fail of this check is a technical error. The check can maybe be done over the SchemaValidation or by checking single CBOR fields against the value sets.

Current Implementation

The Readme file of this repo is empty.

Suggested Enhancement

We should prepare a readme which will describe at least what the purpose of this repo is and how it's codebase could be used.

Expected Benefits

Within the initialization call, an optional callback URL should be integrated and stored next to the subject. If a callback url is given and the validation is done, the callback url should be fired with the result token as payload.

See updated spec document

Are the rules/valuesets during the validation cached or they are loaded always new from the repo?

The provided hash needs to be compared in mode 0 against the calculated cose hash to pre check the signing.

If the service dont run in a national backend, the implementation must be changed to other endpoints (e.g. Verifier Service, BR Service). Please create a abstraction to integrate with other download services.

Is the name and dob check already implemented? (for Mode 1,2)

Currently the keys have just KeyType + .. "+"-1, but there must be the possibility for n keys. The name of the keys should be placed in config file and the enum"KeyType" should just be used for the prefix. The Keyprovider should accept the kid (full url) of the DCC Validation Request. If no kid is provided, the latest key(highest number) should be used.

The token contains the field "type" which must be checked against the dcc type. The type contains currently v,t and r, but t must be more precised by adding "tp" and "tr". The typelist is then v,t,r,tp and tr. For type tp and tt the value for the test type in the dcc must be checked for the correct value of the valueset and if the value is filled within the test manufacturer (mp) according to the JSON schema spec.

The rule validation uses the country of departure instead of the country of arrival.

A technically valid REC certifiate which is chronologically valid during the time of test ( Certificate is valdi from Sep 29, 2021 to Dec 31, 2021) is submitted for check in via the wallet app.

The certificate is found but an unclear error "Recovery validTo befor condition validTo" and "Condition Failed" is shown in the booking frontend.

Describe the bug

A technically valid TEST certifiate which is chronologically valid during the time of test (30.09.2021) is submitted for check in via the wallet app.

ATTENTION: Standardised name in the certificate is the same as Given Name.

The certificate is found but an unclear error "Test collection date after condition validFrom" and "Condition Fulfilled" failed is shown in the booking frontend.

Expected behaviour

Steps to reproduce the issue

The rule validation uses no region of arrival for rule validation. This is different to the verifier devices where no region is provided. Is the region of arrival empty or null, the region can be ignored.

I am missing the Open API specification and the builds for this project..

The access token conditions contains the validfrom and validto date. There should be an additional check in the validation of the DCC expiration like validfrom>=exp && validto<=exp The date times in recovery and test should also be respected.

The public key in the provider should be replaced by a environment variable:

https://github.com/eu-digital-green-certificates/dgca-validation-service/blob/main/src/main/java/eu/europa/ec/dgc/validation/service/impl/FixAccessTokenKeyProvider.java

If the environment variable is not set, please throw a exception.

The redis entries are currently just blank in the DB. Please create the key of the redis DB by using a Key Derivation Function with the values of Subject + ActiveSigningKey (HKDF). The payload of the entry should be encrypted via AES128 and a second key, derived from the subject.

Is the access token jti blacklisted (to the expiration timepoint) after usage?

If no, then please add a replay cache to avoid the replay of a token(e.g. within redis, maximum TTl=expiration time of subject)

Describe the bug

Expected behaviour

Steps to reproduce the issue

Technical details

• Host Machine OS (Windows/Linux/Mac):

Possible Fix

Additional context

Describe the bug

A technically valid REC certifiate which is chronologically valid during the time of test ( Certificate is valdi from Sep 29, 2021 to Dec 31, 2021) is submitted for check in via the wallet app.

The certificate is found but an unclear error "Recovery validTo befor condition validTo" and "Condition Failed" is shown in the booking frontend.

Please create a provider for the accesstoken validation, which gets the JWK from the identity document of the decorator. The URL must be a environment variable.

The validation store contains currently just an local store, but to scale it out on multiple spring boot instances, it should be distributed. E.g. Redis or similar database, which is able to set an TTL to the expiration date of the config.

The dcccrypt class is a little bit misleading. Please add a folder to the service section for "Encryption Schemes" or similar, which contains then RSAOAEPWithSHA256AES.