Re: [ltans] Archival of signed content

"Tobias Gondrom" <tobias.gondrom@gondrom.org> Sun, 05 November 2017 10:59 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 4385C13FAC9 for <ltans@ietfa.amsl.com>; Sun, 5 Nov 2017 02:59:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 tN7gDrPeg38M for <ltans@ietfa.amsl.com>; Sun, 5 Nov 2017 02:59:47 -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 698E713FC56 for <ltans@ietf.org>; Sun, 5 Nov 2017 02:59:47 -0800 (PST)
Received: from seraph (69-172-65-098.static.imsbiz.com [69.172.65.98]) by gondrom.org (Postfix) with ESMTPSA id 749246536C; Sun, 5 Nov 2017 11:59:42 +0100 (CET)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=4v9CnZ7YAAGCg1xP3d6AALBn3iud0GjB8cYtSB7jtuLbb/GIyRBN6CcR3kvEGldUMu3KgCzTZt7226t/o7AEIHwm2QT5nfn1pyza9Jq78o8A+Cum8DQT7b98XGVjA3iTE0v9yqwOV4OpNRfqe78t1YI5c/Lnx7vu9UlHEHcX2SA=; 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>
References: <CANrgx4-G1md1uEsRtex4Vvv61MtdwBS-1Hfb-435zK2=3+Y8pg@mail.gmail.com>
In-Reply-To: <CANrgx4-G1md1uEsRtex4Vvv61MtdwBS-1Hfb-435zK2=3+Y8pg@mail.gmail.com>
Date: Sun, 5 Nov 2017 18:59:38 +0800
Message-ID: <09d901d35625$2ef2f750$8cd8e5f0$@gondrom.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_09DA_01D35668.3D19E0D0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH2TtVB7e9Hkz8aAnhFKbEiTyU246K/pkCg
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/ltans/ctTfFbFOxzHrwfY-V9VsHtXpiQo>
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: Sun, 05 Nov 2017 10:59:49 -0000

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
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.