Re: [ltans] Archival of signed content

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
>   