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

From: Stefan Santesson <[email-masked]>
Date: Thu, 20 Feb 2020 15:14:35 +0100

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 25 Feb 2020 17:24:38 -0800

On Thu, Feb 20, 2020 at 03:14:35PM +0100, Stefan Santesson wrote:
> All previous attempts to address long term validation of electronically signed documents provide very complex solutions, such as the ETSI AdES profiles..
> 

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

> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 26 Feb 2020 11:11:52 +0100

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" <[email-masked] on behalf of [email-masked]> wrote:

    -Ben