eu-digital-green-certificates / dcc-quality-assurance Goto Github PK

eu-digital-green-certificates/dgca-verifier-app-android#81

SpecialCaseHandling.md needs review and correcting on some points, primarily regarding Verifier and Issuer actions.

It looks like is not possible to get valueSetValues for covid-19-lab-test-manufacturer-and-name valueset maybe due to a lack of resources. You can see the problem here (Possible reasons: The provided hash value is not correct).

This problem makes tests failing locally and on PR.

The Script should load from a subfolder all Schemas and should check this schema against the QR code and the embedded version number. If the schema is not fullfilled, the codes are returned. E.g. fnt: "Ärmel" --> fails because [A-Z>]$ is allowed

Consider making the python scripts (https://github.com/eu-digital-green-certificates/dcc-quality-assurance/blob/main/.github/workflows/dgc-testdata-verification.yml) validate the codes so that no QR codes are uploaded unless their they codes adhere to the defined valuesets.

The EXP field must be checked in the recovery statement against the validUntil field. The validuntil field must be greater /equal than EXP date. In some codes there are validuntil fields e.g. to 17.6.2021 but EXP is 2022.

The "recovery cert" in the README file is actually the vaccine certificate (wrong reference):

https://github.com/eu-digital-green-certificates/dcc-quality-assurance/blame/main/IE/1.3.0/README.md#L21

Hi @RKlaus-tsi

Please check on Android: https://github.com/eu-digital-green-certificates/dcc-quality-assurance/blob/90c34582a4adc27fb59a52828ecf90676c304f2f/SL/1.0.0/REC.png

You reported valid with iOS.

During some automated tests, we've discovered an issue with new certificates from Scotland.
@andrewkay18981 you've added new certificates, but these seem to have an invalid date format
GB/1.3.0/TEST_SCT.png has a date '2022-01-31T05:00:00+0'

According to the ISO specification (https://en.wikipedia.org/wiki/ISO_8601), you need to have 2 numbers behind the +

<time>Z
--
<time>±hh:mm
<time>±hhmm
<time>±hh

This results in an error thrown in our validation app, causing these certificates to be marked as invalid, even though they may be valid. Can you confirm the production certificates of Scotland don't all contain this invalid format? If so, we'll have to add a workaround on our side and other countries may block these codes accidentally.

In merge #148 we're merging Qr's that do not meet the Regulation (extra PII, such as passport number and Sex).

May be wise to either mark them thus - or have a separate folder that says 'in-compliant certs for testing'. As to avoid that implementors make a mistaken assumption.

The script should check if the right certificate is used for the OIDs placed in the certificate.

Attaching pass and a link to public keys

Coronavirus (COVID-19) records.pdf

https://covid-status.service.nhsx.nhs.uk/pubkeys/keys.json

Please insert a checkup function which checks if the issuing country is correctly set and follows iso standard.

Please recheck: https://github.com/eu-digital-green-certificates/dcc-quality-assurance/blob/0c0461876d3e3b6e92f97e12d06635ef25622359/DE/1.0.0/REC.png

To avoid the upload of productive certificates, the CI in QA and testdata should be enhanced by checking the prod keys.

As reported by RKlaus-tsi: recovery statement is not valid yet

https://github.com/mkubicek-dtc/dcc-quality-assurance/blob/2d0c3bd3289b7dfc0b4186a22d9d1b1d2c405fd2/BE/1.0.1/REC.png

we scanned an ES country , EU DCC code
we are getting
iat 2021-07-20 07:33:17 and
exp 2021-08-19 07:33:17
for vaccination
is it an valid values ?
in ES country, EU DCC vaccination is valid for only one month ?

SE: VAC.png gives Astra vaccine name but reports BioNtech as manufacturerer, is this correct?
Name reported: Vaxzevria

//Swedavia IT

There seems to be an aliasing artefact in the SG Qr coes from PR#157:

Enlarged example:

Please recheck: https://github.com/eu-digital-green-certificates/dcc-quality-assurance/blob/2d0c3bd3289b7dfc0b4186a22d9d1b1d2c405fd2/HR/1.0.0/REC.png

Got two spanish certificates, one from the reginal (valencia) authority and another one from the spanish government.

both are giving "failed" in the android app verification.

Decoding manually the CBOR records, in the "valencian" one, can see a difference in the "6" field. In this certificates, they used a decimal point in the expiration date.
{
"1": "ES",
"4": 1685271300,
"6": 1624617519.261,

Also i have a problem verifying the signature:

KeyError: 'Key ID not found in cert list: 65c7e496812f7c64'

decoding the "spanish" one, the timestamp is OK, but i get an error:

Key ID not found in cert list: a85345d9d0be9a34

may be there is some problem with the signing keys in the gateway? If you need the png or pdf, let me know how to send it to you.

PS. Related issues are in:

eu-digital-green-certificates/dgca-verifier-app-android#94

and
eu-digital-green-certificates/dgca-verifier-app-android#116

Since the 20th of August, we're getting helpdesk reports that turn out to be float values in the dosage numbers of IE vaccination DCCs. This issue has been reported to the Ireland team on the same day. Since we're getting a lot of reports (also public) about this issue, we're moving to allow whole-number float values in our verifier application (so 1.0, but not 1.5 or 1.0001).

1. Can this case be reproduced with acceptance keys and added to SpecialCaseHandling.md so it can be checked by other member states.
2. We're assuming the dosage floats are always whole numbers, i.e. 1.0 / 1.0, and never something like 1.5 / 1.0 or 1.0001 / 1.0. Is that right?
3. What is the timeline on getting this fixed on the issuer side?

I only have production examples, which I can't share here, so I've recreated the scenario with the NL signer and NL acceptance keys (IE CWT issuer due to details on our side):

HC1:NCF%RN%TS3DH0RGPJB/IB-OM7533SR769CIN3XHW2K6R5EJH5.AAVDXGHP80K1JZZPQA37S47*KB*KYQTKWTNS4.$S6ZCJKBHC3KD3ZQT.LJ/9TL4T.B9GYP:S92 A9PPYW5TW5B/94O5JWE9.M2RURV1RU1QK98O92+PHN9F/9BL5CIE/YU1Y9YPDN*I4OIMEDTJCJKDLEDL9CZTAMEIW CI4U/DCYZJ+PB/VSQOL9DLKWCZ3EBKDHOJ7UJQWT.+S1QDC8CC8C$8D7AD9ZI1FV25WRH0CP4Y5LWERLW4G%89-8CNNI:C01HYE97NV8/FVD98-O7I54IJZJJ1W4*$I*NVPC1LJL4A7K73YNSRB7-FHTGL3HHL853IO3NV5W4*LP$V2GHKW/FMKKY0K5$02.AS*7SA065QW-CC4PM0GD:DU7TQ84B8U 5PX$4MRP1722+PYVAHBS/%D:VA%-UL2MSZL/7A$4WRTOPXU+3FGFWB9N3E1IKPO.T7NCWAUZTLRLO:/KK3S65OJYCHIG%KDT-L/Q2$8KY2H7E9R0T000U50VDW1UK%2

We've done testing on other verifier apps, with these results:

- NL CC: ❌ (invalid QR)
- NL DCC: ❌ (invalid QR)
- BE: ❌ (format not recognized)
- CH: ❌ (format invalid)
- LU: ✅❌ (parses as 1/1, but invalid code IE en invalid code vaccine, maybe config problem)
- IT: ✅
- CZ: ❌ (unable to recognize QR format)
- DK: ✅
- AT: ❌ (Ihr certifikat ist zeitlich abgelaufen / fehler VA3)
- FR: ✅
- HU: ✅
- PT: ✅
- LV: ✅

Could countries who accept these QRs with float dosage values indicate how they handle this case? Are you casting, flooring, rounding?

can you provide some valid test data that passes the TACVerif ? thank you

Bulgarian vaccination certificate cannot be verified using app (Android 'tst' and 'acc' releases, tested using all versions up to 1.1.5). Recently (July 4) all certificates of vaccination issued by the Bulgarian government to those vaccinated with the Pfizer/BioNTech and the Moderna vaccines were reissued, apparently due to a mistake in the 'Manufacturer' field in both vaccines. Still, neither my old certificate, nor my new one, are read correctly by the app - I get the "Verification invalid" message.

Perhaps also add one for the countries that do not have a URN:01:UVCI:.. prefix on their URLs; but have them be LU/1212918219 or something in https://github.com/eu-digital-green-certificates/dcc-quality-assurance/blob/main/SpecialCaseHandling.md

Please recheck: https://github.com/eu-digital-green-certificates/dcc-quality-assurance/blob/87d74dde4692c803142d600165ff60ca3e243ac8/LV/1.0.0/REC.png

Hi, I don't know if this belongs here but any help would be appreciated.
We have received a complaint from a citizen of Uruguay saying that his certificate is not validated by the official verifier app of the Government of Catalonia.

Uruguay has a valid public key in the Trusted List (kid="woowbyJtRFo="), and the certificate of the citizen is correctly signed by the corresponding private key.
However, the format of the certificate seems incorrect, as instead of the fields "ver" and "dob" and structures "nam" and "v", the certificate has the fields "Date", "Name", "CountryCode", "DocumentType", "DocumentNumber" an a structure "VaccinationInfo".

I tend to think that this is an invalid certificate, but given that it is correctly signed by the private key of Uruguay (as I said, the public key is in the official Trusted List), I wonder if anybody has encountered something similar.

By the way, the test certificate in this repository has the correct format, so it seems a problem related to issuance in production. As additional information, the issuance date of the incorrect certificate is December 28th.

Do you have any reccommendations on this subject?
Thanks in advance,
Jesus Ruiz

As asked to by @kerstin-oppermann-tsi in this issue I will also create an issue here (for details see other issue). Here just a short sum up:

Test- and vaccination certificates issued by the austrian government cannot be validated in the android app because of a signature error. Ie, the necessary information (name, test- or vaccination date, ...) can be sucessfully extracted from the QR Code. But when trying to validate the signature, no certificate is found for the keyid, thus the test- or vaccination certificate is flagged as invalid.

The signature of both certificates can be validated in the offical webapp of the austrian government "https://qr.gv.at" using the following certificate

-----BEGIN CERTIFICATE-----
MIIB7zCCAZagAwIBAgIKAXnM+L47fmBcezAKBggqhkjOPQQDAjBEMQswCQYDVQQG
EwJBVDEPMA0GA1UECgwGQk1TR1BLMQwwCgYDVQQFEwMwMDExFjAUBgNVBAMMDUFU
IERHQyBDU0NBIDEwHhcNMjEwNjAyMTM0NTI0WhcNMjMwNjAyMTM0NTI0WjBGMQsw
CQYDVQQGEwJBVDEPMA0GA1UECgwGQk1TR1BLMQ8wDQYDVQQFEwYwMDEwMDExFTAT
BgNVBAMMDEFUIERHQyBEU0MgMTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABGBN
uKiCpnXH0VlIdk6pJZH2ep8jQaV+FR3izMXxZfK5EPGZLtG3Jx+TmV3JJErfrSrP
hRmfbSidVbTQ5nnZS+ujbjBsMA4GA1UdDwEB/wQEAwIHgDAdBgNVHQ4EFgQUNs2s
mrjBhuR5Bqxl6teE1x1o2ycwHwYDVR0jBBgwFoAUHyKsHGUWKbTBmLNjb7/dCZ27
e3swGgYDVR0QBBMwEYEPMjAyMTEyMTYxNDQ1MjRaMAoGCCqGSM49BAMCA0cAMEQC
IDjXHnyzq3sTisMX1uY8xQ2ZqCRL2xmxtYOPhSZ9ZacYAiAqHUMOC7WNgq4h28n3
1WLc1mMPAYauWslSEwnXC79AGw==
-----END CERTIFICATE-----