Receive hash and timestamp policy
RFC 3161 timestamp service profiles
TSA · DIGITAL TRUST PRODUCT / SOLUTION PROFILE
Preserve trusted time, validation material and renewal evidence across algorithm and certificate lifecycles.
CUSTOMER PROBLEM
Long-lived documents need trusted time, revocation material and renewal evidence that survive certificate expiry and future algorithm transitions.
PRODUCT-SPECIFIC IMPLEMENTATION FLOW
TSA, OCSP/CRL, evidence stores, signing services and long-term verification. Timestamp samples, validation reports, renewal tests and trusted-time control records.
RFC 3161 timestamp service profiles
PAdES/CAdES/XAdES LT and LTA
OCSP/CRL evidence embedding
Archive timestamp and evidence renewal
Trusted-time source and HSM controls
Verification after certificate or algorithm transition
NAMED COMPONENTS AND RESPONSIBILITIES
The descriptions below state concrete technical behaviour rather than generic support language.
Defines RFC 3161 policies, accepted hash algorithms, request validation, serial handling, accuracy, ordering and response profiles.
Builds PAdES, CAdES and XAdES LT/LTA evidence with certificates, OCSP/CRL responses, timestamp chains and validation context.
Captures revocation evidence at the correct validation time and records how unavailable or stale status information is handled.
Schedules archive timestamp or evidence renewal before certificates, algorithms or status records become unsuitable for future validation.
Protects TSA signing keys in HSMs and monitors trusted-time sources, drift, redundancy, alarms and continuity procedures.
Replays verification after certificate expiry, CA/TSA rollover and algorithm transition to prove that preserved evidence remains usable.
TSA, OCSP/CRL, evidence stores, signing services and long-term verification.
CA, signing, TSA or release components run in a customer-controlled trust boundary with protected keys.
Service components run in a dedicated private-cloud or appliance topology with HSM/QSCD integration.
Classical and target profiles are introduced in phases with relying-party testing, evidence and rollback gates.
PRODUCT-SPECIFIC BOUNDARIES
These points come from the product profile, not from a shared disclaimer.
NEXT STEP
Select one application, exact versions, measurable acceptance criteria and rollback.