Re: [ltans] Archival of signed content

Glen Vermeylen <> Mon, 06 November 2017 20:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA4DE13FB1F for <>; Mon, 6 Nov 2017 12:38:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OZVGTtoFfrGO for <>; Mon, 6 Nov 2017 12:38:40 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C78113FAE5 for <>; Mon, 6 Nov 2017 12:38:40 -0800 (PST)
Received: by with SMTP id b9so16897147wmh.0 for <>; Mon, 06 Nov 2017 12:38:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=wUY66y0qjsp84Fr733wo1M6hoUnrFuvBPMjbAW7U7+U=; b=ia7aq5wDC8XQJg/xVsIQoPpacEfGAfJb7xYlLR/GipIeaXjhnbiFEZc+3fQ5jMtjoa Qnid7XWmgERil9s4gX+SXjREw5aAcEIKWacJwB1UJGE1kGApvJ9YDx2995hsvxo1kFNu 8G9tzhHwD0isWa93fhIaoBFQfmytLWLjopR+AbWVBnoK29wLIHTEE0UhRVh600yynsDc avb8WxqrD0e/glRJruJkrbP7wfLItOrlFA3Tzv+t1Bjn5t8uYReGTTXeHCawVILM8Ujt pOqH803fLUjFjCwZSQOAaLF8/JjuKNnge9dyxSBerpwy1VkoVIEi6nvEpsuG20OzOoMN tBMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=wUY66y0qjsp84Fr733wo1M6hoUnrFuvBPMjbAW7U7+U=; b=Y2d6sAO3C5SJ5VYmq0i9L0bCoRsHc3rdp87syfI2muJ6nuYHPJ06ht5y6GhPH1U20X xNtnGlsyIxoMfADtS7W2EH95bCDgpYA+7e6acn0wegzvyetd6ftg8HBgjsWwtsiJMWtk P4//yT/xsY9x4Vbz6BZDn9eaq9A5VqxJsZ1JgutZML9ku3zUNhBBtRh6K7cgDcVYX5Qp RKNWETpGQmucQBXGRqAaewq9xSzYDnZqHTvtpeEXIvi9cAoOEB2sTAmXnRIBcgtr3HpD kfUyEwoT8D9drhEMz6tNVLnsCwri3mXSuIsf0OnHzNxHeLprPgClB0MKNRIPRgti06d9 dWuw==
X-Gm-Message-State: AMCzsaVXNzAeSP8QemvHi9td1FCiV7qpELU7oPtOIgm8YByTwclPOezQ U6SA2vSA1Rbth+V+HhAzmfqZbTgm
X-Google-Smtp-Source: ABhQp+SfT9MMHlCQ8rLXVdpb3Lp3Jx7XRbAXxwGacavkeKs4ZD+U7j+FvKDSH5lgpeWef/1eE7OqXQ==
X-Received: by with SMTP id n8mr22260368edl.177.1510000718692; Mon, 06 Nov 2017 12:38:38 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id l9sm8942411edi.31.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 12:38:38 -0800 (PST)
To: Tobias Gondrom <>,, Carl Wallace <>
References: <> <09d901d35625$2ef2f750$8cd8e5f0$>
From: Glen Vermeylen <>
Message-ID: <>
Date: Mon, 6 Nov 2017 21:38:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <09d901d35625$2ef2f750$8cd8e5f0$>
Content-Type: multipart/alternative; boundary="------------CA431A5F4566E22E4CFD8E95"
Content-Language: nl
Archived-At: <>
Subject: Re: [ltans] Archival of signed content
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: LTANS Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Nov 2017 20:38:43 -0000

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 [] *On Behalf Of *Glen 
> Vermeylen
> *Sent:* Saturday, October 28, 2017 12:20 AM
> *To:*
> *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.