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

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Sep 18, 2014 at 10:38 AM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
> 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?

The draft is designed to allow the client to close the door on the
downgrade attack. That meets the problem statement, I think.