Re: [ltans] Archival of signed content

"Tobias Gondrom" <tobias.gondrom@gondrom.org> Thu, 09 November 2017 07:36 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: ltans@ietfa.amsl.com
Delivered-To: ltans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FDD12EC01 for <ltans@ietfa.amsl.com>; Wed, 8 Nov 2017 23:36:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.711
X-Spam-Level:
X-Spam-Status: No, score=0.711 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.org
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 l0FJx0HtG4qs for <ltans@ietfa.amsl.com>; Wed, 8 Nov 2017 23:35:59 -0800 (PST)
Received: from gondrom.org (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E544C12EC56 for <ltans@ietf.org>; Wed, 8 Nov 2017 23:35:57 -0800 (PST)
Received: from seraph (unknown [112.97.57.214]) by gondrom.org (Postfix) with ESMTPSA id 2FA1865140; Thu, 9 Nov 2017 08:35:53 +0100 (CET)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=317JmXXco3zVxaL/AdIOFnDKxBSImubGgkOG8eJqk4tXX9/l5QMPjLELpAt61QTyfgCU577vT1mzFrmGIyuTPXLEqEuE8rClir1wSpWfXO0Fmb1OrMMNUPOIisrMjY/yAVXsRnAMGVt476ZYW0YTrD7YeVaL8i5zxPhkcXjI/EI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language;
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
To: 'Glen Vermeylen' <glen.vermeylen@gmail.com>, ltans@ietf.org, 'Carl Wallace' <carl@redhoundsoftware.com>
References: <CANrgx4-G1md1uEsRtex4Vvv61MtdwBS-1Hfb-435zK2=3+Y8pg@mail.gmail.com> <09d901d35625$2ef2f750$8cd8e5f0$@gondrom.org> <4f741e1d-8fcc-acd8-df0e-ca8828b5fea5@gmail.com>
In-Reply-To: <4f741e1d-8fcc-acd8-df0e-ca8828b5fea5@gmail.com>
Date: Thu, 09 Nov 2017 15:35:50 +0800
Message-ID: <017801d3592d$602cde70$20869b50$@gondrom.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0179_01D35970.6E5611E0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH2TtVB7e9Hkz8aAnhFKbEiTyU24wEypJ7tAZhLp2Wir2OYwA==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/ltans/iMklQB8Etn2nYHWmUhbKh__jTI8>
Subject: Re: [ltans] Archival of signed content
X-BeenThere: ltans@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: LTANS Working Group <ltans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ltans>, <mailto:ltans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ltans/>
List-Post: <mailto:ltans@ietf.org>
List-Help: <mailto:ltans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltans>, <mailto:ltans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Nov 2017 07:36:01 -0000

Yes, you are correct. We anticipated this case of needing addition supporting evidence for verification back then. 

Seems digital signatures never took off in the amount we expected back then. 

One worry from then was the replacement for SHA-1 and RSA-1024 or 2048 and others…

But seems that timestamps and signatures are less important for long-term verification than we expected 15 years ago…

Tobias

 

From: Glen Vermeylen [mailto:glen.vermeylen@gmail.com] 
Sent: Tuesday, November 7, 2017 4:39 AM
To: Tobias Gondrom <tobias.gondrom@gondrom.org>; ltans@ietf.org; Carl Wallace <carl@redhoundsoftware.com>
Subject: Re: [ltans] Archival of signed content

 

Thanks Carl and Tobias;

After your input I realized I did overlook the EvidenceRecord/SupportingInformationList element.
This can indeed be used for storing Objects containing, for each non-timestamp-protected signature:

- SignatureProperties (xml structure akin to the relevant Xades-XL UnsignedSignatureProperties children)
    - CertificateValues 
    - RevocationValues
- EvidenceRecord over this SignatureProperties element

This type would still be somewhat proprietary, but the processing rules remain quite sane and the original ArchiveObject remains unaltered.

ps: Unfortunately xmlers is not really being used except as a personal research project for learning PKI, but I'll notify this mailing list once/if minimal has been achieved.
The idea is to support at least EvidenceRecord generation / validation, timestamping config (tsa and re-timestamping ), digestmethod policies (forcing hashtree renewal) and ingestion of signed content as the topic of this mail.

kind regards, Glen.

Op 5-11-2017 om 11:59 schreef Tobias Gondrom:

I agree with Carl. 

Some additional comments: 

You could add supporting verification information (revocation records, certificates to the root, etc.) into data records or equally as data objects in the tree and protect them thus as well. 

At the time of verification all verification objects must be available and their integrity over the whole time must be guaranteed by the XMLERS. 

 

My 2cents from the work a long time ago. 

 

Best wishes, Tobias

 

Ps.: and in fact happy to hear that it is used. 

 

 

From: ltans [mailto:ltans-bounces@ietf.org] On Behalf Of Glen Vermeylen
Sent: Saturday, October 28, 2017 12:20 AM
To: ltans@ietf.org <mailto:ltans@ietf.org> 
Subject: [ltans] Archival of signed content

 

Hello,

 

On the off-chance that aynone still reads this list, I may as well ask my question .

 

I'm making a preliminary implementation of the XMLERS spec and it seems to me explicit support for long term archival of signed content is out of scope?

What I mean by this that I have a relative large and rapid growing collections of signed PDFs for which long term proof must be maintained.

However rfc6283 seems to only describe the datastructure for maintaining the evidence of the initial and subsequent archivetimestamps, meaning providing revocation info on any signing certificates is to be decided by the implementor.  Or am I missing something obvious?

 

If this is the case, it seems the archival process consists of multiple steps:

 

* stage any archive objects for LTA + provide info on signing certificates (specify file type or provide certificates + chain info or ....)

* at start of inital HashTree creation, obtain full chain + revocation info for each signed dataobject, and add this to the archive object

plus side on this is that for identical signing certificates on many dataobjects (this is my case), these revocation infos can be obtained once and cached 

* Create + timestamp HashTree

* From then on, the process for re-timestamping and hashtree renewal can be followed as described in the spec.

 

 

 

>From this follows that a validator of an EvidenceRecord for an ArchiveObject must obtain

* All dataobjects, including the revocation info ( in a proprietary format ? Any suggestions on this?)

* EvidenceRecord xml structure

 

Is this understanding correct?

 

Many thanks,

Glen Vermeylen.