feat(seal): report a seal's issuer and device leg

.cargo/audit.toml

@@ -11,9 +11,38 @@
 # contract.
 
 [advisories]
-# Empty by design. RUSTSEC-2023-0071 (`rsa`, reached only through the
-# never-enabled `sqlx-mysql`) was suppressed here until the sqlx 0.8 -> 0.9
-# bump pruned both crates from Cargo.lock — exactly the `release-on` condition
-# that entry recorded. The advisory no longer fires, so the entry is deleted
-# rather than left suppressed.
-ignore = []
+# --- RUSTSEC-2023-0071 --------------------------------------------------
+# crate:      rsa 0.9.10
+# path:       dpp-seal -> x509-verify -> rsa
+# class:      reachable-but-mitigated
+# rationale:  The Marvin Attack is a timing sidechannel in RSA **private
+#             key** operations — it recovers a key by timing an attacker's
+#             decryption or signing queries against it. This workspace
+#             performs no RSA private-key operation anywhere: it holds no
+#             RSA key at all. Its own keys are Ed25519 (JWS) and P-256 (the
+#             local seal backend), and `rsa` is reached solely to verify a
+#             certificate authority's signature over a seal certificate,
+#             using a public key read out of a published EU Trusted List.
+#             Verification touches no secret, so there is no key to recover
+#             and no oracle to time. `x509-verify` is pinned to the
+#             algorithms measured in the published lists — RSA is 96.8% of
+#             373 qualified-CA certificates, so dropping RSA is not an
+#             option; see crates/dpp-seal/tests/ca_key_survey.rs.
+#             THIS ENTRY IS VOID THE MOMENT ANY RSA PRIVATE-KEY OPERATION
+#             APPEARS — signing, decrypting, or key generation. The
+#             mitigation is the absence of a private key, not a workaround,
+#             and `scripts/no-rsa-private-key.sh` (in `just check`) holds it:
+#             it fails if any workspace crate takes `rsa` as a direct
+#             dependency, or if RSA private-key material appears in our own
+#             source. The claim is therefore checked rather than asserted.
+# anchor:     scripts/no-rsa-private-key.sh::RsaPrivateKey
+# owner:      LKSNDRTMLKV
+# recorded:   2026-09-15
+# expires:    2027-03-15
+# release-on: `rsa` ships a constant-time fix, or `x509-verify` is replaced
+#             by a verifier whose RSA implementation carries no advisory
+#             (ring / aws-lc-rs), or this workspace stops verifying RSA
+#             signatures.
+ignore = [
+    "RUSTSEC-2023-0071",
+]

.env.example

@@ -174,21 +174,31 @@ RESOLVER_BASE_URL=https://id.odal-node.io
 #
 # SEAL_EIDEASY_HMAC_KEY is shown once, when generated in eID Easy's Eseal
 # Settings. Treat it like MTLS_PROXY_SHARED_SECRET: this file is mode 600.
-# SEAL_CONFORMANCE_LEVEL is the baseline level every seal request asks for --
-# B, T, LT or LTA -- and it defaults to LT. LT is the first level that stays
-# verifiable after the signing certificate expires, which is what a passport
-# needs, since its retention lock is permanent. An unrecognised value fails the
-# boot rather than falling back to the default.
+# SEAL_CONFORMANCE_LEVEL is the baseline level every seal request asks for —
+# B, T, LT or LTA. It defaults to LTA, and the default belongs to the BACKEND
+# rather than to the node: every backend wired today reaches LTA, and one that
+# does not would name its own instead of forcing the node down to meet it.
 #
-# THE TWO MUST AGREE, AND THE NODE NOW REFUSES TO BOOT IF THEY DO NOT. A request
-# the backend does not advertise is refused before the (billable) call, so a node
-# left on the default LT while its eID Easy client is enabled only for
-# CAdES_BASELINE_T would seal nothing. That used to be silent — rows retried,
-# exhausted hours later, and the passports stayed published-but-unsealed while
-# GET /vault/api/v1/seal reported sealingConfigured: true throughout. The
-# mismatch is knowable at boot, so it is now checked there and the error names
-# the axis that failed. Either have eID Easy enable CAdES_BASELINE_LT for the
-# client and leave the default alone, or set both to the same level deliberately.
+# LTA is the level that stays verifiable after the signing certificate expires
+# and carries an archival timestamp besides, which is what a passport needs
+# since its retention lock is permanent. An unrecognised value fails the boot
+# rather than falling back, so a misspelled LTA cannot quietly seal lower than
+# you think it does.
+#
+# YOU NO LONGER NEED TO SET THE PROFILE TO MATCH. With
+# SEAL_EIDEASY_SIGNATURE_PROFILE unset it is derived from the level above, so
+# the two cannot contradict. They used to: the level defaulted to LT while the
+# profile defaulted to CAdES_BASELINE_T, so a node configured for the provider
+# and nothing else refused to boot — correctly, since every published passport
+# would have enqueued a row that could never drain, but the error pointed at
+# LOWERING the level to meet a default nobody had chosen.
+#
+# A profile you DO pin is left alone, because naming one says something
+# specific. The node still refuses to boot when it contradicts the level, and
+# names the axis that failed. That refusal is why this is not silent any more:
+# it used to mean rows retried, exhausted hours later, and passports left
+# published-but-unsealed while GET /vault/api/v1/seal reported
+# sealingConfigured: true throughout.
 #
 # There is deliberately NO variable for the seal *mode*. It states whose
 # attestation the seal is — a provider holding the key on your behalf, or your
