# LAVS-001.3 Offline verification

| | |
|---|---|
| **Status** | Draft spec extension (LAVS-001.3) |
| **Version** | 1.0 (draft) |
| **Date** | 2026-05-27 |
| **License** | CC BY 4.0 |
| **Applies to** | LAVS-001.3+; backward-compatible with LAVS-001.0/1/2 |
| **Companion sections** | `LAVS-001.md` §8.2 (signature), [`KEYS.md`](./KEYS.md), [`CRC-SCOPE.md`](./CRC-SCOPE.md) |

This document specifies offline verification behavior for LAVS-001 implementations. It is the answer to the question implementers in the museum, gallery, embedded, or air-gapped use cases will ask: **what happens when the public-key URL is unreachable?**

The current spec (LAVS-001.0 through 1.2) assumes verifiers fetch the public key from a live HTTPS URL ([`https://lavos-pubkey.projectlavos.com/pubkey.pem`](https://lavos-pubkey.projectlavos.com/pubkey.pem)) before validating signatures. This assumption breaks for any verifier that runs without network access — gallery kiosks, embedded viewers, air-gapped collections, network-isolated demo environments.

LAVS-001.3 (this extension) defines the cache, fallback, and pinning mechanisms that let verifiers operate offline while maintaining cryptographic integrity guarantees.

---

## 1. The use cases

These are real verifier-side scenarios LAVS-001.3 addresses:

**1.A — Gallery kiosk.** A museum installs a touchscreen kiosk displaying a Lavos edition. The kiosk has no internet (intentionally, for security or network-isolation reasons). The verifier must validate the signature without reaching the published pubkey URL.

**1.B — Embedded viewer in a printed catalog.** A QR code on a printed page launches a viewer in the visitor's phone browser. The phone has internet, but the viewer should be able to function even when network access is flaky (subways, basements, conferences with overloaded WiFi).

**1.C — Air-gapped collector environment.** A serious collector keeps their digital art on a machine with no internet. The verifier must run entirely offline.

**1.D — Software preservation use case.** Twenty years from now, the published pubkey URL may not exist. A LAVS edition shipped today should remain verifiable in 2046 even if `lavos-pubkey.projectlavos.com` is gone. (See §6.)

---

## 2. The three mechanisms

LAVS-001.3 specifies three additive mechanisms that work together:

1. **Cache.** Verifiers MAY cache fetched public keys and revocation lists. This document specifies the cache TTL and freshness rules.
2. **Pinning.** Verifiers MAY pin specific public keys, refusing to fall back to fetched keys even if available. This is the highest-integrity mode for environments where the verifier operator wants no surprises from key rotation.
3. **Embedded bundle.** Verifiers MAY ship with a pre-bundled public key and revocation list, sufficient to verify any edition signed under that bundled identity without ever reaching the network.

A verifier MAY implement any subset of these. Implementations SHOULD document which mechanisms they support.

---

## 3. Cache mechanism

A verifier with network access MAY cache fetched artifacts as follows:

| Artifact | TTL (max) | Refresh trigger |
|---|---|---|
| Public key (`pubkey.pem`) | 7 days | Cache miss; explicit refresh request |
| Revocation list (`revoked.txt`) | 24 hours | Cache miss; explicit refresh request |
| Rotation policy (`rotation-policy.md`) | 30 days | Cache miss; explicit refresh request |

**Rationale for the TTLs:**

- **Public key (7d).** Keys do not rotate routinely (per [`KEYS.md`](./KEYS.md) §3); event-driven rotation only. A 7-day cache means a verifier offline for a week still has fresh keys; offline for longer means the verifier becomes potentially stale on key changes but never on signatures.
- **Revocation list (24h).** Revocations may happen between routine refreshes; a verifier offline for > 24h risks displaying editions signed under a recently-revoked key. The 24h TTL is short enough that even infrequent verifiers usually refresh.
- **Rotation policy (30d).** Policy changes rarely. Cache aggressively.

**Cache miss behavior:**

When the cache is missed AND the URL is unreachable, the verifier MUST fall back to the embedded bundle (if present) or the pinned key (if configured). If neither is available, the verifier:

- For unsigned editions (no `signatureAlgorithm`): renders normally; no signature verification needed.
- For signed editions: refuses to render OR renders with a "signature not verified — network unreachable" warning, per the verifier's chosen security posture (Strict vs Lenient per LAVS-001 §13).

**Cache invalidation:**

The verifier SHOULD provide a way for the user to manually invalidate the cache. Operators in gallery / curation contexts will sometimes need to force-refresh after a known rotation event.

---

## 4. Pinning mechanism

A verifier MAY be configured to **pin** specific public keys. A pinned verifier:

- Validates signatures only against the pinned key (or set of pinned keys).
- Refuses to fall back to fetched keys, even if the cache is fresh.
- May display editions signed under non-pinned keys with a "signed under untrusted key" warning, or refuse outright per the verifier's strict mode.

Pinning is the **highest-integrity mode**. It is the right choice for:

- Operators who want explicit control over which keys are trusted (museum curators, professional collectors, marketplace operators).
- Environments where the verifier ships as part of a longer-lived product and the operator wants to opt into key rotations consciously rather than passively.

**Pin format:** verifiers SHOULD accept pinned keys as either:

- Raw 32-byte ed25519 public keys (hex-encoded for human review).
- PEM-encoded SubjectPublicKeyInfo blobs (matching the format served at the canonical URL).
- SHA-256 fingerprints of the PEM-encoded key (32 bytes hex; useful for compact display).

A verifier supporting multiple pin formats MUST treat them as equivalent — a public key pinned by fingerprint is the same key as the matching PEM-encoded key.

**Rotation under pinning:** when the publisher rotates a key (per [`KEYS.md`](./KEYS.md) §2), pinned verifiers MUST be manually updated by their operator. Automatic pin updates defeat the purpose of pinning. The operator's update workflow is out of scope of this spec but SHOULD be supported by the verifier's UI.

---

## 5. Embedded bundle mechanism

A verifier MAY ship with a **bundled identity package** sufficient to verify offline without ever fetching from the network. The bundle is a directory or archive containing:

```
identity-bundle/
  pubkey.pem            — the current active signing public key
  revoked.txt           — the revocation list as of bundle creation time
  rotation-policy.md    — the rotation policy as of bundle creation time
  bundle-metadata.json  — { "publisher": "Project Lavos LLC",
                            "bundled_at": "2026-05-27T01:30:00Z",
                            "pubkey_fingerprint": "<sha256 hex>",
                            "trusted_until": "2027-05-27T00:00:00Z" }
```

**`trusted_until`** is a soft expiration. After this date, the verifier SHOULD warn the user that the bundled identity may be stale and recommend a refresh. The verifier MUST NOT refuse to validate signatures based solely on the bundle being past its `trusted_until` — bundled identity is the offline fallback, not the primary truth source.

**Bundle distribution.** The publisher (Project Lavos LLC for the canonical case) SHOULD make bundled identity packages downloadable from the published URL alongside `pubkey.pem`. The bundle is itself signed by the same identity, so a verifier downloading a bundle can verify the bundle's authenticity using the bundled key (chicken-and-egg solved by trusting the original TLS-certified HTTPS fetch as the root of trust).

**Bundle lifecycle.** Bundles are NOT keys themselves; they are snapshots. The pubkey rotation events (per [`KEYS.md`](./KEYS.md) §2) update the canonical URL; bundles are re-issued by the publisher to reflect those updates. Verifiers using bundles SHOULD refresh their bundle when:

- The current bundle is past its `trusted_until` date.
- The publisher announces a key rotation (publisher MAY notify bundled-verifier operators via email, signed announcement on a website, or other out-of-band channel).
- The verifier operator's policy requires periodic refresh.

---

## 6. The 2046 problem — long-term verifiability

The use case 1.D ("software preservation") asks a harder question: how does a LAVS edition signed in 2026 remain verifiable in 2046?

**Short answer:** the bundled identity mechanism (§5) is the load-bearing piece. A verifier that ships in 2026 with a bundled identity will continue to verify 2026-signed editions in 2046 regardless of whether `lavos-pubkey.projectlavos.com` still exists.

**Long answer:** there are five long-term integrity layers, in increasing order of independence from infrastructure:

1. **TLS HTTPS fetch (primary).** Works while the published URL exists with a valid certificate.
2. **Cache.** Works for 7-day windows of offline operation.
3. **Pinning.** Works as long as the operator's pinned key is correct and the verifier exists.
4. **Embedded bundle.** Works as long as the bundle's pubkey + revocation list are accurate at edition-signing time.
5. **Cryptographic primitive durability.** ed25519 itself remains secure absent a major mathematical break. Even if the publisher disappears, the math holds; a signed edition's signature still demonstrates "the holder of the private key at signing time signed these bytes."

Implementers building for long-term preservation use cases SHOULD layer multiple mechanisms. A museum that ships a LAVS verifier in a kiosk in 2026 should:

- Embed the 2026-current bundle.
- Pin the current public key explicitly.
- Verify each edition's signature against the pinned key.
- Refuse fallback to any non-bundled key.

This verifier will continue to validate 2026-signed editions for as long as the verifier itself runs.

The publisher's commitment is to keep the canonical URL functional and the bundled-identity packages downloadable for as long as the publisher exists. The publisher cannot guarantee the URL will exist in 2046; the embedded-bundle mechanism is the answer to that uncertainty.

---

## 7. Spec impact

LAVS-001.3 does NOT change the format itself. No new property IDs, no new Core types, no new feature flags. The format bytes of a signed edition are identical whether the verifier is online or offline.

What LAVS-001.3 changes is **verifier behavior**. Verifiers conforming to LAVS-001.3:

- MUST implement at least one of the three mechanisms (cache, pinning, or embedded bundle) for offline operation.
- SHOULD document in their user-facing materials which mechanisms they support.
- SHOULD provide a clear UI for the user to inspect the current trust state ("verified against pinned key X"; "verified against bundled identity Y (bundled_at 2026-05-27)"; "verified against cached key Z (cache expires in 4 days)").

An online-only verifier MAY conform to LAVS-001.0/1/2 without implementing LAVS-001.3 — the spec is layered, and verifiers that don't claim offline support don't need to provide it.

---

## 8. Implementer checklist

When building a LAVS-001.3-conformant verifier:

1. **Decide the use case.** Online-only? Cache-supported? Pinned? Bundled? The implementation cost grows roughly linearly with the number of mechanisms supported.
2. **Implement at least one mechanism** for offline operation.
3. **Document the choice** in your verifier's user-facing materials. Trust transparency is a feature; opacity is a vulnerability.
4. **Test offline behavior** by simulating network failure and confirming the verifier behaves correctly per its declared strict/lenient mode.
5. **For pinned verifiers**, provide a clear operator workflow for adding, removing, and rotating pinned keys.
6. **For bundled verifiers**, surface the `bundled_at` and `trusted_until` dates in the UI so the user knows how stale their trust state is.

---

## 9. Cross-references

- [`KEYS.md`](./KEYS.md) §2 — Compromise rotation procedure (defines when key rotations occur).
- [`KEYS.md`](./KEYS.md) §6 — Signing prerequisites (the publisher's commitment to publishing public key + revocation list).
- [`IMPLEMENTER-FAQ.md`](./IMPLEMENTER-FAQ.md) §2 — Operational guidance for verifiers (full-file vs edition-block integrity).
- [`CRC-SCOPE.md`](./CRC-SCOPE.md) — Why CRC32 is not the full-file integrity primitive (signature is; signature requires the public key; the public key may be offline; hence this document).

---

*This document is draft as of the date above. Implementer feedback will refine the cache TTLs, the bundle format, and the operational workflows. The mechanism boundaries (cache / pinning / bundle) are unlikely to change; the parameters within each mechanism may. Cross-link this spec extension from [`LAVS-001.md`](./LAVS-001.md) §8.2 in a subsequent commit once the design is stable.*