Hello Jabob, On Thu, October 29, 2015 11:07, Jakob Bohm wrote: > On 28/10/2015 21:58, Walter H. wrote: >> On 28.10.2015 18:34, Jakob Bohm wrote: >>> On 28/10/2015 17:36, Walter H. wrote: >>>>>> OCSP must not be https ... >>>>>> the same with CRL download ... >>>>> Really, I thought that was only a recent cop out rule to >>>>> cater to clients with inferior SSL libraries that can't >>>>> handle the recursion. >>>> both OCSP and CRLs are signed, and this is enough for validation, >>>> there is no need of SSL; >>> How about privacy. Especially OCSP queries are very >>> revealing, as they indicate the party sending the query >>> is using that particular 3rd party certificate at that >>> very moment. >>> >> what would someone really know, if he would catch the OCSP request of >> the attached certificate? >> privacy is not really the problem ... >> > She (Eve) would know that the requesting party Alice > was talking to Bob at the very moment she sent Trent > the OCSP *request* for Bob's certificate. > > [...] equivalent of having (almost complete) real time > copies of everybody's phone bill/call records. > Who was calling who at what time. this is not a problem as long as the public keys (the certificates) are not really public; because in your example Eve doesn't have the knowledge which certificate the specific serial number has ... if the public keys (the certificates) are searchable by public - the worst case direct by a search engine like google - then you would get an absolute security whole: think of some bad boys, they could get such certificates and get two things with these: a valid e-mail address and everything they need to send encrypted data to this e-mail address, and with this: they can send anything: malware, spyware, whatever; no antivirus, spamfilter, or whatever on any mailserver would stop such emails; everything hangs on the client ... the scenario you gave above is the less problem ... >> there is one thing that is problematic - especially if the CA is >> somewhat stupid: >> using one responder certificate for all OCSP responses for any end >> entity certificate ... >> (the specific RFC says, that it is discouraged to do so) > This is not about the OCSP-response signing certificate > (or the CRL signing certificate). No it is about them ... https://www.rfc-editor.org/rfc/pdfrfc/rfc6960.txt.pdf (stupid CAs - I know at least one - ignore the section on top of page 17) with such CAs it is easy to pretend something different ... >> faking the OCSP response by 3rd party to pretend a good certificate >> even it is bad, >> is quite a little bit difficult, but easy if the CA is stupid ... >> >>> However with careful choice/generation of certificates >>> for the OCSP/CRL server, this can be easily avoided. >>> >> easily - are you sure? >> >> example: >> >> (a) you want to check cert 1 that was signed by the CAs cert A >> (b) the server uses certificate 2 that was signed by the CAs cert B >> >> with https this would be the following: >> to access the CRL or OCSP of cert 1, you need to validate cert 2, >> that itself is needed to access the CRL or OCSP of cert 2, too? >> > As I said it involves recursion and the trick is to > terminate that recursion before it gets infinitely > deep. it is more a deadlock than a recursion ... > Another obvious way would be for that final https > server to do OCSP-stapling, this would be a solution but as soon as using SSL/TLS layer communication for CRL download or OCSP, for whatever reason, accepting OCSP-stapling is strongly discouraged, this is nearly like self-signed ... I'd say security is more important privacy; Greetings, Walter
