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

From: Eric Rescorla <[email-masked]>
Date: Fri, 30 Jul 2021 11:29:49 -0700

To recap my comments on CFRG:
There seems to be a lot of enthusiasm for this in various forums, and it's
largely not well coordinated, with each group (the EU, VCI, etc.) doing
their own thing, and producing work of various levels of quality. Before
the IETF got involved, I'd want to see some evidence that the various
players are interested in a common standard and want to do one here, lest
we end up with XKCD 927.

FWIW, I've spent a bunch of time looking at the various proposals. If
people are interested they can find it at:
https://educatedguesswork.org/tags/vaccine%20passports/

-Ekr

On Fri, Jul 30, 2021 at 11:18 AM Harry Halpin <[email-masked]> wrote:

> Everyone [and apologies if you already got this message on CFRG or
> SECDISPATCH],
>
> While the research community and industry was very quick to work on
> privacy-enhanced contact tracing, I've seen very few people taking the much
> more pressing issue of COVID-19 passports.
>
> If this IETF111 was in person, we could have done an informal BoF, but as
> its' not, I'm sending out an email to gauge interest.
>
> I've earlier seen some very badly done academic work using W3C "Verified
> Credentials" and W3C Decentralized Identifier (DID) standards [1]. However,
> while a bunch of sketchy blockchain technology has not been adopted (so
> far, although I believe IATA and WHO are still being heavily lobbied in
> this direction), there has been the release of the EU "Green" Digital
> Credentials that actually uses digital signatures.
>
> However, there's a number of problems:
>
> * No revocation in case of compromise
> * Privacy issues, i.e. leaking metadata
> * Limited key management (booster shots might require)
> * No use of standards for cross-app interoperability
>
> Furthermore, there appears to be differences between countries, and some
> countries do not use cryptography at all (the US). Therefore, as an
> American in France who flew home ASAP to get vaccinated in the US, as a
> consequence of this lack of interoperability I can't travel on trains or
> eat at restaurants easily, despite being vaccinated. I imagine this will
> become a larger problem.
>
> I have a report I'm willing to share, but I'd first like to know if
> there's any interest in standardization on this front at the IETF despite
> this topic being, I suspect, a bit of  astretch of our remit. However, we
> live in interesting times.
>
> I don't think the W3C (or the ITU, etc.) has the security expertise, and
> while the crypto and security/privacy here is pretty simple, I think it
> should happen somewhere.
>
> While I originally polled it by CFRG IRTF to see if there was any interest
> whatsoever, Benjamin Kaduk pointed out SAAG and SECDISPATCH would be better
> places to start. I'd like to know what others think.
>
>           yours,
>              harry
>
> [1] https://arxiv.org/abs/2012.00136
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Henry Story <[email-masked]>
Date: Fri, 30 Jul 2021 23:19:01 +0200

I doubt that the problem with Covid credentials has to do with the 
format of the credentials, or even the signature technology used to 
sign them.

The knowledge about the virus and the responses to it are evolving
very quickly, and so the flexibility of W3C Verifiable Credentials 
comes in very handy here, as it is built on semantic web standards
built on top of first order logic, hypergraphs, and designed for 
decentralisation, and evolvability. 

This flexibility is particularly important in a geo-political reality 
that covers many nations, with many different languages, different laws 
and no center of control. 
 
The verifiable Credentials standards do provide one important element
of the puzzle, but it does not solve help to tell which institutions 
are authorized  by a country to give out such credentials. That is something each 
country can only decide for itself, each differently as each country 
has different health systems, regulations, policing, etc… 

So what is needed is a way to link these countries together so that 
a verifying software can tell at any time if the institution that signed
a credential is entitled to make such claims by its country, and a way
to allow different vocabularies to evolve in a way that makes convergence
possible.

This requires a Web of Nations (WoN), which I wrote up here:
https://co-operating.systems/2020/06/01/

Technologically we have all the pieces to build such a system.
But it requires many different parties to come together to get it to work.

Henry Story

> On 30. Jul 2021, at 20:29, Eric Rescorla <[email-masked]> wrote:
> 
> There seems to be a lot of enthusiasm for this in various forums, and it's largely not well coordinated, with each group (the EU, VCI, etc.) doing their own thing, and producing work of various levels of quality. Before the IETF got involved, I'd want to see some evidence that the various players are interested in a common standard and want to do one here, lest we end up with XKCD 927.
> 
> FWIW, I've spent a bunch of time looking at the various proposals. If people are interested they can find it at:
> Everyone [and apologies if you already got this message on CFRG or SECDISPATCH],
> 
> While the research community and industry was very quick to work on privacy-enhanced contact tracing, I've seen very few people taking the much more pressing issue of COVID-19 passports.
> 
> If this IETF111 was in person, we could have done an informal BoF, but as its' not, I'm sending out an email to gauge interest. 
> 
> I've earlier seen some very badly done academic work using W3C "Verified Credentials" and W3C Decentralized Identifier (DID) standards [1]. However, while a bunch of sketchy blockchain technology has not been adopted (so far, although I believe IATA and WHO are still being heavily lobbied in this direction), there has been the release of the EU "Green" Digital Credentials that actually uses digital signatures.
> 
> Furthermore, there appears to be differences between countries, and some countries do not use cryptography at all (the US). Therefore, as an American in France who flew home ASAP to get vaccinated in the US, as a consequence of this lack of interoperability I can't travel on trains or eat at restaurants easily, despite being vaccinated. I imagine this will become a larger problem. 
> 
> I have a report I'm willing to share, but I'd first like to know if there's any interest in standardization on this front at the IETF despite this topic being, I suspect, a bit of  astretch of our remit. However, we live in interesting times. 
> 
> I don't think the W3C (or the ITU, etc.) has the security expertise, and while the crypto and security/privacy here is pretty simple, I think it should happen somewhere. 
> 
> While I originally polled it by CFRG IRTF to see if there was any interest whatsoever, Benjamin Kaduk pointed out SAAG and SECDISPATCH would be better places to start. I'd like to know what others think.
> 
>           yours,
>              harry
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 30 Jul 2021 14:23:09 -0700

