Re: [ltans] Archival of signed content

"Tobias Gondrom" <tobias.gondrom@gondrom.org> Sun, 05 November 2017 10:59 UTC

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, 05 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"
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
Precedence: list

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.

[ltans] Archival of signed content Glen Vermeylen
Re: [ltans] Archival of signed content Carl Wallace
Re: [ltans] Archival of signed content Glen Vermeylen
Re: [ltans] Archival of signed content Tobias Gondrom
Re: [ltans] Archival of signed content Carl Wallace
Re: [ltans] Archival of signed content Glen Vermeylen
Re: [ltans] Archival of signed content Tobias Gondrom