Closed QuenzelGISBAU closed 8 years ago
To my knowledge, there are two ways to solve this other than two separate files:
1) Envelope: The XML is signed, which means it is no pure XML anymore. The signature data needs to be removed first, then the XML can be processed. 2) Insertion: The signature is calculated, but then inserted in the XML. After taking it out of the XML, signature checks are possible.
Due to the processing of the XML, option 2 may be sensitive to XML formatting of the processor because signatures usually work on text (i.e., they consider spaces or the difference between <tag></tag> and <tag/>). Thus my preference is creating an envelope.
If the envelope approach is used, this is no modification of the XML definition, but a procedural question. IMHO this should be discussed in the SDScom steering committee. Please comment.
Unfortunately I forget where, but I recently encountered an example of a signature embedden in XML, so option 2 (Insertion) is a proven concept, thus back in the race again and probably preferred because it still allows working with an XML file only.
But if the concept is PDF/A3 with embedded XML, there is another option: 3) Does a signed PDF/A3 file sign the PDF content only, or the PDF content with all containers (attachments)? If the latter, the XML is signed if the PDF is signed, without any XML changes.
Any experts on electronic signatures out there?
PAdES is an European standard for PDF signatures that is getting some traction. Part 5 addresses embedded XML documents: XAdES (PAdES for XML Content).
I haven't used XAdES yet but it seems that the signature is embedded in the XML document.
Especially interesting are the formats with support for long-term validation (LTV). They embed all information required for signature validation (signed timestamps etc.) into the document, so it can be still verified e.g. 10 years from now (even if the certificate was revoked or no longer available).
I have briefly looked into http://www.etsi.org/deliver/etsi_ts/102700_102799/102778/01.01.01_60/ and XAdES, but this is way over my head. The features sound very interesting, but I think we need either someione with practical experience, or tools which support this for average programmers. So I propose to postpone this until either is available.
For Java I found https://github.com/luisgoncalves/xades4j (Presentation: https://prezi.com/06vyxbgohncv/xades4j-en/), but even with library support it's certainly a complex topic.
Workshop in Hamburg: Authentication, Signing, encryption etc should be handles on a different level and not be treated as part of the XML. Closed as out of scope.
It should be possible to sign SDSComXML files. This is important both for the recipient of the file and the sender. The receiving party has to have a way to be sure of the source of the data and the sender has to be sure his data can not be altered and passed along under his name.
As far as I understand signing the XML file is not possible without the addition of a second file at the moment.