XML Signature API has a configuration file storing the settings for signature creation and verification. The configuration file contains proxy settings, timestamp server settings, resolver interfaces, default algorithms, and validation settings.
<?xml version="1.0" encoding="UTF-8"?> <xml-signature-config>
XML signature configuration starts with the root elementxml-signature-config
.
Localization properties are defined within locale
.
<locale language="EN" country="EN"/>
<http> <proxy-host></proxy-host> <proxy-port></proxy-port> <proxy-username></proxy-username> <proxy-password></proxy-password> <basic-authentication-username></basic-authentication-username> <basic-authentication-password></basic-authentication-password> <connection-timeout-in-milliseconds>2000</connection-timeout-in-milliseconds> </http>
If proxy is used then the related configuration is performed within http
.
<resolvers> <resolver class="tr.gov.tubitak.uekae.esya.api.xmlsignature.resolver.IdResolver"/> <resolver class="tr.gov.tubitak.uekae.esya.api.xmlsignature.resolver.DOMResolver"/> <resolver class="tr.gov.tubitak.uekae.esya.api.xmlsignature.resolver.HttpResolver"/> <resolver class="tr.gov.tubitak.uekae.esya.api.xmlsignature.resolver.XPointerResolver"/> <resolver class="tr.gov.tubitak.uekae.esya.api.xmlsignature.resolver.FileResolver"/> </resolvers>
In the element, the classes used to resolve the urls included in the signature. For a standart usage the resolvers lister here is sufficient. For custom protocoles, the interface IResolver must be implemented and added to resolver
in the configuration file. For exapmle, if you want to store a data corresponding to a uri ina database, you can implement a DatabaseResolver class.
public interface IResolver { boolean isResolvable(String aURI, Context aContext); Document resolve(String aURI, Context aContext) throws IOException; }
<timestamp-server> <host>http://timestamp_server_address</host> <userid>fill_id_here</userid> <password>pass</password> <digest-alg>SHA-1</digest-alg> </timestamp-server>
Userid and password are for the timestamp taken from ESYA Timestamp server. For other timestamp services, leave these fields empty.
<algorithms> <digest-method>http://www.w3.org/2001/04/xmlenc#sha256</digest-method> </algorithms>
<validation> <!-- default policy for certificate validation --> <certificate-validation-policy-file>//path/to/certval-policy.xml</certificate-validation-policy-file> <!-- possible types: {QualifiedCertificate, MaliMuhurCertificate, TimeStampingCertificate} --> <certificate-validation-policy-file for="MaliMuhurCertificate">//path/to/certval-mm-policy.xml</certificate-validation-policy-file> <!-- grace period is the time that needs to pass to get exact revocation info--> <grace-period-in-seconds>86400</grace-period-in-seconds> <!-- how old revocation data should be accepted? --> <last-revocation-period-in-seconds>172800</last-revocation-period-in-seconds> <!-- compare resolved policy with the one at policy uri, if indicated --> <check-policy-uri>false</check-policy-uri> <!-- loosening below 2 settings will cause warnings instead of validation failure --> <!-- referenced validation data must be used for cert validation is set true --> <force-strict-reference-use>false</force-strict-reference-use> <!-- validation data must be published after creation ifs set true, requires grace period for signers --> <use-validation-data-published-after-creation>false</use-validation-data-published-after-creation> <validators> ... </validators> </validation>
certificate-validation-policy-file | The policy file for certificate validation. If the attribute 'for' is not used then it is the default policy. By assigining the attribute 'for' to different values like QualifiedCertificate , MaliMuhurCertificate , and TimeStampingCertificate , you can define different policys for each type of certificate respectively. |
---|---|
grace-period-in-seconds | The grace period in terms of seconds. Grace period is the time for the signature verification to be performed securely. |
last-revocation-period-in-seconds | The largest time difference betweent the creation of validation data and the validation. |
force-strict-reference-use | Indicates that the revocation data referenced in the signed document must be used in the certificate validation. For security purposes, this parameter should be true . |
use-validation-data-published-after-creation | Indicates that the validation data must be created after the signing time .Default value is true . For a secure validation the validation data must be created after the signing time. |
XML Signature validator classes are located within validation
/validators
. Normally, you do not have to modify the content of this element if you are not developing custom validators. See the sample configurations for custom validators. The one important thing is that the attribute “inherit-validators-from” is used to define common validators for different profiles.