MOBILE-ID · TRUSTED LTANS

Cryptographic Renewal

Choose renewal modes by cryptographic risk and original-data access.

Outcome and scope

Maintain evidence continuity before required protection conditions are lost, with a traceable renewal decision.

Documentation scope Workflow design and integration contract; operational configuration is confirmed per environment.

Prepare	Receive
Evidence due for review; changes in algorithms, certificates or trust policy.	A new evidence version retains historical links and post-renewal verification.

Participants: Cryptographic-policy owners, approvers and renewal operators.

Workflow and decision points

Assess risk

Assess current evidence algorithms, parameters, TSA certificates and policy conditions; do not impose one schedule on every record.

Choose mode

Distinguish timestamp and hash-tree renewal. For hash-tree renewal, verify access to original data and prior evidence before approval.

Pin starting revision

Pin the starting evidence revision so concurrent renewals cannot silently publish conflicting histories.

Validate continuity

Verify the result, retain previous/next linkage and update the next review under the applied policy.

States, guards and authority

Current	Guard	Actor	Next	Artifact / recovery
DUE / ASSESSED	Required data and mode-specific approval available	Renewal + approver	APPROVED	Retain mode, source revision, algorithm and `approvalId`.
APPROVED	Pin starting revision before execution	Renewal Service	RUNNING / BLOCKED_DATA_ACCESS	HASH_TREE without bytes blocks; do not switch to TIMESTAMP to evade the guard.
RUNNING	Continuation validates and is persisted	Renewal + Evidence	COMPLETED / FAILED	Update schedule only after publication; retain history/checkpoints on failure.

Exceptions and controls

Situation	Action	Boundary
Tree hash no longer suitable	Evaluate hash-tree renewal under its processing profile.	Do not substitute timestamp renewal merely to avoid data access.
Original data unavailable	Block the data-dependent operation and notify its owner.	Retain BLOCKED_DATA_ACCESS in the target business workflow.
TSA outage	Bound retries or use an approved fallback.	Publish only after verification and retain prior evidence.

Authorization, approval and recovery

Timestamp renewal extends a chain while its tree hash remains suitable. Hash-tree renewal reprocesses original data and prior evidence with a secure algorithm and starts a new chain.

If data is unavailable, block hash-tree renewal, notify its owner and restore access before retry; never relabel it as successful renewal.

Reconciliation artifacts and acceptance

Record reason, mode, old/new algorithms, original-data access, approval and outcome; reconcile all due objects.

Hash-tree renewal with revoked data access must block; restore rights and reconcile the job before resuming.
Changing mode, algorithm or starting revision requires a distinct decision and validation result.

Integration and data contract

API	Application scope	Documentation
POST /v1/renewals	renewals:write	Renewal API
GET /v1/renewals/{`renewalId`}	renewals:read	Renewal API

Renewal API Cryptographic Renewal

Technical input and references

Element	Definition
Input	Current evidence version, algorithm risk assessment, renewal mode and original-data access when required.
Output	New evidence version, renewal decision, verification result and linkage to the full history.

RFC 4998 · § 5.2 RFC 6283 · § 4.2.1;4.2.2

Renewal decision and history · Target interface illustration; source images may contain English text.

Decision	Input	Result
Timestamp renewal	Previous evidence; tree hash remains suitable.	New archive timestamp in the applicable chain.
Hash-tree renewal	Original data and prior evidence under the processing model.	Rehash, new tree, new timestamp and new chain.

Hash-Tree Renewal requires access to the archived data and prior evidence required by the applicable Evidence Record processing model.

Choose mode and handle missing inputs

Condition	Decision	Stop condition
Hash remains suitable; timestamp protection needs renewal.	Evaluate TIMESTAMP under profile.	Do not build on unverified tokens.
Assessed risk requires a new hash/tree.	Evaluate HASH_TREE with originals and prior evidence.	Missing bytes/decryption/prior evidence blocks execution; no mode switch to hide failure.
Chain protection prerequisites have already been lost.	Assess limits, retain results and escalate.	New renewal does not retroactively repair old gaps.