Revocation of a green pass

[FedericoCozzi]

According to newspapers, if a person who was vaccinated gets infected, his green pass is revoked. Can verificac19 check a list of revoked green passes? How is this implemented with offline verification?

[kappapiana]

Hi, this is hardly an enhancement. This is a hard requirement. Otherwise you give OK to GP which must be revoked.

[cifred98]

It's not a bug, it's a feature. See paragraph 6.1 here

It is anticipated that health certificates can not be reliably revoked once issued, especially not if this specification would be used on a global scale. Publishing of revocation information containing identifiers may also create privacy concerns, as this information is per definition Personally Identifiable Information (PII). For these reasons, this specification requires the Issuer of HCERTs to limit the validity period of the signature by specifying a signature expiry time. This requires the holder of a health certificate to renew it at periodic intervals.

[FedericoCozzi]

Actually "certificazioni verdi" can be revoked, according to Italian DPCM, see paragraph 2 here

[cifred98]

AFAIK the gateway doesn't support CRLs of DGCs. I think that paragraph 2 of Annex B of the DPCM is the result of a misunderstanding of paragraph 3.3 here. The CRLs mentioned in the EU document are meant to revoke signing certificates, not individual DGCs.

[FedericoCozzi]

Paragraph 2 of Annex B of DPCM may be due to a misunderstanding, however the DPCM is law in Italy and its intent is clear: if a vaccinated person gets infected, his green pass becomes invalid. Perhaps the revocation of green passes can’t be implemented with CRLs mentioned in the EU document, but it must be implemented anyway otherwise VerificaC19 does not comply with Italian DPCM.

[depau]

If a vaccinated person gets infected they must stay home. Not at a restaurant, not in a bus, not in an airplane, home.

Yes, I know, we know Italy well and we know what happens in Italy, but this is exactly the same problem that we had a few months ago.

The solutions that should apply here are the same that used to apply before the green pass was a thing. Putting people's privacy at risk (more than it already is, since the certificate is personally identifying) is not a better solution.

[FedericoCozzi]

The DPCM states the rules for validity of green passes. VerificaC19 is the official app to check green passes.

Among these rules, green passes may become invalid if a vaccinated person gets infected (as long as this infection is reported).

It could be that no green pass has been revoked so far (although there are vaccinated people who got infected according to official statistics); but, if it happens, will VerificaC19 show that those green passes are invalid?

[magomimmo]

Aside from DPCM rules about revoking individual GPs because holders could get infected, what about the fact that GPs could be lost or stolen and used by someone else?

Should exists a way for the holder to self revoke her/his stolen GP? Does it make sense?

[newton00121]

How is possible to get the annexes of DPCM 17 06 2021? The text states that the annexes are in the ministero salute site; can someone give me the related page address? Thanks

[kappapiana]

How is possible to get the annexes of DPCM 17 06 2021? The text states that the annexes are in the ministero salute site; can someone give me the related page address? Thanks

https://www.governo.it/sites/governo.it/files/Green_Pass_all_B.pdf (don't swear on image PDF, I have abused profanities enough for everybody)

[MatteoPaier]

Just my 2 cents:

• The european rule aimed to create a digital green CERTIFICATE, to allow for easier checking that a person either had been vaccinated, had a negative COVID test in the immediate past or had recovered from the disease. So, invalidate a certificate in case of a new infection is semantically wrong (i.e. it is not because now I am positive that I have not been vaccinated in the past)
• Here in Italy we decided that this should be a green PASS, to allow for access in public places

Certificate and pass are two very different concepts, but someone failed to realized that.

So, AFAIK, at the moment there is no mean of invalidating a green pass in case of reinfection. This is not to attribute to the VerificaC19 app though. Simply, the app (correctly, i.e. according to the european standards) validates a certificate and not a pass.

Solution: emit green passes with a duration of e.g. 3 days, to renew until the expiry of the e.g. 9 months the vaccination is valid. This way, without the need of a CRL, any pass will be valid for a short period of time, and, in case of reinfection it could be not reemitted. This will obviously penalize anyone that does not have ready access to the Internet, to renew the pass, e.g. the elderly.

[falemagn]

It's not a bug, it's a feature. See paragraph 6.1 here

It is anticipated that health certificates can not be reliably revoked once issued, especially not if this specification would be used on a global scale. Publishing of revocation information containing identifiers may also create privacy concerns, as this information is per definition Personally Identifiable Information (PII). For these reasons, this specification requires the Issuer of HCERTs to limit the validity period of the signature by specifying a signature expiry time. This requires the holder of a health certificate to renew it at periodic intervals.

I wonder: couldn't the digital signature itself be put in a "black list"? Not the signing certificate key, nor the health certificate itself, but the final signature. This way no personal info would be disclosed.

Or what am I missing?

[cifred98]

I wonder: couldn't the digital signature itself be put in a "black list"? Not the signing certificate key, nor the health certificate itself, but the final signature. This way no personal info would be disclosed.

For that matter there is already an Unique Certificate Identifier that could be used to revoke them, no need to use the signature

Or what am I missing?

The privacy violation is knowing that a certain certificate has been revoked. For example someone could store all the certificates that he has access to (e.g. using a modified verifier app) and then check every day the revocation list to see which of their previous customers got infected.

[FedericoCozzi]

I am afraid that VerificaC19 failing to recognize an invalid green pass (due to a vaccinated person getting infected) may lead to bad PR if reported on mainstream media “Green passes do not stop Covid-infected persons from getting into restaurant” Or even more extreme “I’ve got no covid and no green pass, and I can’t enter restaurants; he is vaccinated and has covid, and he can! Big pharma dictatorship!”

I think that covidc19 should implement paragraph 2 of dpcm annex by checking into a national “DGC revocation list” which contains the IDs of revoked green passes, exactly like described in paragraph 2.

If this “DGC revocation list” is not foreseen by European framework, this is not an issue. DPCM is an Italian law and there is no need to share it with other European countries.

Let’s not forget that VerificaC19 is not in communication with the European gateway but only with the Italian backend. The Italian backend may implement this “DGC revocation list”. It will be used by VerificaC19 but it won’t be shared with the European gateway.

[falemagn]

The privacy violation is knowing that a certain certificate has been revoked. For example someone could store all the certificates that he has access to (e.g. using a modified verifier app) and then check every day the revocation list to see which of their previous customers got infected.

Doesn't the same issue exist on the opposite side of the fence? Like, a modified app could store all certificates to know who's been tested/vaccinated/ill. On the other end, a health certificate could be revoked for a set of multiple reasons, not just the infection: a hcert could be stolen, for instance, as it actually happened already.

[falemagn]

The privacy violation is knowing that a certain certificate has been revoked. For example someone could store all the certificates that he has access to (e.g. using a modified verifier app) and then check every day the revocation list to see which of their previous customers got infected.

Doesn't the same issue exist on the opposite side of the fence? Like, a modified app could store all certificates to know who's been tested/vaccinated/ill. On the other end, a health certificate could be revoked for a set of multiple reasons, not just the infection: a hcert could be stolen, for instance, as it actually happened already.

Even "worse": a modified app could connect with a central db to store that info, linked with the location data of the hcert validation event, to track a person's habits and their movements.

[cifred98]

Doesn't the same issue exist on the opposite side of the fence?

Yes, we are already giving up some privacy with the current certificates. Let's not make it worse.

[falemagn]

Doesn't the same issue exist on the opposite side of the fence?

Yes, we are already giving up some privacy with the current certificates. Let's not make it worse.

I think the surface area of privacy attacks is large enough that one more thing can't really make it that much worse. One must weigh the pros and cons. The question bodes down to: is it an essential feature to be able to revoke hcerts, to the point that not having it hinders the whole purpose of hcerts?

[falemagn]

Just my 2 cents:

• The european rule aimed to create a digital green CERTIFICATE, to allow for easier checking that a person either had been vaccinated, had a negative COVID test in the immediate past or had recovered from the disease. So, invalidate a certificate in case of a new infection is semantically wrong (i.e. it is not because now I am positive that I have not been vaccinated in the past)
• Here in Italy we decided that this should be a green PASS, to allow for access in public places

