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

From: "Dr. Massimiliano Pala" <[email-masked]>
Date: Mon, 10 Nov 2014 16:21:10 -1000

Hi all,

I would just like to point out that stapling is not the only 
distribution mechanism for OCSP responses -  a useful optimization for
high-volume servers, but still an optimization: i.e. the server is not 
the sole (or authoritative) source of revocation information: that is 
the CA/OCSP server role.

The application (and it is NOT only browsers!) can always reference the 
AIA:OCSP URI in the certificate for accessing the OCSP response. Maybe 
it should be mentioned/noted that the application could decide to (a) 
directly abort the connection or (b) use the default PKIX/OCSP response 
protocol as backup.

Cheers,
Max

> On Sep 18, 2014, at 4:38 AM, Nikos Mavrogiannopoulos <[email-masked]> 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?
>
> regards,
> Nikos
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix