1. checks

Each pack runs 15 independent checks: 10 free (mirrored in the public /domain-dossier surface) and 5 paid (Evidence Pack only). Each check returns one of: ok, timeout, not_applicable, error. Only ok results carry findings.

10 free checks

• dns-records-lookup — are authoritative DNS records published correctly for this domain? (SOC 2 CC6.6 · ISO 27001 A.8.20 · NIST SC-20)
• mx-lookup — which mail servers are authoritative for receiving email at this domain? (SOC 2 CC6.7 · ISO 27001 A.8.21 · NIST SC-8)
• spf-checker — does this domain publish an SPF record limiting authorised senders? (SOC 2 CC6.7 · ISO 27001 A.8.20 · NIST SC-8)
• dmarc-checker — does this domain enforce a DMARC policy (quarantine or reject)? (SOC 2 CC6.7 · ISO 27001 A.5.14 · NIST SC-8)
• dkim-lookup — are outgoing emails DKIM-signed under a published selector? (SOC 2 CC6.7 · ISO 27001 A.8.24 · NIST SC-8)
• tls-certificate-checker — is data in transit protected by a valid, current TLS certificate? (SOC 2 CC6.1 · ISO 27001 A.8.24 · NIST SC-8(1))
• redirect-checker — does the public site redirect HTTP to HTTPS without dropping the user? (SOC 2 CC6.6 · ISO 27001 A.8.23 · NIST SC-7)
• security-headers-checker — are HSTS, CSP, X-Frame-Options, and related headers configured? (SOC 2 CC6.6 · ISO 27001 A.8.23 · NIST SC-7(8))
• cors-checker — are cross-origin policies appropriately restrictive at this origin? (SOC 2 CC6.6 · ISO 27001 A.8.23 · NIST AC-4)
• web-surface-inspector — what robots.txt, sitemap, and meta the domain advertises publicly. (SOC 2 CC6.6 · ISO 27001 A.8.9 · NIST CM-7)

5 paid checks

• mta-sts — does this domain enforce MTA-STS to prevent SMTP downgrade attacks? (SOC 2 CC6.7 · ISO 27001 A.8.24 · NIST SC-8)
• tlsrpt — does this domain receive TLS-RPT reports for SMTP failures? (SOC 2 CC7.2 · ISO 27001 A.8.16 · NIST AU-6)
• dnssec — is DNSSEC signing enabled for this zone? (SOC 2 CC6.6 · ISO 27001 A.8.20 · NIST SC-20)
• whois — who owns this domain and when does the registration expire? (SOC 2 CC2.3 · ISO 27001 A.5.20 · NIST PE-2)
• ct-log — which subdomains have certificates issued in CT logs for this root? (SOC 2 CC7.2 · ISO 27001 A.8.16 · NIST SI-4)

2. severity grading

Every ok finding is run through a deterministic rule function that returns one of five severities: info, low, medium, high, critical. Reasons are capped at 120 characters. The rule functions live in the open-source @drwhome/dossier-checks package (MIT) and are versioned alongside this methodology document.

• info — observational; nothing to act on
• low — best-practice deviation; defer or batch
• medium — questionnaire risk; fix in current sprint
• high — likely audit finding; fix before next assessment
• critical — active misconfiguration; fix today

3. subdomain discovery

Subdomains are sourced exclusively from Certificate Transparency logs (crt.sh) for the apex. We do not brute-force DNS, do not port-scan, and do not actively probe. The cap is 100 subdomains per pack; roots with more CT-discoverable hostnames will see the most-recently-issued 100 selected. DNS, TLS, and header checks are run against each subdomain. Email-auth checks (SPF/DMARC/DKIM/MX) run on the apex only.

4. retry + inconclusive policy

Every check has three retries built in. If a check still fails after retries, the pack flags the check as inconclusive rather than presenting a finding, and the order is partially refunded. No silent omissions.

5. signing scheme

Each pack ships with a manifest carrying SHA-256 of pack.pdf and pack.json, ISO-8601 UTC scan timestamp, and the signing key id (drwhome-evp-v1 for v1 packs). The manifest is serialized via deterministic canonical-JSON (RFC 8785) and signed with an Ed25519 detached signature.

Public key: /.well-known/evidence-pack-pubkey.pem · key id: drwhome-evp-v1.

Attestation rung: (a) third-party signed. Not an RFC 3161 trusted timestamp; not an append-only public log. Both are tracked for v2.

6. how to verify a pack

Two equivalent methods. Both run fully offline once the four artifacts and the public key are downloaded.

Option A — single command. Use the bundled CLI:

# from the directory containing pack.pdf, pack.json, manifest.json, manifest.sig
npx tsx https://drwho.me/scripts/verify-pack.ts \
  --pubkey ./evidence-pack-pubkey.pem

Option B — raw OpenSSL. See /evidence-pack#verify for the OpenSSL-only flow. Requires OpenSSL 3+ (LibreSSL ships with macOS and does not implement pkeyutl -rawin).

7. version pinning

Every pack manifest carries signingKeyId identifying which keypair signed it. When v2 ships, v1 packs remain verifiable against the v1 public key (kept indefinitely at /.well-known/evidence-pack-pubkey.pem for current; older keys at /.well-known/evidence-pack-pubkey-v1.pem etc.). The methodology document corresponding to a pack is the page matching the manifest's methodology version.

8. what we do not do

• no DNS brute-forcing or wordlist-based subdomain enumeration
• no port scanning beyond 80/443 (HTTP checks)
• no exploitation, no fuzzing, no auth-bypass probes
• no targets on the public-suffix or hosted-provider denylist (lib/dossier/denylist)