OCSP

[dirkx]

The document should stress the surveillance risks if OCSP endpoints are used (and in the same vein stress that CRLs should be applied centrally).

[daniel-eder]

Fixed in #23

[SZoerner]

@dirkx Could you give more background on the mentioned surveillance risks? In what sense are CRLs better than OCSP? The document now states "due to privacy concerns".. If it is about calling a third party, would OCSP Stapling be an option?

[dirkx]

So with a CRL - you get a list, in one 'GET' from the CRL service, of all the revoked certificates. With OCSP - you ask a OCSP service, is "this specific' x.509 certificate' valid. So in our case - with CRL you get a list of DSC's no longer valid. But the CRL service does not learn which DSC you are interested in. You get them all. With OCSP - the OCSP service learns with DSC you are interested in validity wise. Now if you run this every 24 hours on a central backend - and remove any certifiate thus learned to be invalid - prior to passing on a static list to the verifier. And you make sure that the verifier NEVER does any extra check - both methods are equivalent. But this is not the case if you do it in the verifier (or if your X.509 library does this for you). So consider scenario's such as a CSCA signing two DSCs; one used for almost all citizens; and a special second one which is only used once or twice for the signing of just one or two DGCs given to a citizen you'd like to keep some tabs on. If your verifier does the check in real time - the OCSP service (And anyone that can observe the traffic to and from) - gets an 'alert' that this citizen showed up at this and this time near this and this IP address. Note that only doing CRLs (and not OCSP) is not quite perfect- if a country sets aside a complete CSCA for just this- you still have this problem with CRLs too (if the verifier checks CRLs). So our lines of defense in depth are: 1) advise to do this on the national backend, 2) do not push x.509 to the verifiers; but the KID, X, Y tuples and 3) do put OCSP endpoints in the cert. The reason for cutting CRLs some slack is that they require a duplicated CSCA - which is a lot harder to hide than the often changing DCSs -and- that in general implementations will do OCSP checks 'in line' - e.g. during a signature validation with some caching -- but consider CRL checks too slow for this. Note that above exampel assumes a country that wants to do this for its own citizen; you can make supply chain and bogus cert variations depending on the hostile actor (as you probably do not mind that the verifier goes red).