[Trans] Mail regarding draft-ietf-trans-rfc6962-bis

Aljoscha Meyer <research@aljoscha-meyer.de> Fri, 01 September 2023 17:29 UTC

Return-Path: <research@aljoscha-meyer.de>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9712EC15106B for <trans@ietfa.amsl.com>; Fri, 1 Sep 2023 10:29:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aljoscha-meyer.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxlOXl575sGB for <trans@ietfa.amsl.com>; Fri, 1 Sep 2023 10:29:11 -0700 (PDT)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5EFC14CE25 for <trans@ietf.org>; Fri, 1 Sep 2023 10:29:08 -0700 (PDT)
Received: by mail.gandi.net (Postfix) with ESMTPSA id 769951C0002 for <trans@ietf.org>; Fri, 1 Sep 2023 17:29:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aljoscha-meyer.de; s=gm1; t=1693589346; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=/hN5uWR0NoaD0DW4VYmhIMwUj6kDF2wYq7jXCxjv8bs=; b=pUWdLKsoGdxLQxFugmj6L10HMeLLwxJKE5UmwsYxj8S6x/rvc0OsgVY6b35LJP5DfZdiuY JH04w73MRxR5qe1GmXPLqL0ybV5rDGTeRSfpAjgexkNbiYGug8nJoYhFxu+oUSuaLQitqi PGew5khzgevdPOcajj99kecdvGkULx7WCRSCvLpcZk+Ayr6Zc1vEzIhl0yF/fGJqYLngAG lMWobC7ihWY+epoV8RVfc6YJ5JSRzI8cINfpXereeN9jvDxxTbjf9O2QEd/OalfTgrJRjf kS5e0PRMdFY0pZ+tB5VuomXczg2GItTuU7VQOmUVoQaN/DZavK3443TYXb71nA==
Message-ID: <4a0703f8-600e-416e-a06c-f81c68ea654c@aljoscha-meyer.de>
Date: Fri, 01 Sep 2023 19:29:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0
To: trans@ietf.org
Content-Language: en-US
From: Aljoscha Meyer <research@aljoscha-meyer.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-GND-Sasl: research@aljoscha-meyer.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/Xyqdf8lWmiT-o1X-8X6C2RqkTos>
X-Mailman-Approved-At: Mon, 04 Sep 2023 09:01:36 -0700
Subject: [Trans] Mail regarding draft-ietf-trans-rfc6962-bis
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Sep 2023 17:30:01 -0000

Dear WG for the Certificate Transparency RFC,

I want to point you to two (not yet peer-reviewed) paper drafts of mine 
that pertain to CT. The CT RFC and literature barely looks beyond Merkle 
trees, and is missing out on some interesting and efficient constructions.

The first paper frames append-only logs in a more general light, bridges 
the gap to the rich literature on secure timestamping, characterizes a 
graph class that contains Merkle-tree-based logs but also many other 
designs, and derive some efficiency criteria under which CT logs are 
less than ideal: https://arxiv.org/abs/2308.13836

The second paper proposes an alternate design that has shorter 
consistency proofs than CT, has constant-size inclusion proofs for item 
i from the i-th signed tree head (and twice as small inclusion proofs on 
average for arbitrary items from arbitrary STHs), and requires 
asymptotically less metadata: https://arxiv.org/abs/2308.15058

I'm not familiar with the ietf processes, and given the existing 
adoption of CT, there is probably little practical impact to be had. But 
at the very least I wanted to inform you of this material, and I'm happy 
to answer any question or hear about any faults it might have.

Kind regards,
Aljoscha