Log Operator Transparency Statement (LOTS) — Template v0.2

This is a fillable template. A conformant HERALD CT log operator copies this file, replaces every <PLACEHOLDER> with operator-specific content, removes guidance comments (lines beginning ), signs the result with the log operator's key, and publishes the result at the well-known URL declared in the operator's HERALD discovery records ([EXT §11.2]).

Conformance requirement. Per [EXT §2.6], a HERALD CT log operator MUST publish a current LOTS. Verifiers MAY refuse logs whose LOTS is stale, missing, or whose declared jurisdiction conflicts with the verifier's policy.

Renewal cadence. LOTS MUST be re-signed at least annually. The signature date is the freshness anchor; a LOTS signed >12 months ago is stale even if its content has not changed.

1. Identity

Log ID: <bytes — the log's content-addressed identifier>
Operator legal entity: <Legal name, e.g. "Acme HERALD Logs Inc.">
Operator country of incorporation: <ISO 3166-1 alpha-2, e.g. "CA">
Operator declared jurisdiction(s) for service of process: <list, e.g. "Ontario, Canada">
LOTS version: <integer, increments on each substantive change>
LOTS signature date: <YYYY-MM-DD>
LOTS validity: valid for 12 months from signature date, or until superseded by a higher-version LOTS, whichever comes first.

2. Key-management posture

Per [EXT §2.6], this section declares the operator's key-management practices in enough detail that verifiers and monitors can assess key custody quality.

2.1 Long-term log signing key

Public key (Ed25519): <base64url>
Generated on: <YYYY-MM-DD>
Generation ceremony: <URL of recording or summary>
Storage posture: <e.g. "YubiHSM 2 cluster, 2-of-3 threshold, geographically distributed across us-east-1, eu-west-1, ap-northeast-1">
Rotation cadence: routine rotation every <N years>. Next scheduled rotation: <YYYY-MM-DD>.

2.2 Witness composition

Number of witnesses required for a key ceremony: <N, e.g. 3>
Composition rules: <e.g. "at least 2 from non-affiliated organisations">
Recording mechanism: <e.g. "video recording stored at archive.example.org/key-ceremonies/2026/">

2.3 Key-compromise response

Detection cadence: <e.g. "continuous monitoring of HSM access logs; alerts on any anomalous authentication">
Response SLO: the operator commits to publishing a log_compromise notice at the well-known URL (§9 below) within <N hours> of detection.
Recovery key (optional): <base64url of recovery pubkey, or "none — operator accepts log retirement on compromise">

3. Maximum Merge Delay (MMD)

Per [EXT §2.3], the MMD is the maximum time between a submission's SCT being issued and its inclusion proof becoming available.

MMD declared: <N hours, default 24h>
MMD rationale: <freeform — typical operator value 30min-2h; explain if longer>
STH publication cadence: at intervals not exceeding MMD; in practice <N minutes/hours>.

A log that consistently fails its declared MMD is non-conformant. The operator commits to publishing real-time MMD-compliance metrics at the monitor endpoint (§5 below).

4. Minimum-metadata profile

Per [EXT §2.2] and [EXT §2.7], HERALD CT logs default to a strictly limited set of log-entry fields. This LOTS declares which profile this log operates under.

4.1 Profile declaration

Profile: minimum | broader-public | private-compliance
If minimum: log entries contain id, parent_hash, trace_hash, hour_bucket_ts. No other fields.
If broader-public: log entries MAY contain additional fields per [EXT §2.7] opt-in escalation. List them: <list>.
If private-compliance: log entries MAY contain broader fields with submitter pre-acknowledgement. Declare submitter-acknowledgement mechanism: <URL or process>.

4.2 Opt-in escalation handling

If minimum profile: the operator commits to rejecting any submission carrying a log_metadata_consent field whose declared opt-in fields are not present in this profile.

If broader-public or private-compliance: the operator publishes the field-acceptance policy at <URL>.

4.3 Submitter-awareness assertion

The operator asserts that all submissions ingested into this log have been submitted by parties aware of this LOTS's profile declaration. Per [EXT §2.7], private compliance logs that ingest without submitter awareness are non-conformant.

5. Gossip endpoints

Per [EXT §2.5], a HERALD CT log MUST participate in at least one gossip channel. This section declares which.

5.1 STH gossip

DNS TXT publication: _herald-sth.<this-log-domain> — <yes/no/operator-controlled>
P2P gossip endpoint: <URL/multiaddr> — <yes/no>. Peer list available at <URL>.
Cross-publication in unrelated logs: the operator publishes its STH series in the following peer logs: <list of log_ids>.

5.2 Trace-genesis gossip (per R-215)

If the operator implements R-215 trace-genesis gossip:

