Re: [ltans] Archival of signed content

[Glen Vermeylen <[e-mail]>]

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 <[e-mail] <mailto:[e-mail]>> 
> on behalf of Glen Vermeylen <[e-mail] 
> <mailto:[e-mail]>>
> Date: Friday, October 27, 2017 at 12:20 PM
> To: <[e-mail] <mailto:[e-mail]>>
> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/ltans 
>