WEB / WEB-21.S01

Data, secrets and cryptographic key lifecycle

Separate crypto objectives, key states and data-copy scope.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Archive allowed

Archive request ready
The reader has prepared an ordinary read request for a fixed archived note; key/purpose acceptance is still pending.
Reader
Archive-read request ready; body absent
Key / data policy
Declared archive verification/context pending
Public note store
Own public note unchanged; no delivery
Read request received
The policy completes request arrival; primitive verification and lifecycle acceptance remain two distinct gates.
Reader
Archive-read request ready; body absent
Key / data policy
Read request arrived; crypto/context pending
Public note store
Own public note unchanged; no delivery
Archive gate allow
The verify-only key is accepted for ordinary archive verification; public classification permits the read projection.
Reader
Archive-read request ready; body absent
Key / data policy
Verify-only/purpose/time/public allow; read ready
Public note store
Own public note unchanged; no delivery
Read reached store
The approved read arrives completely at the store; this synthetic message is no actual storage or KMS call.
Reader
Archive-read request ready; body absent
Key / data policy
Verify-only/purpose/time/public allow; read ready
Public note store
Approved archive read received; title pending
Public title ready
The store prepares the fixed public Tea & Bread projection in a local read-only step; no record write occurs.
Reader
Archive-read request ready; body absent
Key / data policy
Verify-only/purpose/time/public allow; read ready
Public note store
Public title body ready; write=false
Title reached policy
The public title body completes arrival at policy; no key material enters the response and no secret is copied.
Reader
Archive-read request ready; body absent
Key / data policy
Public title received; output projection pending
Public note store
Public title body ready; write=false
Read response ready
The policy prepares only a public-title response; no signature/key bytes or server-only data are carried.
Reader
Archive-read request ready; body absent
Key / data policy
Public title response ready; no secret/key material
Public note store
Public title body ready; write=false
Public title delivery
The reader receives the title at completed arrival; this outcome proves neither certificate identity nor all-copy deletion.
Reader
Received title=Tea & Bread; no key/secret delivery
Key / data policy
Public title response ready; no secret/key material
Public note store
Public title body ready; write=false

Key retired

Archive request ready
The reader has prepared an ordinary read request for a fixed archived note; key/purpose acceptance is still pending.
Reader
Archive-read request ready; body absent
Key / data policy
Declared archive verification/context pending
Public note store
Own public note unchanged; no delivery
Read request received
The policy completes request arrival; primitive verification and lifecycle acceptance remain two distinct gates.
Reader
Archive-read request ready; body absent
Key / data policy
Read request arrived; crypto/context pending
Public note store
Own public note unchanged; no delivery
Evidence separated
The policy separates key-state and classification evidence from primitive results; an unknown key is not a false signature.
Reader
Archive-read request ready; body absent
Key / data policy
Crypto declared true; key retired
Public note store
Own public note unchanged; no delivery
Acceptance closed
A required lifecycle or data gate is not accepted; no read reaches the store and no public projection body is prepared.
Reader
Archive-read request ready; body absent
Key / data policy
Acceptance denied; resource dispatch=0; body absent
Public note store
Own public note unchanged; no delivery
Denial ready
A safe denial response carries only decision state; no secret/key/signature material enters that body.
Reader
Archive-read request ready; body absent
Key / data policy
Denial response ready; protected body absent
Public note store
Own public note unchanged; no delivery
Denial delivered
The reader sees completed denial arrival; resource delivery and writes remain withheld in this branch.
Reader
Denial received; protected body absent; write=false
Key / data policy
Denial response ready; protected body absent
Public note store
Own public note unchanged; no delivery
Outcome distinction
The reader locally separates unknown evidence from a known denial reason; no secret or key has been read.
Reader
No body/delivery/write; evidence scope retained
Key / data policy
Denial response ready; protected body absent
Public note store
Own public note unchanged; no delivery

Server-only data

