On 05.09.2015 14:23, Jeff Trawick wrote: > On 09/04/2015 10:59 AM, Kaspar Brand wrote: >>> 1. The default configuration should not trigger unsolicited outgoing >>> queries to untrusted systems, for both a) and b), that's how I would put it. > > Re: "unsolicited": > > Key words/phrases from the other end of the continuum: "unexpected by > many", "responder obtained from explicitly configured certificate"
The other end of the continuum would be "explicitly requested", in my view. "unsolicited" = "not explicitly requested", that's what I intended to say (and "explicitly" referring to something like "manually enabling a directive"). > The unexpected aspect could be helped by a [notice] message at startup > indicating that an OCSP responder will be contacted for N certificates > due to the directive. (If there is only one, an alternate message could > be displayed with the actual responder URL; we couldn't do that for > arbitrary numbers.) IMO, not a sufficient method for justifying a "default on" setting (configuring a Base64 encoded certificate blob through SSLCertificateFile doesn't amount to explicitly configuring a responder URI). > Re: "untrusted": > > The certificate and its content are untrusted in general? Technically speaking, as long as mod_ssl doesn't validate the cert file against a set of (locally configured) trust anchors, the complete file is to be considered untrusted. An admin could have received a "fake reply" for his CSR, where the public key perfectly matches the private key, but the contents are bogus otherwise. Sure, he would most likely realize this quite soon after having configured the cert and trying to connect to his own server, but essentially, I wouldn't consider the contents pointed to by an SSLCertificateFile directive as trusted. > The content > is trusted but the responder URL is not what/who it seems? (I wasn't > sure where you were leading when you alluded to this in prior > correspondence.) X.509v3 certs can have all sorts of "useful" extensions, and I wouldn't consider all this information automatically trusted just because it's signed by the CA (take the OU field in the subject DN as an example: most CAs will have disclaimers stating that these fields are basically "unverified"). With the OCSP URI in particular, an additional aspect of "untrusted" is that resolving its IP address(es) relies on the DNS, i.e. a component which can't be considered trusted when it is queried for records of third-party domains. Kaspar
