Bind did:hive to the TLS leaf you already have.

Hive operates an ACME-style intermediate CA that issues short-lived X.509 certificates linking a did:hive:* identity to a service's existing TLS identity via the Subject Alternative Name URI extension. Every browser, every load balancer, every audit tool already understands it. No new transport. No new client. The trust is legible to the world as it is.

Enroll in 4 lines See where this fits

— Enrollment — RFC 8555 with one extension

If you already run certbot, you already know this.

# Enroll a service for a did:hive-bound cert. Standard ACME flow.
certbot certonly \
  --server https://ca.thehiveryiq.com/acme/directory \
  --domain api.your-service.com \
  --hive-did did:hive:your-service-001 \
  --hive-pubkey ed25519:<your_published_key>

# The issued cert includes a SAN URI: did:hive:your-service-001
# Validity: 30 days. Auto-rotation via standard ACME renewal.
# Chain: leaf -> Hive Intermediate CA -> public trust anchor

— Endpoints

Three URLs. That is the whole CA surface.

GET ca.thehiveryiq.com/acme/directory ACME directory document per RFC 8555 §7.1.1

POST ca.thehiveryiq.com/acme/new-order Order with optional did-binding extension

GET ca.thehiveryiq.com/intermediate.crt Hive intermediate CA — public chain anchor

— Spec

One page. Standards-compatible. Deliberately conservative.

BASE STANDARD ACME RFC 8555 — exact compliance with directory, account, order, authorization, challenge, finalize, certificate endpoints
CHALLENGE TYPES http-01, dns-01, tls-alpn-01 — all standard
EXTENSION hive-did-binding-01 — proves control of a did:hive by signing the ACME order nonce with the DID's published Ed25519 key
CERT FORMAT X.509 v3, Ed25519 leaf, SAN URI extension carries did:hive:* identifier
VALIDITY 30 days. ACME auto-rotation. No human in the loop.
CHAIN ANCHOR rooted under a publicly-anchored intermediate. Long-term path to inclusion in the Mozilla/Apple/Microsoft trust stores.
RECEIPT LINK every issuance is itself a Hive receipt submitted to ct.thehiveryiq.com — the CA is its own first customer
REVOCATION standard CRL + OCSP, plus log-based negative attestation for agents that read the transparency log
PRIVATE KEY HANDLING issuer's private keys held in HSM with quorum control. PQ co-signature with ML-DSA-65 behind feature flag.

— Why this matters for HARM

The CA is the bridge to everything already deployed.

An agent reading the Hive transparency log sees signed receipts. But a browser visiting api.your-service.com sees a TLS handshake. The Hive CA makes both views consistent: the leaf certificate the browser validates is the same identity the agent reasons over.

This is the legibility piece Cloudflare, Datadog, every SIEM, every enterprise procurement team already speaks. We do not ask them to adopt a new transport. We hand them a cert chain their existing tools accept on day one, and the cert chain happens to bind a did:hive into the place every modern toolchain already inspects.

— What an issued cert looks like

Standard X.509. Plus one SAN URI.

Certificate:
    Data:
        Version: 3 (0x2)
        Issuer: CN=Hive Civilization Intermediate CA G1
        Validity:
            Not Before: 2026-05-29 00:00:00 UTC
            Not After : 2026-06-28 00:00:00 UTC
        Subject: CN=api.your-service.com
        Subject Public Key Info:
            Public Key Algorithm: Ed25519
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:api.your-service.com,
                URI:did:hive:your-service-001      ← the binding
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            CT Precertificate SCTs:
                Log: ct.thehiveryiq.com/v1           ← own log inclusion
                Log: ct.googleapis.com/logs/argon2026  ← public CT log mirror

One enrollment. Existing tools all light up.

Bind your did:hive to the cert your browser already trusts. The trust is portable. The receipts are global.

/harm — the full mesh /ct — the log /signal — the thesis