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

Benjamin Kaduk <kaduk@mit.edu> Wed, 26 February 2020 01:24 UTC

Return-Path: <kaduk@mit.edu>
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 923AE3A07BC for <secdispatch@ietfa.amsl.com>; Tue, 25 Feb 2020 17:24:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQSa6QcN3uCh for <secdispatch@ietfa.amsl.com>; Tue, 25 Feb 2020 17:24:53 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B4C5C3A07BB for <secdispatch@ietf.org>; Tue, 25 Feb 2020 17:24:50 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01Q1OdSR007044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Feb 2020 20:24:41 -0500
Date: Tue, 25 Feb 2020 17:24:38 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: secdispatch@ietf.org
Message-ID: <20200226012438.GM56312@kduck.mit.edu>
References: <D278B250-D85C-475B-B5B1-B9E4559CF0EC@contoso.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D278B250-D85C-475B-B5B1-B9E4559CF0EC@contoso.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/NI6Tx-A_lE_A218-DhE4Sagv2sc>
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 01:24:56 -0000

On Thu, Feb 20, 2020 at 03:14:35PM +0100, Stefan Santesson wrote:
> All,
> 
>  
> 
> I would like to request a timeslot at secdispatch at the next IETF meeting in Vancouver.
> 
>  
> 
> I would like to present the Signature Validation Token (SVT) effort as a potential standardization work within the IETF.
> 
>  
> 
> Current specifications for SVT are developed on GitHub as part of a Swedish Government Funded project to address the need to validate signed document in a distant future.
> 
> Current specifications are found here: https://docs.swedenconnect.se/technical-framework/index.html#sigval
> 
> The main document contains some more rationale for the work.
> 
>  
> 
> There specifications are supported by running code and by September 2020 we will provide a complete implementation as free open source code.
> 
>  
> 
> What’s new with SVT and why would the IETF be interested in this?
> 
>  
> 
> SVT address the problem of signature validation in the future. Even a distant future. This is currently an increasing real problem for which no standardization body has presented a good solution yet.
> 
>  
> 
> All previous attempts to address long term validation of electronically signed documents provide very complex solutions, such as the ETSI AdES profiles..
> 
> The basic approach has been to collect data and time stamps necessary to create a virtual “time machine” that can bring the verifier to a point in time in the past when the document was fresh and the signing certificate was valid and unrevoked.
> 
> The problem with this approach is that it creates exponential complexity over time to a point where the complexity destroys any reasonable chance to succeed to prove the validity.
> 
>  
> 
> The SVT is an extremely simple counterproposal with none of the complexity of the traditional solutions.
> 
>  
> 
> The idea is simple: Instead of providing tons of data making it possible to validate the original signature and signing certificate, provide one simple signed statement from a validation service that validated the documents when it was fresh.
> 
> This is captured in the Signature Validation Token (SVT). The SVT can be signed by a really secure signature and will have the data necessary to validate all claims of the original signature without relying on the original algorithms, etc.

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



>   
> 
> The interesting aspect of this approach is that the complexity is reduced to a small fraction of the traditional long-term-validation approaches tried before. A single token with a few KB of data, protected by just 1 signature is all you need.
> 
>  
> 
> The IETF could be interested for a number of reasons:
> 
>  
> IETF has done similar work in the past (LTANS and their evidence records)
> The token format is based on JWT from IETF
> The token could be used with IETF signature formats such as CMS and JOSE
> The proposed format is very simple and would not consume too much work (There is a lot of value with limited effort)
> No other standardization organization is doing anything in conflict with this effort
>  
> 
> I’m kind of expecting a lot of negative opinions due to the subject itself, but even if rejected, it would be valuable to get input from the IETF.
> 
> We are doing this project as research to gain experience and to evaluate if our claims are true and that it can fulfill all necessary legal requirements.
> 
> If this succeeds, it may have a large impact on the use and cost of electronic records in digital archives.
> 
>  
> 
> Best regards
> 
>  
> 
> Stefan Santesson
> 
>  
> 

> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch