[ltans] Archival of signed content

Glen Vermeylen <glen.vermeylen@gmail.com> Fri, 27 October 2017 16:20 UTC

Return-Path: <glen.vermeylen@gmail.com>
X-Original-To: ltans@ietfa.amsl.com
Delivered-To: ltans@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D960613EDE3 for <ltans@ietfa.amsl.com>; Fri, 27 Oct 2017 09:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YpwkW_2bCZml for <ltans@ietfa.amsl.com>; Fri, 27 Oct 2017 09:20:28 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 2C0A71389E6 for <ltans@ietf.org>; Fri, 27 Oct 2017 09:20:28 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id w197so11655241oif.6 for <ltans@ietf.org>; Fri, 27 Oct 2017 09:20:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UyrXZKDO2NPI6Kz6KlkDqopBEnmUcOIELvqh/Yq1WpE=; b=dhPDEahvTI3ZLy5xLp1bDQBkKXaZkZ+NU6LfEOG75r3fgPcDvPNT/s+qzXZ6uqCH24 gIkXxdyv8iCT9UJ2Tl0/DhXbpPzWL/MIKGM9hr0VKcLplsMQtHxg8nQ+pYsw+/DMbRgz 4byXEoCwMci/lMqKIuSnRu2O6NOYC7xUXgDBJ0b/B7xB8n9t8j6vMJD/Uziv3tStY5TP mCjR5Nej2zA1gjDbd53HcUe/4yt5VMZ+qDtbZosjlxLa4Dbu/OXN80L03Qlqdzgiq5hD Na8Ln027yHBbmIud8haeO+v8K2aOmpA40bDP1aywFPAbJqy4B2jO6riP4yCF88awKeQX Trfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UyrXZKDO2NPI6Kz6KlkDqopBEnmUcOIELvqh/Yq1WpE=; b=NZFcW/8hQNfRzKFLDgvUTw9bULjYnD+gm7c6KiyZBvfgiFCTzVgpNZXkXhFVXOMbDb acizP2JQkRVODzVoTiivzatzoNzDgS2UuKazshqiIDV/QHH93B21wWAu/d2BoSlQ3Gzo 1OCc8j8eboXVQtWXreXebpDVhncTEtK54QvbHU7JaT2UN38gN+ADIo9Kl50eDmcYQFAq EhxKRwsy+fFoW0RcosZF56GtUMySpnY7RTyBIf1yqE54V2K20G1j/46VB1fbr12kvxsZ rBHYh190k/z/3O31YVZ39ZKI9q17bEpwzuFBzO4v6tZjMlc13mw7vwyDUlqw2/tqgvS1 Yw6g==
X-Gm-Message-State: AMCzsaVf4dWcCLey7EnpNkeT0ZZhl2DcZ4LbUtGDirZlAaJEHqiIGHZ9 sGHdTwS6zFvChPt/0cM0yNP4OjwiCs/4BgkjKfo=
X-Google-Smtp-Source: ABhQp+Rom7jmceWBJ+AqUWXbIm5ZrPtgVOrIdD56HEqiPc3pDBapTp8sGZf0ks1E3Nfske2rtaiGyPwvqGvnR+8tfAk=
X-Received: by with SMTP id q23mr623735otb.180.1509121227074; Fri, 27 Oct 2017 09:20:27 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 27 Oct 2017 09:20:26 -0700 (PDT)
From: Glen Vermeylen <glen.vermeylen@gmail.com>
Date: Fri, 27 Oct 2017 18:20:26 +0200
Message-ID: <CANrgx4-G1md1uEsRtex4Vvv61MtdwBS-1Hfb-435zK2=3+Y8pg@mail.gmail.com>
To: ltans@ietf.org
Content-Type: multipart/alternative; boundary="001a113cd4dca9b222055c89aa3d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ltans/8MRDOB2Q_doS7It2ZyilLcNs_wA>
Subject: [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: Fri, 27 Oct 2017 16:20:33 -0000


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

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