Subject: Re: [ltans] Archival of signed content

From: Carl Wallace <[email-masked]>
Date: Fri, 03 Nov 2017 17:59:06 -0400

RFC 5276 was the notion for preserving PKI artifacts. Preserve those once.

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

---

From: Glen Vermeylen <[email-masked]>
Date: Sat, 4 Nov 2017 10:54:51 +0100

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:
> From: ltans <[email-masked] <mailto:[email-masked]>> 
> on behalf of Glen Vermeylen <[email-masked] 
> <mailto:[email-masked]>>
> To: <[email-masked] <mailto:[email-masked]>>
>     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?
>
>
>     * 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
>     * 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?)
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/ltans 
>

---

From: "Tobias Gondrom" <[email-masked]>
Date: Sun, 5 Nov 2017 18:59:38 +0800

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:[email-masked]] On Behalf Of Glen Vermeylen
Sent: Saturday, October 28, 2017 12:20 AM
To: [email-masked]
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?

* 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 

* 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?)

Many thanks,

Glen Vermeylen.

---

From: Carl Wallace <[email-masked]>
Date: Mon, 06 Nov 2017 07:36:16 -0500

Inline…

From:  Glen Vermeylen <[email-masked]>
Date:  Saturday, November 4, 2017 at 4:54 AM
To:  Carl Wallace <[email-masked]>, <[email-masked]>
Subject:  Re: [ltans] Archival of signed content

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

[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:

>> collections of signed PDFs for which long term proof must be maintained.
>>  
>> dataobjects (this is my case), these revocation infos can be obtained once
>> and cached 
>>  
>>

---

From: Glen Vermeylen <[email-masked]>
Date: Mon, 6 Nov 2017 21:38:37 +0100

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:
> 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.
>
> *From:* ltans [mailto:[email-masked]] *On Behalf Of *Glen 
> Vermeylen
> *Sent:* Saturday, October 28, 2017 12:20 AM
> *To:* [email-masked]
> *Subject:* [ltans] Archival of signed content
>
> Hello,
>
> seems to me explicit support for long term archival of signed content 
> is out of scope?
>
> archivetimestamps, meaning providing revocation info on any signing 
> certificates is to be decided by the implementor.  Or am I missing 
> something obvious?
>
> 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
>
> dataobjects (this is my case), these revocation infos can be obtained 
> once and cached
>
> * From then on, the process for re-timestamping and hashtree renewal 
> can be followed as described in the spec.
>

---

From: "Tobias Gondrom" <[email-masked]>
Date: Thu, 9 Nov 2017 15:35:50 +0800

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…

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

Tobias

From: Glen Vermeylen [mailto:[email-masked]] 
Sent: Tuesday, November 7, 2017 4:39 AM
To: Tobias Gondrom <[email-masked]>; [email-masked]; Carl Wallace <[email-masked]>
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.

I agree with Carl. 

Best wishes, Tobias

 

From: ltans [mailto:[email-masked]] On Behalf Of Glen Vermeylen
Sent: Saturday, October 28, 2017 12:20 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [ltans] Archival of signed content

Hello,

 

Many thanks,

Glen Vermeylen.