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

Stefan Santesson <stefan@aaa-sec.com> Wed, 26 February 2020 10:12 UTC

Return-Path: <stefan@aaa-sec.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8923A1218 for <secdispatch@ietfa.amsl.com>; Wed, 26 Feb 2020 02:12:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lh9RBKbljjbT for <secdispatch@ietfa.amsl.com>; Wed, 26 Feb 2020 02:12:00 -0800 (PST)
Received: from smtp2.outgoing.loopia.se (smtp2.outgoing.loopia.se [93.188.3.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F2E3A1217 for <secdispatch@ietf.org>; Wed, 26 Feb 2020 02:11:59 -0800 (PST)
Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 4A91F2E7B598 for <secdispatch@ietf.org>; Wed, 26 Feb 2020 11:11:54 +0100 (CET)
Received: from s499.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id 2C1542E27BC2; Wed, 26 Feb 2020 11:11:54 +0100 (CET)
Received: from s470.loopia.se (unknown [172.22.191.6]) by s499.loopia.se (Postfix) with ESMTP id 2580A1CDAF0F; Wed, 26 Feb 2020 11:11:54 +0100 (CET)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s499.loopia.se ([172.22.191.6]) by s470.loopia.se (s470.loopia.se [172.22.190.10]) (amavisd-new, port 10024) with UTF8LMTP id VloNa0TZP148; Wed, 26 Feb 2020 11:11:53 +0100 (CET)
X-Loopia-Auth: user
X-Loopia-User: mailstore2@aaa-sec.com
X-Loopia-Originating-IP: 85.235.7.89
Received: from [192.168.2.38] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s499.loopia.se (Postfix) with ESMTPSA id 9F83C1CDAF09; Wed, 26 Feb 2020 11:11:53 +0100 (CET)
User-Agent: Microsoft-MacOutlook/10.22.0.200209
Date: Wed, 26 Feb 2020 11:11:52 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: <secdispatch@ietf.org>
Message-ID: <C7E500BB-1788-427F-9184-38728F7F9515@aaa-sec.com>
Thread-Topic: [Secdispatch] Signature Validation Token (SVT) - Request for time slot at secdispatch in Vancouver IETF
References: <D278B250-D85C-475B-B5B1-B9E4559CF0EC@contoso.com> <20200226012438.GM56312@kduck.mit.edu>
In-Reply-To: <20200226012438.GM56312@kduck.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/87SOMmjnJ2OE3ipG2hrL726wJEA>
Subject: Re: [Secdispatch] Signature Validation Token (SVT) - Request for time slot at secdispatch in Vancouver IETF
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 10:12:02 -0000

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.

Stefan Santesson 

On 2020-02-26, 02:25, "Secdispatch on behalf of Benjamin Kaduk" <secdispatch-bounces@ietf.org on behalf of kaduk@mit.edu> 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