ARP Signer

Signs a reasoning.json (ARP v1.3) with Ed25519 over the RFC 8785 (JCS) canonical form of the whole file, signature metadata included (Enveloped Pattern, SPEC §13.4). The Signer adds the fixed signature statement, the verify pointers and the SHA-256 of reasoning.md. The signature shows who published the file and that it is unchanged; it does not show that the statements are true.

Runs locally in the browser Algorithm: Ed25519 Canonicalization: RFC 8785 (JCS) File and private key stay in the browser; the Ed25519 library is loaded from esm.sh

1 Configuration

New keys get a new selector (pattern arpYYMM, e.g. arp2610).
Re-sign with the key behind an existing selector
Leave blank to generate a new keypair.
No file yet? The Generator creates one →

2 Signed

A. DNS TXT record

Verifiers (arp_cli verify, the Validator) look up the public key under this name.

Name:
Type: TXT
Value:

B. Deploy & Backup

/.well-known/reasoning.json and /.well-known/reasoning.md, served as published here (the Markdown byte for byte, its SHA-256 is signed).

C. Making both files findable (ARP-D)

After deployment: check the live file in the Validator.

⚠ Keep your Private Key secret! You need it to re-sign under the same selector. It is not stored or transmitted by this page.

How It Works

Step 1 Check the file Version 1.3 (v1.2 files with provenance are upgraded), domain matches, provenance present, wording rules ARP-W pass (same rules as the Validator and arp_cli lint).
Step 2 Signature metadata _arp_signature gets algorithm, selector, timestamps, the fixed statement and the verify pointers (DNS name, DNS-over-HTTPS URL, spec).
Step 3 reasoning.md and its hash The readable Markdown is rendered from the manifest (ARP-R); its SHA-256 goes into representations.
Step 4 JCS canonicalization and Ed25519 signature The whole object, with signature set to "", is serialized per RFC 8785 and signed. The keypair is generated in the browser via @noble/ed25519, or an existing PEM key is used.
Step 5 DNS TXT binding The public key is published at <selector>._arp.<domain>. Verifiers build this name from the retrieval domain and dns_selector.
What the signature shows
The trust model is that of DKIM and HTTPS: a valid signature shows that the operator of the domain published exactly this file and that it has not been altered since. It does not show that the statements are true. A signed reasoning.json remains the entity's self-description.
Command line
The same steps run with arp_cli v1.4.0: sign, render-md, verify and lint (arp_cli.py on GitHub).