Subject: [Cbor] European Digital Health Certificates (used in European Digital Green Certificates = Vaccination certs)

From: Carsten Bormann <[email-masked]>
Date: Sat, 12 Jun 2021 14:48:01 +0200

Given that we occasionally look at how other SDOs use CBOR, COSE, etc.:

This week here in Europe, everybody talks about (Covid-19) “vaccination certs”.

European Digital Health Certificates (as used in the European Digital Green Certificates “DGC” for Covid-19) use CBOR and COSE.

This development had to happen quickly, so you it was run in the open; you find lots of information in github.
It is entertaining and educational to read the discussions on the github repos, e.g.,

»It's very easy to decode HCERT. I coded our HCERT verifier in 4 hours without knowing anything about CBOR and COSE (I have used LD-Profs in the past, but not COSE-based certs).« [1]

It is also interesting that one of the problems they had was with QR-Code integration.  E.g., the base45 ASCII-funneled encoding they are using [2] contains percent characters, which unsurprisingly get mangled by some smartphone QR-Code readers (who try to percent-decode them as URIs).  (That would have been easily avoidable at zero additional cost by using a base41-style encoding instead and using a less risky charset subset.)

Also, they are using zlib (deflate) to “compress” the COSE, except that it doesn’t [3].

We may not pay much attention to these integration issues in our IETF WGs, but they are really important to make the whole package work.

Maybe we can find someone to talk about practical aspects of DGC and related efforts at one of the next CBOR interims...

Grüße, Carsten

(Thanks to Emmanuel Baccelli for alerting me to this…)

[1]: https://github.com/ehn-dcc-development/hcert-spec/issues/64#issuecomment-830692153

[2]: https://datatracker.ietf.org/doc/html/draft-faltstrom-base45

[3]: https://github.com/eu-digital-green-certificates/dgc-testdata/issues/284

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Jun 2021 10:53:32 -0400

> This week here in Europe, everybody talks about (Covid-19) “vaccination

Thanks for posting this, as my email asking you to post this was sent ten
minutes ago :-)

    > It is also interesting that one of the problems they had was with
    > QR-Code integration.  E.g., the base45 ASCII-funneled encoding they are
    > using [2] contains percent characters, which unsurprisingly get mangled
    > by some smartphone QR-Code readers (who try to percent-decode them as
    > URIs).  (That would have been easily avoidable at zero additional cost
    > by using a base41-style encoding instead and using a less risky charset
    > subset.)

My understanding is that QRcode can use the entire 8-bits.  Am I wrong?

    > Maybe we can find someone to talk about practical aspects of DGC and
    > related efforts at one of the next CBOR interims...

Actually, I think it belongs as a IAB Tech plenary talk.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 12 Jun 2021 17:37:59 +0200

> My understanding is that QRcode can use the entire 8-bits.  Am I wrong?

As usual, this is less about what QRcode *can* do (there is a nice binary encoding in there), but about what you can get by all the broken stuff that is out there.

So the canonical way to handle this today is:

(1) Use the “alphanumeric” 45-character set defined by QR-Code specs as upper case letters + digits + space (!) + »$%*+-./:«

(2) Use all these characters — even though 2**16**(1/3) is 40.317473596635935 (45**3 = 91125, way more than 65536), so 41 out of these characters would really suffice - don’t avoid the risky characters.

(3) Suffer.

> Actually, I think it belongs as a IAB Tech plenary talk.

Not a bad idea, but probably requires significant preparation.

Grüße, Carsten