From nobody Fri Nov 3 14:59:21 2017 Return-Path: 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 CF38313FFED for ; Fri, 3 Nov 2017 14:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 aW0I9Dye80u3 for ; Fri, 3 Nov 2017 14:59:18 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 BCD4513FEF8 for ; Fri, 3 Nov 2017 14:59:15 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id y23so4910201qkb.10 for ; Fri, 03 Nov 2017 14:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=FW5+RA2PeOpGvQ34vb5RKqHE8dwJaC5+EwG6rWcW2OA=; b=S17hT5Qs3oQegKKhjnxOXlcs5e6PsO6JVImJOZHPwjkP3UTdGeP0nO1D/KS8fRo7IC Asqcgk04ziYuCIScbQ87XQRmQDkaDTrwflgkK2i9Mr2hF1yJsJMzLY77gUyKeS6BixHP NQI6A3HV+tURnwKY5zTs+e6Ih41Z2hKF98+U0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=FW5+RA2PeOpGvQ34vb5RKqHE8dwJaC5+EwG6rWcW2OA=; b=L/QORtdD9prU0dxY9oSnc4xdosPIqMxPy9ZAZ+C5L3C8BEmXiU4vrLZo86M6Wm1X9a b7ySqGUEqz4aewkbr51I9wQUC20YiJ3xq0TCK73dVuPc/gkhgzFxv6AeDEb+EGQcP1gY b0k/eQdPBfsOM+ELAmZJyzu9LPubVCzzf8xKo1PKwHR2JJoqpCAyr6Sww09A5KyBdv5L sd/kyzEhXO8Sq860m73yUpbJJWB7ttdfMNlLOJM4bvComucgqDBYr9JZBcCi6Fz5C0HE QTXOrT5mvWmTH0PhGvhA5fUtU3Xrp+lXh5zvFbXEpFrug0kSEw62fyvwS4imq7+FLLme eJJw== X-Gm-Message-State: AJaThX7oamdrAfhPO+PpIlTQG6W+xKAKq86NGgOCN9op0m6VzFA7iwxr o3KNWfw6tOaWutDkd+obQJoRLQ== X-Google-Smtp-Source: ABhQp+QHHGdDQtyVDEQPDiSMg6IxzeotHAi92aPIWQf/zuTAvXHDLJZSmOS07/3ZJTEsw70RvtmpNw== X-Received: by 10.55.77.67 with SMTP id a64mr11234955qkb.172.1509746354920; Fri, 03 Nov 2017 14:59:14 -0700 (PDT) Received: from [10.65.104.59] ([64.94.31.206]) by smtp.googlemail.com with ESMTPSA id h21sm4759340qte.72.2017.11.03.14.59.11 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 03 Nov 2017 14:59:14 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Fri, 03 Nov 2017 17:59:06 -0400 From: Carl Wallace To: Glen Vermeylen , Message-ID: Thread-Topic: [ltans] Archival of signed content References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3592576753_5807798" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 21:59:20 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3592576753_5807798 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit 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 > ltans@ietf.org https://www.ietf.org/mailman/listinfo/ltans --B_3592576753_5807798 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
RFC 5276 was the notion for p= reserving PKI artifacts. Preserve those once.

From: ltans <ltans-bounces@ietf.org> on behalf of Glen Vermeylen <glen.vermeylen@gmail.com>
Date: Friday, October 27, 2017 at 12:20 PM=
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 qu= estion .

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 lon= g term proof must be maintained.
However rfc6283 seems to onl= y describe the datastructure for maintaining the evidence of the initial and= subsequent archivetimestamps, meaning providing revocation info on any sign= ing 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 m= ultiple steps:

* stage any archive objects for LTA = + provide info on signing certificates (specify file type or provide certifi= cates + chain info or ....)
* at start of inital Ha= shTree creation, obtain full chain + revocation info for each signed dataobj= ect, and add this to the archive object
plus side on this is that = for identical signing certificates on many dataobjects (this is my case), th= ese revocation infos can be obtained once and cached
* Create + timestamp HashTree
* From then on, the process for r= e-timestamping and hashtree renewal can be followed as described in the spec= .



From this follo= ws 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 struct= ure