Archive request ready
The reader has prepared an ordinary read request for a fixed archived note; key/purpose acceptance is still pending.
Reader
Archive-read request ready; body absent
Key / data policy
Declared archive verification/context pending
Public note store
Own public note unchanged; no delivery
Read request received
The policy completes request arrival; primitive verification and lifecycle acceptance remain two distinct gates.
Reader
Archive-read request ready; body absent
Key / data policy
Read request arrived; crypto/context pending
Public note store
Own public note unchanged; no delivery
Evidence separated
The policy separates key-state and classification evidence from primitive results; an unknown key is not a false signature.
Reader
Archive-read request ready; body absent
Key / data policy
Crypto accepted; server-only classification
Public note store
Own public note unchanged; no delivery
Acceptance closed
A required lifecycle or data gate is not accepted; no read reaches the store and no public projection body is prepared.
Reader
Archive-read request ready; body absent
Key / data policy
Acceptance denied; resource dispatch=0; body absent
Public note store
Own public note unchanged; no delivery
Denial ready
A safe denial response carries only decision state; no secret/key/signature material enters that body.
Reader
Archive-read request ready; body absent
Key / data policy
Denial response ready; protected body absent
Public note store
Own public note unchanged; no delivery
Denial delivered
The reader sees completed denial arrival; resource delivery and writes remain withheld in this branch.
Reader
Denial received; protected body absent; write=false
Key / data policy
Denial response ready; protected body absent
Public note store
Own public note unchanged; no delivery
Outcome distinction
The reader locally separates unknown evidence from a known denial reason; no secret or key has been read.
Reader
No body/delivery/write; evidence scope retained
Key / data policy
Denial response ready; protected body absent
Public note store
Own public note unchanged; no delivery

Key unknown

Archive request ready
The reader has prepared an ordinary read request for a fixed archived note; key/purpose acceptance is still pending.
Reader
Archive-read request ready; body absent
Key / data policy
Declared archive verification/context pending
Public note store
Own public note unchanged; no delivery
Read request received
The policy completes request arrival; primitive verification and lifecycle acceptance remain two distinct gates.
Reader
Archive-read request ready; body absent
Key / data policy
Read request arrived; crypto/context pending
Public note store
Own public note unchanged; no delivery
Evidence separated
The policy separates key-state and classification evidence from primitive results; an unknown key is not a false signature.
Reader
Archive-read request ready; body absent
Key / data policy
Key evidence unknown; crypto not performed
Public note store
Own public note unchanged; no delivery
Acceptance closed
A required lifecycle or data gate is not accepted; no read reaches the store and no public projection body is prepared.
Reader
Archive-read request ready; body absent
Key / data policy
Acceptance denied; resource dispatch=0; body absent
Public note store
Own public note unchanged; no delivery
Denial ready
A safe denial response carries only decision state; no secret/key/signature material enters that body.
Reader
Archive-read request ready; body absent
Key / data policy
Denial response ready; protected body absent
Public note store
Own public note unchanged; no delivery
Denial delivered
The reader sees completed denial arrival; resource delivery and writes remain withheld in this branch.
Reader
Denial received; protected body absent; write=false
Key / data policy
Denial response ready; protected body absent
Public note store
Own public note unchanged; no delivery
Outcome distinction
The reader locally separates unknown evidence from a known denial reason; no secret or key has been read.
Reader
No body/delivery/write; evidence scope retained
Key / data policy
Denial response ready; protected body absent
Public note store
Own public note unchanged; no delivery

ACTORS · STATE · DATA FLOW

What do encryption, MACs and signatures establish?

Encryption aims to keep plaintext unreadable without an appropriate key; not every encryption mode independently supplies integrity or data-origin authentication. Authenticated encryption combines these objectives under a suitable profile. A MAC provides integrity and key-holder origin evidence to parties sharing a secret, but cannot distinguish which of several holders generated it. A digital signature is produced with a private key and verified with a public key; it provides no confidentiality and does not independently prove a person’s business identity. Atlas Notes separates signature verification for Tea & Bread from trusted key provenance and accepted purpose. A hash uses no key: if the expected digest is untrusted, a correct match alone does not establish trustworthy origin. The ledger compares these objectives without claiming to execute encryption, a MAC or a complete identity protocol.

The decisions in a key lifecycle

A key lifecycle includes generation, controlled distribution/storage, active use, rotation, retirement and, where needed, recovery and destruction. The ledger selects key-new as active and key-old as verify-only. The selected application policy prohibits creating a new signature with the old private key, while its public key may verify an accepted archived title within a selected verification period. Profile acceptance stops at now=verifyUntil even though the signature can remain mathematically valid. Rotation selects a new key version; it neither automatically reencrypts old ciphertext nor destroys every copy of a key. Destroying an encryption key too early can prevent a required restore. Archived verification with a signing key raises a different retention question. The native check observes only ordinary title signing/verification and local lifecycle gates with own ephemeral Ed25519 KeyObjects, not KMS, HSM, certificate-chain or secure-zeroization behavior.

