Keys, Signing and Encryption

Each identity holds one elliptic-curve key on the P-256 curve. Everything on this page is that key, published a different way for a different stack. The SHA-256 digest of its subject public key info is the single value that ties them together, so a recipient who learns the digest from DNSSEC-signed DNS can check any of these surfaces without asking Whisper anything.

The DANE pin

TLSA at _443._tcp.<name>, parameters 3 1 1: DANE-EE usage, SPKI selector, SHA-256 match. This is the authoritative binding between the name and the key.

dig +dnssec TLSA _443._tcp.ae3b051ff3bf7f478.t<tenant>.agents.whisper.online

To check a live connection against it in one command:

openssl s_client -dane_tlsa_domain ae3b051ff3bf7f478.t<tenant>.agents.whisper.online \
  -dane_tlsa_rrdata "3 1 1 <hex digest>" \
  -connect ae3b051ff3bf7f478.t<tenant>.agents.whisper.online:443 </dev/null

The key in DNS

TXT at _whisper-agentkey.<name> publishes the same key as base64 SPKI, tagged with its algorithm, for tooling that reads TXT and not TLSA.

dig +short TXT _whisper-agentkey.ae3b051ff3bf7f478.t<tenant>.agents.whisper.online
# "v=whisper1; k=p256; p=<base64 SPKI>"

The identity certificate authority

Each identity gets its own leaf certificate, and the blast radius of that certificate is exactly one identity. The leaf is anchored by the TLSA pin, not by a browser root, so a plain curl against an identity's name fails until you supply the root or check the pin yourself. Rotation is make-before-break: the new pin is published before the new leaf is served.

curl -sO https://rdap.whisper.online/.well-known/whisper-ca.pem
curl -s https://rdap.whisper.online/.well-known/whisper-ca.json   # fingerprints

For a runtime that reads a CA bundle rather than a pin, point it at the root: set SSL_CERT_FILE, or NODE_EXTRA_CA_CERTS on Node. The full chain is at /.well-known/whisper-ca-chain.pem.

The JSON Web Key Set

GET /.well-known/jwks.json on the identity's own name serves the same key in JWK form, for JOSE libraries. It is the key that signs the identity document described in The Proof Chain.

The DID document

GET /.well-known/did.json on the identity's own name serves a did:web document for did:web:<name>. It carries two P-256 keys: an authentication key, which signs the identity document, and an assertionMethod key, which is the same key the TLSA record pins. Each key's fragment is the SHA-256 digest of the key itself.

curl -s --cacert whisper-ca.pem \
  https://ae3b051ff3bf7f478.t<tenant>.agents.whisper.online/.well-known/did.json | jq .

SSH host keys

SSHFP is published at the identity's own name, algorithm 3 with fingerprint type 2, so an SSH client can authenticate the host from DNSSEC instead of a prompt.

dig +dnssec SSHFP ae3b051ff3bf7f478.t<tenant>.agents.whisper.online
ssh -o VerifyHostKeyDNS=yes ae3b051ff3bf7f478.t<tenant>.agents.whisper.online

The S/MIME pin

SMIMEA publishes the same key under <hash>._smimecert.<name> with parameters 3 1 1, for the mailbox agent@<name>. The label hash is fixed, so it is derivable from the name alone.

dig +short SMIMEA <hash>._smimecert.ae3b051ff3bf7f478.t<tenant>.agents.whisper.online

The OpenPGP key

OPENPGPKEY publishes the key under _openpgpkey.<name> as a version-4 packet on the NIST P-256 curve, which is where whisper encrypt finds a recipient's key.

Signing a file

whisper sign produces a detached CMS signature beside the file. A recipient checks it against the SMIMEA pin, so there is no certificate to exchange first.

whisper sign file report.md                       # writes report.md.p7s
whisper sign verify report.md --sig report.md.p7s

whisper verify --signature checks a compact ES256 JWS signed by the same key, which is the shape to use when the artifact is a token rather than a file.

Encrypting to an identity

whisper encrypt looks the recipient's key up over DANE and seals the file to it. Nothing is exchanged in advance, and the sender needs no account.

whisper encrypt --to ae3b051ff3bf7f478.t<tenant>.agents.whisper.online -o secret.wenc plan.txt
whisper decrypt secret.wenc

The container is HPKE: DHKEM on P-256 with HKDF-SHA256, HKDF-SHA256 for key schedule, AES-256-GCM for the payload. The armored form carries the header WHISPER ENCRYPTED MESSAGE.

What the pin proves

The pin proves that one name and one key were published together by the operator of the zone, and that the party answering on that name holds the key. Two limits are worth stating plainly.

A sealed file proves that the recipient's key was used. It does not authenticate the sender, so pair encryption with a signature when you need to know who sent something.

Where Whisper holds the key on the identity's behalf, a signature proves the key was used and not who used it. An identity that supplies its own public key and keeps the private half on its own hardware closes that gap; Vehicle Identities is the shape that does this by default.