Certificate and pass are two very different concepts, but someone failed to realized that.

Not sure I agree with your reasoning.

The HCERTS spec already has the concept of revocation list, and the mere fact that a hcert can expire means that its semantics already include the fact that what was certified once is not certified anymore.

If you reduce the hcert validity to 3 days, it's basically the same as revoking it every 3 days.

[MatteoPaier]

The HCERTS spec already has the concept of revocation list, and the mere fact that a hcert can expire means that its semantics already include the fact that what was certified once is not certified anymore.

The semantic problem I'm referring to is that if the certificate says that I am vaccinated and I am really vaccinated, it is wrong to invalidate it because of a reinfection. The fact that I'm vaccinated it's not related to the reinfection. The HCERT must be invalidated if the thing that it certificates ceases to exists, say e.g. that it comes out that I was in fact vaccinated only with water.

Reducing the cert validity is a patch to allow for easy revoking. Since it is automatically revoked every n days, it is possible to not reissue the HCERT in case of reinfection.

But the key problem remains: we are using certificates as passes, while we probably need two different things. Green Certificates to adhere to the European standards (and allow for international travel) and Green Passes to enter public places.

(Moreover: let's say that we now discover that the lot I was vaccinated with had a fabrication issue and does not protect me from the virus. At the moment it is not possible to invalidate my DGC, since it is signed for 9 months and there is no CRL. The only way to solve a case like that is to revoke the signing keys and reissue all the valid certificates.)

[falemagn]

The HCERTS spec already has the concept of revocation list, and the mere fact that a hcert can expire means that its semantics already include the fact that what was certified once is not certified anymore.

The semantic problem I'm referring to is that if the certificate says that I am vaccinated and I am really vaccinated, it is wrong to invalidate it because of a reinfection. The fact that I'm vaccinated it's not related to the reinfection.

I understood that, but you are "still vaccinated" even if the hcert expires, and especially if it expires, as you propose, every three days. That means that the validity of the hcert is not connected with the concept that you are vaccinated. Revoking an hcert because you got ill, thus, doesn't hinder its semantics.

The crux of the issue is that certifying you're vaccinated has a purpose. That purpose can be, among the others, as the EU itself says, a "Travel purpose", i.e., at all effects, the hcerts assume the role of a travel pass.

And if it can be used to determine whether you can travel, it's only a natural consequence that it can be used to determine whether you can enter a shop.

[FedericoCozzi]

The purpose of VerificaC19 may technically be “to validate the certificate”, but its practical purpose is to allow / don’t allow someone inside a shop / restaurant / whatever.

That is, the owner of the restaurant checks a green pass with VerificaC19. If VerificaC19 says “Ok”, the customer is allowed (as long as the certificate matches the personal ID).

DPCM says that the green pass of a vaccinated person who gets infected is revoked; that is, that person should not be allowed inside the restaurant.

Therefore I argue that VerificaC19 should, in that case, show “not valid” to the restaurant owner, even if that person is “still vaccinated” and therefore the green pass is still “true”. Otherwise, how can the restaurant owner know that the customer should not be allowed in?

[MatteoPaier]

I understood that, but you are "still vaccinated" even if the hcert expires, and especially if it expires, as you propose, every three days.

IMHO expiration and revocation of a Certificate are quite different. In both cases the certificate is no longer valid but, while in the first case the reason is the natural "death" of a certificate (like SSL certificates, that do not live forever), in the second the reason is much more serious (remaining on SSL, e.g. a compromised private key).

I know that my proposed solution is not pretty (it tries to patch the current implementation) but I fail to find another (except for a CRL, that I assume it's excluded for privacy concerns).

[FedericoCozzi]

A CRL is not excluded for privacy concerns.

Actually Annex B of DPCM, paragraph 2, explicitly introduces such CRL.

Garante della Privacy has not objected to such CLR, so far.

[albertosottile]

FWIW, Switzerland implements such a revocation mechanism via a remote CRL, as described e.g. here on page 8 https://github.com/admin-ch/CovidCertificate-Documents/blob/main/20210617_CovidZertifikat_Presentation_System_Integration.pdf

[ddbit]

if a revocation list (even of hashed certificates ) is a privacy concern, did anyone think of using zero-knowledge proofs or rsa accumulators to prove that a certificate is in a encrypted revocation list?

[TheNewHEROBRINEX]

I think that if we were to start checking Certificates against a CRL in order to allow the revocation in case of infection, we should allow this check to be disabled or otherwise the app would stop being suitable as EU Digital COVID Certificate validator since the European specifications do not provide for this behaviour. I personally liked the idea of a switch between Italian/European validation rules as suggested by @Aldo97 (even though it was for another issue https://github.com/ministero-salute/it-dgc-verificaC19-android/issues/110#issuecomment-897040240)

[jaromil]

if a revocation list (even of hashed certificates ) is a privacy concern, did anyone think of using zero-knowledge proofs or rsa accumulators to prove that a certificate is in a encrypted revocation list?

developers spent more time drafting the base45 encoding than focusing on such details. Here my post detailing how ZKP can already be done using software we developed in a flagship EU research project https://medium.com/think-do-tank/the-eu-vaccine-passport-c0af92f0bc1c

[FedericoCozzi]

DPCM (with its annex B) is law. According to DPCM:

1. VerificaC19 is the official app to check green passes
2. If a vaccinated person gets infected, his green pass becomes invalid after being inserted in a revocation list.

I think that VerificaC19 should check this revocation list while verifying green passes. No other app can do that. No other mechanism can be implemented.

Garante della privacy already scrutinized DPCM and made a few remarks, but none on revocation lists.

[jaromil]

A CRL is not excluded for privacy concerns.

as mentioned by @ddbit privacy concerns could be solved by use of zero-knowledge proof, but this unfortunately requires an entirely different procedure for signatures that should replace the EU '90s style crypto scheme with something actual.

FTR the following papers detail a suitable ZKP crypto scheme:

• https://arxiv.org/abs/1802.07344 - using the ζ signature produced by the petition scheme in a CRL
• https://ui.adsabs.harvard.edu/abs/2021arXiv210514527R/abstract - where we did precisely that, ζ is called "fingerprint"

Another approach for a privacy preserving CLR is the one developed in hyperledger indy:

• https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/0011-cred-revocation/README.html where a crypto accumulator (modulo EC), a private factor and a witness are used for blind verification.

AFAIK the latter approach is more complex and requires more space and computation.

One or the other may be implemented adding functionalities to the national issuer without requiring changes in the EU infrastructure.

[djechelon]

@cifred98

The privacy violation is knowing that a certain certificate has been revoked. For example someone could store all the certificates that he has access to (e.g. using a modified verifier app) and then check every day the revocation list to see which of their previous customers got infected.

But here comes the law, prohibiting to retain information. Yet, at least on paper...

We know that these certificates/passes already reveal a lot of information. If on August 10th I show a valid certificate expiring in less than 48 hours, chances are that I made a swab (thus I am not vaccinated). Worse if I bring always a new short-lived certificate with a different serial number. I am forbidden to process such information in a modified app, despite technically feasible.

A malicious verifier can already do a lot of nasty things, including geolocation tracking (as soon as the malicious app is given to a number of verifiers scattered around). Pass contains subject's biographic data that could be matched with marketing lists etc, adding precious health information to the subject's profile.

These dangerous behaviours are particularly forbidden, but nobody is tearing their hair because of the possibility of a mass surveillance with few changes to the code of this app. So I really don't fully understand why we are reluctant to implement CRLs the classic way while the population can be under surveillance since yesterday.

In the case of revocation list, the presence of a mere ID in the revocation list reveals that the certificate is now invalid. This may be caused by:

• The subject got infected
• The pass was abused

There is no 100% assurance on the first event. Yet, any kind of processing of this data is forbidden under the law.

@jaromil

as mentioned by @ddbit privacy concerns could be solved by use of zero-knowledge proof, but this unfortunately requires an entirely different procedure for signatures that should replace the EU '90s style crypto scheme with something actual.

I am not sure this could be possible. As discussed, a malicious user (for example, gym owners are currently retaining a copy of their customers' passes) is supposed to be retaining the unique ID of the certificate along with the subject's data. Forgive me for not having read the articles yet, but if a genuine verifier can (live, on the fly) check that a certain certificate ID is (not) revoked, why shouldn't someone who already pwned the full QR code?

@MatteoPier

Solution: emit green passes with a duration of e.g. 3 days, to renew until the expiry of the e.g. 9 months the vaccination is valid. This way, without the need of a CRL, any pass will be valid for a short period of time, and, in case of reinfection it could be not reemitted. This will obviously penalize anyone that does not have ready access to the Internet, to renew the pass, e.g. the elderly.

If all passes have 48-hours duration this will definitely not reveal any information about the vaccination/recovery/swab status of the subject. But as you clearly mentioned, people without proper IT education or those without ready internet access will suffer the most.

[ddbit]

I think the attack scenario for CRL is that anytime any verifier should be able to download the full list of revoked passes, and even if those are hashed this is still a huge disclosure because there is only one level of indirection between the hash and the user identity. ZKP is a solution to prove that a pass is in the revoke list without actually knowing the contents of the list and it can work offline too.

On Fri, Aug 20, 2021 at 10:14 AM djechelon @.***> wrote:

@cifred98 https://github.com/cifred98

The privacy violation is knowing that a certain certificate has been revoked. For example someone could store all the certificates that he has access to (e.g. using a modified verifier app) and then check every day the revocation list to see which of their previous customers got infected.

But here comes the law. We know that these certificates/passes already reveal a lot of information. If on August 10th I show a valid certificate expiring in less than 48 hours, chances are that I made a swab (thus I am not vaccinated). Worse if I bring always a new short-lived certificate with a different ID. I am forbidden to process such information in a modified app, despite technically feasible.

A malicious verifier can already do a lot of nasty things, including geolocation tracking (as soon as the malicious app is given to a number of verifiers scattered around). Pass contains subject's biographic data that could be matched with marketing lists etc, adding precious health information to the subject's profile.

These dangerous behaviours are particularly forbidden, but nobody is tearing their hair because of the possibility of a mass surveillance with few changes to the code of this app. So I really don't fully understand why we are reluctant to implement CRLs the classic way while the population can be under surveillance since yesterday.

In the case of revocation list, the presence of a mere ID in the revocation list reveals that the certificate is now invalid. This may be caused by:

• The subject got infected
• The pass was abused

There is no 100% assurance on the first event. Yet, any kind of processing of this data is forbidden under the law.

@jaromil https://github.com/jaromil

as mentioned by @ddbit https://github.com/ddbit privacy concerns could be solved by use of zero-knowledge proof, but this unfortunately requires an entirely different procedure for signatures that should replace the EU '90s style crypto scheme with something actual.

I am not sure this could be possible. As discussed, a malicious user (for example, gym owners are currently retaining a copy of their customers' passes) is supposed to be retaining the unique ID of the certificate along with the subject's data. Forgive me for not having read the articles yet, but if a genuine verifier can (live, on the fly) check that a certain certificate ID is (not) revoked, why shouldn't someone who already pwned the full QR code?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ministero-salute/it-dgc-verificaC19-android/issues/103#issuecomment-902519031, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIC4IUHFXQQIM46YIELUU5LT5YFFLANCNFSM5BXOGDCQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

--

*Ing. Davide Carboni, PhD Partita IVA 03800580924 -- *Albo sez. A (CA) n. 7236

Via Stresa 5 - 09045 - Quartu Sant'Elena (CA)Tel: +39 3293547783 Cod. Destinatario SDI: M5UXCR1 Book call on Calendly https://calendly.com/dcarboni-1/30min Blog -- http://digitaldavide.me Dagli Smart Contract alle ICO https://bit.ly/2NI3174

[falemagn]

I think the attack scenario for CRL is that anytime any verifier should be able to download the full list of revoked passes

They'd be just random numbers, until one could match them with a real certificate. Then, the only information that can be desumed is that that certificate's owner might have become ill OR their pass might have been stolen, which adds very little to what can already be known by processing valid certificates: even in that case, one can know that a person has gotten ill: that info is written right into the certificate.

In this scenario, ZKP doesn't seem to be a solution because, even if one doesn't know what is into the CRL, the moment a certificate is checked through ZKP against it, then one knows that that certificate is in the CRL, and that info can be shared with other copies of the malicious app through a side channel.

[jaromil]

In this scenario, ZKP doesn't seem to be a solution because, even if one doesn't know what is into the CRL, the moment a certificate is checked through ZKP against it, then one knows that that certificate is in the CRL, and that info can be shared with other copies of the malicious app through a side channel.

ZKP proofs (certificates to check) are untraceable and their fingerprint is the same only within the same context (UID). One malicious app disregarding the data-retention policy would not be able to track them across contexts whose definition very much depends on implementation specifics (time-based, location based etc.)

Also by applying the accumulator / witness approach detailed in hyperledger, the CRL would not expose fingerprints in clear.

So let me dissent here: if properly applied a ZKP crypto scheme would not allow malicious apps to track revocations.

[falemagn]

So let me dissent here: if properly applied a ZKP crypto scheme would not allow malicious apps to track revocations.

The moment you need to check whether a certificate is valid or not, you are going to know whether a certificate, with its unique ID and related personal info, is valid or not. That information can be shared to other malicious apps through a side channel.

Given that the certificate itself contains information about its own expiration date - and this cannot be changed - it means that if the expiration date hasn't been reached yet, it can only be invalid for reasons that are not related to the expiration date, and those reasons are exactly the information you'd not want to be known and which prompted you to postulate the necessity of ZKP.

That's why I state that ZKP is not useful in this context.

[ddbit]

On Fri, Aug 20, 2021 at 12:43 PM Fabio @.***> wrote:

So let me dissent here: if properly applied a ZKP crypto scheme would not allow malicious apps to track revocations.

The moment you need to check whether a certificate is valid or not, you are going to know whether a certificate is valid or not. that information can be shared to other malicious apps through a side channel.

Given that the certificate itself contains information about its won expiration date, it means that if the expiration date hasn't been reached yet, it can only be invalid for reasons that are not related to the expiration date, and those reasons are exactly the information you'd not want to be known through ZKP.

That's why I state that ZKP is not useful in this context.

Though it makes a lot of difference having a CRL in clear or even with hashed items disclosed by the authorities at once, and having a CRL built by coordinated malicious users that build a common knowledge where there is little or no incentive. Of course any solution works (or fails) within a given attacker model.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ministero-salute/it-dgc-verificaC19-android/issues/103#issuecomment-902604387, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIC4IUB3AWJB3Y3NDUH5VRLT5YWUZANCNFSM5BXOGDCQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

--

*Ing. Davide Carboni, PhD Partita IVA 03800580924 -- *Albo sez. A (CA) n. 7236

Via Stresa 5 - 09045 - Quartu Sant'Elena (CA)Tel: +39 3293547783 Cod. Destinatario SDI: M5UXCR1 Book call on Calendly https://calendly.com/dcarboni-1/30min Blog -- http://digitaldavide.me Dagli Smart Contract alle ICO https://bit.ly/2NI3174

[falemagn]

Though it makes a lot of difference having a CRL in clear or even with hashed items disclosed by the authorities at once,

As said, those are just random numbers, whose meaning can only be understood when they are matched with a live certificate.

But for the reasons depicted above, when that moment arrives, then there's no difference between the ZKP approach and the non-ZKP approach.

I believe we must live with the fact that hcerts disclose certain amount of personal info for design reasons and that cannot be fixed. The Italian Privacy Authority has already had the matter under its scrutiny and has come out with a verdict that states that the current law and hcerts are ok, under the current privacy framework, given their application scope.

Therefore, like others have said before me, the italian app must just abide by the law.

[jaromil]

Though it makes a lot of difference having a CRL in clear or even with hashed items disclosed by the authorities at once,

As said, those are just random numbers, whose meaning can only be understood when they are matched with a live certificate.

But for the reasons depicted above, when that moment arrives, then there's no difference between the ZKP approach and the non-ZKP approach.

I don't know about you, but I work as an applied cryptographer since 15 years and I lead the technical development of flagship projects for the European Commission focused on privacy-by-design research and data sovereignty. I hereby declare the above is false in my informed opinion: a ZKP approach can make a big difference.

I don't say this to influence any decisional process, but since I am a scientist and this is my field of interest I like facts to be defined with correct information.

[falemagn]

Though it makes a lot of difference having a CRL in clear or even with hashed items disclosed by the authorities at once,

As said, those are just random numbers, whose meaning can only be understood when they are matched with a live certificate. But for the reasons depicted above, when that moment arrives, then there's no difference between the ZKP approach and the non-ZKP approach.

I don't know about you, but I work as an applied cryptographer since 15 years and I lead the technical development of flagship projects for the European Commission focused on privacy-by-design research and data sovereignty. I hereby declare the above is false in my informed opinion: a ZKP approach can make a big difference.

That's a blatant appeal to authority, which doesn't address the crux of the matter in any way.

I'll be happy to be proven wrong, about the specific issue I raised, alas that's not what you are doing.

[jaromil]

We agree to disagree then, also about being blatant... the world is full of unqualified experts and we must live with that.

FTR and all technicalities considered, my humble opinion about the policy is to agree with @MatteoPaier:

Certificate and pass are two very different concepts, but someone failed to realized that.

So, AFAIK, at the moment there is no mean of invalidating a green pass in case of reinfection. This is not to attribute to the VerificaC19 app though. Simply, the app (correctly, i.e. according to the european standards) validates a certificate and not a pass.

This is also well explained by an authoritative expert here https://www.giornalettismo.com/revoca-green-pass-verifica-c19-stefano-zanero/

[falemagn]

We agree to disagree then, also about being blatant... the world is full of unqualified experts and we must live with that.

Putting this on a personal level is very typically Italian, yet you have not proved the correctness of your claims nor you have proved the incorrectness of mines.

[FedericoCozzi]

I think that the distinction between a certificate and a pass is not useful.

An “analog” standard passport, issued by a government, is a “certificate”: it associates a picture with a name and a nationality. However, standard passport may be “revoked” when the passport holder loses the right to go abroad.

How is this possible? A passport should just be a “certificate”, i.e. - even if the passport holder loses the right to go abroad - his name, nationality and picture do not change!

Of course this happens because a passport is not only a certificate, but also a pass! I argue that the same holds true for a digital green certificate aka green pass.

The difference with the analog, real world case is that a digital passport - whose validity is checked offline - can’t be easily revoked. The digital green certificate may simply keep a copy of the certificate which - being verified offline - would still appear “valid” to the verifier app.

The solution prescribed by the DPCM (which is law!) is to supplement offline verification with a hybrid offline/online verification, where the verifier app periodically downloads a “revocation list” (daily?) and checks if the digital certificate is listed there.

This works (if it’s implemented, which is not the case currently) as long as the revocation list doesn’t grow too big. Otherwise one could simply download a “good certificate list” and check if the certificate is there!

[oliversaggau]

Any news on this one? We are developing an international software and just checked with an italian lawyer that we have to comply with this law (which was also cited here) in order to offer our service in Italy. But after reading this whole thread, it doesn't seem to me there is any implementation (or even an actual finished concept) for this law or any revocation lists yet, is there? I mean all in all this is the official app for Italy, if that doesn't have an implementation for revoking, so doesn't comply with this law, how are we supposed to do it?

[marcomarsala]

I think a CRL, even with ZKP, reveals a lot about the size of the list itself.

[jaromil]

I have an unfinished implementation made as a Zenroom.org portable scenario, feel free to contact me via email at J@dyne.org if interested. @marcomarsala is correct in saying that the quantity of revokations is leaked. In my application of ZKP based on Sonnino's Coconut the zeta is a sort of pseudonym related to UID (found in the petition use-case), I haven't studied this use-case enough yet to be sure this would be the best solution.

[jumpjack]

So at the end of the discussion, what we know is that an idea which was created to protect people (privacy) is actually endangering people (by allowing spreading of a disease).

It's a real mistery for me why the information about a person being or not harmful for millions of people should be kept secret. As a matter of fact, currently if a person is a killer and is walking around, people is immediately informed and warned; if a person is infected by a killer and contagious disease and is walking around, it must be kept secret. It's just insane.

Apart from this, I don't understand why such a critical issues didn't go mainstream yet: with current version of the app, during next Covid peak we could have ten millions people infected but "legally" free to walk around destroying society.

[djechelon]

It was all a design defect in the earliest project stages. It was clarified several times that the best privacy-preserving approach is short-lived certificates (all 48 or 72 hours, but vaccinated/recovered would get a free renewal online).

My best educated guess is that a lot of people, especially the computer science illiterates (analfabeti informatici) that do now own a smart device or own a smart device too old prefer paper certificates. Some of them even line up at pharmacy (and spend up to 4€ according to unverified sources) to get a printed copy of the green pass. Now these people would have to regenerate the pass every 48 hours and print it on a new sheet of paper.

Owners of IO/Immuni apps could get their certificate renewed online already, but it requires the phone to go online regularly to update. IO app requires a new login every 30 days.

Of course there is a privacy misconception again: some people will argue that they will have to go online every 48 hours to download a new pass, but that's the same who are 24/7 connected and Accept every kind of privacy-related question by questionable mobile apps (e.g. you complain the Government is tracking you but you granted a free game access to your live GPS location for marketing purposes).

It's a real mistery for me why the information about a person being or not harmful for millions of people should be kept secret.

This is the core concept of privacy. Unless there is a legal basis, information regarding one's health is heavily protected. Discrimination and prejudice are behind the corner. Until the law changes, this information is private.

As a matter of fact, currently if a person is a killer and is walking around, people is immediately informed and warned

I disagree with the statement because the statement is not well-posed. Being a killer does not affect one's appearence and make someone more recognizable. I never had the privilege (sarcasm on) of meeting one of them, but I am totally confident that in certain Southern cities (e.g. Naples, Foggia, Locri...) killers are walking around like normal people waiting to get their next job from organized crime.

if a person is infected by a killer and contagious disease and is walking around, it must be kept secret.

Thanks to the vaccination campaign that dropped the fatality rate, I'd refrain from calling SARS-CoV-2 a killer agent nowadays.

Call it private information, sensitive or discreet information. Only authorized people (medical doctor, national health service...) are allowed to know one's health and vaccination status. The privacy law prohibits the employer, the gym owner etc. from knowing one's health status, make questions about why didn't you get vaccinated? etc.

[jumpjack]

Everybody forgot that a centralized database of all Italian citizens already exists, and that each Italian citizen holds in his pocket a microchip of Ministero Della Salute, probably invented just to allow easy updates when needed. It would be just a matter of having in each pharmacy a reader/writer for this card (probably it's already there since many years).

There is also a barcode on the card, which any cellphone could read and compare with a database of authorized citizens.

There was no need at all to invent greenpass and qrcode and VerificaC19 app, a whole system able to handle a "health authorization" already exists since 2003. Probably such a system has been blocked/destroyed/dismantled by privacy laws.

[marcomarsala]

But here they needed offline verification too

[djechelon]

@jumpjack the CNS/EHIC card is issued only to EU citizens. The DGC is also issued to extra-EU citizens who got vaccinated in EU.

Chipped EHIC card is not feasible

1. The chip is not deployed in all EU member states, thus is not interoperable. Italian EHICs (TEAM card) has a chip, others don't
2. Reading the chip requires specialized hardware
3. Reading the barcode is possible only in Italy, because EU EHIC cards do not require barcodes according to standard
4. Reading a barcode with national health ID requires permanent online access as @marcomarsala

We have already revealed that long-lived DGCs are a design flaw, and I have tried to explain that the reason behind this flaw is somehow a balance between multiple interests in privacy, effectiveness and technical requirements.

I'd suggest to close this issue because Github issues are a space to discuss technical issues that can be implemented. I believe this issue is a strong WONTFIX that must be addressed by the Ministry of Health.

Of course I am available to contribute by explaining how and why things are done, up to my knowledge.