Secrecy does not survive delivery to a browser

A server credential, a signing private key and browser-visible public configuration belong to different classifications. Server secrets should not enter a source repository, build log, generated bundle or source map. A value substituted into browser JavaScript at build time becomes data delivered to the client; calling it an environment variable does not preserve secrecy. Obfuscation is not trusted secret storage either. A public endpoint name, public verification key or color setting need not be a secret; classification depends on its intended use rather than its appearance. The artifact contains only aliases and booleans, never actual secret values. Its source/build/browser ledger requires delivered=false for server-secret. Secret access is limited to the server workload’s minimum needs and an appropriate lifetime. Access to a secret manager does not permit forwarding that secret to every client.

The data lifecycle continues in every copy

A data lifecycle begins with collection and purpose, then covers processing, storage, sharing, retention and deletion. Although Tea & Bread is a public teaching note, the same ledger makes copy purposes explicit: primary storage, cache, logs and backups are not interchangeable. A visible delete marker does not prove that every copy has disappeared. In particular, absent backup-deletion evidence stays unknown instead of becoming a claim of complete erasure. Retention follows real product needs and applicable obligations; the example’s 30-tick value is not a legal rule. W3C minimization and purpose principles reduce unnecessary data transfer, while OWASP’s log-disposal guidance includes log copies and retention bounds. Neither source proves that this note was actually deleted. The copy ledger is our own declared example.

Read every scenario without motion

Retired key

Normal verify-only use
Normal key-old is verify-only with public classification and matching purpose. now 150 is below verifyUntil 200; acceptance/delivery are true but write remains false.
Key/data ledger
Old verify-only / public verification accepted
Purpose/state/classification gate
Not yet evaluated
Delivery/lifecycle outcome
Not yet evaluated
Retired-key decision
retired-key keeps declared cryptographic verification true but is rejected for retired state. The primitive result does not replace key-use/state policy.
Key/data ledger
Old verify-only / public verification accepted
Purpose/state/classification gate
Crypto true / retired / accepted false
Delivery/lifecycle outcome
Not yet evaluated
Stop delivery
retired-key has delivery false and null body, with no signing/write right. Mathematical verification yields neither title delivery nor provenance approval.
Key/data ledger
Old verify-only / public verification accepted
Purpose/state/classification gate
Crypto true / retired / accepted false
Delivery/lifecycle outcome
Retired → no body / no write
Verification-window equality
verificationTimeRows accepts 199 and rejects 200/201. Equality is outside the window; teaching ticks are not organizational retention or a legal period.
Key/data ledger
199 accepted /200 and201 rejected
Purpose/state/classification gate
Crypto true / retired / accepted false
Delivery/lifecycle outcome
Retired → no body / no write
Separate identity binding
A signature can associate origin with a private-key holder but identity mapping needs separate trust. Hash without a trusted expected digest grants no origin; encryption and MAC serve distinct purposes.
Key/data ledger
199 accepted /200 and201 rejected
Purpose/state/classification gate
Primitive purpose ≠ trusted identity mapping
Delivery/lifecycle outcome
Retired → no body / no write
Key-inventory outcome
key-new actively signs/verifies, key-old only verifies, and retired does neither. This declared inventory does not establish KMS rotation or secure zeroization.
Key/data ledger
199 accepted /200 and201 rejected
Purpose/state/classification gate
Primitive purpose ≠ trusted identity mapping
Delivery/lifecycle outcome
Lifecycle permissions distinct / KMS unmeasured

Copy and data

