Two small defects found while auditing the seal path. Both are in crates/dpp-seal, neither changes behaviour today, and both are the kind that become wrong answers once something else starts trusting them.
1. SealResponse.sealedAt is described as the QTSP's time; it is this node's clock
crates/dpp-vault/src/handlers/seal.rs documents the field as "When the QTSP produced it." Every construction site sets Utc::now() on the node — local/sealer.rs, eideasy/client.rs, adapter.rs, ghost.rs, seal_drain.rs. It is the moment this node recorded the response, and for the local backend there is no QTSP at all.
It matters more than a normal doc slip because of what surrounds it. A seal carries an independently established signing time only from BaselineT upward, where a timestamp authority attests it; at BaselineB there is no timestamp token anywhere in the envelope, so sealedAt is an unattested claim by the party that bought the seal. SealResponse is scrupulous about exactly this distinction everywhere else — signingCertRef says "as reported by the seal, never verified", sealedPayloadHash says "a record, not proof", verification states what was not checked. sealedAt is the one field that reads as evidence without saying it is not.
Fix in SealResponse's doc comment and in api/components/schemas/seals/SealResponse.yaml. dpp-domain's SealedEnvelope has already been corrected upstream; this is the engine-side mirror.
2. LocalIdentity::generated_at() is dead, and its body contradicts its doc
crates/dpp-seal/src/local/sealer.rs:
/// When this identity's certificate was generated.
pub fn generated_at(&self) -> chrono::DateTime<Utc> {
Utc::now()
}Zero callers anywhere in the workspace. It returns a fresh timestamp on every call, so anything that wired it into a trust report or a diagnostic would get "now", not the certificate's generation time, and would look plausible while doing it.
Either delete it, or implement it from self.cert.tbs_certificate.validity.not_before, which is the real answer and is already in hand. Deleting is the better default — the identity is persisted specifically so a seal produced yesterday still verifies today, and nothing has needed to ask when it was minted.
Two small defects found while auditing the seal path. Both are in
crates/dpp-seal, neither changes behaviour today, and both are the kind that become wrong answers once something else starts trusting them.1.
SealResponse.sealedAtis described as the QTSP's time; it is this node's clockcrates/dpp-vault/src/handlers/seal.rsdocuments the field as "When the QTSP produced it." Every construction site setsUtc::now()on the node —local/sealer.rs,eideasy/client.rs,adapter.rs,ghost.rs,seal_drain.rs. It is the moment this node recorded the response, and for the local backend there is no QTSP at all.It matters more than a normal doc slip because of what surrounds it. A seal carries an independently established signing time only from
BaselineTupward, where a timestamp authority attests it; atBaselineBthere is no timestamp token anywhere in the envelope, sosealedAtis an unattested claim by the party that bought the seal.SealResponseis scrupulous about exactly this distinction everywhere else —signingCertRefsays "as reported by the seal, never verified",sealedPayloadHashsays "a record, not proof",verificationstates what was not checked.sealedAtis the one field that reads as evidence without saying it is not.Fix in
SealResponse's doc comment and inapi/components/schemas/seals/SealResponse.yaml.dpp-domain'sSealedEnvelopehas already been corrected upstream; this is the engine-side mirror.2.
LocalIdentity::generated_at()is dead, and its body contradicts its doccrates/dpp-seal/src/local/sealer.rs:Zero callers anywhere in the workspace. It returns a fresh timestamp on every call, so anything that wired it into a trust report or a diagnostic would get "now", not the certificate's generation time, and would look plausible while doing it.
Either delete it, or implement it from
self.cert.tbs_certificate.validity.not_before, which is the real answer and is already in hand. Deleting is the better default — the identity is persisted specifically so a seal produced yesterday still verifies today, and nothing has needed to ask when it was minted.