CAdES (CMS Advanced Electronic Signatures) is a set of extensions to Cryptographic Message Syntax (CMS) signed data making it suitable for advanced electronic signatures

CMS is a general framework for Electronic Signatures for various kinds of transactions like purchase requisition, contracts or invoices. CAdES specifies precise profiles of CMS signed data making it compliant with the European eIDAS regulation (Regulation on electronic identification and trust services for electronic transactions in the internal market). The eIDAS regulation enhances and repeals the Electronic Signatures Directive 1999/93/EC. EIDAS is legally binding in all EU member states since July 2014. An electronic signature that has been created in compliance with eIDAS has the same legal value as a handwritten signature.

An electronic signature, technically implemented based on CAdES has the status of an advanced electronic signature. This means that

• it is uniquely linked to the signatory;
• it is capable of identifying the signatory;
• only the signatory has control of the data used for the signature creation;
• it can be identified if data attached to the signature has been changed after signing.

A resulting property of CAdES is that electronically signed documents can remain valid for long periods, even if the signer or verifying party later attempts to deny the validity of the signature.

A CAdES-based electronic signature is accepted in a court proceeding as evidence; as advanced electronic signatures are legally binding. But it gets higher probative value when enhanced to a qualified electronic signature. To receive that legal standing, it needs to be doted with a digital certificate, encrypted by a security signature creation device ("qualified electronic signature"). The authorship of a statement with a qualified electronic signature cannot be challenged - the statement is non-repudiable.

CAdES defines six profiles (forms) differing in protection level offered.

• CAdES-B (also named XAdES-BES for "Basic Electronic Signature"), basic form just satisfying Directive legal requirements for advanced signature;
• CAdES-T (timestamp), adding timestamp field to protect against repudiation;
• CAdES-C (complete), adding references to verification data (certificates and revocation lists) to the signed documents to allow off-line verification and verification in future (but does not store the actual data);
• CAdES-X (extended), adding timestamps on the references introduced by XAdES-C to protect against possible compromise of certificates in chain in future;
• CAdES-XL (extended long-term), adding actual certificates and revocation lists to the signed document to allow verification in future even if their original source is not available;
• CAdES-A (archival), adding the possibility for periodical timestamping (e.g. each year) of the archived document to prevent compromise caused by weakening signature during a long storage period.

# 1 Signature levels

By default, CAdES_BASELINE_B will be used. You can use any of the following enum types to setup signature level by using constants provided by class CAdES.SIGNATURELEVEL

• CAdES_BASELINE_B: Basic Electronic Signature The lowest and simplest version just containing the SignedInfo, SignatureValue, KeyInfo and SignedProperties. This level combines the old -BES and -EPES levels.
• CAdES_BASELINE_T: Signature with a timestamp. A timestamp regarding the time of signing is added to protect against repudiation.
• CAdES_BASELINE_LT:Signature with Long Term Data Certificates and revocation data are embedded to allow verification in future even if their original source is not available. This level is equivalent to the old XAdES_XL level.
• CAdES_BASELINE_LTA: Signature with Long Term Data and Archive timestamp. By using periodical timestamping (e.g. each year) compromising is prevented which could be caused by weakening previous signatures during a long-time storage period. This level is equivalent to the old XAdES_A level.

LT and LTA requires revocation list.

# 2 Signature packaging

You can select from any of the following signature packaging:

• ENVELOPING, The signature includes the XML document encoded in base64.
• DETACHED, The signature without the document is returned.

# 3 Methods

#### TO DO

This section is incomplete and will be concluded as soon as possible.

# 4 Enum constants

For either signature level, signature packaging and digest algorithm and enum constant is provided.

Copy
<script>
</script>

# 5 Detached example

Copy
<script>
var ks = new Ax.ks.KeyStoreManager("https://bitbucket.org/deister/axional-docs-resources/raw/master/KeyStores/swview/jks-files/jack.jks", "secret");

// Load any document (text, file ...)
// In our example, we use a simple text
var src = "This is a memo text that must be signed to certifify it's author";

// Sign the document using keystore private key alias "jack" with password "moon"
.setTspServer("http://tsa.belgium.be/connect")
.sign(ks, "jack", "moon")
;

// The resulting data is a byte[] in PKCS#7 (CMS) format
new Ax.io.File("/tmp/books.p7s").write(tmp);

// Look at the content of PKCS7 data
console.log(tmp);

</script>

# 6 Enveloping example

Copy
<script>
var ks = new Ax.ks.KeyStoreManager("https://bitbucket.org/deister/axional-docs-resources/raw/master/KeyStores/swview/jks-files/jack.jks", "secret");

// Load any document (text, file ...)
// In our example, we use a simple text
var src = "This is a memo text that must be signed to certifify it's author";

// Sign the document using keystore private key alias "jack" with password "moon"
.setTspServer("http://tsa.belgium.be/connect")
.sign(ks, "jack", "moon")
;

// The resulting data is a byte[] in PKCS#7 (CMS) format
new Ax.io.File("/tmp/books.p7s").write(tmp);

// We can extract the data from PKCS#7 envelope
</script>