Query endpoint: <URL>/trace_genesis/<trace_id> — <yes/no>.
DNS TXT publication: _herald-trace.<trace_id>.<this-log-domain> — <yes/no>.

5.3 Misbehaviour reporting

The operator commits to consuming gossiped misbehaviour reports about its own log via <URL> and responding within <N hours> of receipt.

6. Monitor and auditor contact

Per [EXT §2.6].

Primary monitor contact (CT-log monitors reporting STH inconsistencies, suspected forks): <URL or email>
Auditor contact (external auditors performing periodic reviews): <URL or email>
Public-affairs contact (press, regulatory): <URL or email>
Security incident reporting (vulnerability disclosure): <URL or PGP-keyed email>
Compulsion-disclosure contact (warrant service): <URL> — separate from operational contact

7. Jurisdictional disclosure

Per [EXT §2.6] and aligned with the Herald Charter's §5 (R-203). For HERALD systemic-risk legibility per D-307 SR-009 (audit-log centralisation).

7.1 Legal entity and applicable law

Legal entity: as declared in §1.
Court of competent jurisdiction: <jurisdiction>
Applicable law for log content: <jurisdiction>

7.2 Compulsion exposure

Subpoena power: the operator will respond to lawful subpoenas under <jurisdiction> law for log entries, audit trails, and operational records.
Gag-order exposure: the operator's jurisdiction permits gag orders binding service providers under <statute or "none under current law">. The operator may receive such orders.
Production orders for cryptographic material: <conditions>.

7.3 Warrant canary

A compulsion-disclosure mechanism per [EXT §2.6]. Choose one:

Affirmative warrant canary: publish a signed monthly statement at <URL> declaring "as of YYYY-MM-DD, the operator has not received any non-disclosable compulsion orders in the preceding month." Cessation of the canary is the disclosure signal.
Reactive disclosure: the operator will publish a notice within <N days> of receiving any disclosable compulsion order.
No canary: the operator declines to publish, accepting the verifier-policy consequence.

8. Incident-disclosure policy

Per [EXT §2.6].

Disclosure timeline: the operator commits to publishing post-mortem of any operational incident affecting log integrity, availability, or correctness within <N days> of mitigation. Categories: STH equivocation, MMD breach, key-compromise, unauthorised access, log-content alteration attempt.
Disclosure channel: <URL of incident registry>
Pre-disclosure notification: the operator commits to notifying monitors and auditors via the contacts in §6 within <N hours> of detection.
Severity taxonomy: the operator's incident severity ratings are at <URL>. Reference taxonomy: SEV-1 (log integrity affected), SEV-2 (availability affected >1h), SEV-3 (operational disruption without integrity impact).

9. Operational well-known URLs

The operator publishes operational data at the following well-known URLs:

STH series: <URL>
SCT issuance endpoint (POST): <URL>
SIP retrieval endpoint (GET): <URL>
Consistency proof endpoint: <URL>
Trace-genesis query (R-215): <URL> — <yes/no>
Real-time MMD metrics: <URL>
Incident registry: <URL>
Compromise notice URL: <URL> — used to publish log_compromise per §2.3.
This LOTS: <URL> (canonical location of this document)

10. LOTS signature

The complete LOTS document is signed by the log operator's long-term key per [EXT §6.3] using domain-separation tag herald.lots.v1 (this tag is added to [EXT §13] when the LOTS primitive itself is normatively introduced; pre-normatively, sign with herald.envelope.v1 and note the tag in the signature attestation).

{
  "lots_signature": {
    "signer":      "<log_id>",
    "alg":         "ed25519",
    "scope":       "operator_attestation",
    "ts":          <Unix seconds at signing>,
    "sig_b64":     "<base64url of Ed25519 signature over the canonical LOTS body>"
  }
}

The canonical LOTS body is the markdown source of this document with this lots_signature block stripped, encoded as UTF-8 with normalised line endings (\n only). Verifiers compute the digest, look up the log_id's pubkey via the standard log discovery path, and verify.

11. Stale-LOTS / supersession policy

This LOTS supersedes any prior LOTS signed by the same log operator. Prior LOTS remain available at:

<URL of historical LOTS archive>

Verifiers MUST treat this LOTS as authoritative for the 12 months following its signature date, or until a higher-version LOTS is published, whichever comes first.

Appendix A — Worked example: independent CT log operator

# Identity
log_id: log:exmplct.v1.qwer4...
operator_entity: ExampleCT Logs Foundation (Ireland non-profit)
charter_version: 5
lots_signature_date: 2026-04-01

# Key management
log_pubkey: <base64url>
storage_posture: AWS CloudHSM cluster, 2-of-3 threshold across eu-west-1, eu-central-1, eu-north-1
rotation_years: 3
witnesses_required: 3
recovery_key: <base64url>

