Re: [ltans] Archival of signed content

Glen Vermeylen <glen.vermeylen@gmail.com> Sat, 04 November 2017 09:54 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 473F113FB99 for <ltans@ietfa.amsl.com>; Sat, 4 Nov 2017 02:54:56 -0700 (PDT)
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 DApJrsLz5Jo1 for <ltans@ietfa.amsl.com>; Sat, 4 Nov 2017 02:54:54 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 6CBBB13FB92 for <ltans@ietf.org>; Sat, 4 Nov 2017 02:54:53 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id b9so5756065wmh.0 for <ltans@ietf.org>; Sat, 04 Nov 2017 02:54:53 -0700 (PDT)
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=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; 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=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 10.80.171.67 with SMTP id t3mr12088263edc.224.1509789291363; Sat, 04 Nov 2017 02:54:51 -0700 (PDT)
Received: from [192.168.1.47] (ip-62-235-85-175.dsl.scarlet.be. [62.235.85.175]) by smtp.gmail.com with ESMTPSA id d12sm5446589edh.40.2017.11.04.02.54.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Nov 2017 02:54:50 -0700 (PDT)
To: Carl Wallace <carl@redhoundsoftware.com>, ltans@ietf.org
References: <CANrgx4-G1md1uEsRtex4Vvv61MtdwBS-1Hfb-435zK2=3+Y8pg@mail.gmail.com> <D6225E68.A3D28%carl@redhoundsoftware.com>
From: Glen Vermeylen <glen.vermeylen@gmail.com>
Message-ID: <243ff309-ed42-bbb4-902e-109bf9a17d45@gmail.com>
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: <D6225E68.A3D28%carl@redhoundsoftware.com>
Content-Type: multipart/alternative; boundary="------------654B460F1F85840A124BCD86"
Content-Language: nl
Archived-At: <https://mailarchive.ietf.org/arch/msg/ltans/5UVS0Ec5q1ldEWmsRv775jyo-Fs>
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: 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 
implement...)
+ 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,
Glen

Op 3-11-2017 om 22:59 schreef Carl Wallace:
> RFC 5276 was the notion for preserving PKI artifacts. Preserve those once.
>
> From: ltans <ltans-bounces@ietf.org <mailto:ltans-bounces@ietf.org>> 
> on behalf of Glen Vermeylen <glen.vermeylen@gmail.com 
> <mailto:glen.vermeylen@gmail.com>>
> Date: Friday, October 27, 2017 at 12:20 PM
> To: <ltans@ietf.org <mailto: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 mailing list
>     ltans@ietf.org <mailto:ltans@ietf.org>
>     https://www.ietf.org/mailman/listinfo/ltans 
>