IETF Logo Mail Archive

[TLS] Re: Ambiguity of TLS Certificate Compression (RFC 8879)

Kazu Yamamoto <kazu@iij.ad.jp> Fri, 30 January 2026 08:58 UTC

Return-Path: <kazu@iij.ad.jp>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 9C2DBAF5A66B for <tls@mail2.ietf.org>; Fri, 30 Jan 2026 00:58:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=iij.ad.jp
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZY22Lri2FQ2 for <tls@mail2.ietf.org>; Fri, 30 Jan 2026 00:58:45 -0800 (PST)
Received: from omgo.iij.ad.jp (mo1120.iij.ad.jp [202.232.173.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 70838AF5A649 for <tls@ietf.org>; Fri, 30 Jan 2026 00:58:45 -0800 (PST)
DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:In-Reply-To:References:Mime-Version:Content-Type: Content-Transfer-Encoding;i=kazu@iij.ad.jp;s=20250414.omgo;t=1769763523;x= 1770973123;bh=xTez7YqGtrufFi+G8l6V7TsyhEHvNxMJ36qEDBsY7nw=;b=K2GQmITqxQc9GLSa dVKRwWPOE4WPXzp05z9HG+FSEeZCsoFZ5Jz955qZcIDWHH01qVgT9jQPVyi2z4YP6JdBjJt+4ki2X QrapXNer42Aouofhjxonat+5EOSrnapjQ9Vt9iAELg/KFPLF+63rtDyu+upByo4QEFdYJmHjRSL6O MVnZ54x0crZq/8JW0gUsefbtJYnx8EqQ+L65c11wj6Si22Wrl5lf4EQvF5HgCKmnqHd2ITAZL+D7M bQspPJqiY5b1XECos2wBTdDD9tX42FZd5nJmXg40nELcI1YqLQI7ZHwOK7YlF4UkNU7QW3j3tZZNA 6gVxyP6SohsqTJPnxg==;
Received: by omgo.iij.ad.jp (of-mo1120) id 60U8whkA1829489; Fri, 30 Jan 2026 17:58:43 +0900
X-ENVID: IIJ
X-Iguazu-Qid: C8OKNQ29nmcUsYt0Bk
X-Iguazu-QSIG: v=2; s=0; t=1769763523; q=C8Oiyzpq3Q71bZEz0i; m=45Y6YWDXKtRnrDbbLFCu9oV8DV+8xzBD671QQQejNMo=
Date: Fri, 30 Jan 2026 17:58:42 +0900
Message-Id: <20260130.175842.2291594055613731968.kazu@iij.ad.jp>
To: tls@ietf.org
From: Kazu Yamamoto <kazu@iij.ad.jp>
In-Reply-To: <cefc1df7-d500-4902-8321-4351223eb5c3@betaapp.fastmail.com>
References: <20260130.124640.484427558490648192.kazu@iij.ad.jp> <CAF8qwaAcWWVFbe8sOwnE5hu-+xEEpEoQr1Tk4z2uR+xZ8VLeVQ@mail.gmail.com> <cefc1df7-d500-4902-8321-4351223eb5c3@betaapp.fastmail.com>
X-Mailer: Mew version 6.10 on Emacs 31.0.50
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: FXBSBZRR6QRBIGKRUXYKHFI5OGU5HNZT
X-Message-ID-Hash: FXBSBZRR6QRBIGKRUXYKHFI5OGU5HNZT
X-MailFrom: kazu@iij.ad.jp
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Ambiguity of TLS Certificate Compression (RFC 8879)
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iXJSaBdJA9idrZz7a5DnxX8gg60>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

> Suggestion:
> 
>>  After decompression, the Certificate message MUST be processed as
>>  if it were encoded without being compressed, with the exception of
>>  the handshake transcript. The CompressedCertificate message is
>>  hashed into the handshake transcript (Section whatever of [TLS])
>>  in place of a Certificate message.

I support this errata.

--Kazu

v2.46.0 | Report a Bug | By Email | System Status