Altova MapForce 2025 Enterprise Edition

The signature can be based on a certificate or a password.

•Certificate: If you wish to use a certificate, the certificate must have a private key and be located in an accessible certificate store. The signature is generated using the private key of the certificate. To verify the signature, access to the certificate (or a public-key version of it) is required. The public key of the certificate is used to verify the signature. To select the private-public-key certificate you wish to use, click the Select button and browse for the relevant certificate.

•Password: Enter a password with a length of 5 to 16 characters. This password is used to create the signature and will be required to verify the signature. The OK button of the dialog box becomes active only if this requirement is fulfilled.

•Save password in MFD file: When active, the password entered in the Password field is encrypted and not human-readable. Note that anyone who has access to the MFD file can create signatures using this password.

The XML data is transformed, and the result of the transformation is used for the creation of the signature. You can specify the algorithm to be applied to the file's XML data (the SignedInfo content) prior to performing signature calculations. The following options are available:

•None: No transformation is carried out, the XML data from the binary file is saved on disk and passed directly for signature creation. Any subsequent change in the data will result in a failed verification of the signature. However, if the check box Strip whitespaces between XML elements is selected, all whitespaces will be stripped, and changes in whitespaces will be ignored.

•Canonical XML with/without comments: If comments are included for signature calculation, any change to comments in the XML data will result in verification failure. Otherwise, comments may be modified or added to the XML document after the document has been signed, and the signature will still be verified as authentic.

Note that the Canonical XML option with comments is available only in Detached placement.

•Base64: The root element of the XML document is considered to be Base64-encoded. If the root element is not Base64, an error is returned or the element is read as empty, depending on the type of element.

 
The difference between None and Canonical XML is that the second option produces an XML data stream, in which some differences, such as attribute order, are normalized. Note, however, that a default canonicalization is performed if the signature is embedded (enveloped). The XML data will be used as is (i.e., no transformation) when the following is true: (i) the signature is detached, (ii) None is selected, and (iii) the Strip whitespaces check box is not selected.

The following signature placement options are available:

•Enveloped: The signature element is created as the last child element of the root (document) element. For the output XML file to be valid, the associated XML schema must contain the signature definition elements.

•Detached: The XML signature is created as a separate file. In this case, you can specify the file extension of the signature file and whether the file name is created with (i) the extension appended to the name of the XML file (e.g., test.xml.xsig) or (ii) the extension replacing the XML extension of the XML file (e.g., test.xsig). You can also specify whether the signature file should have the reference to the XML file with a relative or an absolute path.

The Append Keyinfo option is available only when the signature is certificate-based. If Append KeyInfo is active/checked, public-key information is placed inside the signature. Otherwise the key information is not included in the signature. The advantage of including key information is that the certificate itself (specifically the public-key information in it) will not be required for the verification process, because the key information is present in the signature.