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

2. Archiving electronic documents
Long-term Problems
algorithms weaken, certificates expire
verification data no longer available
changes of formats and media
ArchiSig-Project
requirements, concepts, implementation, evaluation
clinical trial in Heidelberg
simulation study (mock trial)
influence on ERS
Digital signatures offer the possibility to secure integrity and authenticity of data and documents.
Data + signature, the eletronic form, shall substitute paperbased form, paper + handwritten signature
In many fields of application, documents need to be archived for 30 years or more in a secure and conclusive way.
In Civil Procedure Code Verjährungsfrist is 30 Years
Some Documents, e.g. those, which are needed to proove properties, need to be archived for ever
One problem is, that additional verification data, e.g. actual used public keys of certification instances may be not available in future. We do not deal with that problem here.
Another problem, the topic of this lecture, is, that the hash- or public key-algorithms used can loose their security suitability in the course of time.
The reason is, that computers will get faster or new algorithms will be found, so it is possible to find other documents to the same hash value or to find signature keys
So there is a need to conserve value of evidence of signed documents over long times actively.
Aim of the archisig-project ist to develope technical concepts and solutions which have to be practical, cost-effective and in accordance to legislation.

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
Digital signatures offer the possibility to secure integrity and authenticity of data and documents.
Data + signature, the eletronic form, shall substitute paperbased form, paper + handwritten signature
In many fields of application, documents need to be archived for 30 years or more in a secure and conclusive way.
In Civil Procedure Code Verjährungsfrist is 30 Years
Some Documents, e.g. those, which are needed to proove properties, need to be archived for ever
One problem is, that additional verification data, e.g. actual used public keys of certification instances may be not available in future. We do not deal with that problem here.
Another problem, the topic of this lecture, is, that the hash- or public key-algorithms used can loose their security suitability in the course of time.
The reason is, that computers will get faster or new algorithms will be found, so it is possible to find other documents to the same hash value or to find signature keys
So there is a need to conserve value of evidence of signed documents over long times actively.
Aim of the archisig-project ist to develope technical concepts and solutions which have to be practical, cost-effective and in accordance to legislation.

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

11. Evidence Record Structure
EvidenceRecord ::= SEQUENCE {
version INTEGER { v1(1) },
digestAlgorithms SEQUENCE OF AlgorithmIdentifier,
cryptoInfos [0] CryptoInfos OPTIONAL,
encryption [1] EncryptionMethod OPTIONAL,
archiveTimeStampSequence
ArchiveTimeStampSequence}
Req.7 digestAlgorithms
Req.10 cryptoInfos
Req.9 encryption
Req.1-6 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
R.2-6 reducedHashtree
R.1 timeStamp

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