Server-only classification
The server-only row has normal crypto/lifecycle predicates but server-secret classification. Source/build/browser delivery are closed; only an alias exists, not secret material.
Key/data ledger
Server-secret classification / no browser body
Purpose/state/classification gate
Not yet evaluated
Delivery/lifecycle outcome
Not yet evaluated
Type or hash does not declassify
A valid signature or encoding does not make server-only data public. Classification is separate from purpose/state, and public-note success does not approve secret delivery.
Key/data ledger
Server-secret classification / no browser body
Purpose/state/classification gate
Crypto success ≠ public classification
Delivery/lifecycle outcome
Not yet evaluated
Unknown key differs
unknown-key has null state/provenance/crypto and false acceptance. It is not labelled cryptographic failure; missing evidence closes delivery.
Key/data ledger
Server-secret classification / no browser body
Purpose/state/classification gate
Crypto success ≠ public classification
Delivery/lifecycle outcome
Unknown key evidence / no delivery
Inventory copies
Primary, cache and log deletion evidence are true while backup is null. A primary deletion marker supplies no new evidence about backup state.
Key/data ledger
Primary/cache/log true / backup unknown
Purpose/state/classification gate
Crypto success ≠ public classification
Delivery/lifecycle outcome
Unknown key evidence / no delivery
Complete-deletion assumption
allCopiesDeleted remains null. Different purposes/retention can require different lifecycles; setting unknown backup true exceeds documented scope.
Key/data ledger
Primary/cache/log true / backup unknown
Purpose/state/classification gate
Partial evidence / all-copy deletion unknown
Delivery/lifecycle outcome
Unknown key evidence / no delivery
Report bounded scope
No secrets are searched, storage deleted or key memory zeroized. The control separates classification, allowed delivery and copy-specific evidence.
Key/data ledger
Primary/cache/log true / backup unknown
Purpose/state/classification gate
Partial evidence / all-copy deletion unknown
Delivery/lifecycle outcome
Classification/copy reasoning / no erasure claim

ASSUMPTION · BOUNDARY · CONTROL

Mistaking primitive success for trust

The assumption under review is that a valid signature makes its key and purpose acceptable. An incorrect result requires the caller to skip key provenance, use/state or verification-window gates. A verify-only old public key validating ordinary archived data is not itself a problem; it is intended behavior within the selected policy. In the retired-key branch cryptoVerifiedDeclared can remain true while application acceptance is false. A mathematical operation and a resource-delivery decision therefore retain separate evidence. This perspective does not treat that row as key forgery or credential theft. The unknown-key branch has null cryptographic evidence, so an unperformed verification is not mislabeled an invalid signature. There is also no actual issuer or certificate evidence for binding business identity; reasoning uses only supplied aliases and an ordinary policy.

Copy visibility and deletion claims

The second assumption is that removing a secret line from source, or marking a primary record deleted, ends the lifecycle. That claim depends on the scope of copies in build outputs, logs, caches and backups; one UI observation is insufficient. No secret is searched for or read in this lesson. The classification ledger closes browser delivery for server-only data while allowing the public title. The data-copy table does not turn unknown backup evidence into true merely because the primary copy is marked deleted. Different copy purposes and retention periods are not automatically errors, but storage or sharing outside a documented scope needs a separate control. Ask which evidence exists for each copy. Because no repository history, browser bundle or key store was examined, these fixtures establish neither actual exposure nor complete deletion.

Read every scenario without motion

Lifecycle controls

Normal verify control
Normal key-old returns Tea & Bread under verify-only/public/purpose predicates. Native primitives and application acceptance retain separate evidence.
Lifecycle metadata
Normal public body / write false
Policy comparison
Not yet evaluated
Evidence outcome
Not yet evaluated
Three denial controls
Retired, server-only and unknown rows all require null body and false delivery/write, but for different state, classification or missing-evidence reasons.
Lifecycle metadata
Normal public body / write false
Policy comparison
Three distinct denies / no body or write
Evidence outcome
Not yet evaluated
Time-window control
The 199/200/201 comparison makes equality explicit. now and verifyUntil are logical inputs, not measured clock skew or actual key-manager timers.
Lifecycle metadata
Normal public body / write false
Policy comparison
Three distinct denies / no body or write
Evidence outcome
Finite time window / no KMS clock measurement
Minimal key metadata
Alias, purpose, state and comparison outcomes suffice. Key material is not logged, and public-key identity mapping or caller/object permission is not inferred.
Lifecycle metadata
Metadata only / identity and permission separate
Policy comparison
Three distinct denies / no body or write
Evidence outcome
Finite time window / no KMS clock measurement
Copy conjunction
With backup null, all-copy conjunction is unknown. Primary/cache/log true evidence is retained without turning partial coverage into complete-deletion certification.
Lifecycle metadata
Metadata only / identity and permission separate
Policy comparison
Known three copies / backup unknown
Evidence outcome
Finite time window / no KMS clock measurement
Primitive-evidence boundary
Ephemeral ordinary-title sign/verify can be actual mathematical evidence; KMS, certificate identity, destruction and production rotation need separate proof. Model acceptance does not broaden that scope.
Lifecycle metadata
Metadata only / identity and permission separate
Policy comparison
Known three copies / backup unknown
Evidence outcome
Primitive vs policy vs lifecycle evidence distinct

