Doctrine entries in this series may include operational tests and controls. These are design requirements derived from first principles; references are illustrative, not determinative. They are not audit methods or compliance checklists. Confidence is high because claims are architectural and derived from first principles, not event reporting. References are included only as context. Failure modes described in this entry reflect general engineering and compliance patterns. They are not claims about any specific platform or organisation.
Summary
Independent verifiability is the property of a record whereby an external party, with no access to the originating system, can confirm its integrity and time of attestation using publicly available trust infrastructure. A record that requires the originating system to confirm its own integrity is not independently verifiable.
RFC 3161 defines a timestamp protocol under which a Timestamp Authority (TSA), often operated as a trusted third party, issues a signed timestamp token over a hash of the record. The token establishes evidence that the data existed no later than the genTime value, and is verifiable by any party with access to the TSA's public certificate, certificate chain, and relevant revocation material, without reference to the originating system.
ETSI EN 319 421 specifies policy and security requirements for operating and managing trust service providers issuing time-stamps. The standard notes that the time-stamping protocol is defined in RFC 3161 (with RFC 5816 update) and profiled in ETSI EN 319 422. ETSI EN 319 421 is cited here as context for TSA governance where operational assurance is a documented requirement.
The verification dependency is the structural property that determines whether a record is independently verifiable. If verification depends on the originating system, the record is not independently verifiable regardless of the strength of the cryptographic mechanisms applied.
Compliance programs that rely on internal verification mechanisms alone cannot demonstrate independent verifiability under adversarial scrutiny. Where records may be demanded as independently verifiable proof, this gap constitutes structural evidence debt (as defined in the companion entry on structural accumulation of evidence debt).
Definition
Independent verifiability (as used in this entry): The property of a record whereby an external party, with no access to the originating system, can confirm the record's content integrity and time of attestation using publicly available trust infrastructure. As used in this entry, requires cryptographic integrity binding at point of write and an external timestamp token issued by a TSA that is independent of the writing system, verifiable using archived certificate chain and revocation material.
Verification dependency (as used in this entry): The structural property of a verification mechanism that determines whether it can be performed without access to the originating system. A verification mechanism with high dependency on the originating system cannot produce independent verification. A verification mechanism with no dependency on the originating system can produce independent verification.
Timestamp Authority (TSA) (per RFC 3161): A trusted third party that issues timestamp tokens. RFC 3161 defines the Time-Stamp Protocol (TSP) under which a TSA receives a hash of a data object, binds it to a time value, and returns a signed timestamp token establishing evidence that the data existed no later than the genTime value. RFC 3161 notes that a TSA may be operated as a trusted third party or under other operational models. For evidence-class records as used in this entry, the TSA should be independent of the writing system.
Timestamp token (per RFC 3161): A signed data structure issued by a TSA containing the hash of the submitted data object (the messageImprint), the time of signing (genTime), and the TSA's identity anchored through the signing certificate identifier mechanism. Verifiable independently of the originating system using the TSA's public certificate, certificate chain, and revocation material. If tokens are obtained at point of write, genTime can be treated operationally as the attestation-time bound for the record.
Boundary
Internal verification confirms that a record matches the originating system's own reference. Independent verification confirms that a record matches a reference established by a party external to and independent of the originating system. These are distinct verification modes. The first does not satisfy the second.
Mechanism
How verification dependency determines independence:
Every verification mechanism has a dependency structure. The dependency structure determines what a verifier must access in order to confirm the record's integrity and time of attestation.
Record Created
|
v
Integrity binding applied.
|
v
Verification mechanism established.
|
v
Verification Dependency Analysis
|
/ \
/ \
/ \
High Low
dependency dependency
on on
originating originating
system system
| |
v v
Internal Independent
verification verification
only possible
| |
v v
Cannot satisfy Can satisfy
independent independent
verifiability verifiability
under under
adversarial adversarial
scrutiny scrutiny
What RFC 3161 defines:
RFC 3161 defines the Time-Stamp Protocol (TSP). Under this protocol a requesting system submits a hash of a data object to a TSA. The TSA signs the hash together with a time value and returns a timestamp token. The token contains the messageImprint (the submitted hash), the genTime (the time of signing), and the TSA's identity anchored through the signing certificate identifier mechanism. The token establishes evidence that the data existed no later than the genTime value.
The token is verifiable by any party that has access to the TSA's public certificate, certificate chain, and relevant revocation material. Verification does not require access to the originating system, the originating system's keys, or any internal reference maintained by the originating system.
RFC 3161 allows TSAs to be operated as trusted third parties or under other operational models, including internal use. For evidence-class records as used in this entry, the TSA should be outside the administrative control of the writing system to satisfy the independence requirement.
RFC 3161 Section 4 (Security Considerations), item 3, states that timestamp tokens SHOULD be time-stamped again at a later date, using authentic copies of old CRLs where available, or notarized if they are not, to renew trust as TSA signing keys age. For long-retention verification, this requires retaining authentic copies of old CRLs and renewing trust via re-timestamping or notarization as keys age. For long-retention evidence-class records, a documented re-timestamping schedule is appropriate.
What ETSI EN 319 421 addresses:
ETSI EN 319 421 specifies policy and security requirements for operating and managing trust service providers issuing time-stamps. The standard notes that the time-stamping protocol is defined in RFC 3161 (with RFC 5816 update) and profiled in ETSI EN 319 422. It provides a governance framework for TSA operations including compliance, evidence collection, incident management, and business continuity requirements. Where the operational assurance of the timestamp service is a documented requirement, the TSP should operate under ETSI EN 319 421 or an equivalent documented policy framework. ETSI EN 319 421 is cited here as context for TSA governance. It is not a substitute for RFC 3161 as the protocol definition.
Where independent verifiability fails:
A record can carry a cryptographic hash and still not be independently verifiable if the hash is verified only against an internal reference maintained by the originating system. The external party has no way to confirm that the internal reference is itself unmodified.
A record can carry a timestamp and still not be independently verifiable if the timestamp is sourced from the originating system's own clock. The external party has no way to confirm that the clock was accurate or unmanipulated at the time the record was written.
Independent verifiability requires both: a hash verifiable against a reference established externally at point of write, and a time attestation by a TSA independent of the writing system, with the certificate chain and revocation material necessary to confirm that attestation over the retention period.
Failure Modes
Failure Mode 1: Internal Hash Verification Only. A system computes a cryptographic hash of each record at point of write and stores the hash internally. Verification is performed by recomputing the hash and comparing against the stored internal reference. The verification confirms that the record matches the internal reference. It does not confirm that the internal reference is itself unmodified. An external party cannot verify the record without access to the originating system's internal reference store.
Failure Mode 2: System Clock Timestamp Without External Attestation. A record carries a timestamp sourced from the originating system's clock. The timestamp is stored with the record. Under adversarial scrutiny, the external party cannot confirm that the clock was accurate or unmanipulated at the time the record was written. The timestamp is an assertion by the originating system about its own state. It is not an attestation by an independent party.
Failure Mode 3: TSA Not Independent of Writing System. A system issues timestamp tokens using a TSA that is within the same administrative control boundary as the writing system. RFC 3161 permits this operational model. For evidence-class records as used in this entry, it does not satisfy the independence requirement. The token is cryptographically valid. An adversary can challenge the independence of the attestation. The token does not establish independent verifiability as defined here.
Failure Mode 4: Timestamp Token Not Stored with Record. A system obtains RFC 3161 timestamp tokens at point of write but stores them in a separate index or reference system, not co-located with or cryptographically linked to the record. Over time the index is migrated, partially lost, or becomes inaccessible. On retrieval, the record exists but the timestamp token is unavailable. The record's time of attestation is unverifiable independently.
Failure Mode 5: Revocation and Status Material Not Archived. A system issues RFC 3161 timestamp tokens at point of write and stores them with the records. Over the retention period, the revocation and status material necessary to confirm certificate validity at the time of signing becomes unavailable. At the point of verification, the verifier cannot confirm the certificate status evidence required to validate the token for the relevant time period. Per RFC 3161 Section 4 (Security Considerations), item 3, authentic copies of old CRLs should be retained and tokens re-timestamped or notarized to maintain verifiability as keys age. The core long-retention risk is missing status evidence at the relevant time, not certificate expiration in isolation.
Failure Mode 6: Verification Requires Originating System. A record is produced in response to an adversarial demand. The record holder demonstrates integrity by querying the originating system's internal verification API, which returns a confirmation that the record is valid. The external party cannot perform this verification independently. The confirmation is the originating system attesting to its own record. Independent verifiability is not established.
Failure Mode 7: Signing Certificate Identified Using Deprecated Algorithm. A record carries a timestamp token whose long-term verification depends on SHA-1-based signing-certificate identification. RFC 5816 updates RFC 3161 to allow ESSCertIDv2 and use of SigningCertificateV2 when algorithms other than SHA-1 are used, enabling migration away from SHA-1 for certificate identification; SigningCertificateV2 MUST be used if any algorithm other than SHA-1 is used. Separately, as an operational control choice, the messageImprint hash submitted to the TSA should use SHA-256 or stronger. RFC 3161 already allows different hashAlgorithm OIDs in the messageImprint and notes TSAs may reject weak algorithms. These are two distinct concerns: certificate identifier hash agility (RFC 5816) and messageImprint hash strength (RFC 3161 operational choice).
Operational Tests
The following tests allow a practitioner to validate or falsify the independent verifiability of a given record set. Pass conditions are internal engineering gates, not regulatory requirements.
Test 1: External Verification Without Originating System. Select five records from the production store. Attempt to verify each record's integrity and time of attestation using only publicly available trust infrastructure: the TSA's public certificate, certificate chain, archived revocation material, the stored hash, and the stored timestamp token. Do not access the originating system's internal verification mechanisms or reference stores. Pass condition: all five records verify successfully without any access to the originating system. Any record that cannot be verified in this way is not independently verifiable as used in this entry.
Test 2: Timestamp Token Independence Check. For a sample of records, identify the TSA that issued the timestamp tokens. Verify that the TSA is operated by an entity outside the administrative control of the writing system operator. RFC 3161 permits internal TSA operational models; this test applies the independence requirement as defined in this entry for evidence-class records. Pass condition: TSA is demonstrably outside the administrative control boundary of the writing system. A TSA within the same boundary does not satisfy the independence requirement as used here.
Test 3: Token Co-Location Verification. Select ten records. Verify that each carries a timestamp token co-located with or cryptographically linked to the record payload. Verify the token independently against the TSA certificate chain and revocation material. Pass condition: token is present, linked, and verifiable for 100% of sampled records. Any record with a missing or unlinked token is not independently verifiable as to time of attestation.
Test 4: Revocation Material Archival Check. Identify the TSA certificates used to sign timestamp tokens for records in long-term retention. Verify that authentic copies of those certificates, and associated CRLs or equivalent revocation material, are archived and accessible for future verification. Pass condition: complete certificate chain and revocation material are archived and accessible without dependence on the TSA's live systems. Any gap in archival is a future verifiability risk.
Test 5: Re-Timestamping Schedule Verification. For records with retention periods that may exceed the TSA certificate lifecycle, verify that a documented re-timestamping schedule exists and has been executed. Per RFC 3161 Section 4 (Security Considerations), item 3, tokens SHOULD be re-timestamped to renew trust as signing keys age. Pass condition: re-timestamping schedule is documented, executed on schedule, and results are logged.
Test 6: Certificate Identifier Algorithm Check. For records in long-term retention, verify that timestamp tokens use ESSCertIDv2 and SigningCertificateV2 per RFC 5816 where a non-SHA-1 algorithm is used for certificate identification. Separately, verify that the messageImprint hash uses SHA-256 or stronger as an operational control choice. Pass condition: certificate identification uses current algorithm per RFC 5816 requirements; messageImprint uses SHA-256 or stronger. Tokens using SHA-1-based certificate identification without RFC 5816 migration present a weakened identification basis.
Controls
A high-assurance evidence system capable of demonstrating independent verifiability typically implements the following at minimum. These controls are architectural reference points derived from first principles. They are not a compliance guarantee and are not a prescriptive checklist.
Minimum viable set
- Cryptographic hash computed over the full record payload at point of write.
- RFC 3161 timestamp token obtained at point of write from a TSA that is, for evidence-class records as used in this entry, outside the administrative control of the writing system. Token stored co-located with or cryptographically linked to the record.
- TSA certificate chain and revocation material archived for the full retention period.
- Re-timestamping schedule documented and executed for records with retention periods that may exceed the TSA certificate lifecycle.
These four controls represent a minimal baseline. Everything below extends them.
Integrity Binding Controls
- Cryptographic hash computed over the full record payload at point of write. SHA-256 or stronger is a common operational choice in practice. RFC 3161 requires a one-way collision-resistant hash function but does not mandate SHA-256 specifically.
- Hash stored co-located with the record in a form that is not overwritable or replaceable without generating an auditable event.
Time Attestation Controls
- RFC 3161 timestamp token obtained at point of write. For evidence-class records as used in this entry, the TSA should be outside the administrative control of the writing system. RFC 3161 permits other operational models; the independence requirement here is a doctrine requirement, not an RFC 3161 mandate. If tokens are obtained at point of write, genTime can be treated operationally as the attestation-time bound for the record.
- The token's messageImprint should be computed using SHA-256 or stronger as an operational control choice.
- RFC 5816 updates RFC 3161 to allow ESSCertIDv2 so the TSA signing certificate can be identified using hash algorithms other than SHA-1. Where a non-SHA-1 algorithm is used for certificate identification, SigningCertificateV2 must be used per RFC 5816. This is distinct from the messageImprint hash, which is governed by RFC 3161 directly.
- Token stored co-located with the record or cryptographically linked to it. Separate index storage without a verified link is not sufficient.
- Per RFC 3161 Section 4 (Security Considerations), item 3, tokens SHOULD be time-stamped again at a later date, using authentic copies of old CRLs where available, or notarized if they are not, to renew trust as TSA signing keys age. For long-retention records, a documented re-timestamping schedule is appropriate. Authentic copies of historical revocation material should be retained to support future verification.
- Where operational assurance of the timestamp service is a documented requirement, the TSP should operate under ETSI EN 319 421 or an equivalent documented policy framework.
TSA Governance Controls
- For evidence-class records as used in this entry, the TSA should be operated by an entity outside the administrative control of the writing system operator. This is a doctrine requirement. RFC 3161 permits internal TSA operational models.
- TSA selection should be documented, including the basis for the independence determination.
- TSA certificate chain and all associated revocation material (CRLs or equivalent) should be archived for the full retention period of the records they attest, accessible without dependence on the TSA's live systems.
Verification Independence Controls
- Verification procedures should be documented and executable without access to the originating system's internal verification mechanisms or reference stores.
- Verification procedures should be tested periodically by an entity that does not have access to the originating system. Pass condition: verification succeeds using only publicly available trust infrastructure.
- Records that cannot be verified without access to the originating system should be classified as not independently verifiable as used in this entry.
Architecture
Record Created
|
v
Hash(payload)
|
v
Submitted to TSA at point of write (RFC 3161)
(For evidence-class records: TSA outside
administrative control of writing system)
|
v
TSA issues timestamp token
(messageImprint + genTime + TSA identity
via signing certificate identifier)
genTime = attestation-time bound for this record
|
v
Token stored co-located with record
|
v
TSA certificate chain + CRLs archived
|
v
Retention period
|
v
Re-timestamping event (if approaching key expiry)
(per RFC 3161 Section 4, Security Considerations, item 3)
|
v
Verification demand (external party)
|
v
External party verifies using:
- Stored hash (recomputed against record)
- Stored timestamp token
- Archived TSA certificate chain + CRLs
- No access to originating system required
|
v
Independent verifiability confirmed or not confirmed
Diagram reflects controls described in this entry. No new claims are introduced.
What This Is Not
This is not a statement that RFC 3161 is the only mechanism for independent time attestation. RFC 3161 is cited as the primary protocol reference for external timestamp tokens. Equivalent mechanisms may apply depending on context. The framework-level requirement is for time attestation by a TSA that is, for evidence-class records as used in this entry, independent of the writing system, and verifiable by a third party without access to the originating system.
This is not a statement that RFC 3161 mandates TSA independence from the writing system. RFC 3161 permits internal TSA operational models. The independence requirement in this entry is a doctrine requirement for evidence-class records, not an RFC 3161 mandate.
This is not a statement that timestamp tokens establish time of creation. RFC 3161 timestamp tokens establish evidence that a datum existed no later than the genTime value. If tokens are obtained at point of write, genTime can be treated operationally as the attestation-time bound for the record. The strength of that operational treatment depends on the process discipline of the writing system.
This is not a TSA certification or audit standard. ETSI EN 319 421 is cited as context for TSA governance and operational assurance requirements. Full ETSI EN 319 421 scope is broader and is covered separately in that standard.
This is not an encryption or access control framework. Encryption addresses confidentiality. Access control addresses who can read or write records. Independent verifiability addresses whether an external party can confirm a record's integrity and time of attestation without access to the originating system. These are distinct requirements.
This is not a post-incident remediation guide. Records that were not externally attested at point of write are generally not recoverable to an independently verifiable state. Re-attestation after the fact can reduce future verification cost but cannot recreate the original attestation conditions.
This is not limited to financial services. The verification dependency problem applies to any system in which records may be demanded as independently verifiable proof by an external party. The controls apply wherever independent verifiability is an evidentiary requirement.
This is not a prescriptive compliance checklist. Controls described represent a minimum architectural baseline. They are not a guarantee of legal sufficiency for any specific deployment or jurisdiction.