Re: [ltans] Archival of signed content

Glen Vermeylen <glen.vermeylen@gmail.com> Mon, 06 November 2017 20:38 UTC

Return-Path: <glen.vermeylen@gmail.com>
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 EA4DE13FB1F for <ltans@ietfa.amsl.com>; Mon, 6 Nov 2017 12:38:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 OZVGTtoFfrGO for <ltans@ietfa.amsl.com>; Mon, 6 Nov 2017 12:38:40 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C78113FAE5 for <ltans@ietf.org>; Mon, 6 Nov 2017 12:38:40 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id b9so16897147wmh.0 for <ltans@ietf.org>; Mon, 06 Nov 2017 12:38:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.80.226.8 with SMTP id n8mr22260368edl.177.1510000718692; Mon, 06 Nov 2017 12:38:38 -0800 (PST)
Received: from [192.168.1.47] (ip-62-235-132-182.dsl.scarlet.be. [62.235.132.182]) by smtp.gmail.com with ESMTPSA id l9sm8942411edi.31.2017.11.06.12.38.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 12:38:38 -0800 (PST)
To: Tobias Gondrom <tobias.gondrom@gondrom.org>, ltans@ietf.org, Carl Wallace <carl@redhoundsoftware.com>
References: <CANrgx4-G1md1uEsRtex4Vvv61MtdwBS-1Hfb-435zK2=3+Y8pg@mail.gmail.com> <09d901d35625$2ef2f750$8cd8e5f0$@gondrom.org>
From: Glen Vermeylen <glen.vermeylen@gmail.com>
Message-ID: <4f741e1d-8fcc-acd8-df0e-ca8828b5fea5@gmail.com>
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$@gondrom.org>
Content-Type: multipart/alternative; boundary="------------CA431A5F4566E22E4CFD8E95"
Content-Language: nl
Archived-At: <https://mailarchive.ietf.org/arch/msg/ltans/RkelHBnRZlsSfKacqwWt7_xgAGA>
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: 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 [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.
>