Trusted Archive Protocol (TAP) Carl Wallace

What is TAP? A specification that defines: Data structures for representation of archived data and artifacts of the archive process Transactions for interacting with a Trusted Archive Authority (TAA) Service that preserves data via periodic timestamp refresh Transactions include Submission of data for archiving Retrieval of archived data and evidence Deletion of archived data

TAP Goals Data integrity preservation in perpetuity Achieved through timely timestamp refresh Preservation of relevant cryptographic data Data format and data validity agnostic Any type of data (cryptographic or non- cryptographic) can be preserved “Valid” or “invalid” data can be preserved Support additional, optional server-side operations Data validation (evidence verification) Certificate path processing (evidence collection) Etc. Support non-TAP-aware clients for submission

TAP Terminology Archived data Data submitted for archiving (with optional type information) Target of submission operation Archive token Generated by TAA and returned to the submitter to facilitate future retrieval (essentially a canned query) Includes a timestamp, submitter name, tracking information Suitable for inclusion in documents as an unsigned attribute Result of submission operation ArchivedData ::= SEQUENCE { type ArchivedDataType OPTIONAL, data OCTET STRING } ArchiveToken ::= ContentInfo -- content type: id-tap-archiveToken -- content: ArchiveTokenData ArchiveTokenData ::= SEQUENCE { submitterName GeneralName, timestamp TimeStampToken, //rfc3161 curTime GeneralizedTime, trackingInfo TrackingInfos OPTIONAL }

TAP Terminology (continued) Archive record Nested structure containing the timestamp history (innermost layer is the original timestamp) Each layer can be self-contained for verification purposes Maintained by the TAA ArchiveRecord ::= ContentInfo -- content type: id-tap-archiveRecordData -- or id-signedData (id-ct-TSTInfo) -- content: ArchiveRecordData or SignedData (TSTInfo) ArchiveRecordData ::= SEQUENCE { timestampedData TimeStampedData, timestamp TimeStampToken } TimeStampedData ::= SEQUENCE { prevArchRecord ContentInfo, -- previous record messageImprint MessageImprint -- hash archived data }

TAP Terminology (continued) Archive package Minimally includes archive token, archive record and archived data Result of retrieval operation ArchivePackage ::= SEQUENCE { archiveToken ArchiveToken, packageData [0] ArchivePackageData OPTIONAL, pollReference [1] OCTET STRING OPTIONAL } ArchivePackageData ::= SEQUENCE { digestAlgorithms DigestAlgorithmIdentifiers, policy OBJECT IDENTIFIER OPTIONAL, archiveRecord ArchiveRecord, cryptoInfos [0] CryptoInfos OPTIONAL, archivedData ArchivedData }

TAA Services Required services Archived data preservation Archive token generation (including timestamp acquisition) Periodic refresh of the archive record Preservation of PKI information for verification of archive record (i.e. certs, CRLs, OCSP responses, trust anchors, etc.) Optional services Historical trust anchor preservation (i.e. give me trust anchors known at time X) To permit operation of one TAA for data and another TAA for trust roots PKI information collection and/or validation (SCVP) Cryptographic message validation (DVCS)

TAP Transactions All rely upon CMS Requests may optionally be authenticated Deletion requests MUST be authenticated All responses are signed using SignedData CMS messages Only TAA-generated signatures are those on response messages All TAP requests/responses include an optional archive controls field to support nesting of related requests Type/value structure a la extensions, attributes, etc. Field is request/response oriented Intended to convey nonce, SCVP, DVCS, etc.

TAP Submission 1) Submission request -submitter’s name -archived data -policy (optional) -archive controls (optional) Submission client TAA 3) Submission response -status -archive token -archive controls (optional) 2) TAA Processing -Check authentication and authorization (optional) -Process archive controls, if present -Obtain (or generate) a timestamp for archived data -Create archive token and archive record -Store archived data and archive record -Generate response containing archive token and archive control responses, if necessary -Sign and send response 4) Client processing -Verify TAA signature on response -Verify timestamp from archive token - Store archive token for future use

TAA Archive Record Refresh Following submission, TAA is responsible for maintaining archive records without further involvement of the submitter Periodically the TAA will obtain a new timestamp for each archive record - New timestamp covers the previous archive record plus a hash of the archived data generated using a current hashing algorithm - Each layer should be self-contained with regard to certificates, CRLs, etc. - Frequency of refresh operations is dictated by TSA certificate validity period and confidence in current cryptographic algorithms - Structure grows over time

TAP Retrieval 1) Retrieval request -requestor’s name -archive token (or info to initiate a search) -archive controls (optional) Retrieval client TAA 3) Retrieval response -status -archive package -archive controls (optional) 2) TAA Processing -Check authentication and authorization (optional) -Process archive controls, if present -Retrieve archive record and archived data -Create archive package containing archived data, archive token and archive record -Generate response containing archive package and archive control responses, if necessary -Sign and send response 4) Client processing -Verify TAA signature on response -Verify archive record (including all timestamps)

TAP Deletion* 1) Deletion request -requestor’s name -archive token (or info to initiate a search) -archive controls (optional) Deletion client TAA 3) Deletion response -status -archive package -archive controls (optional) 2) TAA Processing -Authenticates requestor -Check authorization (optional) -Process archive controls, if present -Delete archive record and archived data -Generate response containing archive token and archive control responses, if necessary -Sign and send response 4) Client processing -Verify TAA signature on response *Deletion could simply be termination of future refresh operations not physical deletion

What’s Next? Originally submitted as a PKIX draft Topic not accepted as a WG task Draft expired in August Cannibalize, revise or discard -“Long-Term Archive Architecture” draft posted to LTANS web site describes some recommended updates - Specifically cites limited support for searching an archive; no specified means for including metadata, e.g. filename; no means to specify a preservation period, i.e. point in time after which data need no longer be preserved