No Revocation check on Certificates !Important

[iamsilvio]

Page 5 of verifiable vaccination certificates - basic interoperability elements states:

A trust framework, including digital infrastructure, that is needed for establishing the
authenticity and validity of certificates presented by certificate holders.

Page 11 of Interoperability of health certificates
Trust framework states :

3.1.1.7 Health certificate revocation list (HCRL)
A system used by Country A for publishing information about revoked health certificates.
Each Country A shall publish one and only one aggregate list of all revoked health
certificates. Country A is responsible for putting its revoked certificates on the list and signing
it using one of its signing keys controlled by the PHA.

I do not see any implementation of a revocation check.

[oliver-steinbrecher]

HCRL is currently out of scope on european level

[iamsilvio]

Outside of which scope?
Are there comprehensible reasons for this?
Checking for crl is no magic, and it has a big impact on the confidentiality of the solution!

[oliver-steinbrecher]

The hcrl is meant to provide a list of individual certificates which have been revoked. This does not scale on national and European level. We’re able to revoke Document Signing Certificates (DSC) but such a revocation will effect all issued DCCs signed by that dsc. The eu does not leverage the standard for crl instead they issue a list of trustworthy DSCs.

[iamsilvio]

This means that in the application domain, the "certificate" is only a signed document and not a certificate in the sense of x.509?

[martin-verlage]

Hm, the case in Friesland obviously shows the need for revoking issued documents. A nurse exchanged the doses and salt water was injected. The current solution smells like "fire and forget". In my understanding there is no way to invalidate the certificates issued by pharmacies, as neither the place where the injection was provided is in the certificate enclosed nor any data is hosted centrally. This is a significant drawback and far beyond what was specified in spring this year.

[oliver-steinbrecher]

There is an ongoing European discussion on how to address certificate revocations. We're going to adopt the solution once it has been clarified within the ehealth network.

[lennybacon]

As long as there is no solution implemented I do not see a reason why the issue was closed. The issue in the real world is till alive:

https://www.watson.ch/digital/schweiz/419566012-zertifikate-dealer-packt-aus-wir-versorgen-schweizer-kunden

[martin-verlage]

I fully support @lennybacon to leave the issue open - it is a serious issue. A further example false certificates in Bavaria (sorry, in German language only), shows the full consequences for holders: by press release the holders are requested to not longer use the original documents (z.B. gelber Impfpass) as well as the issued EU certificates, otherwise there is a risk of criminal penalties (Androhung strafrechtlicher Konsequenzen).

[lennybacon]

Revocation is a thing. As we said…
ehn-dcc-development/eu-dcc-hcert-spec#103 (comment)

[no-identd]

I concur, this issue shouldn't be set to closed.

@iamsilvio please do change the title of the issue to something more specific & concrete

@oliver-steinbrecher please do reopen the ticket. Just because a topic currently ain't in scope doesn't mean it shouldn't get tracked. After all, that's how things move from out of scope to in scope. Also, how & as what should one interpret 'doesn't scale' here? Because I hope it doesn't mean 'makes penny pinchers wince too much' and refers to some actual technical issues. Which people could help with, if they'd get outlined.

[Ein-Tim]

@jleufgen / @whiskey / @timokoenig

The last comment should probably be hidden for off topic or be deleted?

[RichiH]

https://docs.github.com/en/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam#reporting-a-user is the relevant documentation.

[Ein-Tim]

@RichiH

Thanks! I reported both comments. However, IHMO, they should still be deleted.

The same thing was commented in https://github.com/ehn-dcc-development/hcert-spec/discussions/105 and it was deleted 2 min. later.

[oliver-steinbrecher]

I removed the content

[Ein-Tim]

Thanks @oliver-steinbrecher!

[iamsilvio]

please do change the title of the issue to something more specific & concrete

The issue is still closed, what other title should cause this to be recognized as an issue?

Fire! Fire! Fire!

[lennybacon]

Today I was still able to use MICKEY MOUSE and other certificates

• to import it into the cwa on iOS - it shows and validates it as valid
• validate it with the CovPassCheck app - it shows and validates it as valid

So I'm asking POLITELY to reopen the issue as this is a big f###in problem.

[martin-verlage]

Definitely this issue is an issue and should be kept open until a satisfying solution is implemented. After some more studies of the process of issuing a certificate in Germany my observations are as follows:

• There is a split in the issuing process which produces no trustful documents. All 20.000+ pharmacies potentially issue digital certificates. The Robert Koch Institute (RKI) provides "just" a technical platform and by design trusts the input provided by the issuers (i.e., the holder of the Document Signing Certificates (DSC) and the responsible party for checking the validity of the data for the document / certificate are different). The real issuers (pharamcies) do not own an individual DSC. Hence, there is no other way instead declaring all digital certificates as invalid. - In my eyes this is the killer argument to all issuer-based revoking ideas.

• The solution is on document level only and is open for GIGO (garbage in, garbage out - greetings to Mickey Mouse and Johnny Walker). See the comment of @iamsilvio above (signed document versus certificate). Certificates are issued even when names do not exist and other personal data is wrong (e.g., typo at birth date). Daily experience shows that a cross check of the digital certificate with other documents (i.e., passport, id) is not the rule. Hence, the chance of using a digital certificate being recognized valid without detecting the mismatch between certified person and holder is very high.

• Moreover, there is an ongoing discussion whether faking certificates is illegal. So, no revoking, and no penalty. What should be the reason not to fake? Benefit with little risk attached was always a motivator for unwanted behavior.

