e-Signature Library and API

PAdES (PDF Advanced Electronic Signatures) is an electronic signature format in which the signature is embedded inside the PDF file; it is defined by the ETSI EN 319 142 standard. The signed document remains a PDF, is verified through the signature panel in PDF readers such as Adobe Reader and can carry a visible signature field on the page. Its levels go up through B-B, B-T (timestamped), B-LT and B-LTA (long-term archive).

CAdES (CMS Advanced Electronic Signatures) is an electronic signature format based on the CMS/PKCS#7 structure; it is defined by the ETSI EN 319 122 standard. It can sign any type of file; the signature is usually carried with the document as a .p7s or inside a signed envelope. In Turkey it is the most widely used format in e-signed official correspondence.

XAdES (XML Advanced Electronic Signatures) is an electronic signature format developed for XML documents; it is defined by the ETSI EN 319 132 standard. The signature can be embedded in the XML or kept separate. It is used for XML-based documents such as e-invoices in the UBL-TR format.

An e-signature library is a developer component (SDK) that adds creating and verifying electronic signatures to your own software. A ready-made signing application gives the user a screen; a library is a building block without a screen — your application signs, within your workflow. It works with smart cards, tokens or HSMs and creates and verifies CAdES, XAdES and PAdES formats.

An e-Yazışma package is the standard package used in official electronic correspondence with public institutions in Turkey: the signed document, the metadata file and any attachments are put together into a single package. Between institutions it is usually sent via KEP (registered electronic mail).

An official e-Yazışma package is the signed document packaged together with its metadata file. The library does this in a single call: it signs the document with CAdES or XAdES, generates schema-compliant metadata and closes the package. e-Yazışma versions 1.3 and 2.0 are supported and the KamuSM root certificate comes built in. Give it a folder and it signs the documents inside in bulk.

A library goes inside your own software: your workflow triggers signing and the interface is yours. The ready-made application (İmzacı) runs on the desktop, where the user picks a file and signs it. Both use the same signing infrastructure; which one suits you depends on who starts the signature — your software or the user.

CAdES (BES, EPES, T, C, X, XL, A), XAdES (BES, T, C, X, XL, A), PAdES (B-B, B-T, B-LT, B-LTA) and ASiC-S and ASiC-E. You reach long-term archive level with a single library.

No. The library is modular; the eSignature.PAdES package is enough for PDF. Standards, TSAs and hardware providers you do not use never enter your project.

The signature is not created in the browser but on the server side of your web application: the eSignature.PAdES package is called and the signed PDF is returned to the user. Where the key lives is what decides it — if you use a cloud HSM, a network HSM or mobile signature, the server can reach the key, so the whole flow runs over the web. If the key is on the user's smart card, the browser cannot access the card; in that scenario signing is done on the desktop with İmzacı.

Yes. The signing source is abstracted: smart cards and USB tokens (CNG/PKCS#11), network HSMs, cloud HSM services and mobile signature are used with the same flow. Each provider is an independent package.

Yes. RFC 5280 certificate chain validation, CRL, OCSP, Delta CRL and offline validation are inside the library; the same component creates and verifies the signature.

Yes. The desktop application you use without writing code is İmzacı: it signs PDF and XML with a smart card, creates e-Yazışma packages and does folder-based bulk signing.

Add the package for the standard you need to your project: eSignature.PAdES for PDF signatures, the XAdES package for XML. Because the library is split into 39 NuGet packages, you install only what you use; no single large dependency enters your project.

Devices such as AKİS, SafeNet/eToken, Gemalto/Thales, IDEMIA, Feitian, YubiKey and Nitrokey are supported via Windows CNG and PKCS#11. Each provider is a separate, independent package; drivers you do not use never enter your project.

Yes. Thales Luna, Utimaco and Entrust nShield network HSMs as well as AWS CloudHSM/KMS, Azure Key Vault HSM and Google Cloud KMS are supported. This is how an automated signing flow is set up on the server, without a user holding a card.

No; the same component creates and verifies the signature. RFC 5280 certificate chain validation, CRL, OCSP, Delta CRL and offline validation are inside the library.