Re: [TLS] OCSP must staple

Yoav Nir <> Thu, 12 June 2014 21:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2C7841A0276 for <>; Thu, 12 Jun 2014 14:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7T-PvxXl6csD for <>; Thu, 12 Jun 2014 14:48:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 669B11A0282 for <>; Thu, 12 Jun 2014 14:48:48 -0700 (PDT)
Received: by with SMTP id r20so2367283wiv.10 for <>; Thu, 12 Jun 2014 14:48:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zzGvwPINri2d3NNJCMn3z8QZYvbArDWHcEe9DPJZjBo=; b=ZCtOwVd21wRx0Z+eMn38N7975Z2FPaHTm6bH60NZuE/xHNWbIzMXUVrAabdZ3vfUWw 5FHezA/NkDdCsuXj9EMV4Ks6fY1VddBF3I5DZor0IjE2uD1EeIg+yFyA60MDKt9ViPqm Gr/Y5Nhkq13m/zYBl1mmcVT6EXm4aDntrmlSDi6tKDdAm9cuTKD37Eu3RtLI+dB3BfLY 5WN8YWp6gLeKESw17kZeWYukV0jKbk/QCO4D7nkkh2O6vLRvnJRy8ccsTdAXsRSrDf5L YLCcxfuMDS+bVexRY85DEBnQLDMMTyRiZM27ZqExm4Kb/v/ehP5a7twjjh1qX1IKRfGe +9rg==
X-Received: by with SMTP id n1mr3018727wic.4.1402609726776; Thu, 12 Jun 2014 14:48:46 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id l45sm7318333eep.25.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 14:48:46 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Fri, 13 Jun 2014 00:48:42 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <097101cf7aa7$17f960a0$47ec21e0$> <> <> <> <> <> <> <> <> <> <>
To: Kurt Roeckx <>
X-Mailer: Apple Mail (2.1878.2)
Cc: "<>" <>
Subject: Re: [TLS] OCSP must staple
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: Thu, 12 Jun 2014 21:48:53 -0000

On Jun 12, 2014, at 9:39 PM, Kurt Roeckx <> wrote:

> On Thu, Jun 12, 2014 at 12:02:40PM +0300, Yoav Nir wrote:
>> Hi, Brian
>> Interesting stuff. Also good to hear that it's easy to implement, although mileages vary.
>> Regarding TLS proxies, I can give my perspective, as I work for one vendor. 
>> <hat type="vendor" status="on">
>> Our fake certificates contain the DNs and alternate names from the original certificate. We don't copy over any extensions that we don't understand. The same is also true of TLS - we don't copy extensions we don't know. That is what allows our proxy to gracefully downgrade HTTP/2 or SPDY clients and gateways to HTTP/1.
>> As for dates, these *are* copied from the original certificate, the reason is that this makes the client behavior similar to whatever it is with the original certificate. We did consider making the certificates short-lived, but decided against it. 
>> </hat>
> I'm wondering if it also strips things it doesn't know but are
> marked critical.

For the server-side half of the connection, a proxy acts as a client, or in certificate terminology, a relying party. If there’s a critical extension it doesn’t understand, it rejects the certificate, and never even gets to the stage of creating a fake certificate.

So there’s the big set of certificate extension, a proper subset of this that are the extensions that the product understands, and a proper subset of that, which are the extensions that it copies.