# Contraktia signature and evidence policy Identifier: contraktia-sig-policy-v1 Version: 1 of 25 September 2026 Publisher: Contraktia, platform for preparing, signing and monitoring contracts This policy describes the electronic signature process implemented by Contraktia, the evidence it produces, how that evidence is kept and how it can be verified. Its identifier and SHA-256 fingerprint appear in every evidence file issued under this version. ## 1. Signature level and limits - Simple electronic signature (eIDAS Regulation, Article 3; French Civil Code, Article 1367). It is neither an advanced nor a qualified signature: it does not benefit from the presumption of reliability provided for by Decree No 2017-1416. Its reliability is established by the items described below and, between the parties, by the evidence agreement (identifier contraktia-evidence-agreement). - The code sent by email proves control of the email address used; it does not by itself prove the civil identity of the signatory or their powers of representation. - The process is not suitable for deeds for which the law requires a specific form (notarial deed, handwritten statements, qualified signature). ## 2. Freezing the document - Before signing opens, the document is frozen: its content (title, parties, clauses, signatories and signing order) is recorded as a snapshot. Its SHA-256 fingerprint is computed over the canonical JSON of this snapshot (sorted keys, no whitespace). - The frozen document can no longer be changed: to change the text, the signing campaign must be cancelled and the document frozen again, which produces a new fingerprint. All signatories of a campaign sign the same fingerprint. - Signatories sign in the defined order; each one is invited by email. ## 3. Access and identification of the signatory - Member of the issuing organisation: personal Contraktia account. - External party: personal link sent by email, then a one-time access code sent to the same address. This code opens a session limited to the document; it never counts as a signature. - Agent: member signing on behalf of another member under a mandate confirmed by the principal, limited to document types and to a period. The mandate is checked at the exact time of signature and the principal is notified. ## 4. Signing journey 1. Reading and consent: the complete frozen document is displayed. The signatory ticks a box that is not pre-ticked, whose exact text is recorded, and accepts the evidence agreement with a second box that is not pre-ticked (version, language and fingerprint recorded). 2. One-time code: a 6-digit code is sent to the signatory's address (to the agent's address when an agent acts). Default parameters: valid for 15 minutes; only the latest code issued is valid; single use; at most 3 sends per address within 5 minutes and 10 sends per IP address; 5 consecutive failures block verification for 15 minutes. The code is never stored in clear text (only a keyed HMAC fingerprint is) and never appears in any log or evidence file. 3. Final confirmation: a separate box restates the title, the reference and the signature statement. On click, the server re-checks within a single transaction the contract status, the campaign, the signing order, the deadline, the recomputed fingerprint of the frozen document, the consent and code verified less than 15 minutes earlier by the same person, the acceptance of the evidence agreement and the mandate relied upon. If any check fails, nothing is signed and the journey restarts at step 1. ## 5. Evidence recorded For each signature: declared identity, capacity and organisation; email address; type of access (account or external party); exact text and language of the ticked boxes; acceptance of the evidence agreement (identifier, version, language, fingerprint, date, IP address, browser); dates and times of consent, of sending and verifying the code and of confirmation; code challenge identifier (never the code); IP address and browser; signature statement; signed fingerprint; where applicable, a snapshot of the mandate. Dates are those of the platform's servers, in Coordinated Universal Time (UTC). ## 6. Chained audit log - Every significant action is written to an append-only audit log, specific to each organisation. - The fingerprint of each event is the SHA-256 of the concatenation of the fingerprint of the organisation's previous event (in hexadecimal, empty string for the first one) and of the canonical JSON of its content: scope, organisation, contract, actor type and identifiers, actor label, action, object type and identifier, result, IP address, browser, support access, details, date to the millisecond. Any change to or deletion of an event breaks the chain. - The evidence file includes the events of the contract's signing phase (no internal note), with the whole of their hashed content, their fingerprint, the previous fingerprint and their sequence number, together with the result of the check of the organisation's chain at sealing time and the head fingerprint of that chain. ## 7. Sealing - Once all signatures have been collected, the platform produces: the final PDF copy (frozen document, signature block with the exact statements, signature certificate); the proof.json file (frozen snapshot, evidence for each signature, mandates, audit events, references to this policy and to the evidence agreement); the PDF evidence report, readable by a non-specialist. - A sealing manifest (version 2) states the SHA-256 fingerprints of these three files, the fingerprint of the frozen document, the signatures, the sealing date, the signature level, the identifier and fingerprint of this policy, the versions and fingerprints of the evidence agreement that were accepted, the address where keys are published, the time-stamping rules applied (standard, fingerprint algorithm, time-stamped items, whether the service was enabled at sealing, declared qualification of the authority) and the head fingerprint of the organisation's audit log at sealing time. It is signed with Ed25519 over its canonical JSON (sorted keys, no whitespace) with the platform's sealing key. - The private sealing key is generated by the platform and kept encrypted (AES-256-GCM) in its vault; it is never logged or transmitted. Each key is identified by the first 16 hexadecimal characters of the SHA-256 of its public key (SPKI, DER encoding). Public keys, current and past, are published with their validity dates. - Sealing is idempotent; a failure leaves the contract awaiting sealing, can be retried and does not alter the signatures collected. - An evidence file that has been issued is never changed. Evidence files issued before this policy (manifest version 1) remain verifiable under the rules in force when they were issued. ## 8. Time-stamping and anchoring - Recorded dates come from the clocks of the platform's servers. - When the time-stamping service is enabled, two RFC 3161 timestamp tokens (SHA-256 fingerprints) are requested from a third-party time-stamping authority after each sealing: one for the final PDF copy, the other for the sealing manifest. Only the fingerprint is sent to the authority. Each token is checked on receipt: fingerprint, signature of the authority, time-stamping usage of its certificate and certification chain up to the authority's root designated by the operator; the service cannot be enabled without that root. - An unavailable authority never prevents sealing: the request is automatically renewed at increasing intervals, and the operator is alerted after several failures. A token obtained after sealing (retry, or contract sealed before the service was enabled) proves that the document existed at the date it bears, not at the date of signature; it is presented as such. - Anchoring of the audit log: when the service is enabled, the platform draws up, periodically (every 24 hours by default) and at each sealing, a statement of each audit chain: segment covered, number of events, head fingerprint, root of a Merkle tree (RFC 6962) of the fingerprints of the segment's events and reference to the previous statement. The fingerprint of that statement is time-stamped by the authority, within 72 hours of its creation at the latest. A later rewriting of the log, even fully recomputed, would contradict a statement dated by a third party; the platform regularly checks that no statement is contradicted and alerts the operator otherwise. Each time-stamped statement is recorded, by the fingerprints of the statement and of the token and by its date alone, with no organisation and no content, in an append-only public log (/.well-known/contraktia-audit-anchors.json) whose entries are chained: anyone who keeps a copy can detect a later removal or change. - The tokens, the anchoring statements covering the contract's events and the proofs of inclusion of those events in the statements (fingerprints only, with no content of any other contract or organisation) are added to the evidence file as additional files, without changing the sealed items. They are listed in an index signed with Ed25519 with a published sealing key, and can be checked with the openssl ts -verify command and with the independent verifier. - The "eIDAS qualified" status of a time-stamping authority is a declaration of the operator, shown as such in the evidence file; only the authority's listing on the EU trusted list makes the time-stamp qualified. - The absence of time-stamping or anchoring (service disabled or unavailable) is visible in the evidence file and does not affect the other items. ## 9. Retention - The final copy, proof.json, the evidence report, the signed manifest and the audit log are kept durably with the contract archive of the issuing organisation, encrypted (AES-256-GCM); the fingerprint of each file is checked every time it is read. - Short-lived technical data (code challenges, sessions) is purged in accordance with the privacy policy; the items needed as evidence are copied into the signature evidence at the time of signature. - Each signatory receives the final copy and the evidence report by email. The complete evidence file (ZIP) can be downloaded by authorised members of the issuing organisation and by authenticated signatories. ## 10. Verification - Public verification page (/verify): an uploaded PDF copy is compared with the sealed copies and the seal of its manifest is checked. The file is not kept. - Independent verification: each evidence file contains a standalone verifier (verify.mjs, Node.js, no dependency) and instructions to check by hand with sha256sum and OpenSSL: file fingerprints, Ed25519 signature of the manifest, match between the key and the published keys, fingerprint of the frozen document, audit log events, reference documents, timestamp tokens, anchoring statements and proofs of inclusion. The verifier does not trust the key included in the evidence file: it compares it with the keys published at the official address written in its code, never at an address given by the evidence file. It only takes a timestamp as established if the certification chain of the authority leads to a root that it recognises or that the user designates. The copy included in an evidence file comes from the same server as the file: the official version can be downloaded from the /seal-keys page, which publishes the SHA-256 fingerprint of each version. - Public sealing keys: /.well-known/contraktia-seal-keys.json and the /seal-keys page; public anchor log: /.well-known/contraktia-audit-anchors.json. ## 11. Changes Any change to the process leads to a new version of this policy, under a new identifier. A published version is never changed. An evidence file remains verifiable under the version under which it was issued.