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

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