Unique DGC identifier

[fredriklj]

Colleagues, I propose to use the COSE signature as an opaque identifier of the DGC to fulfil the requirement of a unique certificate identifier per the proposed regulation (Annex, point 1(g)) rather than this DGCID.

The signature consists of 64 bytes which in practice is guaranteed to be universally unique.

Adding another identifier is only increasing the size of the DGC and creates additional burdens, i believe?

[thinkberg]

Two cents:

1. ECDSA signatures have a random part, signing the same data structure twice will create two different signatures
2. the DGCI currently adds a random element to the data which allows the content to be anonymized (i.e. for online verification)

[martin-lindstrom]

Two cents:

1. ECDSA signatures have a random part, signing the same data structure twice will create two different signatures
2. the DGCI currently adds a random element to the data which allows the content to be anonymized (i.e. for online verification)

1. But the exact same data will only be signed once, so this shouldn't be a problem.
2. OK. Could you elaborate?

[dirkx]

Given that the same blob is offered for scanning - this does not help much with privacy.

Corroborating border guards or airline staff can stil track citizen as they already they can anyway - as they have full access to the passport).

[asitplus-pteufl]

@martin-lindstrom regarding your assumption:

But the exact same data will only be signed once, so this shouldn't be a problem.

In the Austrian case, the same data can be signed multiple times, since the certificate is generated on the fly and signed on the fly.

[thinkberg]

@martin-lindstrom Correct, but keep in mind that the thing may be used at other places as well (difficult to prevent) and then being able to check anonymously may be useful. Basically: a verifier scans the qr code (only keeps it on the device, hashes the data which contains the random part (secret) and can send it for verification to a third party without conflicting to GDPR rules. Given that the anonymized hash is kept at a secure place for later verification.

[martin-lindstrom]

@martin-lindstrom regarding your assumption:

But the exact same data will only be signed once, so this shouldn't be a problem.

In the Austrian case, the same data can be signed multiple times, since the certificate is generated on the fly and signed on the fly.

Yes, but part of what you are signing is the iat-claim of the CWT and that changes over time. So as long as you don't sign all DGC:s within the same second there will be different data signed.

[dirkx]

So we do this in the Netherlands too (with C.L. signatures and full blown unlink-ability). For the DGC this is not quite that feasible - as the payload contains the full name and DoB which, regardless of extra randomness elsewhere in the QR, is rather distinguishable. For this reason we use initial in the dutch domestic of this (https://github.com/minvws/nl-covid19-coronacheck-app-coordination/tree/main/architecture/identity).

[martin-lindstrom]

@martin-lindstrom Correct, but keep in mind that the thing may be used at other places as well (difficult to prevent) and then being able to check anonymously may be useful. Basically: a verifier scans the qr code (only keeps it on the device, hashes the data which contains the random part (secret) and can send it for verification to a third party without conflicting to GDPR rules. Given that the anonymized hash is kept at a secure place for later verification.

OK, and you want to use the ID for this? I wasn't aware that the seamingly random number of bytes of an ID had a built in meaning. @fredriklj News for you as well?

[thinkberg]

@martin-lindstrom Correct, but keep in mind that the thing may be used at other places as well (difficult to prevent) and then being able to check anonymously may be useful. Basically: a verifier scans the qr code (only keeps it on the device, hashes the data which contains the random part (secret) and can send it for verification to a third party without conflicting to GDPR rules. Given that the anonymized hash is kept at a secure place for later verification.

OK, and you want to use the ID for this? I wasn't aware that the seamingly random number of bytes of an ID had a built in meaning. @fredriklj News for you as well?

Originally, we had a secret, a random number. Then the spec came up with the UVCI which contains a random part.

Ultimately I am rather interested in having a final spec that we can implement :-) Please.

[thinkberg]

Originally, we had a secret, a random number. Then the spec came up with the UVCI which contains a random part.

To be clear: meaning, in our local PoC before the EU spec came around.

[martin-lindstrom]

Originally, we had a secret, a random number. Then the spec came up with the UVCI which contains a random part.

To be clear: meaning, in our local PoC before the EU spec came around.

Yes. I want a final schema as much as anyone. So the ID has meaning for some countries? But not for others? Am I correct?

@fredriklj I suggest that we put the ID back but make it optional.

[thinkberg]

@fredriklj I suggest that we put the ID back but make it optional.

Maybe another take. The DGCI could also act in some countries where no central database exists to be a kind of anchor. So it may have its uses.

[martin-lindstrom]

@fredriklj I suggest that we put the ID back but make it optional.

Maybe another take. The DGCI could also act in some countries where no central database exists to be a kind of anchor. So it may have its uses.

Indeed. So keep it in the schema as an optional opaque string?

[asitplus-pteufl]

just for our rationale on the ID: we probably need the identifier for our revocation requirements (crl-based revocation, no online check due to tracing, other privacy issues still need to be analysed). not sure if it would be enough to rely on the signature as ID (not sure on the interpretation here, that IAT is different and then we have a different vacc. cert).

but that would be covered by "optional"

[chris2286266]

AT plans to use the ID to "revoke" single DGCs, as @asitplus-pteufl wrote. So the system generating the data for the DGC has to generate and store the ID, before the CBOR/COSE/QR-Chain is called.

Optional is fine, of course.

[fredriklj]

Very good discussion, I can now see several reasons for keeping the DGCI in there. So let's do that, but I also think we should make it mandatory to ensure that we remain interoperable for whatever use cases may come that relies on this identifier for revocation or other types of lookups?

If it is not just an opaque string, we should take care to define the format clearly. I saw there was a suggestion to put the country code, prefixed by something (01)? Do we need the country code, or can we take that from the CWT header?

Should it be strictly numeric, or combined with a set of upper-case letters? If this is something that the holder of the DGC may eventually have to read out (maybe when checking in to a flight over the phone), then we should take care to not make it too long or mix characters that may be confused with each other (1, I, l)?

[martin-lindstrom]

Very good discussion, I can now see several reasons for keeping the DGCI in there. So let's do that, but I also think we should make it mandatory to ensure that we remain interoperable for whatever use cases may come that relies on this identifier for revocation or other types of lookups?

If it is not just an opaque string, we should take care to define the format clearly. I saw there was a suggestion to put the country code, prefixed by something (01)? Do we need the country code, or can we take that from the CWT header?

Should it be strictly numeric, or combined with a set of upper-case letters? If this is something that the holder of the DGC may eventually have to read out (maybe when checking in to a flight over the phone), then we should take care to not make it too long or mix characters that may be confused with each other (1, I, l)?

Suggestion: The ID is prefixed with the country code of the issuing country followed by any number of characters in the range [0-9A-Z]. And the documentation states that the ID must be unique (therefore the issuing country prefix).

SEW567YUT54

[chris2286266]

Suggestion: The ID is prefixed with the country code of the issuing country followed by any number of characters in the range [0-9A-Z]. And the documentation states that the ID must be unique (therefore the issuing country prefix).

SEW567YUT54

Yes, that looks good (for AT)

[fredriklj]

Like this then?

ff83991

[jschlyter]

Good, but please add Regexp pattern to limit possible characters.

[fredriklj]

Good, but please add Regexp pattern to limit possible characters.

7ff8c19

[fredriklj]

Please submit your review when you are happy.