Locked History Attachments


Signature system:


  1. WYSIWYS (What you see is what you sign);
  2. Simplicity - just a web browser required to sign a document;
  3. Be clear in the intention of the signing, e.g. I hereby acknowledge... etc.
  4. Allow the signature to be counter-signed by organizations that have a relation with the signed document;
  5. The signature must be in an open format;
  6. Allow the organization to store the signature and protect it's authenticity recurring to trusted timestamping;
  7. Allow the organization to counter-sign the document validating the eventual relationship of that person inside the organization e.g. I'm the responsible for this project and have full authority to sign this document;
  8. All of the signatures MUST have a secure timestamp associated with it - thus making sure the non repudiation of the signature on a given date (to avoid claiming that the date was wrong)

Counter signature process requirements:

  1. Validate the signature;
  2. Validate the certificate, and the hierarchy of certificates, used to make the signature;
  3. The timestamp (if transmitted on the signature made by the user);
  4. The responsibilities that the signer says it has on the signed document e.g. responsibilities of the user amongst the organization, (if implicit/required by the document to sign);
  5. Any other misc. qualifying proprieties claimed by the signer (if any other are claimed by him);
  6. Utilization of a Timestamp signature authority to make the counter signature;

The counter-signature proccess can be a manual one or not depending on the requirements of the document

