← Back to Research

Architecture

Components

1. User Key Management

User Identity
├── Primary Key (ed25519)
│   ├── Public key published in DNS/LDAP
│   └── Private key stored in user's client
├── Subkeys (short-lived, rotatable)
│   ├── 30-day validity
│   └── Signed by primary key
└── Revocation List
    └── Published at well-known URL

2. SMTP Extension

MAIL FROM:<user@msgs.global> AUTH-PROOF=<base64-encoded-proof>

Proof Structure:
{
  "version": "1.0",
  "sender": "user@msgs.global",
  "timestamp": 1234567890,
  "message_id": "unique-id",
  "signature": "ed25519-signature",
  "key_id": "subkey-fingerprint",
  "chain": ["forwarding-signatures"]
}

3. Verification Process

def verify_authenticated_routing(proof, message):
    # 1. Extract proof from MAIL FROM
    auth_proof = parse_auth_proof(proof)

    # 2. Fetch public key
    public_key = fetch_user_key(auth_proof.sender, auth_proof.key_id)

    # 3. Check revocation
    if is_revoked(auth_proof.key_id):
        return FAIL_REVOKED

    # 4. Verify signature
    if not verify_signature(auth_proof, public_key):
        return FAIL_SIGNATURE

    # 5. Check timestamp (prevent replay)
    if abs(now() - auth_proof.timestamp) > 300:  # 5 min window
        return FAIL_TIMESTAMP

    # 6. Verify chain for forwarded messages
    if auth_proof.chain:
        for hop in auth_proof.chain:
            if not verify_hop(hop):
                return FAIL_CHAIN

    return PASS

DNS Records

; User public key publication
_authroute.user._domainkey.msgs.global. IN TXT (
  "v=AUTHROUTE1; "
  "k=ed25519; "
  "p=MCowBQYDK2VwAyEA..." # base64 public key
)

; Revocation list URL
_authroute-revoke.msgs.global. IN TXT "url=https://msgs.global/.well-known/authroute-revocations"

Message Headers

Authentication-Results: msgs.global;
    authroute=pass
    header.from=user@msgs.global
    key-id=abc123

Authenticated-Routing: v=1; s=user; d=msgs.global;
    k=abc123; t=1234567890;
    sig=base64signature

Key Management

Key Generation

# Generate primary key (long-term, offline storage)
openssl genpkey -algorithm ed25519 -out primary.key

# Generate subkey (active use)
openssl genpkey -algorithm ed25519 -out subkey.key

# Sign subkey with primary
sign_subkey(primary.key, subkey.key, valid_until="2026-04-07")

Key Rotation

  • Subkeys: 30-day automatic rotation
  • Primary keys: Annual rotation recommended
  • Emergency revocation: Immediate via revocation list

Key Distribution

  1. DNS (primary method)
  2. LDAP (enterprise integration)
  3. Key server (optional, for discovery)
  4. In-message header (for one-off verification)

Protocol Flow

Sending

1. User composes message in client
2. Client generates auth proof:
   - Sign (timestamp + message_id + sender)
   - Include key_id reference
3. Client includes AUTH-PROOF in MAIL FROM
4. Receiving MTA verifies proof
5. Adds Authentication-Results header

Forwarding

1. Forwarder receives authenticated message
2. Forwarder adds own signature to chain:
   chain: [original_auth, forwarder_auth]
3. Maintains original authentication
4. Recipient can verify entire path

Security Considerations

Threat Model

  • Replay attacks: Mitigated by timestamp validation
  • Key compromise: Mitigated by short-lived subkeys
  • MITM: Prevented by signature verification
  • Revocation delay: Max 5-minute window for emergency revocation

Privacy

  • Public keys are publicly discoverable (like DKIM)
  • Signatures reveal sender identity (by design)
  • Metadata protection out of scope (see Zero-Knowledge Delivery initiative)

Performance Impact

  • Key lookup: ~50ms (DNS/cache)
  • Signature verification: ~1ms (ed25519)
  • Total overhead: <100ms per message

Backward Compatibility

  • Falls back to traditional DKIM if AUTH-PROOF not supported
  • Non-supporting MTAs ignore extension
  • No breaking changes to existing infrastructure

Implementation Phases

Phase 1: Core Infrastructure

  • User key generation and storage (LDAP integration)
  • DNS publication mechanism
  • Revocation list service

Phase 2: SMTP Extension

  • Postfix SMTP auth-proof policy service
  • Verification daemon
  • Authentication-Results header injection

Phase 3: Client Integration

  • Webmail signing support
  • API for third-party clients
  • Key management UI

Phase 4: Advanced Features

  • Chain-of-custody for forwards
  • Delegated signing for services
  • Integration with compliance/audit logs