This page documents build dependencies, bundled schema adaptations, interoperability testing, and certificate-validation behavior relevant to maintainers and advanced integrators.
Dependencies
Software libraries
Libdigidocpp library depends on the software libraries listed below.
OpenSSL (required) – Used for validating certificates and digest values.
libxml2 (required) – Used for validating the documents according to XML Schema, reading and writing XML.
xmlsec (required) – Used for handling signature related components.
ZLIB (required) – Used when compressing and extracting ASiC files in ZIP format.
Minizip (required) – Used when creating and opening ZIP container for ASiC file. If the component is not found from system then bundled version with source code is used. Forms a part of ZLIB component.
PKCS11 (optional) – Used for searching for default PKCS#11 driver in the system so that its path could be registered in configuration entries.
Doxygen (optional) – Used for generating API documentation from source code.
SWIG (optional) – Used for creating C#, Java, and Python bindings.
XML Schemas
Several XML schemas are used when creating digitally signed documents in ASiC file format and validating their structure. The schemas are included in etc/schema/ subdirectory of the Libdigidocpp distribution package, their description is given in the list below.
Note
Some modifications have been made to some of the schemas. Differences in comparison with the original schemas are listed in section XML schema modifications of the current document.
XAdES01903v141-201601.xsd – Defines XML syntax for additional elements of XAdES signatures that were added with version 1.4.1 of the (XAdES EN) standard. Used for XAdES archive time-stamps, including the ArchiveTimeStamp element. http://uri.etsi.org/01903/v1.4.1/XAdES01903v141-201601.xsd
ts_119612v020201_201601xsd.xsd, ts_119612v020101_additionaltypes_xsd.xsd, ts_119612v020101_sie_xsd.xsd – Defines the format of Trust Service status Lists (TSL) that contain information about trusted CA, OCSP and TSA certificates.
conf.xsd – Configuration properties’ schema. Defines the Libdigidocpp configuration file’s digidocpp.conf structure (see also Configuration guide).
The following figure describes dependencies between the abovementioned schemas (direction of the arrow indicates the direction of dependency).
Dependencies between XML Schemas
XML schema modifications
The following section describes modifications that have been made to XML schemas used in Libdigidocpp. The library uses several XML schemas when creating digitally signed documents and validating their structure. The schemas are included in etc/schema/ subdirectory of the Libdigidocpp distribution package, their description has been provided in section XML Schemas.
Modifications are marked between xml comment tags.
Schema en_31916201v010101.xsd
The schema’s location has been altered so that the imported schema file is looked up from the local file system.
The initial integer data type used in the original schema is converted into long data type when generating C++ source code from the current schema. However, as the SK issued certificates’ serial numbers are too long to fit into long type variable then the data type has been changed to string.
<complexTypename="X509IssuerSerialType">
<sequence>
<elementname="X509IssuerName"type="string"/>
<elementname="X509SerialNumber"type="string"/> <!-- originally type="integer" -->
</sequence>
</complexType>
Schema XAdES01903v132-201601.xsd
The schema’s location has been modified so that the file is looked up from the local file system.
Change child elements of type SignedSignaturePropertiesType from "xsd:sequence" to "xsd:all" in order to allow the child elements to be listed in any order.
Change child elements of type SignatureProductionPlaceType from "xsd:sequence" to "xsd:all" in order to allow the child elements to be listed in any order.
<!-- originally "http://uri.etsi.org/01903/v1.3.2/XAdES.xsd" -->
Online validation through SiVa
PDF files, legacy DDoc files and ASiC containers with CAdES signatures are not validated locally; the library sends them to the SiVa service. The document is base64-encoded into a JSON request together with its file name and the POLv4 signature policy, and posted to the URL configured with verify.serivceUri (see Signature Verify Service settings). When digidoc::ConfV4::verifyServiceCerts returns a non-empty list, those certificates are used as trust anchors for the TLS connection. The default list is empty. The whole request is built in memory, so its size grows with the document.
What is sent depends on the format:
PDF files and ASiC containers with CAdES signatures are sent in full, including the signed data files.
DDoc files are first sent in hashcode form: the content of each EMBEDDED_BASE64<DataFile> element is replaced with a SHA-1 digest of the canonicalized element, so the data file content is not sent. If SiVa answers with Bad digest for DataFile, the library repeats the request with the original DDoc, including the data file content. DDoc files whose data files are already in HASHCODE form are rejected.
An ASiC-S container whose only data file is a .ddoc file and whose only signature is an RFC 3161 time-stamp token can enclose a DDoc. When a callback is passed and allows online validation, the enclosed DDoc is sent to SiVa as described above. digidoc::Container::dataFiles then returns the DDoc's data files, and digidoc::Container::signatures returns the time-stamp token followed by the DDoc's signatures. Signatures cannot be removed while the enclosed DDoc is exposed. Without a callback, when online validation is not allowed, or when DDoc parsing or the SiVa request fails, the container is opened as a plain time-stamped ASiC-S container and the .ddoc file is its only data file. A SiVa report that marks a DDoc signature invalid still exposes that signature and its validation errors.
Interoperability testing
DigiDoc framework cross-usability tests
Automated cross-usability tests of digitally signed and encrypted files are periodically carried out between different DigiDoc software libraries:
Cross-usability of ASiC-E file format with TS (time-stamp) profile is tested between DigiDoc4j and Libdigidocpp libraries.
The interoperability tests are executed through the command line utility tools of the software libraries (for example, in case of Libdigidocpp library, the utility program described on the digidoc-tool page).
Certificate validation behavior
For certificates used to validate commitment to signed content, ETSI EN 319 412-2 V2.4.1, clause 4.3.2, permits key-usage types A, B, and F and recommends type A. All three types include the "Non-repudiation" bit, also called "Content Commitment". Libdigidocpp normally uses this bit when selecting certificates for qualified electronic signature creation.
Signature can be created with a certificate that doesn’t have "Non-repudiation" value in its "Key-Usage" field when specific parameters have been set but validation of such signature will produce a respective error message and the signature is not considered as a qualified electronic signature.
During signature validation, it is checked that the validity periods of the signer’s certificate and all the certificates in its CA chain include the signature creation time (value of the time in TSA response or case time-mark profile producedAt field in OCSP response).
1.15.0