[SANTUARIO-615] Implementation pre-post processing extension with xades (basic) example.

[jrihtarsic]

The purpose of this PR is to present the proposals [SANTUARIO-615] for the pre/post processor for the signatures.
The use case is the request for XAdES support as requested in SANTUARIO-402 and SANTUARIO-416. The use-case already supports (Basic Signatures profile) and (with the right certificate) it pass the validation by EC DSS tool:
https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/validation

Please note that for "composing" the "XAdES" data, the generated jaxb objects are used from the xades scheme v1.4.1 and v1.3.2.

This is a experimental PR to discuss/verify the following architectural approaches for the XAdES:

• the pre-post processing design pattern for signing (Is the approach accepted, in example is used one interface, or it wold be better to have each own for pre and post processing,.. )
• use of jaxb generated objects with jakarta.xml.bind.(Marshaller|Unmarshaller).Currently xmlsec is using internal jaxb implementation using ElementProxy for some parts and for others DOMStructure/XMLStructure both with with internal/own/(non generated) "jaxb" object.

[jrihtarsic]

Hi @coheigea
Does closing this PR mean that the xmlsec library is not in favor to support the XAdES extension (There are two open tickets asking for this SANTUARIO-416, SANTUARIO-402) for XML signatures, or was it closed specifically because it relies on the JAXB approach?

[coheigea]

@jrihtarsic Sorry, I thought the PR was abandoned. How complete is the existing PR? It needs to be rebased off the latest code.

[jrihtarsic]

@coheigea Before updating the code, I’d like to briefly discuss the implementation approach.

The main change in this PR is the introduction of pre‑ and post‑signature processor interfaces (see XMLSignature and SignatureProcessor).
The design is intentionally generic so it can support extensions like XAdES, which adds metadata before signing and timestamps afterward. This approach also enables more experimental use cases, such as recording hashes on a ledger and placing verification ledger url as part of signature.

My first question is whether the pre‑ and post‑signature processor interfaces look acceptable to you, and whether you see any potential security risks in this approach. From development perspective it would be a great addition.

Regarding XAdES
I suggest placing XAdES in a separate extension module rather than the core xmlsec codebase—though I’m unsure about the best location. But If we keep XAdES inside xmlsec, I have one question:
Should we continue using JAXB for building the XAdES structures, or should we switch to custom DOM handlers to stay consistent with xmlsec’s internal XML construction?