4 min read

Introduction into XAdES for Trust Service Providers

Cryptomathic : 19. February 2016

Digital Signatures eIDAS
Introduction into XAdES for Trust Service Providers

The term XAdES stands for XML Advanced Electronic Signatures, which specifies a set of extensions that are used with the W3C recommendation for XML Signature Syntax and Processing (XML-DSig). This documents includes the final drafts for a revised framework by the European Telecommunications Standards Institute (02-2016).

XAdES specfies advanced electronic signatures, technically implemented through digital signatures, in compliance with the eIDAS regulation regulation that has evolved from European Union Directive 1999/93/EC. Electronically signed documents that are validated by XAdES can remain secure for long periods, even if the cryptographic algorithms that were used were broken. 

Other eIDAS-compliant signature designs are PAdES and CAdES.

Standardization Position

W3C and ETSI join together to maintain and update XAdES. Given the relevance of W3C for global Internet standards and the Semantic Web, this indicates the role that XAdES and TS101 903 in particular will play.

XAdES Signature Policies

A signature policy is "a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined" (RFC3125 and ETSI Electronic Signature Policy Report).

Signature policies that are associated with XAdES may be used to establish technical consistency during the process of electronic signatures validation: ETSI TS 101 903 illustrates technical consistency as follows:

"When a comprehensive signature policy used by the verifier is either explicitly indicated by the signer or implied by the data being signed, then a consistent result can be obtained when validating an electronic signature."

New Call-to-action

The verifier will receive a consistent result provided he used the comprehensive signature policy either specified by the signer or that which is implied by the signed data when attempting to validate an electronic signature.

If the signer or signed data does not specify which signature policy has been used, or if it is incomplete, the verifiers may find that their results are inconsistent. It is recommended that in order to maintain consistency, it is recommended that the signer and the verifier use the same comprehensive signature policy.

XAdES Electronic Signature Forms

In conformance with ETSI TS 101 903 V1.4.1 TS 101 903 V1.4.1 (2009-06) specifications, there are four forms of XML advanced electronic signatures available:

  • XAdES-BES – Basic Electronic Signature – this format builds on the XML-DSIG by including qualifying properties that are defined within the document. It is mandatory to protect the signing certificate by incorporating signed property of SigningCertificate or by incorporating the certificate from within ds:KeyInfo. By doing so, XAdES-BES is able to prevent the signer’s certificate from being substituted. A XAdES-Basic Electronic Signature may also contain these additional properties:
    • SigningTime
    • DataObjectFormat
    • CommitmentTypeIndication
    • SignerRole
    • SignatureProductionPlace
    • IndividualDataObjectsTimeStamp
    • AllDataObjectTimeStamp
    • CounterSignature
  • XAdES-EPES – Explicit Policy-based Electronic Signature – this format allows for the extension of the electronic signature’s definition so that it conforms to the signature policy that has been identified. XAdES-EPES builds on XML-DSIG or XAdES-BESforms by adding a SignaturePolicyIdentifier property, which indicates that the signature policy must be used to validate the signature.

Two XAdES signature formats require the addition of validation data, which may be collected by the signer, verifier, or both. This data includes:

  • Public Key Certificates (PKCs)
  • Individual PKCs revocation status information
  • Trusted time-stamp and/or time-mark
  • Information regarding signature policy information used to verify electronic signature

XAdES formats requiring validation data are:

  • XAdES-T – Electronic Signature with Time. A trusted time is associated to the electronic signature. This is accomplished by adding an unsigned time-stamp attribute or a time-mark that is provided by the Trusted Service Provider.
  • XAdES-C – Electronic Signature with Complete Validation Data References.Complete-certificate-references and complete-revocation-references attributes are added to XAdES-T. Additionally, AttributeCertificateRefs and AttributeRevocationRefs elements are also used to validate the signature. These references allow for the storing of the values of the certification path and revocation data elsewhere, thus minimizing the size of the stored electronic signature.

XAdES Electronic Signature Forms (draft of 2016-02)

The updates, drafted in Feb. 2016 in the document ETSI EN 319 132-1 V1.1.0 (2016-02) V1.1.0 (2016-02) will provide significant simplification to the baseline signatures. There will be four levels of XAdES baseline signatures:

  • B-B – this level requires signed and some qualifying properties when the signature is created.
  • B-T – building upon the B-B level, a trusted token is also incorporated into the signature during creation to prove that it existed on a certain date and time.

The final two XAdES signature formats require the addition of validation data, which may be collected by the signer, verifier, or both. This data includes:

  • Public Key Certificates (PKCs)
  • Individual PKCs revocation status information
  • Trusted time-stamp and/or time-mark
  • Information regarding signature policy information used to verify electronic signature

XAdES formats requiring validation data are:

  • B-LT – this level is concerned with incorporating all variables that are required to validate the signature in the signed document. The purpose of this level is to assure the long term availability of the signature’s validation.
  • B-LTA – this level incorporates electronic time-stamps to will provide long term signature validation. This is to allow for long term availability and integrity of the signed document.

Levels B-T, B-LT and B-LTA can be used when a signature needs to be preserved for a long time and there is concern of that certificates will expire, be revoked or the algorithm used will become obsolete.

B-LTA is appropriate for validation of availability and integrity of digitally signed documents for the long term. It is considered an appropriate method for preserving and transmitting signed data.

Validation Process

When validating an electronic signature, the validation process will produce one of three output statuses:

  • Invalid – This response will indicate that the signature format is incorrect or that the digital signature has failed verification. An invalid response may be triggered when an integrity check fails or if the certificates used are now invalid or revoked.

  • Incomplete Validation – This response will show that verifications for both the format and digital signature have not failed, but there is not enough information to show that the signature is valid. This could be because the certificates used are not available. It may be possible to check the validity of the signature at a later time when the certificates become available.

  • Valid – If the signature passes verification and it complies with the validation policy, a valid response will be given.

 

New Call-to-action

 References and Further Reading

Photo: courtesy of Lucy Fisher, Flickr