Re: [Secdispatch] Signature Validation Token (SVT) - Request for time slot at secdispatch in Vancouver IETF

Benjamin Kaduk <> Mon, 02 March 2020 01:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D2033A0DF1 for <>; Sun, 1 Mar 2020 17:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4dDi9K-1Z9wI for <>; Sun, 1 Mar 2020 17:40:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C4493A0DED for <>; Sun, 1 Mar 2020 17:40:48 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 0221eZs2023664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 1 Mar 2020 20:40:37 -0500
Date: Sun, 1 Mar 2020 17:40:35 -0800
From: Benjamin Kaduk <>
To: Stefan Santesson <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [Secdispatch] Signature Validation Token (SVT) - Request for time slot at secdispatch in Vancouver IETF
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Mar 2020 01:40:52 -0000

On Wed, Feb 26, 2020 at 11:11:52AM +0100, Stefan Santesson wrote:
> Hi,
> Great question!
> We have not yet identified any reason to create any mechanisms within the present specification even though we recognize that this concept could be supported by external mechanisms such as block chaining and hash trees etc.
> However. I'm more than willing to discuss whether anything should be added to the specifications.
> The basic claim and idea is that storing a claim from a trusted authority that a particular certificate was valid at a certain point in time is no different from storing a claim that the whole signature was valid at a certain point in time.
> This change of how things are done (from the former to the latter) do however have an extreme positive effect on the simplicity of the solution.
> This is the only parameter that is fixed. Everything else can be discussed.

I think that our general trend is to recognize that very few things (e.g.,
the "trusted authority") behave perfectly and without error, and thus to
build in mechanisms to detect and/or recover from such failure when the
cost of doing so is not too great.  So I would welcome research into what
mechanisms are available and their cost, so as to assess whether the cost
is "too great".


> Stefan Santesson 
> On 2020-02-26, 02:25, "Secdispatch on behalf of Benjamin Kaduk" < on behalf of> wrote:
>     Are there any technical mechanisms (e.g., blockchain with periodic
>     timestamps) to mitigate the requirement to trust the validation/re-signing
>     service?  There are probably some solution sketches in the list archives
>     here or on saag ("merkle tree" might be a good search term).
>     -Ben