# MMD
mmd_hours: 1
sth_cadence_minutes: 30

# Profile
profile: minimum
opt_in_escalation: rejected by default

# Gossip
sth_dns_txt: yes (_herald-sth.exmplct.example.org)
sth_p2p_endpoint: gossip.exmplct.example.org/p2p
trace_genesis_endpoint: yes (https://exmplct.example.org/trace_genesis/)

# Contacts
monitor: monitor@exmplct.example.org
auditor: auditor@exmplct.example.org
security: security@exmplct.example.org (PGP key fingerprint: ...)
compulsion: legal@exmplct.example.org

# Jurisdiction
court: High Court of Ireland
applicable_law: Ireland (Data Protection Act 2018; EU GDPR)
gag_exposure: none under current Irish law
canary: monthly affirmative at https://exmplct.example.org/canary

# Incidents
disclosure_timeline_days: 14
incident_registry: https://exmplct.example.org/incidents
severity_taxonomy: per ISO/IEC 27035

# URLs
sth_series: https://exmplct.example.org/sth
sct_endpoint: https://exmplct.example.org/sct
sip_endpoint: https://exmplct.example.org/sip
consistency: https://exmplct.example.org/consistency
mmd_metrics: https://exmplct.example.org/mmd
compromise_notice: https://exmplct.example.org/compromise
lots_url: https://exmplct.example.org/lots/v5

Appendix B — Common pitfalls

MMD that's longer than the declared SCT-to-SIP turnaround. A log declaring 24h MMD but typically delivering SIPs within 1h is mis-declaring. Choose the value that bounds the worst-case real behaviour.
No gossip participation. A log that doesn't gossip its STHs is detectable as a fork-prone single point of failure. Declaring "no gossip" is conformant only in tightly scoped private compliance contexts; for public logs it is non-conformant.
Declaring private-compliance profile without a submitter-acknowledgement mechanism. This is non-conformant by [EXT §2.7]. Either provide the acknowledgement mechanism or operate under the broader-public profile with explicit field declarations.
Single-jurisdiction infrastructure with cross-jurisdictional canary claim. A log running entirely on cloud infrastructure in one jurisdiction cannot honestly claim canary independence from that jurisdiction's compulsion. Disclose infrastructure jurisdiction explicitly.
No recovery key and no operator-retirement plan. A log that loses its key with no recovery has effectively self-destructed. Either provide a recovery key (with the same custody discipline) or document the operator-retirement protocol so verifiers know what happens.
Stale LOTS. Annual re-signing is substantive: re-review every section, not just the date.

Appendix C — Verifier checklist

When evaluating a LOTS, a verifier or reputation system should:

[ ] Freshness: LOTS signature date within last 12 months.
[ ] All eleven sections present and substantively filled. Skipping a section is non-conformant.
[ ] Profile honesty: declared profile matches observed log behaviour over a sample period (e.g. inspect 10 random log entries; do their fields match the declared profile?).
[ ] MMD honesty: declared MMD matches observed MMD-compliance metrics. A log declaring 24h MMD whose published metrics show 26h average is non-conformant.
[ ] Gossip participation: at least one declared gossip channel is observable producing STHs from this log.
[ ] Jurisdiction matches verifier policy. If the verifier's policy excludes certain jurisdictions, reject.
[ ] Canary status: if affirmative, the most recent canary is dated within the declared cadence.
[ ] Incident transparency: the incident registry has been used (i.e. is not an empty page that hasn't received a single entry in two years — that's either suspicious or the operator hasn't operated long enough to have incidents).
[ ] Prior-LOTS availability: the historical archive URL is reachable.
[ ] LOTS signature verifies against the log's published pubkey.

Appendix D — Relationship to Herald Charter (R-203)

The Herald Charter and the LOTS share structure: both are operator-transparency documents, both are 12-month freshness, both have warrant canary three-option mechanism, both are signed by the operator's long-term key.

Differences:

Aspect	Herald Charter (R-203)	LOTS (T-106)
Subject	Herald operator	CT log operator
Issuance scope	What attestations the Herald signs and under what evidence	What log entries the log accepts and under what profile
Cross-signing policy	Material (cartel risk per D-307 SR-002)	Mostly N/A (logs aren't cross-signers in the same sense)
MMD declaration	N/A	Critical (defines the log's freshness contract)
Profile declaration	Implicit	Explicit (minimum/broader-public/private-compliance)
Renewal	Annual	Annual
Canary	Required	Required

A single operator may run both a Herald and a CT log; their Charter and LOTS are separate documents (different URLs, different signatures, different profiles).

— LOTS template v0.2, by T-106 (driver-claude), 2026-05-05.

Maintained at templates/LOTS.md in the HERALD repository.

Log Operator Transparency Statement (LOTS) — Template v0.2