Deletion evidence

Primary deletion observed
The review sees primary deletionEvidence true. Backup null prevents an all-copy conclusion; primary absence does not establish completed retention.
Lifecycle metadata
Primary known / backup evidence missing
Policy comparison
Not yet evaluated
Evidence outcome
Not yet evaluated
Secret-lifecycle distinction
Removing a source row does not prove deletion of build/cache/log/backup copies. actualValueIncluded is false; no exposure or deletion scan occurs here.
Lifecycle metadata
Primary known / backup evidence missing
Policy comparison
Source removal ≠ all-copy deletion
Evidence outcome
Not yet evaluated
Leave completeness unknown
allCopiesDeleted remains null; cryptographic acceptance cannot establish erasure. Key destruction is not assumed without copy scope and verification requirements.
Lifecycle metadata
Primary known / backup evidence missing
Policy comparison
Source removal ≠ all-copy deletion
Evidence outcome
Complete deletion/zeroization unproved
Required copy evidence
Each copy needs purpose, retention scope and deletion/recovery evidence. Alias inventory contains neither actual storage paths nor secrets; metadata can explain scope.
Lifecycle metadata
Needed: copy/purpose/retention/evidence
Policy comparison
Source removal ≠ all-copy deletion
Evidence outcome
Complete deletion/zeroization unproved
Restore and destruction binding
Recovery requirements need a separate encrypted-data/key-version relation. Dropping a key reference without verified restore proves neither recovery nor secure zeroization.
Lifecycle metadata
Needed: copy/purpose/retention/evidence
Policy comparison
Recovery needs independent key/data evidence
Evidence outcome
Complete deletion/zeroization unproved
Bounded lifecycle outcome
New review must answer missing backup evidence. This record retains three known-copy outcomes without adding all-storage, browser-secrecy or key-erasure claims.
Lifecycle metadata
Needed: copy/purpose/retention/evidence
Policy comparison
Recovery needs independent key/data evidence
Evidence outcome
Retain partial coverage / completeness unknown

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Purpose, state and copy inventory together

The defensive key inventory separates alias, algorithm, purpose, active/verify-only/retired state, originator-use period and recipient verification/decryption needs. A rotation profile documents which key creates new material, how long archived data can be verified and how acceptance closes after compromise. Sensitive-data classification remains distinct: an explicit delivery gate separates a server-only secret from a public note. Access-controlled audit records key metadata rather than key material. Where recovery is required, preserve the relationship between encrypted data and necessary key versions; do not assume successful destruction or recovery without evidence. These old/new aliases are not files or endpoints of an actual key manager. Native keypair generation certifies neither a validated cryptographic module nor an organizational rotation program.

Test denial and unknown evidence

The positive fixture checks accepted verification and public-title delivery. Retired-key, server-only and unknown-key rows must jointly produce delivered=false, write=false and body=null. The primitive test signs and verifies only ordinary Tea & Bread bytes with own generated Ed25519 keypairs; it serializes no token, certificate or credential. A verify-only policy blocks new signing with the old key while separately observing that its ordinary archived signature remains mathematically verifiable. Dropping KeyObject references does not guarantee secure zeroization in JavaScript memory, and no such claim is recorded. The data-deletion check keeps an unknown backup unknown in the all-copy conjunction. These are concrete, rerunnable local checks; actual KMS rotation, browser secrecy, storage restore or backup erasure require separate integration evidence.

NOW APPLY IT TO THE CASE

Does a valid signature establish lifecycle and delivery correctness?

key-old in verify-only state can verify public Tea & Bread at now 150. A retired key is rejected despite declared mathematical verification; server-secret classification closes browser delivery. Primary/cache/log deletion evidence exists while backup remains unknown.

