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

"Dr. Massimiliano Pala" <> Tue, 11 November 2014 02:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9101E1AD445; Mon, 10 Nov 2014 18:21:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.39
X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001, T_HK_NAME_FM_DR=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fQyVx7sveF7e; Mon, 10 Nov 2014 18:21:16 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F03861AD441; Mon, 10 Nov 2014 18:21:15 -0800 (PST)
Received: by with SMTP id k14so10429068wgh.28 for <multiple recipients>; Mon, 10 Nov 2014 18:21:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eF84d63HUe946qA64CZBbz0A9K7G7JYtYF4DTdzLdvM=; b=URPkg8wRJv/PrBtXcVHVU1w+KQRS1BktZuZafpY7nkw1qPCazgg1eg+tRA3KYuIfeI Rot/uMfBQZfpDz8u6NH+FCqRUAKwu8wai2up08a65llMLldvtoBG6rxKu7NWwrXJyfyQ CsGe24EZJ7S+Lye+Tij+6eUZ+EuBKYH5+yFQ0H7KLMWjBjuCJAR0jjksEnG9rorTDmm8 r0bO0QbX2h+UZSJ5TeIgvjCOuQSCyu5Hn4JEqIC5NBjXEtA6ribYTuBnD0eNfcUk3y3n rt/53rqV308lldZfPDBvQq7yC3KY/0N240E49khXhkcdrnljhKSNkYtoauaWA/4pUQLg 8QRQ==
X-Received: by with SMTP id ck18mr48914104wjb.103.1415672474802; Mon, 10 Nov 2014 18:21:14 -0800 (PST)
Received: from iMassi.local ([2001:67c:1231:998:2daf:6f04:992b:d693]) by with ESMTPSA id ft8sm2421452wjb.17.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 18:21:14 -0800 (PST)
Message-ID: <>
Date: Mon, 10 Nov 2014 16:21:10 -1000
From: "Dr. Massimiliano Pala" <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [TLS] [pkix] New version of the TLS feature draft
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Nov 2014 02:21:18 -0000

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.


> On Sep 18, 2014, at 4:38 AM, Nikos Mavrogiannopoulos <> 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