@@ -198,8 +208,9 @@ RESOLVER_BASE_URL=https://id.odal-node.io
 # SEAL_EIDEASY_BASE_URL=https://test.eideasy.com     # sandbox; prod = https://id.eideasy.com
 # SEAL_EIDEASY_CLIENT_ID=
 # SEAL_EIDEASY_HMAC_KEY=
-# SEAL_EIDEASY_SIGNATURE_PROFILE=CAdES_BASELINE_T    # optional; must be enabled for the client
-# SEAL_CONFORMANCE_LEVEL=LT                          # optional; must match the profile above
+# SEAL_EIDEASY_SIGNATURE_PROFILE=CAdES_BASELINE_LTA  # optional; derived from the level when
+#                                                    # unset; must be enabled for the client
+# SEAL_CONFORMANCE_LEVEL=LTA                         # optional; this is already the default
 #
 # --- Local development sealer (no QTSP, no credentials, no legal weight) -----
 # A real detached CAdES signature over the passport's JWS digest, under a
@@ -212,10 +223,19 @@ RESOLVER_BASE_URL=https://id.odal-node.io
 # enrolment is outstanding. It is not a substitute for a qualified seal and
 # produces nothing fit for compliance use.
 #
-# BOTH LINES ARE REQUIRED. The local sealer advertises BaselineB only — it is
-# self-signed, with no timestamp, no revocation data and no archival timestamp —
-# so it cannot honour the LT default. Setting SEAL_PROVIDER=local without
-# SEAL_CONFORMANCE_LEVEL=B now fails the boot naming exactly that.
+# IT NOW EMITS THE FULL LTA STRUCTURE, so it needs no lower level set beside
+# it. The node generates a local timestamping authority next to its sealing key,
+# and a seal carries what ETSI EN 319 122-1 Table 1 requires at each level: a
+# signature timestamp from T, revocation material in SignedData.crls from LT,
+# and an archive timestamp at LTA.
+#
+# That is the SHAPE of a long-term seal, not the substance of one. The
+# signature, the timestamps and the revocation list are all made by keys this
+# node generated for itself. The TSA certificate says so — its organisation
+# field is "NOT A QUALIFIED TIMESTAMP" and its policy identifier is deliberately
+# unregistered — and the seal port stays on the Ghost trust tier regardless.
+# What it buys is that every path which reads a seal can be exercised against a
+# realistic envelope rather than a stripped-down one.
 #
 # SEAL_LOCAL_KEY_PATH is where the generated key and certificate persist between
 # runs. Persisted rather than regenerated per boot, so a seal produced yesterday
@@ -229,8 +249,34 @@ RESOLVER_BASE_URL=https://id.odal-node.io
 # absolute path there, or a `just up` and a `cargo run` will disagree about which
 # certificate signed what.
 # SEAL_PROVIDER=local
-# SEAL_CONFORMANCE_LEVEL=B
-# SEAL_LOCAL_KEY_PATH=/data/seal-local               # default: ./.seal-local
+# SEAL_LOCAL_KEY_PATH=/data/seal-local               # default: ./.seal-local; holds the sealing
+#                                                    # key and certificate, and the local TSA's
+#
+# ── How often this node re-checks the seals it already holds ─────────────────
+#
+# A background pass opens every stored seal and reports the ones that no longer
+# verify — the failure no count can find, because a corrupt seal is still a seal
+# and every "is it sealed" query says yes. It walks the estate in batches and
+# publishes only when it wraps, so these two numbers decide how fresh the answer
+# on `GET /api/v1/seal` can be: a walk takes (stored seals / batch) * interval.
+#
+# Defaults suit thousands of seals. A node holding hundreds of thousands should
+# raise the batch, and the boot log says so if a full walk would take more than
+# 24 hours.
+#
+# A day is the target because a seal that has stopped verifying is invisible to
+# every other number the node reports — the walk is the only thing that will ever
+# say so. (The same 24h appears in the EU validation policy as the maximum age of
+# revocation information for a signing certificate. It does not bind this walk:
+# the revocation material read here is the CRL inside the seal, fixed at sealing
+# time. It would bind a node that fetched fresh revocation data, which this one
+# does not.)
+#
+# An unparseable value fails the boot rather than falling back to the default:
+# believing your seals are checked hourly while they are checked daily is the
+# failure this surface exists to prevent.
+# SEAL_AUDIT_BATCH=200                               # seals opened per pass; 1..=10000
+# SEAL_AUDIT_INTERVAL_SECS=60                        # seconds between passes; 1..=3600
 
 # =============================================================================
 # EU digital product passport registry (ESPR Art. 13).

.gitignore

@@ -124,4 +124,8 @@ api/openapi.html
 # them and what they prove. The guard that must not depend on them, the check
 # that the fork is the `xml-sec` which actually resolved, reads Cargo.lock and
 # runs everywhere.
+#
+# The rule has to be on whatever branch the files are sitting on, not only on
+# the one that introduced it: without it a plain `git add crates/dpp-seal/`
+# recommits 60k lines of XML, which is how it came to be written twice.
 crates/dpp-seal/tests/fixtures/local/*.xml