Include Timestamp certificates and crls in TimeStampValidationData when extending to XAdES X-L

[gcontini]

ETSI TS 101 903 V1.4.2 section 8.1 :

The TimeStampValidationData element is an optional unsigned property qualifying the signature
...
This element is specified to serve as an optional container for validation data required for carrying a full verification of time-stamp tokens embedded within any of the different time-stamp containers defined in the present document.
...
The structure of xades:CertificateValues child is defined in clause 7.6.1. When present, it shall contain
certificates used in the full verification of time-stamp tokens embedded in one XAdES time-stamp container....

The structure of xades:RevocationValues child is defined in clause 7.6.2. When present, it shall contain the
revocation information used in the full verification of time-stamp tokens embedded in one XAdES time-stamp container ...

Xades4j doesn't include TimeStampValidationData when extending a XAdES document to XAdES X-L

[luisgoncalves]

I think this feature falls into a broader set of features/refactorings needed to better support extended forms. The library has some well-known design limitations (see older issues) that probably make those refactorings almost a rewrite of many parts. This is not something I'll tackle right away.

[gcontini]

Yes I agree the modification isn't easy, unfortunately I inherited some code that use your library extensively and i was asked to upgrade it to support XAdES X-L... At this stage adding the support will be less expensive than replacing it.

We're keeping our modifications open source, as per LGPL requirement. Maybe they won't be beautiful but we must complete the feature somehow.
We'll be very glad if our modifications will make it to the official release one day. :-)

[luisgoncalves]

I understand. It will be nice to see your mods anyway and we may discuss some aspects here if you want/need. Development has been kind of stalled, but I hope to bring this back on track (maybe with some help?) soon enough.

I'm not sure if you'd also need to support X-L on verification. Anyway, here are some things I remember from previous discussions with other folks:

• At some point it may be required to know which type of certificate is being validated or have multiple certificate validation providers.
• The verification process needs to collect and make available the different certificate chains resulting from validation.
• Verification may need some sort of 2-pass or incremental-pass approach so that validation data (e.g. CertificateValues) can be collected prior to verifying other properties (e.g. timestamps).

[sayat2002]

How can I sign with XAdES X-L format? Is there any approach? I tried to patch libraries with patches found in the web but many errors occured in my project.

[luisgoncalves]

@sayat2002 there's no supported way to directly sign to X-L. However, it is possible to extend a XAdES-C signature to XAdES -X-L upon verification, given the limitations described in this issue.

https://github.com/luisgoncalves/xades4j/wiki/SignatureEnrichment

Regarding the existing patches, they are scattered among multiple issues and some override others... It would require some work to find yout which ones should be applied and on which order.

[luisgoncalves]

Probably handled by #55 which has been recovered and submitted in #146.