Actual source seems to be here: https://rfmirror.com/Thread-TRADING-make-EU-green-pass?page=...
Actual source seems to be here: https://rfmirror.com/Thread-TRADING-make-EU-green-pass?page=...
The apps for Latvia, Luxembourg and Switzerland say OK, the one for France says "OK but fraudulent", the one for Iceland says no. From the article it looks like the Italian app also says no.
Not revoked everywhere it seems. Also, the French app seems to check against a blacklist, so it is possible that only the Hitler code is considered invalid and not the signing key.
What does that even mean?
It is a weird UI choice but making the distinction between an invalid pass (ex: partial vaccination) and a fraudulent one is useful.
The certificate I am using is printed on a piece of paper I carry with me.
Just out of curiosity, is that for privacy reasons or ? Seems rather strange for a smartphone ?
Since the French app is pretty terrible (it used to be the barely functional contact tracing app that didn't want to use Google/Apple's API, so there's a pretty strong popular stigma against it), even a sizeable portion of smartphone users use an alternative too (I personally have my QR code in Apple's Wallet, but there are other 3rd party solutions).
Depending on when that key was in use, this may be an epic bureaucratic mess to solve here in France if they have to reissue many.
Edit : I'll quickly add that while there's a database of vaccinated people handled by CNAM (the single payer social security administration), it doesn't seem extremely accurate : my best friend and one of his collegues were vaccinated, issued a QR code, but they weren't added to said database and had a terrible time getting the situation fixed. In the end, a pharmacist reissued a "vaccination" for them to "get them in the system". So that database is probably at best incomplete (for the process of reissuing).
There is however a prevalent issue with QR code scanning that I noticed twice personally (and friends reported the same experiences at other places), which is that most restaurants use a super cheap phone/tablet with a terrible camera that usually is unable to focus on a smartphone screen correctly.
Once, the person was honest about it and explained they kept having issues with it, and I tried to help him focus correctly his device (QR code size + luminosity seems to be the issue from what I saw).
The second one tried a couple of time, didn't manage to focus and told me "all ok" despite it's device not having scanned me (I could see the screen).
If I had to travel though, I'd definitely take the paper certificate on top of it, as, at least here in France, that's considered for better of for worse the source of truth.
1. Scan the code with the app every time.
2. Ask if I have the pass, maybe look at it once, hopefully remember me the next times.
There is also a small percentage of cases of no questions asked, ever.
By the way, I'm using a printed copy of the pass. It never runs out of battery, I don't mind if it falls on the floor when I'm using it, it works even if I'm using the phone for something else. Cons: it needs to be replaced if its key gets revoked.
In Ireland it’s hit and miss. About 60% of the time had to produce it, but very few places want to see ID as well, which is needed to prevent people just using someone else’s pass.
I’m all for it so I’d love to see better enforcement.
Yeah the UK very wisely put the passports and the contract tracing in separate apps (helps that the NHS already had an app pre-pandemic). Not sure if it was intentional, but it certainly sidesteps this issue!
So that was pretty poor shot at me.
Both backdating and forward dating have been done in the Web PKI for various reasons, both legitimate (e.g. historically if you couldn't randomise serial numbers enough it was acceptable to randomise the notBefore time parameters slightly, this is no longer allowed) and illegitimate (we have pretty good circumstantial evidence that StartCom issued SHA-1 certificates long after such issuance was forbidden, probably for $$$ from companies that realised they should have bought one before the cut-off) but there is no inclination to insist upon timestamping to try to prevent that.
The most likely place you'll see timestamping in arguably publicly trusted certificates is code signing.
In case of a leaked private key where the actual PKI wasn't breached, they still have authority over the CA itself and can therefore determine which certs are valid and which are fake.
This retains validity of the known issued certificates, but invalidates fraudulently issued certificates. The downside is that its an optional check and that every client needs an online connection in order to validate the cert.
Anyway, the COVID certificates don't seem to be actual X.509 certificates and are rather just a signed message, so this isn't something that could be utilized right now.
In a very important sense the private key is the CA.
The OCSP responses are not encrypted (you'll notice that URL you mentioned is HTTP, you can't use HTTPS for this) but they are signed documents. They're signed by the issuer using its Private Key.
So, somebody who has the Private Key can mint bogus OCSP responses signed with that key too.
The recovery from losing a signing key is to revoke the entire tree under that key. This will usually involve pushing out software changes e.g. a Firefox or Chrome gets fresh data from the vendor saying "This CA is no longer trustworthy, disregard it".
This disaster scenario is why the root keys aren't (must not be) online. If you break into the computer systems of a famous but competent CA and seize total control of everything, you could perhaps (it should be difficult because they're using HSMs but if you've really got control of everything it may be possible) steal the private keys for the online intermediates. But their root is physically locked in somebody's safe, so, you can't steal that by this route for the same reason you can't steal gold bars from Fort Knox by hacking the Pentagon's web site.