Storing the signatures requirements (came from requirement #6)

  1. Allow successive timestamps to the signature;

Signature formats suitable for the requirements:

  1. XAdES-X-L;
  2. XAdES-A;

Important elements to retain and evaluate from the XAdES specification:

  • CounterSignature - Support for counter-signatures;

  • SignerRole - Support for the role of the individual amongst the organization;

  • DataObjectFormat - Description (metadata) of the document being signed e.g. content-type, etc. Sub-elements:

  • CommitmentTypeIndication - Signing intention e.g. I hereby acknowledge the validity of... etc. - textual description;


Highly based on: 'Assinatura Electrónica Qualificada' Author: Daniel Tiago Nave Prata de Almeida Master thesis for Computer Sciences Engineering at IST

XAdES resources

  • http://santuario.apache.org/index.html - Looks a bit incomplete, not sure if it supports XAdES-X-L or XAdES-A;

  • http://jcp.org/en/jsr/detail?id=105 - Not sure if it supports XAdES at all or just the basics to the the signing - the result of the specifications I think are translated to the Signature JAVA6 class

  • http://code.google.com/p/eid-dss/ - Apparently the way to go - not sure of the feasibility/necessity of using this library versus constructing the XML document 'by-hand';

  • http://code.google.com/p/xades4j/ - A portuguese project, it can support XAdES-X-L and XAdES-A but it doesn't do it out of the box: It enables producing, verifying and extending signatures in the main XAdES forms: XAdES-BES, XAdES-EPES, XAdES-T and XAdES-C. Also, extended forms are supported through the enrichment of an existing signature. The API provides an high level of abstraction, handling all the structural details of XAdES. Not sure how easy it is to accomplish this, again, at this point we will make due with what we have already implemented as a result of Daniel's thesis.

XAdES v.1.3.2 vs XAdES v.1.4.1 and XAdES v.1.4.2

To update from v.1.3.2 to v.1.4.1 (according to Annex E):

  • Schema correction - can probably use v.1.4.1 schema
  • Probably the TimeStampValidationData data which contains validation data for the time-stamp token might be useful

The rest are mostly changes in the writing of the specifications, or simply not worth mentioning due to the use of the XAdES format in this project.

To update from v.1.4.1 to v.1.4.2 (according to Annex E): Just an error that existed on v1.4.1 on the specification of some fields, the rest remains the same

One can probably upgrade the version to the latest and make sure that the validation signatures details found on Annex G are being respected

Steps taken to validate a received XAdES-EPES signature and evolve it to a XAdES-A

  • After receiving the signature, check its value;
  • Add a timestamp to the signature - generating a XAdES-T signature;
  • [optional] - the validation process may also validate the electronic signature using additional data (CRL, certificates, etc);
  • [optional ?] - validation of the signature policy sepcified by SignaturePolicyIdentifier;

  • [To XAdES-C] - get all of the complete certificate and revocation information, and check it, adding the references to the XAdES-T signature, thus making it a XAdES-C one;
  • [To XAdES-X] - add a SigAndRefsTimeStamp to the data in XAdES-C or simply a RefsOnlyTimestamp;

  • [To XAdES-A] - add a timestamp and the CertificateValeus and RevocationValues - this kind of timestamp can/should be added annualy for instance;

  • It's also possible to skip the XAdES-C state, to the XAdES-A, thus from a XAdES-T to a XAdES-A which already has the validation data (?)

Technical rules of verification of the XAdES formats

  • === General verification ===
  • Should identify the specific format of the XAdES file received - which must be exactly one of those specified in the normative parts or in the Annex B (extended formats).
  • check that the ds:SigningCertificate is present;

    • if it isn't present, that the ds:KeyInfo contains the signing certificate and is referenced by one of the ds:Reference elements in the signature, thus verifying that the signing certificate is protected by the signature value;

      • while executing the aforementioned check, assess if the incorporation of properties is direct (all of the properties within one ds:Object element enveloped by the ds:Signature element) or indirect (denoted by the presence of QualifyingPropertiesReference elements within one of the ds:Object elements envolped by the ds:Signature). Once this is done check that the section 6.3 rules apply.

  • Check the presence and the value of the Type attribute in the ds:Reference element referencing the ds:Object which encloses all the XAdES signed properties in the direct incorporation case or the QualifyingPropertiesReference in the indirect incorporation case. if no Type attribute is present with such a value, it is not a XAdES signature.

    === XAdES-A (CertificateValues) property verification ===

  • Use the CertificateValues and the ds:KeyInfo property to get all the chain of certificates. If can't, this signature is invalid.

  • If CertificateValues is not present but CompleteCertificateRefs is, the verifier should get the certificates referenced and check if they forma a valid certification path;

  • If neither CertificateValues nor CompleteCertificateRefs are present, the specific means by which the verifier can get

the certification path are out of scope of the present document. - thus probably making it still a valid if you have the certificates

Authorities certificates and its usage in the validation of the attribute certificate(s) present in the SignerRole property;

XAdES-A Getting certificates status information for verification

  • RevocationValues should contain only CRLs and OCSP responses.

  • If the XAdES signature contains the RevocationValues property, then the verifier should use this property for

getting the information on the status of all the aforementioned certificates. The verifier should also check if they actually provide adequate revocation information for all the certificates required for verifying the electronic signature. If not, the verifier should assume that the verification process has failed.

certificate status information data referenced there and check if they actually provide adequate revocation information for all the certificates required for verifying the electronic signature. If not, the verifier should assume that the verification process has failed.

verifier can get this information is out of the scope of the present document.

attribute certificate(s) present in the SignerRole property and the Attribute Authorities certificates and its usage in its validation.

=== Checking SigningTime === - Check! (minus the SignaturePolicy part)

  • Should a signature policy (implicit or explicit) be in place, applications SHOULD follow its rules for checking this

signed property. Otherwise, the present document considers the verification of this signed property an application dependant issue.

Checking ''SigningCertificate''

  • Either if the certificate comes from the CertificateValues or the ds:KeyInfo or by an outside mean, are outside of the scope, so it can get it from some other place.

  • The ds:SigningCertificate, if present, its properties should be checked against the properties of the certificate. It should perform the following tasks:

  • Compare the name of the issuer and the serial number of the certificate with those indicated in the IssuerSerial

element, following the indications given in in XMLDSIG clause 4.4.4 on how to generate the string corresponding to the issuer"s distinguished name. If they do not match take the next reference and re-start again in 1. If they match, continue with 2.

  1. If the ds:KeyInfo contains the ds:X509IssuerSerial element, check that the issuer and the serial

number indicated in both, that one and IssuerSerial from SigningCertificate, are the same

  • 3.Check that the content of ds:DigestValue is the result of digesting the certificate with the algorithm

indicated in ds:DigestMethod and base-64 encoding this digest.

If the verifier does not find any reference matching the signing certificate, the validation of this property should be taken as failed.

If SigningCertificate contains references to other certificates in the path, the verifier should proceed to check each of the certificates in the certification path against them.

Should this property contain one or more references to certificates other than those present in the certification path, the verifier should assume that a failure has occurred during the verification.

Should one or more certificates in the certification path not be referenced by this property, the verifier should assume that the verification is successful unless the signature policy mandates that references to all the certificates in the certification path "must" be present.

. Abbreviated . The rest can be found on annex G


Public API


Responsible for the implementation

João Antunes (joao.antunes (at) tagus.ist.utl.pt)