1 / 15

Enhancing Data Integrity with XML Evidence Record Syntax: Updates from 78th IETF Meeting

This document outlines the latest advancements in the XML Evidence Record Syntax (XMLERS) presented at the 78th IETF Meeting in Maastricht. It provides an overview of data integrity through time-stamping, highlights structuring and processing improvements, and details the need for XML normalization (canonicalization). Key points include hash treeing based on Merkle structures, the significance of embedded binary data, and ongoing developments for supporting ERS renewal processes. Future directions and essential questions are also addressed, paving the way for enhanced data protection protocols.

ethel
Télécharger la présentation

Enhancing Data Integrity with XML Evidence Record Syntax: Updates from 78th IETF Meeting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Agenda • Overview • Current status and specs • Further steps and wrapup

  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)

  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

  5. Hashtreeing

  6. Structure • General structure • Sequence of chains of archive time-stamps Archive Time Stamp Chain 1 ATS1 ATS2 ATS3 ATSn same digest algorithm ... Archive Time Stamp Chain 2 protecting previous chain ATS1 ATS2 ATSm ... ... Archive Time Stamp Chain 1 ATS1 ATS2 ATSk ...

  7. Structure • Archive time-stamp structure • Time-Stamp • 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)

  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>

  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>

  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

  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)

  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

  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

  14. Further work • Further steps • New version 07 due • Mid August • Last call • End of August

  15. Questions SETCCE Tehnološki park 21 Ljubljana Slovenia +386 1 6204500 info@setcce.si www.setcce.si

More Related