Re: [ltans] Archival of signed content

Glen Vermeylen <> Sat, 04 November 2017 09:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 473F113FB99 for <>; Sat, 4 Nov 2017 02:54:56 -0700 (PDT)
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 DApJrsLz5Jo1 for <>; Sat, 4 Nov 2017 02:54:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6CBBB13FB92 for <>; Sat, 4 Nov 2017 02:54:53 -0700 (PDT)
Received: by with SMTP id b9so5756065wmh.0 for <>; Sat, 04 Nov 2017 02:54:53 -0700 (PDT)
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=Uyfk3DlWH1IPJoxJwkVWEZdEwtbOeIVtxmvMF6NSzPM=; b=dq5xCCuFRrk7i4YrNXtuKfe1hdCOn2lLYmliZFCpe8c6TSyAJ/dSdfHT7CMhI2+2OF WVK3nhnfh+S8U3KlcQhbeqdFJdWAzlH7NpOsVKXeu79/XXu56bsxvh3lxJaZkWIOR9uF jEscSBq50KuSjMF1+S++IIZ/S0EO1hIDf5x+F7xeJJRco+7LRjK1nmYVx2Hvrhsm6gge 9Wc7ZCEIirSSYKbs7fiBIagevf5U3Fouzy0ffU7i8dzdhOC8EH3hHmv8P4sbwfS1bMKP WLaqiYulHurUEdWXlhdg6zfKjQE0WCdYMim2cjnNg7ES7SBWqlwO51GBhlCNcOSi7xau r2hg==
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=Uyfk3DlWH1IPJoxJwkVWEZdEwtbOeIVtxmvMF6NSzPM=; b=CrVcr2+/o/K6wDdZ97gOHiydtM2gJs14pfi3oT7JnDtXzX2trmnICUSilNDpVwuY/B SBrdNG3KEdcSgELUcUIjRVC4bJtSuqdBP+0XGqpyMe/PyFOQNDrVu8eVu1TTJy893B1H YnyqYFldQgfO+x265lnwJIjpXO8k06oiFWGNQUx6xwEpmq+fNdfQVl3zR6inloXczspk GZed+iDFfeL9THlbGYYVvu8bc8HQZaeWYjOsSJmbD8qEsQKnRYi7aeM62HKmcdET0SmU mhbdRBUZLF6HwLXHIGUEJ58jAP5jYJSmRWkj0LL579KqDswe7gzO09XPI27U091sQ+KI apSA==
X-Gm-Message-State: AMCzsaWXlp76TlAdTDqTCghNMmuGgYN0AC2kKDoZxe+UAGXJYgoEMN2G 5h5KRHJYAwfJtka5wZEtJV6z7Ksb
X-Google-Smtp-Source: ABhQp+SoTKz7CyOjlcOBQ8zuieDdMdoGJYa4fPa9L1xtABpR1DG5Kgk+CeWjTKyqHwgcfkI0lqraew==
X-Received: by with SMTP id t3mr12088263edc.224.1509789291363; Sat, 04 Nov 2017 02:54:51 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id d12sm5446589edh.40.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Nov 2017 02:54:50 -0700 (PDT)
To: Carl Wallace <>,
References: <> <>
From: Glen Vermeylen <>
Message-ID: <>
Date: Sat, 4 Nov 2017 10:54:51 +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: <>
Content-Type: multipart/alternative; boundary="------------654B460F1F85840A124BCD86"
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: Sat, 04 Nov 2017 09:54:56 -0000

Thanks for your response,

SCVP is interesting on its own, but it seems no open source (server) 
implementation exists? As I'm doing this as an after-hours open source 
project, additionally implementing rfc5055 is unrealistic.
Also, is rfc5276 compatible with rfc6283? It seems to describe a way to 
include rfc4998 structures in a svcp reply (now I have 3 specs to 
+ It seems that if an open source implementation for rfc5276 existed, 
there likely would exist an implementation for its prerequisite rfc4998.

I did doubt between using the idea of rfc5276 (maintaining separate 
evidence records for PKI artifacts) and what I described below 
(enriching archive object with all required info for non-repudiation).
I went with the latter as it would simplify processing and it resembles 
the notion of XADES-C where also all required info is included. In fact, 
I was thinking on reusing its CompleteCertificateRefs and  
CompleteRevocationRefs  structures as dataobjects to enrich the original 
archive object.

Kind regards,

Op 3-11-2017 om 22:59 schreef Carl Wallace:
> RFC 5276 was the notion for preserving PKI artifacts. Preserve those once.
> From: ltans < <>> 
> on behalf of Glen Vermeylen < 
> <>>
> Date: Friday, October 27, 2017 at 12:20 PM
> 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.
>     _______________________________________________ ltans mailing list
> <>