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

Stefan Santesson <stefan@aaa-sec.com> Thu, 20 February 2020 14:14 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 1AE241208A1 for <secdispatch@ietfa.amsl.com>; Thu, 20 Feb 2020 06:14:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Tp3cdtItJITQ for <secdispatch@ietfa.amsl.com>; Thu, 20 Feb 2020 06:14:41 -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 5A2621208AA for <secdispatch@ietf.org>; Thu, 20 Feb 2020 06:14:40 -0800 (PST)
Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id EAC9C2E4CAE6 for <secdispatch@ietf.org>; Thu, 20 Feb 2020 15:14:36 +0100 (CET)
Received: from s498.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id CC4E42E284E8 for <secdispatch@ietf.org>; Thu, 20 Feb 2020 15:14:36 +0100 (CET)
Received: from s473.loopia.se (unknown [172.22.191.6]) by s498.loopia.se (Postfix) with ESMTP id C85FB47085A for <secdispatch@ietf.org>; Thu, 20 Feb 2020 15:14:36 +0100 (CET)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s645.loopia.se ([172.22.191.5]) by s473.loopia.se (s473.loopia.se [172.22.190.13]) (amavisd-new, port 10024) with LMTP id hCLlGjnc483v for <secdispatch@ietf.org>; Thu, 20 Feb 2020 15:14:36 +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 s645.loopia.se (Postfix) with ESMTPSA id 05BD5156E555 for <secdispatch@ietf.org>; Thu, 20 Feb 2020 15:14:35 +0100 (CET)
User-Agent: Microsoft-MacOutlook/10.22.0.200209
Date: Thu, 20 Feb 2020 15:14:35 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: <secdispatch@ietf.org>
Message-ID: <D278B250-D85C-475B-B5B1-B9E4559CF0EC@contoso.com>
Thread-Topic: Signature Validation Token (SVT) - Request for time slot at secdispatch in Vancouver IETF
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3665056476_439323597"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/VhtsrzIyjDcXZYDT3e3p_aQlV9Y>
Subject: [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: Thu, 20 Feb 2020 14:14:48 -0000

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.

  

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