This page intentionally contains implementation-level security detail. The customer-facing system status page reports operational impact, incidents and maintenance without exposing integration internals.
Production signing-key rotation
Dynamic Feed rotated its production Ed25519 data-signing key after exposure of the former signing credential. The former key is classified as compromised; it is retained only as public historical material with explicit lifecycle status and must not be accepted for live policy decisions.
df-ed25519-4cb32e72f333df-ed25519-6ca0de29113b2026-07-11T00:00:00ZKey lifecycle and rotation history
The compatibility endpoint at /.well-known/keys publishes only the active key. Historical public bytes and lifecycle state remain in /.well-known/signing-key-registry.json. The former private key must never be restored or used as rollback.
The emergency cutover completed on 11 July 2026. Existing signed receipt bytes, historical signature blocks, canonicalization rules and notary rows were not rewritten. Registry revision 1 records the active and compromised lifecycle states.
Verifier upgrade guidance
The affected versions accepted key bytes without enforcing the published lifecycle state. Do not use them as a policy or actuation gate. Install at least the fixed version shown after confirming that the package is available from its registry and that its provenance matches the reviewed release. Prepared repository source alone is not a published package.
| Package | Affected | Required minimum |
|---|---|---|
PyPI dynamicfeed-verify | ≤ 1.0.2 | ≥ 1.0.3 |
npm @dynamicfeed/verify | ≤ 1.0.1 | ≥ 1.0.2 |
npm @dynamicfeed/tools | ≤ 0.1.0 | ≥ 0.1.1 |
crates.io df-verify | ≤ 0.1.1 | ≥ 0.1.2 |
crates.io dynamicfeed-verify | 1.0.0 | ≥ 1.0.2 |
For crates.io dynamicfeed-verify, version 1.0.2 was published at 2026-07-11T16:14:45.939696Z and clean-install verified from the registry. Reviewed source is verifier commit 95e033efd252e9e97029c0ef97a3ccddad9b6351, tagged rust-v1.0.2, with published crate artifact SHA-256 798bc660b4e9abe25c7f62bcd8007cf1897ca0d8607d975d8b9ba0b8d841d019.
The clean-install lifecycle check returned POLICY_ACCEPTED for the active key and CRYPTO_VALID with LIFECYCLE_REJECTED for the compromised former key. This confirms the tested Rust package only; it does not complete the wider signing-key rotation or provide independent timestamp-proof validation.
Every other listed upgrade remains availability-gated until its fixed package is published and independently clean-installed from the named registry. dynamicfeed-bundle-verify is not currently published on crates.io; version 0.2.0 is prepared source only and cannot be treated as an available upgrade until its df-verify 0.1.2 dependency is published and an install-from-registry test passes.
Developer migration steps
- Upgrade to the minimum supported verifier version listed above only after confirming registry availability and release provenance.
- Use
/.well-known/keysfor active traffic and enforce the lifecycle policy in/.well-known/signing-key-registry.json. - Reject the former key for live policy decisions even when its signature mathematics pass.
- Retain historical public bytes only for explicit historical inspection; never restore the former private key.
- Test one fresh active-key receipt and one archived former-key fixture. The expected states are
POLICY_ACCEPTEDandLIFECYCLE_REJECTED, respectively.
Cryptographic rationale and historical receipts
A mathematically valid signature from the former key does not establish when a receipt existed or make that signer acceptable after compromise. A receipt's own issued_at value is not independent time evidence.
Any pre-boundary conclusion requires a separately trusted, independently validated timestamp or checkpoint that commits to the complete signed record, including its signature, strictly before the conservative boundary. Dynamic Feed does not currently claim complete independent cryptographic validation for every RFC 3161 or OpenTimestamps proof. This advisory does not designate any former-key receipt as confirmed pre-boundary.
DFEP security notes
DFEP remains a working draft and target architecture. Existing legacy receipts do not claim DFEP or DFR/1 conformance. The draft security direction preserves immutable signed bytes, explicit source identity, versioned canonicalization, lifecycle-aware verification and additive proof upgrades.
No protocol profile may treat a key embedded in an untrusted bundle as its own trust root. Timestamp artifact presence is distinct from complete independent verification, and conflicting evidence must remain inspectable rather than silently rewritten.