Re: [TLS] ct_compliant cached info field

Martin Thomson <> Mon, 31 December 2018 06:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D316F1277CC for <>; Sun, 30 Dec 2018 22:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=UZ6XKsVG; dkim=pass (2048-bit key) header.b=WJJEaJqa
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TIm39Ou7SijU for <>; Sun, 30 Dec 2018 22:06:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 269E512008F for <>; Sun, 30 Dec 2018 22:06:22 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailnew.west.internal (Postfix) with ESMTP id 6C383139E for <>; Mon, 31 Dec 2018 01:06:21 -0500 (EST)
Received: from web3 ([]) by compute1.internal (MEProxy); Mon, 31 Dec 2018 01:06:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:date:subject:in-reply-to; s=fm1; bh=iic qVNq+IpRpM76htOKChbmfQnGZdkRGxRyewQMkoJs=; b=UZ6XKsVGZKfpkmD4Ty7 56OazLS0KI92LBf9iE5PCuBC9HWTBWfeAtx4kOX7Fp+krPCSBOPv2NGZbHP/UJXY nr0iMCfMDIt44vTZ4fhXbxMhr/NKf4fTA7mHUcIl3uu6dZ/wA90VJLVLOWYejmuv //4y7UMXk0QvjEHt9KMGgxrOWR3s03ONkFFyyZNJn/f7bcGCLSB+E9CjHoLm4kJu 7nONFwr9UwWXrp7LhgSri9D0SoG8AGKMy2/2WD7TVFlMfZMccrFPi/XnuWFkwUm+ YbtQCqNYPqGs6aI64mbncPQ0jNWrLXtMZ3pszrTk4j/W6K1IGT01SNWeaIBndKKS ICA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=iicqVNq+IpRpM76htOKChbmfQnGZdkRGxRyewQMko Js=; b=WJJEaJqa3DrcSrOwWNlVM632gXEwlaWoQ++DemRKgzuw1KVZrTgU16fcV yrGn0whYjkDelgQq1pPYUJyAk6/5culGcIQQOL776KKknJLOKsbM8ccamS8kI/Pr eDRMPSHk4p0JxBKfixA4vFPKbEeE4sZFOtSvTniJ9Jd2kGKupZXC07TxiVoVa9By 3lP0+8GoO2fHQXTUTqajfavXGLcAzZGIRl7wkWLL3nZ70v0WTvoGQgkJvXwHThCZ UI435PAsoxvkPLGYd8i9mdlJzAh+e2A2L+z0qWjkVXmBIdgYFr0Y9YSrLfCS1h5u M8VmYLlix/XaNrwv5sgbCe8Du2+1w==
X-ME-Sender: <xms:2rEpXLcJS8L-FBqcHzG8NzYf5gKivE1C4L9Tc5qCld2xtwuDPYmQ0g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddugdelvdculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucgoteefjeefqddtgeculdehtddmnecujfgurhepkf fhvfgggfgtofhffffujgesthejredtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhho mhhsohhnuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivg htfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:2rEpXN7nQ5szGv2UUPjDHvhBWYEx3qAZBvYN1EL0WYb10cPuDVt9Mw> <xmx:2rEpXNmCTr_hFW-aaG2eAcVJLHlm6KdZDqP0ID3Zrn5yw5vGuXOTIQ> <xmx:2rEpXB_aQC5wcitHxUc9-uJdNlmqBBAFipS7UwXE0Q6w1DqIt9OUuA> <xmx:2rEpXNgj9qpoKax1pdpEKJk4PyTXhu5oErng7X8JVkzImGTfZy_kcsonUEM>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 09D9A9E565; Mon, 31 Dec 2018 01:06:18 -0500 (EST)
Message-Id: <>
From: Martin Thomson <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: Webmail Interface - ajax-2f590f9a
References: <>
Date: Mon, 31 Dec 2018 17:06:17 +1100
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] ct_compliant cached info field
X-Mailman-Version: 2.1.29
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: Mon, 31 Dec 2018 06:06:24 -0000

On Fri, Dec 28, 2018, at 04:58, Eric Rescorla wrote:
> Please take a look at

At a minimum, this would seem to update cached_info.

There's not a lot of meat on this text.  It seems to be saying that if you are providing transparency_info, then you can provide a certificate other than any of the certificates that the client believes to be CT compliant.  Also, you don't provide "x509_sct_v2" or "precert_sct_v2" in transparency_info.

How is the client then able to determine that this new certificate is CT compliant?  Using  "inclusion_proof_v2" and "signed_tree_head_v2" (or one or other)?  If so, the text doesn't point in that direction.

There's a lot of "why" missing in this document.  Why would a client choose to indicate "ct_compliant"?  Why is cached_info being extended in this way?

I might guess that the reason here is that the draft aims to avoid including information that might change over time, which would render caches invalid.  Isn't that motivation to recommend an SCT over an STH?

Separately, why does this establish a new registry for signature schemes?  It is obviously trying to keep TLS compatibility, based on the codepoints, but forking the registry is a great way to create problems.