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 private signing credential material for the former production key was exposed outside its intended custody. 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. The rotation is complete and current production signing uses the replacement key.
DF-SA-2026-0012026-07-112026-07-11df-ed25519-4cb32e72f333df-ed25519-6ca0de29113b2026-07-11T00:00:00Z2026-07-11T09:49:41ZImpact
Possession of the exposed private credential could allow an unauthorized party to create signatures that are mathematically valid under the former public key. A mathematical signature pass alone would not establish when a record existed, whether the former key was acceptable at that time, or whether the underlying source claim was true.
Dynamic Feed therefore rejects the former key for current policy decisions. This advisory does not assert that unauthorized signing occurred, and it does not designate any former-key receipt as confirmed pre-boundary. Any historical acceptance decision requires independently trusted time evidence and the lifecycle checks described below.
Mitigation
The former production key was retired at 2026-07-11T09:49:41Z and replaced by active key df-ed25519-6ca0de29113b. The active-key endpoint now exposes only the replacement key, while the lifecycle registry preserves the former public key with compromised status so historical bytes remain inspectable without making the former signer acceptable for live traffic.
The former private credential must never be restored. Existing receipt bytes, signatures and canonicalization semantics were not rewritten during mitigation.
Customer and integrator action
Ordinary users: no action is required. The incident is resolved, current production responses use the replacement key, and this advisory does not indicate an active customer-facing outage.
Integrators and security teams: stop accepting the former key for live decisions, remove any policy pin that treats it as active, enforce the machine-readable lifecycle registry, and follow the verifier upgrade guidance below. Keep former public bytes only where explicit historical inspection is required.
Key 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.
Verification steps
- Fetch
/.well-known/signing-key-registry.jsonover an authenticated channel. Confirm registry revision1or later, retain that minimum revision outside the document, and confirm active keydf-ed25519-6ca0de29113b. - Fetch
/.well-known/keysfor current traffic and confirm that it contains the active replacement key, not the compromised former key. - Verify a fresh receipt's Ed25519 signature over its documented canonical bytes, then separately require lifecycle status
active. Signature validity and lifecycle acceptance are distinct checks. - Use a historical former-key fixture to confirm that your verifier can report
CRYPTO_VALIDtogether withLIFECYCLE_REJECTED; never collapse those states into one green result. - Do not use a receipt's own
issued_atvalue or the presence of an RFC 3161/OpenTimestamps field as independent time proof. Accept a pre-boundary claim only after the complete proof and trust path are independently validated.
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 keeps the signed bytes frozen exactly as issued, 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.
Security contact
Report security concerns to [email protected]. The canonical reporting contact, expiry and preferred language are published at /.well-known/security.txt.