Evidence Record Syntax <draft- ietf-ltans-ers -00.txt>

1. Evidence Record Syntax<draft-ietf-ltans-ers-00.txt> Brian Hunter brian.hunter@sit.fhg.de

2. Archiving electronic documents • Long-term Problems • algorithms weaken, certificates expire • verification data no longer available • changes of formats and media • ArchiSig-Project 2001 - 2003 • requirements, concepts,implementation, evaluation • clinical trial in Heidelberg • simulation study (mock trial) • influence on ERS

3. Goals of data structure • Standard structure containing complete proof of existence, which can be exchanged between parties • EvidenceRecord external format, without forcing a particular architecture to be used by Archive Provider • No restriction on type of data • Support of encrypted data

4. Requirements from LTANS • include all timestamps necessary to verify existence • data structure can efficiently provide evidence for many archived data objects • possible to provide evidence for data groups • even within groups, non-rep proof for single object still possible • deletion possible without affecting proofs of other data objects • time-stamping possible without accessing data objects; only access data when hash alg becomes weak • single location of all hash algorithms applied • possible to include evidence and data within one structure or separately • possible to archive encrypted data and allow integration of encryption info within evidence record • possible to integrate additional info within the evidence record

5. ERS Overview • Syntax and Processing (particularly verification)of an Archive Time Stamp Element • to verify existance of any data objects over an undetermined period of time, useable for signature renewal • optimized (but not restricted to) centralized Archive Time Stamping by Trusted Archive Authority • including optional encryption • addendum: integration into signed documents • Not specified here: • Service protocol: possible but not necessary for internal use • Architectures of archive systems

6. Archive Time-Stamp • Archive Time Stamp • hash-tree (Merkle) • time-stamp containing digital signature • single time-stamp for many data objects • Initial Stamp • event: after document is archived • collect hash values of many documents and build tree, request time-stamp • store archive time-stamp • renew if necessary • Reduction to Archive Time-Stamp • necessary hash values for verification +time-stamp • {SEQUENCE of SEQUENCE of OCTET STRINGtime-stamp} Hint: each Sequence Of Octet String is one layer of the tree SEQ2[1] SEQ1[2]

7. Time-Stamp Renewal • Event: Any algorithm in time-stamp becomes weak(or time-stamp certificate expires) • Method • hash time-stamp with old hash algorithm • and include it in new archive time-stamp • Properties • no access to data objects • only few (at minimum 1) time-stamp for a whole archive • Reduction: ArchiveTimeStampChain • SEQUENCE of ArchiveTimeStamp

8. Hashtree Renewal • Event: Hash Algorithm of chain becomes weak • Method (for each data object) • build Archive Time-Stamp chain • include hash of (hash of chain + hash of data object) in new Archive Time-Stamp • Properties • need to access data objects • avoidable via redundant hash trees • Reduction: ArchiveTimeStampSequence • SEQUENCE of ArchiveTimeStampChain

9. ERS Approach Client - Submission • Select data objects (document, ..) • Optional: Encrypt data objects Trusted Archive Authority – Reception and maintenance • Initial Archive Time-Stamp • Renewal: Time-Stamp Renewal, Hashtree Renewal • Reduce hashtrees, generate Archive Timestamps Elements Client - Retrieval • Optional: Decrypt data objects • Optional: Add encryption info to record • Optional: Integrate as an attribute if wanted • Verify Archive Time-Stamps Element and document

10. Doc Storage Evidence Record1 Time rHT(Doc1 wrt Doc1-j) TSa (Root of rHT) Today eDoc1 .. eDocn ERinit= rHT(TSa wrt other TS) TStsr (Root of rHT) Expiry of TS-cert or sig alg weakens Expiry of TS-cert or sig alg weakens ERtsr1= rHT(TSa wrt other TS) TStsr (Root of rHT) Hash alg weak ERtsr2= rHT(Prev ERs|Hash(Doc1)..) TStsr (Root of rHT) ERhtr= ER1 EvidenceRecord1 Judge ERS Approach Client Trusted Archive Authority eDoc1 EncryptionMethod cek or private key rHT = reduced hash-tree TS = Time-stamp eDoc1

11. Evidence Record Structure EvidenceRecord ::= SEQUENCE { version INTEGER { v1(1) }, digestAlgorithms SEQUENCE OF AlgorithmIdentifier, cryptoInfos [0] CryptoInfos OPTIONAL, encryption [1] EncryptionMethod OPTIONAL, archiveTimeStampSequence ArchiveTimeStampSequence}

12. Archive Time-Stamp ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm AlgorithmIdentifier OPTIONAL, reducedHashtree [0] SEQUENCE OF {SEQUENCE OF OCTET STRING} OPTIONAL, timeStamp ContentInfo} ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp ArchiveTimeStampSequence ::= SEQUENCE OF ArchiveTimeStampChain

13. Optional Encryption • Caution: Encryption must be unambigious! • Method: • CMS-Encryption before archiving (Algorithms: RSA, DES-CBC) • Archive Service time-stamps data as always • add CMS-cover to CMS-encryption-params, store content seperately • verification: reconstruction of archive time-stamped data object by decryption of content-encryption key, reencrypt content, insert content CMS_encryption_params::= SEQUENCE { encryptionCover ContentInfo, publicKey BIT STRING OPTIONAL, params CHOICE { [0] privateKey BIT STRING, [1] encryptionKeyRan EncryptionKeyRandom}} EncryptionKeyRandom::= SEQUENCE { encryptionKey OCTET STRING, randomValue BIT STRING}}

14. Appendices • Optional Integration • CMS: signed data • Archive Time-Stamps-Element as an unsigned signature attribute for signature

15. Summary • Syntax + Processing of ArchiveTimeStamp Element • optimized for centralized time-stamping • effective for large document volumes • applicable for any data objects and groups of data objects • normally no need to access data • redundancy easy to realize • compatible with existing services