On Tue, Apr 25, 2017 at 5:50 AM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote:
> > So you point is that as long as you don't use OCSP responses there is > no interoperability issue. That's very interesting point. More > interestingly you delegate that definition to an application profile. > Could you refer to such application profiles for TLS which define how > OCSP responses are to be used? > I would argue that the Web PKI, as practiced by browsers, is one example that is specific to the (publicly trusted CA) ecosystem. In this profile, all major implementations but one (Firefox) allow for stapling an expired response. With the exception of Firefox, when such an expired response is received, they'll (if configured) go obtain a live response. In this respect, PCT got it right - the certificate (and additional inputs, such as OCSP stapling) are inputs to a blackbox which yields a binary response. So, too, should it be for TLS - because in several major clients, that's precisely what it's implemented/exposed as. That's not to say you, for your use case, need to treat it as such. But it highlights the existing disagreement for which using the spec to 'force' clients to a particular viewpoint isn't productive, nor does it meaningfully improve security.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