Is this understanding correct?
Many thanks,
Glen Vermeylen.
_______________________________________________ ltans mailing list ltans@ietf.org https://www.ietf.org/= mailman/listinfo/ltans
--B_3592576753_5807798-- From nobody Sat Nov 4 02:54:58 2017 Return-Path: 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 ; 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 ; 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 ; Sat, 4 Nov 2017 02:54:53 -0700 (PDT) Received: by mail-wm0-x232.google.com 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; 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 , ltans@ietf.org References: From: Glen Vermeylen 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: Content-Type: multipart/alternative; boundary="------------654B460F1F85840A124BCD86" Content-Language: nl Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 09:54:56 -0000 This is a multi-part message in MIME format. --------------654B460F1F85840A124BCD86 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 > > 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 > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans > --------------654B460F1F85840A124BCD86 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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> on behalf of Glen Vermeylen <glen.vermeylen@gmail.com>
Date: Friday, October 27, 2017 at 12:20 PM
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.
_______________________________________________ ltans mailing list ltans@ietf.org https://www.ietf.org/mailman/listinfo/ltans

--------------654B460F1F85840A124BCD86-- From nobody Sun Nov 5 02:59:50 2017 Return-Path: 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 4385C13FAC9 for ; Sun, 5 Nov 2017 02:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.org 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 tN7gDrPeg38M for ; Sun, 5 Nov 2017 02:59:47 -0800 (PST) Received: from gondrom.org (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698E713FC56 for ; Sun, 5 Nov 2017 02:59:47 -0800 (PST) Received: from seraph (69-172-65-098.static.imsbiz.com [69.172.65.98]) by gondrom.org (Postfix) with ESMTPSA id 749246536C; Sun, 5 Nov 2017 11:59:42 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=4v9CnZ7YAAGCg1xP3d6AALBn3iud0GjB8cYtSB7jtuLbb/GIyRBN6CcR3kvEGldUMu3KgCzTZt7226t/o7AEIHwm2QT5nfn1pyza9Jq78o8A+Cum8DQT7b98XGVjA3iTE0v9yqwOV4OpNRfqe78t1YI5c/Lnx7vu9UlHEHcX2SA=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; From: "Tobias Gondrom" To: "'Glen Vermeylen'" , References: In-Reply-To: Date: Sun, 5 Nov 2017 18:59:38 +0800 Message-ID: <09d901d35625$2ef2f750$8cd8e5f0$@gondrom.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09DA_01D35668.3D19E0D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH2TtVB7e9Hkz8aAnhFKbEiTyU246K/pkCg Content-Language: en-us Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 10:59:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_09DA_01D35668.3D19E0D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree with Carl.=20 Some additional comments:=20 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.=20 At the time of verification all verification objects must be available = and their integrity over the whole time must be guaranteed by the = XMLERS.=20 =20 My 2cents from the work a long time ago.=20 =20 Best wishes, Tobias =20 Ps.: and in fact happy to hear that it is used.=20 =20 =20 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 =20 Hello, =20 On the off-chance that aynone still reads this list, I may as well ask = my question . =20 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? =20 If this is the case, it seems the archival process consists of multiple = steps: =20 * 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=20 * Create + timestamp HashTree * From then on, the process for re-timestamping and hashtree renewal can = be followed as described in the spec. =20 =20 =20 >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 =20 Is this understanding correct? =20 Many thanks, Glen Vermeylen. ------=_NextPart_000_09DA_01D35668.3D19E0D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

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.

------=_NextPart_000_09DA_01D35668.3D19E0D0-- From nobody Mon Nov 6 04:36:34 2017 Return-Path: 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 62B6B13FB18 for ; Mon, 6 Nov 2017 04:36:32 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (1024-bit key) header.d=redhoundsoftware.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 1I4ps7prm6B0 for ; Mon, 6 Nov 2017 04:36:30 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 BD2EE13FC08 for ; Mon, 6 Nov 2017 04:36:24 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id w5so7620658ywg.11 for ; Mon, 06 Nov 2017 04:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=M8bZBXWLMWX7Da/IvQ8uRrzirMOkH6+UcwFBKGuKHUQ=; b=ctfLPJe5p/d1D3ZMIZ0MWRO0saWrsYorlkBX0mRcxgRZX/Hsg0jO5XeDxW23VKY5Rz y1Su6m5UG36TmYCJE1IR9qZO9WKXbBvMzESubthfiPs1BMOpDa+/OktF02zbTFrPdLed qxbvGFHYjIPEXi6xllczqSxnSqoefWDaoM9Sc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=M8bZBXWLMWX7Da/IvQ8uRrzirMOkH6+UcwFBKGuKHUQ=; b=IKczW0GnZ66DpwyfCyEwRpzkFAtNipFBoz3/OgZm2UFPhZM8YIfvtChDSALN2L5dMI D4fbpaDtx6LAyesrJkn8ZyXa237xP2qEF+lj0bYvFRE0lxyO8AVnKZvtAa7aHZY94Gko LDIUgoeOr3FmH4IiG9RKyPY6Qde2VEbpy9tfKYhvhDmmCZcje7dRkzF549r7UBwVc/ro gJJ8hEC07odpBV5lqHRJz40fskYMbocSawJNl++O6qI/FEWFPOciJc14uruZIIZW/wTd hy1/DMFv9/NkqRgNpMp3xwIHvMaVx4er+Sfo0jbIU1bZHh8KQAudDKrrcDbq7w9bsHpx gIig== X-Gm-Message-State: AMCzsaVj4sFmwMlf0sLRTNmH5aFz+y14BrKB4BQ7pzz/qNhxxMqRVIV6 TsDQQLaL7UBRJLGFxyrl6biNIA== X-Google-Smtp-Source: ABhQp+R8GusOK6XzDVlEwjvYWfbrfdxfZRk5W4KT5h9NAtcoOiivnzDAGCTssNHAgTjorqsEILOa3A== X-Received: by 10.129.156.72 with SMTP id t69mr10247216ywg.279.1509971783771; Mon, 06 Nov 2017 04:36:23 -0800 (PST) Received: from [50.95.117.209] ([50.95.117.209]) by smtp.googlemail.com with ESMTPSA id q7sm5918443ywh.41.2017.11.06.04.36.20 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 06 Nov 2017 04:36:23 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Mon, 06 Nov 2017 07:36:16 -0500 From: Carl Wallace To: Glen Vermeylen , Message-ID: Thread-Topic: [ltans] Archival of signed content References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3592798582_6785412" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 12:36:32 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3592798582_6785412 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Inline=E2=80=A6 From: Glen Vermeylen Date: Saturday, November 4, 2017 at 4:54 AM To: Carl Wallace , Subject: Re: [ltans] Archival of signed content > =20 > =20 >=20 > Thanks for your response, > =20 >=20 > SCVP is interesting on its own, but it seems no open source (server) > implementation exists? [CW] I don't know of any, and I've only seen one fielded version of RFC5276 at all. There are some open source client SCVP implementations kicking around. Part of the problem is that SCVP failed to be adopted in any broad way. Ideally, validating a certificate from the distant past complete with evidence records would have been the same process as validating a current certificate. That was the aim anyway. > 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...) [CW] RFC5276 is compatible with any scenario where you validate an X.509 certificate. It's a (relatively) small addition to the server-based processing of 5280 path validation. > + It seems that if an open source implementation for rfc5276 existed, th= ere > likely would exist an implementation for its prerequisite rfc4998. [CW] To check all of the various pieces, you are looking at > 3 specs in an= y case. But I get your point and do not disagree. 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 th= e 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. [CW] I never cared for repeatedly preserving the same stuff, but it works too, if potentially heavier for storage/maintenance/usage. =20 Kind regards, Glen =20 =20 Op 3-11-2017 om 22:59 schreef Carl Wallace: =20 =20 > =20 > RFC 5276 was the notion for preserving PKI artifacts. Preserve those once= . > =20 >=20 > =20 > =20 > From: ltans on behalf of Glen Vermeylen > > Date: Friday, October 27, 2017 at 12:20 PM > To: > Subject: [ltans] Archival of signed content > =20 > =20 >=20 > =20 > =20 >> =20 >> Hello,=20 >>=20 >> =20 >> =20 >> On the off-chance that aynone still reads this list, I may as well ask m= y >> question . >> =20 >>=20 >> =20 >> =20 >> 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 scop= e? >> =20 >> 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. >> =20 >> However rfc6283 seems to only describe the datastructure for maintaining= the >> evidence of the initial and subsequent archivetimestamps, meaning provid= ing >> revocation info on any signing certificates is to be decided by the >> implementor. Or am I missing something obvious? >> =20 >> =20 > =20 >> =20 >> =20 >>=20 >> =20 >> =20 >> If this is the case, it seems the archival process consists of multiple >> steps: >> =20 >>=20 >> =20 >> =20 >> * stage any archive objects for LTA + provide info on signing certificat= es >> (specify file type or provide certificates + chain info or ....) >> =20 >> =20 >> * at start of inital HashTree creation, obtain full chain + revocation i= nfo >> for each signed dataobject, and add this to the archive object >> =20 >> plus side on this is that for identical signing certificates on many >> dataobjects (this is my case), these revocation infos can be obtained on= ce >> and cached=20 >> =20 >> =20 >> * Create + timestamp HashTree >> =20 >> * From then on, the process for re-timestamping and hashtree renewal can= be >> followed as described in the spec. >> =20 >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >> From this follows that a validator of an EvidenceRecord for an ArchiveOb= ject >> must obtain >> =20 >> * All dataobjects, including the revocation info ( in a proprietary form= at ? >> Any suggestions on this?) >> =20 >> =20 >> * EvidenceRecord xml structure >> =20 >> =20 >>=20 >> =20 >> =20 >> Is this understanding correct? >> =20 >>=20 >> =20 >> =20 >> Many thanks, >> =20 >> Glen Vermeylen. >> =20 >> =20 >> _______________________________________________ ltans mailing list >> ltans@ietf.org https://www.ietf.org/mailman/listinfo/ltans > =20 =20 =20 --B_3592798582_6785412 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Inline…

<= /div>
From: Glen Vermeylen <glen.vermeylen@gmail.com>
Date: Saturday, November 4, 2017 at 4:54 AMTo: Carl Wallace <carl@redhoundsoftware.com>, <ltans@ietf.org>
Subject: Re: [ltans] Archival of signed content
<= br>

Thanks for your response,

SCVP is interesting on its own, but it seems no open source (server) implementation exists?

<= div>[CW] I don't know of any, and I've only seen one fielded version of RFC5= 276 at all. There are some open source client SCVP implementations kicking a= round. Part of the problem is that SCVP failed to be adopted in any broad wa= y. Ideally, validating a certificate from the distant past complete with evi= dence records would have been the same process as validating a current certi= ficate. That was the aim anyway.

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

[CW] R= FC5276 is compatible with any scenario where you validate an X.509 certifica= te.  It's a (relatively) small addition to the server-based processing = of 5280 path validation.
=

+ It seems that if an open source implementation for rfc5276 existed, there likely would exist an implementation for its prerequisite rfc4998.

[CW] To= check all of the various pieces, you are looking at > 3 specs in any cas= e. But I get your point and do not disagree.

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  structur= es as dataobjects to enrich the original archive object.

[CW] I never cared for repeatedly preserving the same stuf= f, but it works too, if potentially heavier for storage/maintenance/usage.


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> on behalf of Glen Vermeylen <glen.vermeylen@gmail.com>
Date: Friday, October 27, 2017 at 12:20 PM
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.
_______________________________________________ ltans mailing list ltans@ietf= .org https://www.ietf.org/mailman/listinfo/ltans

--B_3592798582_6785412-- From nobody Mon Nov 6 12:38:44 2017 Return-Path: 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 ; 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 ; 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 ; Mon, 6 Nov 2017 12:38:40 -0800 (PST) Received: by mail-wm0-x235.google.com 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; 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 , ltans@ietf.org, Carl Wallace References: <09d901d35625$2ef2f750$8cd8e5f0$@gondrom.org> From: Glen Vermeylen 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 20:38:43 -0000 This is a multi-part message in MIME format. --------------CA431A5F4566E22E4CFD8E95 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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. > --------------CA431A5F4566E22E4CFD8E95 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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.


--------------CA431A5F4566E22E4CFD8E95-- From nobody Wed Nov 8 23:36:03 2017 Return-Path: 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 A2FDD12EC01 for ; Wed, 8 Nov 2017 23:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.711 X-Spam-Level: X-Spam-Status: No, score=0.711 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.org 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 l0FJx0HtG4qs for ; Wed, 8 Nov 2017 23:35:59 -0800 (PST) Received: from gondrom.org (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E544C12EC56 for ; Wed, 8 Nov 2017 23:35:57 -0800 (PST) Received: from seraph (unknown [112.97.57.214]) by gondrom.org (Postfix) with ESMTPSA id 2FA1865140; Thu, 9 Nov 2017 08:35:53 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=317JmXXco3zVxaL/AdIOFnDKxBSImubGgkOG8eJqk4tXX9/l5QMPjLELpAt61QTyfgCU577vT1mzFrmGIyuTPXLEqEuE8rClir1wSpWfXO0Fmb1OrMMNUPOIisrMjY/yAVXsRnAMGVt476ZYW0YTrD7YeVaL8i5zxPhkcXjI/EI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; From: "Tobias Gondrom" To: "'Glen Vermeylen'" , , "'Carl Wallace'" References: <09d901d35625$2ef2f750$8cd8e5f0$@gondrom.org> <4f741e1d-8fcc-acd8-df0e-ca8828b5fea5@gmail.com> In-Reply-To: <4f741e1d-8fcc-acd8-df0e-ca8828b5fea5@gmail.com> Date: Thu, 9 Nov 2017 15:35:50 +0800 Message-ID: <017801d3592d$602cde70$20869b50$@gondrom.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0179_01D35970.6E5611E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH2TtVB7e9Hkz8aAnhFKbEiTyU24wEypJ7tAZhLp2Wir2OYwA== Content-Language: en-us Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 07:36:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0179_01D35970.6E5611E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, you are correct. We anticipated this case of needing addition = supporting evidence for verification back then.=20 Seems digital signatures never took off in the amount we expected back = then.=20 One worry from then was the replacement for SHA-1 and RSA-1024 or 2048 = and others=E2=80=A6 But seems that timestamps and signatures are less important for = long-term verification than we expected 15 years ago=E2=80=A6 Tobias =20 From: Glen Vermeylen [mailto:glen.vermeylen@gmail.com]=20 Sent: Tuesday, November 7, 2017 4:39 AM To: Tobias Gondrom ; ltans@ietf.org; Carl = Wallace Subject: Re: [ltans] Archival of signed content =20 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=20 - 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.=20 Some additional comments:=20 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.=20 At the time of verification all verification objects must be available = and their integrity over the whole time must be guaranteed by the = XMLERS.=20 =20 My 2cents from the work a long time ago.=20 =20 Best wishes, Tobias =20 Ps.: and in fact happy to hear that it is used.=20 =20 =20 From: ltans [mailto:ltans-bounces@ietf.org] On Behalf Of Glen Vermeylen Sent: Saturday, October 28, 2017 12:20 AM To: ltans@ietf.org =20 Subject: [ltans] Archival of signed content =20 Hello, =20 On the off-chance that aynone still reads this list, I may as well ask = my question . =20 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? =20 If this is the case, it seems the archival process consists of multiple = steps: =20 * 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=20 * Create + timestamp HashTree * From then on, the process for re-timestamping and hashtree renewal can = be followed as described in the spec. =20 =20 =20 >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 =20 Is this understanding correct? =20 Many thanks, Glen Vermeylen. =20 ------=_NextPart_000_0179_01D35970.6E5611E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Yes, you are correct. We anticipated this = case of needing addition supporting evidence for verification back then. =

Seems digital signatures never took off in = the amount we expected back then.

One worry from then = was the replacement for SHA-1 and RSA-1024 or 2048 and = others=E2=80=A6

But seems that timestamps and signatures are = less important for long-term verification than we expected 15 years = ago=E2=80=A6

Tobias

 

From: Glen Vermeylen = [mailto:glen.vermeylen@gmail.com]
Sent: Tuesday, November 7, = 2017 4:39 AM
To: Tobias Gondrom = <tobias.gondrom@gondrom.org>; ltans@ietf.org; Carl Wallace = <carl@redhoundsoftware.com>
Subject: Re: [ltans] = Archival of signed content

 

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.

 

------=_NextPart_000_0179_01D35970.6E5611E0--