Separate decisions for verified actor, tenant relation and requested action in the case. Do not substitute authentication or proof success for object permission.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Atlas Notes — boundary ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "profile": {
    "title": "Tea & Bread",
    "purpose": "public-note-verification",
    "now": 150,
    "verifyUntil": 200,
    "actualKMS": false,
    "actualIdentity": false,
    "actualZeroization": false
  },
  "rows": [
    {
      "case": "normal",
      "keyAlias": "key-old",
      "keyState": "verify-only",
      "provenanceTrustedDeclared": true,
      "purpose": "public-note-verification",
      "cryptoVerifiedDeclared": true,
      "classification": "public",
      "now": 150,
      "verifyUntil": 200,
      "expectedAccepted": true,
      "expectedDelivery": true,
      "expectedBody": {
        "title": "Tea & Bread"
      },
      "expectedWrite": false
    },
    {
      "case": "retired-key",
      "keyAlias": "key-old",
      "keyState": "retired",
      "provenanceTrustedDeclared": true,
      "purpose": "public-note-verification",
      "cryptoVerifiedDeclared": true,
      "classification": "public",
      "now": 150,
      "verifyUntil": 200,
      "expectedAccepted": false,
      "expectedDelivery": false,
      "expectedBody": null,
      "expectedWrite": false
    },
    {
      "case": "server-only",
      "keyAlias": "key-old",
      "keyState": "verify-only",
      "provenanceTrustedDeclared": true,
      "purpose": "public-note-verification",
      "cryptoVerifiedDeclared": true,
      "classification": "server-secret",
      "now": 150,
      "verifyUntil": 200,
      "expectedAccepted": false,
      "expectedDelivery": false,
      "expectedBody": null,
      "expectedWrite": false
    },
    {
      "case": "unknown-key",
      "keyAlias": "key-unlisted",
      "keyState": null,
      "provenanceTrustedDeclared": null,
      "purpose": "public-note-verification",
      "cryptoVerifiedDeclared": null,
      "classification": "public",
      "now": 150,
      "verifyUntil": 200,
      "expectedAccepted": false,
      "expectedDelivery": false,
      "expectedBody": null,
      "expectedWrite": false
    }
  ],
  "cryptoPurpose": [
    {
      "mechanism": "encryption",
      "confidentiality": true,
      "integrity": "mode-dependent"
    },
    {
      "mechanism": "MAC",
      "confidentiality": false,
      "origin": "shared key holder"
    },
    {
      "mechanism": "digital signature",
      "confidentiality": false,
      "origin": "private key holder; trusted identity mapping separate"
    },
    {
      "mechanism": "hash",
      "confidentiality": false,
      "origin": "none without trusted expected digest"
    }
  ],
  "keyInventory": [
    {
      "alias": "key-new",
      "state": "active",
      "maySign": true,
      "mayVerify": true
    },
    {
      "alias": "key-old",
      "state": "verify-only",
      "maySign": false,
      "mayVerify": true
    },
    {
      "alias": "key-retired",
      "state": "retired",
      "maySign": false,
      "mayVerify": false
    }
  ],
  "classificationLedger": [
    {
      "alias": "public-note-title",
      "classification": "public",
      "sourceAllowed": true,
      "buildAllowed": true,
      "browserDeliveryAllowed": true
    },
    {
      "alias": "server-secret-reference",
      "classification": "server-secret",
      "sourceAllowed": false,
      "buildAllowed": false,
      "browserDeliveryAllowed": false,
      "actualValueIncluded": false
    }
  ],
  "dataCopies": [
    {
      "copy": "primary",
      "purpose": "public-note storage",
      "deletionEvidence": true
    },
    {
      "copy": "cache",
      "purpose": "bounded read acceleration",
      "deletionEvidence": true
    },
    {
      "copy": "log",
      "purpose": "minimal decision metadata",
      "deletionEvidence": true
    },
    {
      "copy": "backup",
      "purpose": "controlled recovery",
      "deletionEvidence": null
    }
  ],
  "allCopiesDeleted": null,
  "retention": {
    "teachingTicks": 30,
    "legalRule": false
  },
  "boundaries": {
    "actualSecretsRead": false,
    "actualEncryption": false,
    "actualMAC": false,
    "actualCertificates": false,
    "actualStorageDeletion": false
  },
  "verificationTimeRows": [
    {
      "now": 199,
      "verifyUntil": 200,
      "expected": true
    },
    {
      "now": 200,
      "verifyUntil": 200,
      "expected": false
    },
    {
      "now": 201,
      "verifyUntil": 200,
      "expected": false
    }
  ]
}

