Re: [pkix] [TLS] New version of the TLS feature draft

[Nikos Mavrogiannopoulos <[e-mail]>]

On Thu, 2014-09-18 at 07:57 -0400, Phillip Hallam-Baker wrote:

> >> Section 3.1.1 specifies "a server MUST return a valid OCSP token".   I
> >> would consider an expired ocsp staple to not actually be valid.  I
> >> would refer to it as expired, with the implication that the signature
> >> is correct, because if it wasn't a person probably would have said
> >> that in addition to describing it as expired.
> >
> > That's pretty sketchy. OCSP responses have a recommended validity
> > interval, this is not the same as X.509 certificate expiration. I'm not
> > sure what popular browsers do with responses received by the server that
> > are outside the validity period, but I would be very surprised if they
> > dropped the connection. If in this document it is assumed that responses
> > not within the recommended interval should cause a TLS connection
> > failure, it should be explicit.
> Given that we currently have a situation where the vast majority of
> Web browsers are not PKIX compliant and ignore revocation information
> completely and Web browsers are only one PKIX application, I don't
> think it is appropriate to use a MUST here to direct how invalid
> status is handled.

Maybe not, but it makes sense to define what is valid and invalid.
The problem statement of this draft as you set it is to close a door on
a "downgrade" attack where no OCSP response is sent. However, if you
don't define what is a secure connection to a server that supports OCSP
status request, how can you claim to fix an attack?

regards,
Nikos