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

[Phillip Hallam-Baker <[e-mail]>]

While I would be interested in working on this, I don't see a role for the
IETF unless the government bodies come to IETF asking for the spec. Get the
stakeholders round the table before we start talking or it is pointless.

The problem here of course is that the governments/airlines etc. don't
typically have people with the direct experience of designing this sort of
infrastructure. So the most likely outcome is some sort of committee
process where almost nobody in the room has the confidence to do the job
from scratch and so they start with 'lets build from an existing system it
will be quicker' and end up in the mud.


Looking at the paper, it does not mention SAML which is actually the only
cryptographic assertion format that was expressly designed for this type of
use case. The OASIS TC had a much more narrow scope but the original work I
did on TAXI (Trust Assertion XML Infrastructure) is the work that was
adopted to become the A in SAML.

If I was going to revisit that area, I would definitely start from the SAML
semantics. People could recast them in JSON or even CBOR if they really
wanted but it would be rather pointless.

I would certainly avoid PKIX because the TAXI work was begin to address
major shortcomings in the semantics of X.509v3 attribute assertions that we
had discovered trying to apply them to this type of application.

I would also be less interested in OATH, OAUTH, OpenID, etc because they
are all designed as Web authentication/authorization schemes and 80% of the
specs are working around the constraints of that environment, none of which
are relevant to this application. You might as well start with DNSSEC as a
starting point.


The Mesh has a scheme in which a URL which can be presented as a QR code
contains both a locator and a decryption key which can be used to
retrieve a static encrypted blob from a Web server and decrypt and
authenticate it:

Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint. (ietf.org)
<https://www.ietf.org/archive/id/draft-hallambaker-mesh-udf-12.html>

The intended field of application was to make it easy to transfer from
paper driven processes to digital (and back if needed). There are many
bureaucratic processes that are paper driven. So digital forms end up being
printed out on paper. The EARL scheme allows the paper to have a QR code
from which the digital version of the data can be recovered.

So electricity company sends me a bill on paper, I scan the QR code, it
goes to my payments app.

The data on the Web server is inaccessible to any party unless they have
the QR code. So this makes a paper document (e.g. patient record) a bearer
token for access to the plaintext.


The way I would apply this to COVID passports is that I would print out a
QR code on a sticker and stick it on the back of the passport. So airline
etc. can scan the sticker and get the vaccination status. This can then be
correlated to the data obtained from the passport scan.

To source the data, I would have each clinic issue signed SAML assertions
under a signing key validated by a PKIX credential. I would not use PKIX
for the vaccination assertions, the semantics don't match. But I would take
advantage of the fact that DigiCert, Sectigo, etc. already have all the
CA/LRA etc infrastructure deployed and could spin up private CAs for this
in a matter of days.

If audit transparency was required, I would not go to Blockchain, I would
go to Certificate Transparency. But that is very much a secondary issue.





On Fri, Jul 30, 2021 at 2:19 PM Harry Halpin <[e-mail]> wrote:

> Everyone [and apologies if you already got this message on CFRG or SAAG],
>
> 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
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>