DGC issuing and expiring date

[lcimaglia]

Hi

probably is not the right place to ask this but I hope to get some confirmation about this.

The DGC issuing and expiring date are not included in the DGC JSON schema. I assume the reason behind this is to use the common payload values "Issuing Date of the DGC" and "Expiring Date of the DGC" (see https://ec.europa.eu/health/sites/health/files/ehealth/docs/digital-green-certificates_v3_en.pdf, page 8, table at paragraph 2.6.3)

I recently reviewed the paragraph 3.3.5 of this document: https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-certificates_v1_en.pdf Here the "Expiration time" seems to be related to the signature instead of the DGC expiration date.

The DGC validity period is important for the Verifier app, so I think we must agree about the meaning of those fields.

[gabywh]

The general principle/constraint is that the container used for carrying the data payload has its own valid from / until dates. Table 2.6.3 covers this, as you say. Then there are the individual entries within that container that have their own valid from / until date ranges.

So what we have is a two-stage verification process:

1. The DGC expiry date governs the validity of the package as a whole (the DGC). For Verification, the package/DGC should not have expired (and also be presented on or after valid from).
2. Next "level" down: once you have ascertained that the package/DCG is valid date-wise as a whole, then you can check the validity of the individual entry (or entries) in the package/DGC - e.g. a vaccination certificate - to see if that is also valid.

(note to self; FAQ ?)

[lcimaglia]

Hi

so from your comment I understand that DGC expiration date in the common payload is indeed related to the signature expiration date.

Then my question again about DCG verification, as you wrote:

2) Next "level" down: once you have ascertained that the package/DCG is valid date-wise as a whole, then you can check the validity of the individual entry (or entries) in the package/DGC - e.g. a vaccination certificate - to see if that is also valid.

Unlike recovery entry, vaccination and test entry does not have a "valid until" date field. I do not think we would like this business logic to be embedded in the Verifier app and business rules will not be implemented in phase 1.

So, for example, how the verifier app should verify that a DGC vaccination entry is valid? The only date there is the vaccination date. Same could be said for the test entry. I think we need a "valid until" date field in each entry, unless we want every MS verifier app to implement their own rules but this could result in a lot of issues.

[gabywh]

Right, so there's a whole separate, active sub-group within eHealthNetwork currently concerned with the process of defining business rules (in particular for Verification).

Unlike recovery entry, vaccination and test entry does not have a "valid until" date field

Correct. Two reasons, take vacc as an example:

1. vacc type + start date gives an effective valid until date, based on the considered validity duration of the vaccine itself.
2. for interop with other countries, the duration of validity of a vaccine may differ. The usual travel rules apply: the regulations in force at the destination determine whether you are allowed entry or not. Thus you have a start date and vaccination type. Countries can then apply their own business logic as to what they calculate the "valid until" date is. Within the EU I do not expect any difference in validity of vaccine. The vaccine validity may, however, be different for countries outside the EU.

Test entry: same reasoning as for vaccination.

[vitorpamplona]

It's simply not the issuing jurisdiction to define expiration dates. If the vaccine was given in France and is read in Germany, the verifier is operating under German laws and regulations and thus the expiration should follow Germany's guidance, not France's.

Of course, each verifier can also have its own rules and each verifying user/business can decide to not follow their government's direction.

[lcimaglia]

ok so to simply put this, every MS decide which rules to apply.

In phase 1, I suppose the business rules would be hard coded in the MS verifier app. In phase 2, these MS business rules would be shared thorugh the DGC gateway so that every verifier app should be able to check DGC from a MS point of view.

Assuming the above is correct, the recovery entry "du" field (Certificate Valid Until) does not seem so necessary, but I suppose that field is intended from a medical perspective and not as for the DGC validity.

[vitorpamplona]

Remember that there is also the issuing and expiration dates of the CWT. Those are the issuer's prerogative: I can certify a "recovery card" from and until this date. Those dates have nothing to do with the medical condition itself.

The du is a recommendation of the lasting COVID protections made by the issuer. But it might not be followed by the verifier (the verifying government can disagree w/ the recommendation).

[PeterEbraert]

Have I got this straight?

1. I by a new ECDSA certificate on 01/06/2021 (valid until 31/06/2022)
2. I upload the public part of the ECDSA certificate to the DGCG (so other countries can validate our attestations QR-codes).
3. On 01/06/2021, I issue a first DGC using that certificate
4. I keep using that certificate for 6 months.
5. On 15/11/2021, I issue second DGC using that certificate

Do I need to set the expiration date of both DGCs on 31/06/2022? That would be a real pity, as both citizens got the same vaccine, and deserve DGCs with the same validity period... I would prefer to issue:

• first certificate with validity end date 31/05/2022
• second certificate with validity end date 14/11/2022

Although, given the fact that the ECDSA certificate I used expires on the 31/06/2022, I am wondering if the second certificate could still be positively validated after the expiration of the certificate that was used to sign its QR. Can someone enlighten me?

[lcimaglia]

In the situation you mentioned:

5. On 15/11/2021, I issue second DGC using that certificate

in my opinion you are going to need another ECDSA in order to sign that DGC, since the DGC validity end date would exceed the ECDSA validity.

[PeterEbraert]

So we always need to make sure

ECDSA cert validity > max DigitalGreenCertifcate validity + usage period of the ECDSA cert

In that case, I hope we can acquire ECDSA's with a validity of at least 18 months. :-)

[vitorpamplona]

The Expiration Time (exp) claim on the CWT MUST not exceed the validity period of the certificate.

To the best of my understanding, the du field doesn't need to be inside the expiration date of the certificate or of the exp claim.

[PeterEbraert]

eHN_Guidelines_DGC_Vol5_Certificate_Governance-v1.02[49].docx

[PeterEbraert]

The above doc clarifies a lot. :-)

Now, we only need to find a way to obtain a CSCA that is itself long living (4 years). We will than use that CSCA to issue DSCs (with a 2 year life) every 6 months, upload those to the DGC and start to use those DSCs 30 days afterwards.

Anybody knows a commercial CA who still issues certificates that are valid for more than 1 year? How are the others approaching that? We could use Self-signed certs... what is your opinion?

[jschlyter]

Anybody knows a commercial CA who still issues certificates that are valid for more than 1 year? How are the others approaching that? We could use Self-signed certs... what is your opinion?

You can, and should, use a self-signed certificate for your CSCA - this has nothing to do with WebPKI.

[PeterEbraert]

OK. We will probably use our own CA to generate and sign the CSCA... The EU document above insinuates however, that one could be using commercial CA's to generate and sign the CSCA... Does not seem to be the case, does it?