- WYSIWYS (What you see is what you sign);
- Simplicity - just a web browser required to sign a document;
- Be clear in the intention of the signing, e.g. I hereby acknowledge... etc.
- Allow the signature to be counter-signed by organizations that have a relation with the signed document;
- The signature must be in an open format;
- Allow the organization to store the signature and protect it's authenticity recurring to trusted timestamping;
- 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;
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:
- Validate the signature;
- Validate the certificate, and the hierarchy of certificates, used to make the signature;
- The timestamp (if transmitted on the signature made by the user);
- 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);
- Any other misc. qualifying proprieties claimed by the signer (if any other are claimed by him);
- 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)
- Allow successive timestamps to the signature;
Signature formats suitable for the requirements:
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
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;
- 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 ===
the certification path are out of scope of the present document. - thus probably making it still a valid if you have the certificates
Same applies for the 'AttrAuthoritiesCertValues' property regarding the retrieval of Attribute
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.
The same rules apply for the AttributeRevocationValues property regarding to the retrieval of the status of the
attribute certificate(s) present in the SignerRole property and the Attribute Authorities certificates and its usage in its validation.
- 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.
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.
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
G.2.2.6 Checking SignaturePolicyIdentifier
- G.2.2.7 Checking Countersignatures
G.2.2.8 Checking DataObjectFormat
G.2.2.9 Checking CommitmentTypeIndication
G.2.2.10 Checking SignatureProductionPlace
G.2.2.11 Checking SignerRole
G.2.2.12 Checking CompleteCertificateRefs and
- G.2.2.16 Checking time-stamp tokens
- G.184.108.40.206 Containers using one identification mechanism
- G.220.127.116.11 Containers using two/both identification mechanism
- G.18.104.22.168.1 Common rules
G.22.214.171.124.2 Checking RefsOnlyTimeStamp
G.126.96.36.199.3 Checking SigAndRefsTimeStamp
G.188.8.131.52.4 Checking xadesV141:ArchiveTimeStamp
Responsible for the implementation
João Antunes (joao.antunes (at) tagus.ist.utl.pt)