Re: [Secdispatch] [saag] Interest COVID-19 'passport' standardization?

[Dirk-Willem van Gulik <[e-mail]>]

On 31 Jul 2021, at 00:09, Harry Halpin <[e-mail]> wrote:

> working systems are not using modern cryptography. I suspect there is definitely a need for a privacy analysis that is more thorough than DGC has done

Fully agreed -and with the worst of the crisis over - this is a good time. Also as it is very likely that this is the time for changes/fixes. 

We are getting the first from the field experience, mis-implementations (e.g. the UK got the KeyIdentifier wrong, some countries have URNs that are not valid URIs, etc), the type of fraud that makes economic or political sense and start to see where the trust model is hard from a national governance perspective (e.g. due to delegation of sovereignty of overseas territories). But also as the DCC system is now pushed beyond its design - from a governance perspective (the majority of countries using it may soon well be non EU/EC & EEA /), from a  technical perspective (as countries are now considering boosters & similar) and from a use case perspective - - domestic / private sector scanning is now becoming a thing. 

So the timing is right to address this. And the IETF would be a good & neutral place - as this is first and foremost a standards exercise (actual code is almost laughably trivial[1] - so it is not a essential to start own the open source / code side).

> (surprised to see linkable signatures, centralized databases, and so on and so forth) when we know how to build better and

Note tha the DCC does not have a centralised database (and in fact, a lot of countries do not have any central database either - but rely on very distributed, delegate and often offline/non-API approachable data holdings in the country. Nor is the trust list centralised - each member state manages this essentially itself. The main central elements are the design, the joint list of ‘valid’ (that include “valids” that are not generally accepted; e.g. the codes for Sinovac en Sputnik) that is jointly maintained and a convenience ’trust list’ that is jointly managed for countries that are under the (privacy) regulation or have some adequacy/equivalence regulation or law in place.

> more in the EU GDPR-compliant standards - although I suspect COVID-19 falls under a national security derogation and so GDPR does not apply.

Currently - the engineering design assumption is that the GDPR fully applies - and both EUPD and the various national privacy regulators are heavily involved/heavily influenced the design. The final regulation actually goes quite a few steps further than the GDPR - and disallows certain things (around PII handling, revocation lists and especially the retention of any data post scan) that could conceivable be reasonable and proportional under the GDPR for certain goals.

> Not sure how many people are actually interested in chartering something and the scope, but I'd be happy to host a meeting if someone is attending IETF 111.

Happy to help out / provide information on what was done & why. As I realise that both speed and the international collaboration processes used were not that easy to follow from afar.

With kind regards,

Dw


1: Basically line 126 in https://github.com/ehn-dcc-development/ehn-sign-verify-python-trivial/blob/main/hc1_sign.py — CBOR package your JSON, COSE sign it; Zlib-deflate compress and put it into Base45[2] so it becomes Qr friendly (QRs then have a a 5.5bit efficient mode that is more scanner in the field-resistant than a raw 8bit Qr - yet is almost the same # of pixels).

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