Simply speaking, the whole process is potentially canning and signing garbage. Improving can and pen does not help.

[molk-ibm]

The dccs mentioned have not been issued by the german issuer. Currently, certs illegally issued in Germany will be rejected by CovPass Check after Nov. 15th, allowing legally issued certificate holders to re-issue their certificates.

There is a single pharmacy that issued valid certificates illegally. The only counter measure is to make CovPass Check to reject those certificates.

Rejecting the certificates mentioned (Mickey Mouse et. al.) can only be done on a EU level.

[oliver-steinbrecher]

The discussion about European wide revocation mechanisms are still ongoing. Multiple approaches are in discussion within the working group of the ehealth network. These details cannot be shared at the moment.

[lennybacon]

Dear project owners the communication, especially on this topic here, was non-transparent and the helpful and free volunteer work obviously not wanted. Keep going if you want the ones standing, helping and fighting for the same goals become frustrated until they turn of...

@molk-ibm of course it would be nice to have an EU wide solution. It would have been even more nice if anybody at EU level would have had brought up the idea that revocation is a necessity and cannot be postponed.I measure can only be done on a EU level as: We do not really care, will not build a tentative deny-list, and wait for somebody else fix it.

@oliver-steinbrecher it's a complete different story that the working group does something behind the closed curtains. I did not expect different - community work is not valued. Security researchers, especially in Germany, know this pretty well.
But sharing information was not what we asked for. Our request was to re-open the issue until the problem, which you cannot deny actually exists, is fixed by whoever - just to be transparent about: There is an issue and somebody is working on it.

[oliver-steinbrecher]

In order to provide more clarity please have a look into the published documents which describe the current agreed solution for DCC handling in the EU:

• Overview: https://ec.europa.eu/health/ehealth/covid-19_en
• Trustframework: https://ec.europa.eu/health/sites/health/files/ehealth/docs/trust-framework_interoperability_certificates_en.pdf

Please read them to have a better understanding.

The current trust framework is based on publishing CSCA and DSC lists which are considered as the anchor of trust for validation. CSCA and DSC revocations can be accomplished by removing them from the trust list. This mechanism is used but does not allow individual revocation of one specific issued DCC. This is going to be addressed in the next version of the trust framework.

In Germany we have additional capabilities to revoke specific DCC based on the location-id in the UVCI. This allows us to revoke DCCs issued by a specific pharmacy . In contrast to the EU framework this approach only works within Germany with the CovPass Check. This mechanism is also in use.

In summary it’s neither valid to say that we’re lacking revocation capabilities nor does the work on further trust framework improvements happen behind 'closed curtains'.

[martin-verlage]

@oliver-steinbrecher, I think it's not a god idea to refer to docs for a better understanding, when the docs contain exactly the demanded functionality which is not working (yet) - see section 3.1.1.7 HCRL in the trust framework outline. Moreover, as my most significant other is a pharmacist I can tell you that the location-id approach is causing massive confusion at the time of writing in this thread (see for example, https://www.deutsche-apotheker-zeitung.de/news/artikel/2021/11/16/alle-zertifikate-aus-einer-apotheke-fuer-ungueltig-erklaert). The location-id approach is a design bomb for the unlikely case that the issuer is the bad guy. The usual case of certificates which need revocation is that fake data is brought to the issuer, the issuer checks with high effort but does not detect the fake and issues the certificate, and later on, the fake is detected. This is far less than 1% of all certificates issued by that issuer, but still significant. Fighting the fake certificates with the location-id approach would also invalidate the other 99,+% of certificates issued by that issuer. Due to harming the issuers' business by using it (many regulars are affected), the location-id approach is very likely to be never used. The bulk of problems is not approached.

[oliver-steinbrecher]

The hcrl was not implemented due to privacy issues on European level. Hence the working group is discussing an alternative and enhanced approach to revoke specific DCCs. The solution Outline will be part of the next version of the related documents.

[lennybacon]

As I said before. There is no interest to a) inform anybody about ongoing discussions in (technical) committees on EU level b) discuss issues c) work on solutions.

This reminds me of the early Microsoft open source. It's just a placebo. Sad about the potential wasted.

But hey, look at how well we cope with Covid-19. The politics get it all right and maybe in 3- 5 years we leave the Virus behind

[martin-verlage]

After drilling down into the subject a little bit my interpretation of the current status of implementation of revoking by location-id is as follows: a) the issuing body (i.e., a pharmacy) is represented in the system with a unique (?) identifier "location-id", b) the "location-id" is not a specific field in the DCC, c) the "location-id" is encoded in the "unique certificate identifier" (UCI), d) there are algorithms to retrieve the location-id from a given UCI, e) the "location-id based revokation mechanism" is an algorithm implemented in the CWA and CovPassCheck-App user device code declaring all certificates as illegal where the location-id matches a list of suspicious / non trustworthy / to-be-blocked location-ids, f) the revoking mechanism requires an update of the app, the to-be-blocked location-ids are not handled in a separate list, g) following the link in the above comment of @chscheiber the to-be-blocked location-ids are not available to developers of checking apps others than CovPass und CWA. @oliver-steinbrecher: can you confirm?

[molk-ibm]

@martin-verlage this is the way it is currently implemented, yes. as it is open source, you can check the implementation in the German apps yourself. The algorithm is a simple list of hashes of the location ids to be blocked.
this national approach shall be replaced by a centralized one on eu-level, soon.