> decentralisation, and evolvability.

I don't really agree with this claim. Some of the proposals here use
VC and some do not, but they all seem roughly equally capable and
flexible to me.

-Ekr

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Fri, 30 Jul 2021 23:29:40 +0200

> a verifying software can tell at any time if the institution that signed

..snip..
> Technologically we have all the pieces to build such a system.

Indeed.

> But it requires many different parties to come together to get it to work.

The DCC / European system (well, eHealth Network to be precise) consists of a technical system (code at https://github.com/eu-digital-green-certificates/dgc-gateway) that collects ‘root certificates’ of each countries within the context of the pandemic. These sign document signer certificates - which in turn sign the Qr codes. This is very similar to the ICAO master lists used for electronic cross board passports.

Joining this network is a technical and legal/governance process: 

	https://ec.europa.eu/health/sites/default/files/ehealth/docs/covid-certificate_equivalence-decision_en.pdf

> to allow different vocabularies to evolve in a way that makes convergence

And this is handled by the technical working groups; with the vocabulary, schema and similar kept at:

	https://github.com/ehn-dcc-development/ehn-dcc-valuesets
	https://github.com/ehn-dcc-development/ehn-dcc-schema
	https://github.com/ehn-dcc-development/dgc-business-rules

And changing/evolving almost as rapidly as the pandemic response.

Dw

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Fri, 30 Jul 2021 23:35:57 +0200

On 30 Jul 2021, at 23:23, Eric Rescorla <[email-masked]> wrote:
> On Fri, Jul 30, 2021 at 2:19 PM Henry Story <[email-masked] <mailto:[email-masked]>> wrote:

From an implementor/designing perspective (both the NL domestic version -and- the EU DCC version)  — and although we tried very very hard - the absolute need for totally off-line use & preventing surveillance*, also, or especially by the issuing entities  (or blind trust in) combined with the inflexible state of the available semi-usable VC implementations and the very strong desire to have nothing ‘central’ and no ‘central trust’ - had us gradually evolve to something not quite VC. Despite this being the stated goal.

So I think we have some useful lessons learned w.r.t. the importance of off-line / totally local validation.

Dw

*:  e.g. spiked certificates with something unlikely to be cached or requiring a very unique lookup/OCSP, etc.

---

From: Harry Halpin <[email-masked]>
Date: Sat, 31 Jul 2021 00:09:11 +0200

Everyone,

Good to see this conversation, and the contributions from Dirk have been
exceptionally relevant. In particular, I would put out of scope requiring
any verifier to be online and I would also put out of scope data formats
with limited real-world uptake, like W3C RDF and Verified Credentials. I
would focus on widely deployed standards, such as JOSE/COSE and TLS. In
this regard, the EU DGC has done well. I'd like to see international
comparison though, as I can imagine many other "proposals" or even 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
(surprised to see linkable signatures, centralized databases, and so on and
so forth) when we know how to build better and more in the EU
GDPR-compliant standards - although I suspect COVID-19 falls under a
national security derogation and so GDPR does not apply.

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.

Although it may be rather late for some, I will be hosting a "side meeting"
virtually at the IETF 111 meeting today right after the CFRG IRTF meeting
ends. See the wiki for the link:
https://trac.ietf.org/trac/ietf/meeting/wiki/111sidemeetings

  yours,
    harry

On Fri, Jul 30, 2021 at 11:39 PM Dirk-Willem van Gulik <[email-masked]>
wrote:

> From an implementor/designing perspective (both the NL domestic version
> -and- the EU DCC version)  — and although we tried very very hard - the
> absolute need for totally off-line use & preventing surveillance*, also, or
> especially by the issuing entities  (or blind trust in) combined with the
> inflexible state of the available semi-usable VC implementations and the
> very strong desire to have nothing ‘central’ and no ‘central trust’ - had
> us gradually evolve to something not quite VC. Despite this being the
> stated goal.
>
> *:  e.g. spiked certificates with something unlikely to be cached or
> requiring a very unique lookup/OCSP, etc.
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Sat, 31 Jul 2021 12:02:22 +0200

On 31 Jul 2021, at 00:09, Harry Halpin <[email-masked]> 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/