1. XML Evidence Record Syntax
XMLERS v06 update and further steps
78th IETF Meeting, Maastricht

2. Agenda Overview Current status and specs Further steps and wrapup
LTANS, 78th IETF, Maastrich, July 2010

3. Overview
XMLERS
Evidence Record Syntax representation in XML format  long term demonstration of data integrity based on time stamping
Structure and processing instructions distinction from ASN.1 ERS representation (!)
Hash values calculation require XML normalization (canonicalization)
Repeating XML sibling elements have no natural order  need for order indicating attributes
Embedded binary data must be encoded into XML compliant characters (base64)
LTANS, 78th IETF, Maastrich, July 2010

4. Overview XMLERS Hash treeing Based on Merkle hash treeing
Optimization of time-sptaming infrastructure/process
Part of archive time stamp element
No general rule for hash tree composition except for archive data object group  has values of archive data object present the initial list of hash values
Might be used for time stamp renewal  hash tree input values presented by time stamp tokens of several ERSs
LTANS, 78th IETF, Maastrich, July 2010

5. Hash treeing
LTANS, 78th IETF, Maastrich, July 2010

6. Structure General structure Sequence of chains of archive time-stamps
ATS1
ATS2
ATS3
ATSn
Archive Time Stamp Chain 1
same digest
algorithm
...
protecting previous chain
ATS1
ATS2
ATSm
Archive Time Stamp Chain 2
...
...
ATS1
ATS2
ATSk
Archive Time Stamp Chain 1
...
LTANS, 78th IETF, Maastrich, July 2010

7. Structure Archive time-stamp structure Time-Stamp Hash-Tree (optional)
Time-Stamp Token
RFC 3161 – base64 encoded
XMLEntrust
CryptographicInformationList (optional)
CERT, CRL, OCSP – base 64 encoded
Hash-Tree (optional)
Unambiguous relationship between time-stamped value and protected data, created as reduced tree from (Merkle) hash tree
Attributes (optional)
LTANS, 78th IETF, Maastrich, July 2010

8. Structure XML structure <EvidenceRecord Version>
<EncryptionInformation /> ?
<ArchiveTimeStampSequence>
<ArchiveTimeStampChain Order>
<DigestMethod />
<CanonicalizationMethod />
<ArchiveTimeStamp Order>
<HashTree /> ?
<TimeStamp>
<TimeStampToken Type />
<CryptographicInformationList /> ?
</TimeStamp >
<Attributes />
</ArchiveTimeStamp> +
</ArchiveTimeStampChain> +
</ArchiveTimeStampSequence>
</EvidenceRecord>
LTANS, 78th IETF, Maastrich, July 2010

9. Processes ERS Generation Compute hash value for archive data object
When consisted of more data chunks /or/ a group process is performed, create a (Merkle) hash-tree and calculate the root hash
Obtain time-stamp for (root) hash value
Create <ArchiveTimeStamp> element composed of:
<ArchiveTimeStamp Order=1>
<HashTree>
<Sequence Order=1>
<DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>
<DigestValue>AZkBNkcGgW...</DigestValue>
</Sequence>
</ HashTree>
<TimeStamp><TimeStampToken Type="RFC3161"> MIAGCSqGSI...</ TimeStampToken >
</TimeStamp>
<ArchiveTimeStamp>
LTANS, 78th IETF, Maastrich, July 2010

10. Processes ERS Renewal Simple (using same hash algorithms)
Collect cryptografic information for the last time-stamp token
Calculate hash value for that time-stamp element
Optionally (group process)
create hash values for all time-stamps to be renewed and generate (Merkle) hash tree
Obtain time-stamp for (root) hash value
Create an archive-time stamp within the current chain
LTANS, 78th IETF, Maastrich, July 2010

11. Processes ERS Renewal Complex (using new hash algorithms)
Collect cryptografic information for the current time-stamp
Calculate hash value for the complete sequence and archive data objects with the new algorithm
Optionally (group process)
create hash values for all time-stamps to be renewed and generate a (Merkle) hash tree
Obtain time-stamp for the (root) hash value
Create a new chain and the initial archive-time stamp within that chain (with a reduced hash-tree)
LTANS, 78th IETF, Maastrich, July 2010

12. Status Current (stable) version 06
Optimization of elements use and structuring
Renewal processes supported
Initial and ERS grouping supported
Time stamp format independency
Cryptographic information = validation data (CRLs, OCSPs, X.509…)
At least two independent implementations and several (at least 5) end user implementations
LTANS, 78th IETF, Maastrich, July 2010

13. Further work Needs to be done Canonicalization methods!
Some (important) typos
Supported methods (some problems with namespaces might arise when using XML interpretation of time stamp tokens)
General structure change
Redefine time stamp element structure
Add time stamp token (e.g. RFC3161 or XML-TS)
Move crypto information into time stamp element resolve the issue with re-timestamping of the whole tree structure
LTANS, 78th IETF, Maastrich, July 2010

14. Further work Further steps New version 07 due Last call Mid August
End of August
LTANS, 78th IETF, Maastrich, July 2010

15. Questions SETCCE Tehnološki park 21 Ljubljana Slovenia +386 1 6204500
LTANS, 78th IETF, Maastrich, July 2010