Re: [ltans] Archival of signed content

Carl Wallace <carl@redhoundsoftware.com> Mon, 06 November 2017 12:36 UTC

Return-Path: <carl@redhoundsoftware.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 62B6B13FB18 for <ltans@ietfa.amsl.com>; 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 <ltans@ietfa.amsl.com>; 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 <ltans@ietf.org>; Mon, 6 Nov 2017 04:36:24 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id w5so7620658ywg.11 for <ltans@ietf.org>; 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 <carl@redhoundsoftware.com>
To: Glen Vermeylen <glen.vermeylen@gmail.com>, <ltans@ietf.org>
Message-ID: <D625C005.A3E4F%carl@redhoundsoftware.com>
Thread-Topic: [ltans] Archival of signed content
References: <CANrgx4-G1md1uEsRtex4Vvv61MtdwBS-1Hfb-435zK2=3+Y8pg@mail.gmail.com> <D6225E68.A3D28%carl@redhoundsoftware.com> <D6247039.A3DCF%glen.vermeylen@gmail.com>
In-Reply-To: <D6247039.A3DCF%glen.vermeylen@gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3592798582_6785412"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ltans/kQBa677CPIMNPIf8M8FlneMWW6w>
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 12:36:32 -0000

Inlineā€¦

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

>     
>  
> 
> Thanks for your response,
>  
> 
> 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, 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
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 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.

[CW] I never cared for repeatedly preserving the same stuff, 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
>