cryptoPurpose: Different crypto objectives; not universal identity proof.
rows: Supplied lifecycle/classification gates and protected-title delivery result.
classificationLedger: Aliases only; no server-only value is included anywhere.
dataCopies: Copy-specific deletion evidence; null means unknown.

Inert key/secret aliases; native only own nonexported ephemeral Ed25519 ordinary-title primitives. No KMS, encryption/MAC, identity or secure destruction executes.

Two reality checks

A valid signature always makes its key acceptable.

Lifecycle, purpose and provenance gates are separate from mathematical verification.

Deleting the primary copy deletes all data.

Cache/log/backup evidence is separate; unknown is not success.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

cryptoVerifiedDeclared=true, but keyState=retired. Is the public title body accepted?

No. Delivery is withheld for the retired key.
Yes. Crypto success makes key state irrelevant.

Read the explained answer

No. Delivery is withheld for the retired key. — Even with signature success supplied, lifecycle policy rejects the retired key. expectedBody stays null.

Primary, cache and log have deletionEvidence=true; backup has null. Can all copies be declared deleted?

Selected lesson artifact fields; teaching example

dataCopies: [{"copy":"primary","purpose":"public-note storage","deletionEvidence":true},{"copy":"cache","purpose":"bounded read acceleration","deletionEvidence":true},{"copy":"log","purpose":"minimal decision metadata","deletionEvidence":true},{"copy":"backup","purpose":"controlled recovery","deletionEvidence":null}]
allCopiesDeleted: null

Yes. Deleting the primary automatically deletes every cache/log/backup.
No. allCopiesDeleted=null and the backup outcome is unknown.

Read the explained answer

No. allCopiesDeleted=null and the backup outcome is unknown. — Three copy outcomes do not determine the fourth. Missing evidence gives no complete-deletion or retention-compliance guarantee.

Encryption, MAC, signatures and hashes do not provide identical properties. How do verify-only keys and server-secret classification add separate controls?

Read the explained answer

Encryption can provide confidentiality, with integrity depending on the mode. MACs and signatures do not provide confidentiality; signature identity mapping requires trusted provenance. A hash is no origin authority without a trusted expected digest. A verify-only key may permit verification while withholding signing. Successful verification does not make server-secret data public. No real secret or KMS is accessed here, and runtime zeroization or complete storage deletion is not verified.

□ I separated primitive properties from identity binding.

□ I did not treat key verification as data-classification permission.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

OWASP Key Management Cheat SheetKey Selection / symmetric, asymmetric, MAC and digital signatures · Key Usage; Storage; Cryptoperiods and Rotation; Escrow and Backup; Zeroization and Destruction
OWASP Secrets Management Cheat Sheet§2.7 Creation, Rotation, Revocation and Expiration · §2.6 Auditing / §8.3 Detection lifecycle: do not log secrets
W3C Privacy Principles§2.2 Data Minimization · §2.10 Purpose limitation
OWASP Logging Cheat SheetDisposal of logs: temporary/debug logs, backups/copies/extractions and retention bounds
Node.js v24.13.0 CryptogenerateKeyPairSync: ed25519; KeyObjects without explicit encoding · crypto.sign/verify: null algorithm for Ed25519; ordinary data/private/public key arguments

YOUR NOTES / THIS BROWSER

Data, secrets and cryptographic key lifecycle

1. Core · Mechanism

Archive allowed

Key retired

Server-only data

Key unknown

What do encryption, MACs and signatures establish?

The decisions in a key lifecycle

Secrecy does not survive delivery to a browser

The data lifecycle continues in every copy

2. Red · Trust & Impact

Retired key

Copy and data

Mistaking primitive success for trust

Copy visibility and deletion claims

3. Blue · Secure development & defense

Lifecycle controls

Deletion evidence

Purpose, state and copy inventory together

Test denial and unknown evidence

Does a valid signature establish lifecycle and delivery correctness?

Two reality checks

cryptoVerifiedDeclared=true, but keyState=retired. Is the public title body accepted?

Primary, cache and log have deletionEvidence=true; backup has null. Can all copies be declared deleted?

Encryption, MAC, signatures and hashes do not provide identical properties. How do verify-only keys and server-secret classification add separate controls?

Sources and scope