Security

Signed and timestamped receipts

• Every decision, every release or refusal and every send is a receipt signed with Ed25519. Each receipt is linked to the one before it, so a removed or altered receipt shows as a break.
• Each receipt is stamped by an outside European time-stamping authority under RFC 3161, so its time does not rest on our word. The authority receives a fingerprint of the receipt, never its content.
• If the authority cannot be reached, the receipt says plainly that no stamp was obtained. A later stamp is added as a receipt of its own that points back to it.
• Each day's signed records are gathered into one signed root.
• Qualified time-stamps, from Aruba PEC in Italy, are available on request. Your Order Schedule states whether you have them.
• A receipt names the message and each attachment by a fingerprint. The content is sealed separately, one message at a time under its own key (AES-256-GCM), so erasing a message destroys its key, and the receipt still passes the checker.

Mailbox connections ask for the least access they need

To connect a Microsoft 365 or Gmail mailbox, you sign in to your provider through OAuth, the sign-in standard it uses, with PKCE. The connection asks your provider for permission to send mail and to confirm which address you connected, and for nothing else:

Microsoft 365

Mail.Send offline_access openid email

Gmail

gmail.send openid email

• These two connections give the service no permission to read your mail, your contacts or your profile.
• If a provider grants more than this, the connection is refused and the tokens are thrown away without being stored.
• For Gmail, the connected address must be one that Google has verified. Our app is still in Google's testing mode, so Gmail can be connected for named test users only.
• Capture of incoming mail reads one folder that you name, over IMAP, and opens it read-only. The connection must use TLS 1.2 or later, and the password is never sent over a connection that is not encrypted.

Mail you send through Microsoft 365 or Gmail travels through that provider, as it does now. Email Decision Record adds the decision and the record; it does not change the route your mail takes.

Lot references in email records with linked artifacts

• Where an organisation's subscription includes linked artifacts, an Email Decision Record can name a lot by a reference. That field is signed, sequenced and rolled into the day's sealed root, so the reference itself cannot be erased. Two emails that name the same lot carry the same reference, so they are linkable to each other. Treat it as a permanent fingerprint.
• The reference is SHA-256 over the lot reference, the chain head and the day root. It reveals nothing by itself, and it identifies a lot only to someone who holds that lot's Provenance data.
• If the lot's openings are later erased, the reference can no longer be recomputed and the checker reports it as unopened, which is not a fault of the email record. A consignment file already built is a snapshot and goes stale after an erasure.
• The link means only that a signed email record names this lot reference, never that the dossier was attached to that email. The field is off unless the organisation's subscription includes it. This describes the design; it is not legal advice.