XML Signature Settings
In the XML Signature Settings dialog (screenshot below), you can specify the default certificate/password to be used for the signature, where the signature will be placed, transformation options, whether certificate key information is saved with the XML file, etc. The individual settings are described below.
Authentication method: certificate or password
The signature can be based on a certificate or a password. Select the radio button of the method you wish to use.
•Certificate: Click the Select button and browse for the certificate you want. The certificate you select must have a private key. The signature is generated using the private key of the certificate. For the signature to be verified subsequently, access to the certificate (or to a public-key version of it) is required. The public key of the certificate is used to verify the signature. For more details about certificates, see the section Working with Certificates. Alternatively, the certificate's key information can be saved with the signature by checking the Append Keyinfo check box at the bottom of the dialog. In this case, no certificate will be referenced for verifying the signature; the key information saved with the signature will be used. Note: StyleVision's XML Signature feature supports only certificates of type RSA-SHA1 and DSA-SHA1.
•Password: Enter a password with a length of five to 16 characters. This password will subsequently be required to verify the signature. Alternatively, the password can be saved with the SPS file. In this case, verification will be carried out directly, without Authentic Viewprompting for a password.
The certificate/password you specify will be the default for the signature.
Transformations
The XML data is transformed and the result of the transformation is used for the creation of the signature. You can specify the canonicalization algorithm to be applied to the file's XML data (the SignedInfo content) prior to performing signature calculations. Significant points of difference between the algorithms are noted below:
•Canonical XML with or without comments: If comments are included for signature calculation, then any change to comments in the XML data will result in verification failure. Otherwise, comments may be modified or be added to the XML document after the document has been signed, and the signature will still be verified as authentic. The Comments option is available for detached signatures and is disabled for enveloped signatures.
•Base64: The root (or document) element of the XML document is considered to be Base64 encoded, and is read in its binary form. If the root element is not Base64, an error is returned or the element is read as empty.
•None: No transformation is carried out and the XML data from the binary file saved on disk is passed directly for signature creation. Any subsequent change in the data will result in a failed verification of the signature. However, if the Strip Whitespace check box option is selected, then all whitespace is stripped and changes in whitespace will be ignored. A major difference between the None option and a Canonicalization option is that canonicalization produces an XML data stream, in which some differences, such as attribute order, are normalized. Consequently, a canonicalization transformation will normalize any changes such as that of attribute order (so verification will succeed), while no-transformation will reflect such a change (verification will fail). Note, however, that a default canonicalization is performed if the signature is embedded (enveloped). So the XML data will be used as is (i.e. with no transformation), when the signature is detached, None is selected, and the Strip Whitespaces checkbox is unchecked.
Signature placement
The signature can be placed within the XML file or be created as a separate file. The following options are available:
•Enveloped: The signature element is created as the last child element of the root (document) element.
•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 (for example, test.xml.xsig), or (ii) the extension replacing the XML extension of the XML file (for example, test.xsig). You can also specify whether, in the signature file, the reference to the XML file is a relative or an absolute path.
Append key information
The Append Keyinfo option is available when the signature is certificate-based. It is unavailable if the signature is password-based.
If the option is selected, public-key information is placed inside the signature, otherwise 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 (since the key information is present in the signature).