XAdES XAdES 2.13

 The XAdES specification has been developed by the European Telecommunications Standard Institute (ETSI) to meet the growing importance of XML in electronic commerce and the need for signature standards to support the development of electronic business and electronic government. It fulfills the requirements of the advanced electronic signature according to the EU directive (1999/93/EC), and provides non-repudiation and long-term validity.
 Extending common XMLDSIG signatures XAdES signatures meet the same legal requirements as handwritten signatures do in relation to paper-based data.
 The IAIK-XAdES toolkit offers you a comprehensive software library, continuation with product up-dates and support from the product developers.
 

• Supports all forms of XAdES signatures: Basic forms ( XAdES-BES, XAdES-EPES, XAdES-T and XAdES-C) as well as extended forms ( XAdES-X, XAdES-X-L and XAdES-A)
• Supports all signature properties:
  • Signed properties:
    SigningTime and SignatureProductionPlace: Usually included in each real world contract common XMLDSIG compliant signatures lack of information about signing time and signing place. XAdES provides a standardised way to integrate these properties into electronic signtures.
     
  • SigningCertificate: Includes an unambiguous reference to the signer’s certificate (issuer name, serial number and cert digest) to avoid diversities in interpretation on the verifier’s side (e.g. if the signer uses different certificates implying different semantics with the same public key).
  • SignaturePolicyIdentifier: Unambiguously identifies a signature policy so that the verifier cannot claim that another policy was used when signing the data.
  • SignerRole: In many cases the role of the signing party is an essential information to be included into the signature.
  • DataObjectFormat: Information about the format of the signed data may be crucial for an (verifying) application (using a wrong format when presenting the signed data (text, sound or video) to a human user may break the signature).
  • CommitmentTypeIndication: As supplemental information to the SignaturePolicy this property can be used for qualifying signed data objects. The predefined commitments (e.g. proof of origin, proof of sender) may be refined by additional statements specified by the user.
  • AllDataObjectsTimeStamp and IndividualDataObjectsTimeStamp: These timestamps are added to some or all data objects to be signed to indicate that they have been created before a specific point in time.
     
• Unsigned properties:
  • CounterSignature: Unlike XMLDSIG compliant signatures, real world contracts are usally signed by more than one party. The CounterSignature property can be used for signing the signature value of an existing signature and thus implicitly all the data covered by this signature. By these means arbitrarily long series of countersignatures may be built representing real world contracts signed by different parties.
  • SignatureTimeStamp: This timestamp placed on the signature value element protects against repudiation in the case of a key compromise.
  • CompleteCertificateRefs, CompleteRevocationRefs, CertificateValues, RevocationValues: When dealing with long term signatures information necessary for validating the signer’s certificate (CA certificates and especially revocation data) may not be available after a specific period of time.These properties can be used to append the validation data itsself or unambiguous references to the validation data to the signature.
  • AttributeCertificateRefs, AttributeRevocationRefs, AttrAuthoritiesCertValues, AttributeRevocationValues: Append information for validating attribute certificates to the signature.
  • SigAndRefsTimeStamp and RefsOnlyTimeStamp: These timestamps are added on certificate validation data and ( SigAndRefsTimeStamp only) signature value and signature timestamps to indicate that the signature has been successfully validated with the timestamped validation data at a specific point in time.
  • ArchiveTimeStamp: By periodically adding this timestamp over the whole signature, it especailly protects against weakness of cryptographic algorithms or compromised keys as it undoubtedly proves that the signature has been valid before an algorithm may be broken or a key may be compromised.