RFC 6283
Extensible Markup Language Evidence Record Syntax (XMLERS)
RFC 6283: Extensible Markup Language Evidence Record Syntax (XMLERS) 🎀
- Title: Extensible Markup Language Evidence Record Syntax (XMLERS) 💅
- Authors: A. Jerman Blazic, S. Saljic (SETCCE), and T. Gondrom 🫶
- Category: Standards Track 🔥
- Published by: Internet Engineering Task Force (IETF) 🌈
- ISSN: 2070-1721
- Date: July 2011 🍓
- Obsoletes / Updates: this header doesn't list any RFCs that it obsoletes or updates 🙈
Abstract
okay so the big idea here is that people often need to prove stuff about their data, like when it existed, that it hasn't been messed with, and that it's still valid, even when the data is signed and the timeline is super long or totally undetermined ⏳✨ this document lays out the XML syntax and processing rules for making evidence for long-term non-repudiation of data existence and integrity 💖 XMLERS gives you an alternative to the ASN.1 (Abstract Syntax Notation One) ERS (Evidence Record Syntax) (RFC 4998) syntax, but it's written in XML instead 🦋
Status of This Memo
this is an Internet Standards Track document 👑
it's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check out Section 2 of RFC 5741 🧚
for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6283 💜
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. please read these carefully, because they explain your rights and restrictions for this document 🙏 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ⭐
Table of Contents
1. Introduction ....................................................3
1.1. Motivation .................................................3
1.2. General Overview and Requirements ..........................4
1.3. Terminology ................................................6
1.4. Conventions Used in This Document ..........................7
2. Evidence Record .................................................7
2.1. Structure ..................................................8
2.2. Generation ................................................12
2.3. Verification ..............................................13
3. Archive Time-Stamp .............................................13
3.1. Structure .................................................13
3.1.1. Hash Tree ..........................................13
3.1.2. Time-Stamp .........................................14
3.1.3. Cryptographic Information List .....................15
3.2. Generation ................................................16
3.2.1. Generation of Hash Tree ............................17
3.2.2. Reduction of Hash Tree .............................19
3.3. Verification ..............................................21
4. Archive Time-Stamp Sequence and Archive Time-Stamp Chain .......22
4.1. Structure .................................................23
4.1.1. Digest Method ......................................23
4.1.2. Canonicalization Method ............................24
4.2. Generation ................................................25
4.2.1. Time-Stamp Renewal .................................25
4.2.2. Hash Tree Renewal ..................................26
4.3. Verification ..............................................27
5. Encryption .....................................................28
6. Version ........................................................29
7. Storage of Policies ............................................30
8. XSD Schema for the Evidence Record .............................30
9. Security Considerations ........................................34
9.1. Secure Algorithms .........................................34
9.2. Redundancy ................................................34
9.3. Secure Time-Stamps ........................................35
9.4. Time-Stamp Verification ...................................35
10. IANA Considerations ...........................................36
11. References ....................................................37
11.1. Normative References .....................................37
11.2. Informative References ...................................39
Appendix A. Detailed Verification Process of an Evidence Record ...411. Introduction ✨
so the whole point of this document is to define an XML schema and processing rules for Evidence Record Syntax in XML (Extensible Markup Language) format 🎀 It's related to the original ASN.1 (Abstract Syntax Notation One) syntax for Evidence Record Syntax, which is defined in [RFC4998] 🦋
1.1. Motivation
okay, the way electronic commerce and electronic data exchange keep growing means we need non-repudiable proof of data existence, plus proof of data integrity and authenticity 💼 That data and its non-repudiable proof of existence have to last for long periods of time, even when the original info that proves its existence and integrity gets weaker or stops existing altogether 😭 Digital signatures, like the ones defined in [RFC5652], don't give absolute reliability over the long haul. The algorithms and cryptographic material used to make a signature can get weak over time, and the info you need to validate a digital signature might get compromised or just disappear, for example because a certificate service provider shut down 💀 So if we want a stable environment for electronic data over the long term, we need extra ways to keep providing an appropriate level of trust in evidence of data existence, integrity, and authenticity 🫶
every integrity and authenticity protection technique we use today has the same problem: its reliability fades over time 🥀 That includes Time-Stamping, which people generally recognize as a way to prove data existence and integrity 🕰️ Over long periods, the cryptographic algorithms in use might get weak, or encryption keys might get compromised 🔑 Some of the problems aren't even technical, like a Time-Stamping Authority going out of business and stopping its service 🙈 To build a stable environment where proof of existence and integrity can last well into the future, we need a new technical approach 🌈
long-term non-repudiation of data existence and demonstration of data integrity techniques already exist. For example, long-term signature syntaxes like the ones defined in [RFC5126] do this 🧠 But those long-term signature syntaxes and processing rules only cover the long-term survival of the digital signatures themselves. Evidence Record Syntax takes the same approach further, so it works for data of any type or format, including digital signatures ⭐
XMLERS (Extensible Markup Language Evidence Record Syntax) is based on Evidence Record Syntax as defined in [RFC4998], and it tackles the same problem: long-term non-repudiable proof of data existence and long-term demonstration of data integrity 💖 XMLERS doesn't supplement the [RFC4998] specification. Instead, it follows extensible markup language standards and [RFC3470] guidelines to bring the same approach in a different format with adapted processing rules 🦋
XML (Extensible Markup Language) is already recognized by a huge range of applications and services, and it's becoming the de facto standard for lots of data exchange apps 👑 Putting Evidence Record Syntax into XML format makes XML even more useful and gives us a harmonized syntax that fits with a growing community of XML-based standards, including security services like [XMLDSig] or [XAdES] 💅
because XML processing rules and other XML characteristics are different, XMLERS isn't a direct transformation of ERS in ASN.1 syntax. For example, it doesn't support importing ASN.1 values into XML tags 🙅♀️ If you're creating Evidence Records in XML syntax, you must follow the steps defined in this document. XMLERS is a standalone document, and it's only conceptually based on [RFC4998]. This document has enough info to implement Evidence Record Syntax in XML format, and references to [RFC4998] are for informative purposes only 🎀
Evidence Record Syntax in XML format is based on the long-term archive service requirements defined in [RFC4810] 🗂️ XMLERS delivers the same (level of) non-repudiable proof of data existence as ASN.1 ERS [RFC4998] does ✨ The XML syntax supports archive data grouping (and de-grouping), along with simple or complex Time-Stamp renewal processes 🔄 Evidence Records can be embedded in the data itself, or stored separately as a standalone XML file 🧚
1.2. General Overview and Requirements
Okay so XMLERS is the XML syntax and processing rules for making evidence that proves the long-term non-repudiation of existence and integrity of data 🔐✨. That evidence gets packed into a unit called the "Evidence Record" 📜. XMLERS is built to meet the data structure requirements in [RFC4810], and this doc also refers to the ASN.1 ERS spec from [RFC4998] 🎀.
An Evidence Record can be made and maintained for a single data object, or for a group of data objects that together form an archive object 🗂️. A data object (a binary chunk or a file) can be any kind of document or a part of one 🌸. Dependencies between data objects, their validation, or any relationship other than "a data object is a part of particular archived object" are outside the scope of this document 🙅♀️ (not me being dramatic, just the boundaries 💅).
Evidence Record is closely related to Time-Stamping techniques 💜. But Time-Stamps as defined in [RFC3161] can only cover a single unit of data, and they don't give processing rules for keeping Time-Stamps stable over the long term 😭. So evidence for an archive object is created by getting a Time-Stamp from a trustworthy authority for a specific value that is unambiguously related to one or more data objects. The relationship between several data objects and a single Time-Stamped value is handled with a hash tree 🌳, a technique first described by Merkle [MER1980] and later in [RFC4998], using the data structures and procedures specified in this document. The Evidence Record Syntax lets you process several archive objects in one processing pass using a hash tree, and you only need to acquire one Time-Stamp to protect all of them ⭐. The leaves of the hash tree are hash values of the data objects in a group, and a Time-Stamp is only requested for the root hash of the tree 🍃. Deleting a data object from the tree doesn't affect the provability of the others 🦋. For any particular data object, the hash tree can be reduced to a few sets of hash values, which are enough to prove the existence of that one data object 🔍. The hash tree can also be reduced to prove the existence of a data group, as long as all members of the group have the same parent node in the hash tree 👑. Archive Time-Stamps are made up of an optional reduced hash tree and a Time-Stamp 💖.
Besides a Time-Stamp, other artifacts are also kept in an Evidence Record 🧚: the data needed to verify the relationship between a time-stamped value and a specific data object (packed into a structure called a "hash tree"), and long-term proofs for the formal verification of the included Time-Stamp(s) 📦.
Here's the thing though 😤. Digest algorithms or cryptographic methods may become weak, and certificates used within a Time-Stamp (and signed data) may be revoked or expire. Because of that, the collected evidence data must be monitored and renewed before those events happen ⏰. This document introduces XML-based syntax and processing rules for creating and continuously renewing evidence data 🔄✨.
1.3. Terminology
Archive Data Object: An archive data object is a data unit that is archived and has to be preserved for a long time by the long-term archive service 🗃️.
Archive Data Object Group: An archive data object group is a set of archive data objects that, for some reason, (logically) belong together. For example, a group of document files, or a document file and a signature file, could represent an archive data object group 👯♀️.
Archive Object (AO): An AO is an archive data object or an archive data object group 🎁.
Archive Time-Stamp (ATS): An ATS contains a Time-Stamp Token, useful data for validation, and optionally a set of ordered lists of hash values (a hash tree). An Archive Time-Stamp relates to a data object if the hash value of this data object is part of the first hash value list of the Archive Time-Stamp, or if its hash value matches the Time-Stamped value. An Archive Time-Stamp relates to a data object group if it relates to every data object of the group and no other data object (i.e., the hash values of all but no other data objects of the group are part of the first hash value list of the Archive Time-Stamp) (see Section 3) 🧾.
Archive Time-Stamp Chain (ATSC): An ATSC holds a sequence of Archive Time-Stamps generated during the preservation period 🔗.
Archive Time-Stamp Sequence (ATSSeq): AN ATSSeq is a sequence of Archive Time-Stamp Chains 🧵.
Canonicalization: Canonicalization refers to processing rules for transforming an XML document into its canonical form. Two XML documents may have different physical representations but the same canonical form. For example, a sort order of attributes does not change the meaning of the document, as defined in [XMLC14N] 🪄.
Cryptographic Information: Cryptographic information is data, or part of data, related to the validation process of signed data, e.g., digital certificates, digital certificate chains, and Certificate Revocation Lists 🔑.
Digest Method: A digest method is a digest algorithm, which is a strong one-way function, for which it is computationally infeasible to find an input that corresponds to a given output, or to find two different input values that correspond to the same output. A digest algorithm transforms input data into a short value of fixed length. The output is called digest value, hash value, or data fingerprint .
Evidence: Evidence is information that may be used to resolve a dispute about various aspects of authenticity, validity, and existence of archived data objects ⚖️.
Evidence Record: An Evidence Record is a collection of evidence compiled for a given archive object over time. An Evidence Record includes an ordered collection of ATSs, which are grouped into ATSCs and ATSSeqs 📚.
Long-Term Archive (LTA): An LTA is a service responsible for generation, collection, and maintenance (renewal) of evidence data. An LTA may also preserve data for long periods of time, e.g., storage of archive data and associated evidences 🏰.
Hash Tree: A hash tree is a collection of hash values of protected objects (input data objects and generated evidence within archival period) that are unambiguously related to the Time-Stamped value within an Archive Time-Stamp 🌲.
Time-Stamp Token (TS): A TS is a cryptographically secure confirmation generated by a Time-Stamping Authority (TSA), e.g., [RFC3161], which specifies a structure for Time-Stamps and a protocol for communicating with a Time-Stamp Authority. Besides this, other data structures and protocols may also be appropriate, such as those defined in [ISO-18014-1.2002], [ISO-18014-2.2002], [ISO-18014-3.2004], and [ANSI.X9-95.2005] 🎫.
1.4. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📏✨.
2. Evidence Record 📜
An Evidence Record is a unit of data that is used to prove the existence of an archive object (a single archive data object or an archive data object group) at a certain time ⏳. Through the lifetime of an archive object, an Evidence Record also demonstrates the data objects' integrity and non-repudiability 🛡️. To achieve this, cryptographic means are used, i.e., the LTA obtains Time-Stamp Tokens from the Time-Stamping Authority (TSA) 🤝. It's possible to store the Evidence Record separately from the archive object, or to integrate it into the data itself 🧩.
Since cryptographic means are used to support Evidence Records, those records may lose their value over time 🥀. Time-Stamps obtained from Time-Stamping Authorities may become invalid for a number of reasons, usually because of time constraints on Time-Stamp validity, or when cryptographic algorithms lose their security properties 🕰️. Before the used Time-Stamp Tokens become unreliable, the Evidence Record has to be renewed 🔁. This may result in a series of Time-Stamp Tokens that are linked together according to the cryptographic methods and algorithms used 🔗💅.
Evidence Records can be supported with additional information, which can be used to make the processes of Evidence Record validation and renewal easier 🧸. Information such as digital certificates and Certificate Revocation Lists, as defined in [RFC5280], or other cryptographic material can be collected, enclosed, and processed together with archive object data (i.e., Time-Stamped) 💎.
2.1. Structure
Okay so an Evidence Record holds one or several Archive Time-Stamps (ATSs) ✨. Each ATS has a Time-Stamp Token, plus optional extras that help validate the timestamp, like certificates, CRLs (Certificate Revocation Lists), or OCSP (Online Certificate Status Protocol) responses, and specific attributes such as service policies 💅.
Here's the glow-up part 🦋: an ATS gets acquired first, and then, before it expires or becomes invalid, a new ATS gets acquired. That renewal prolongs the validity of the archived object (its data objects together with all the Archive Time-Stamps generated before it). This process MUST continue for the whole desired archiving period of the archive data object(s). A series of successive Archive Time-Stamps is collected into Archive Time-Stamp Chains, and a series of chains makes up an Archive Time-Stamp Sequence 🧚.
In XML syntax, the Evidence Record is the <EvidenceRecord> root element. Its structure is shown below in Pseudo-XML. The full XML schema is in Section 8 💖 (where "?" means zero or one occurrences, "+" means one or more occurrences, and "*" means zero or more occurrences):
<EvidenceRecord Version>
<EncryptionInformation>
<EncryptionInformationType>
<EncryptionInformationValue>
</EncryptionInformation> ?
<SupportingInformationList>
<SupportingInformation Type /> +
</SupportingInformationList> ?
<ArchiveTimeStampSequence>
<ArchiveTimeStampChain Order>
<DigestMethod Algorithm />
<CanonicalizationMethod Algorithm />
<ArchiveTimeStamp Order>
<HashTree /> ?
<TimeStamp>
<TimeStampToken Type />
<CryptographicInformationList>
<CryptographicInformation Order Type /> +
</CryptographicInformationList> ?
</TimeStamp>
<Attributes>
<Attribute Order Type /> +
</Attributes> ?
</ArchiveTimeStamp> +
</ArchiveTimeStampChain> +
</ArchiveTimeStampSequence>
</EvidenceRecord>The syntax of an Evidence Record is defined as an XML schema [XMLSchema], see Section 8. The schema uses the XML namespace [XMLName] urn:ietf:params:xml:ns:ers as its default namespace, and there's a detailed xml schema header listed in Section 8 too 🎀.
The XML elements and attributes mean the following:
- The
Versionattribute MUST be included. It indicates the syntax version, so it stays compatible with future revisions of this specification and can be told apart from earlier non-conformant or proprietary versions of XMLERS. The current version of XMLERS is 1.0. The versioning scheme is described in detail in Section 6. - The
<EncryptionInformation>element is OPTIONAL and holds information on the cryptographic algorithms and cryptographic material used to encrypt archive data (in case the archive data is encrypted, e.g., for privacy purposes). This optional information is needed to unambiguously re-encrypt data objects when Evidence Records are processed. When it's omitted, the data objects are not encrypted, or non-repudiation proof is not needed for the unencrypted data. Details on how to process encrypted archive data and generate Evidence Record(s) are in Section 5 🔐. - The
<SupportingInformationList>element is OPTIONAL and can hold information that supports processing of Evidence Records. An example is a processing policy, like a cryptographic policy (e.g., [RFC5698]) or an archiving policy, which can give input about preservation and evidence validation. Each data object goes into its own child element<SupportingInformation>, with an OPTIONAL Type attribute to indicate its type for processing directions. As outlined, the Types to be used must be defined in the specification of the information structure to be stored, or in this standard. As outlined in Section 9.4, cryptographic information may also be stored in theSupportingInformationelement, in which case its Section 3.1.3 defined type MUST be used. Or, as defined in Section 7, cryptographic policies [RFC5698] MAY be stored, in which case the used type is defined in the relevant RFC.
Note that if supporting information and policies are relevant for, and already available at or before, the time of individual renewal steps (e.g., to indicate the DSSC crypto policy [RFC5698] that was used at the time of the individual renewal), they SHOULD be stored in the <Attributes> element of the individual Archive Time-Stamp (see below), because that's integrity protected by the Archive Time-Stamps 🛡️. Supporting information that's relevant for the whole Evidence Record (like the LTA's current Cryptographic Algorithms Security Suitability policy (DSSC, [RFC5698])), or that wasn't available at the time of renewal (and therefore couldn't later be stored in the protected <Attributes> element), can be stored in this <SupportingInformation> element.
- The
<ArchiveTimeStampSequence>element is REQUIRED and contains a sequence of one or more<ArchiveTimeStampChain>elements. - The
<ArchiveTimeStampChain>element is REQUIRED and holds a sequence of Archive Time-Stamps generated during the preservation period. Details on Archive Time-Stamp Chains and Archive Time-Stamp Sequences are in Section 4. The sequences of Archive Time-Stamp Chains and Archive Time-Stamps MUST be ordered, and the order MUST be indicated with the "Order" attribute of the<ArchiveTimeStampChain>and<ArchiveTimeStamp>elements 🔢. - The
<DigestMethod>element is REQUIRED and contains anAlgorithmattribute that identifies the digest algorithm used within one Archive Time-Stamp Chain to calculate digest values from the archive data object(s), the previous Archive Time-Stamp Sequence, Time-Stamps, and within a Time-Stamp Token. - The
<CanonicalizationMethod>element is REQUIRED. It specifies which canonicalization algorithm is applied to the archive data for XML data objects, or to<ArchiveTimeStampSequence>or<TimeStamp>elements, before digest value calculations are performed. - The
<HashTree>element is OPTIONAL and holds a structure as described in Section 3.1.1 🌳. - The
<TimeStamp>element is REQUIRED and holds a<TimeStampToken>element with a Time-Stamp Token (as defined in Section 3.1.2) provided by the Time-Stamping Authority, plus an OPTIONAL<CryptographicInformationList>element. - The
<CryptographicInformationList>element is OPTIONAL. It allows storing the data needed in Time-Stamp Token validation, for cases where that data isn't provided by the Time-Stamp Token itself. This could include possible trust anchors, certificates, revocation information, or the current definition of the suitability of cryptographic algorithms, past and present. Each data object goes into its own child element<CryptographicInformation>, with a REQUIRED Order attribute to indicate the order within its parent element. These items may be added based on the policy used. This data is protected by successive Time-Stamps in the sequence of the Archive Time-Stamps 🔒. - The
<Attributes>element is OPTIONAL and contains additional information that may be provided by an LTA to support processing of Evidence Records. An example is a processing policy, like a renewal policy, a cryptographic policy (e.g., [RFC5698]), or an archiving policy. Such policies can provide inputs that are relevant for preservation of the data object(s) and evidence validation at a later stage. Each data object goes into its own child element<Attribute>, with a REQUIRED Order attribute to indicate the order within the parent element, and an OPTIONAL Type attribute to indicate processing directions. The type to be used must be defined in the specification of the information structure. For example, the type to be used when storing a cryptographic policy [RFC5698] is defined in Appendix A.2 of [RFC5698].
The Order attribute is REQUIRED in all cases where one or more XML elements with the same name occur on the same level in XMLERS' <ArchiveTimeStampSequence> structure. Although most XML parsers preserve the order of sibling elements with the same name, XML has no definition of how to unambiguously define such an order. Preserving the correct order in these cases matters a lot for digest value calculations over XML structures 🧠.
2.2. Generation
The generation of an <EvidenceRecord> element MUST be as follows:
- Select an archive object (a data object or a data object group) to archive.
- Create the initial
<ArchiveTimeStamp>. This is the first ATS within the initial<ArchiveTimeStampChain>element of the<ArchiveTimeStampSequence>element. - Refresh the
<ArchiveTimeStamp>when necessary, by Time-Stamp renewal or hash tree renewal (see Section 4) ♻️.
The Time-Stamping service can be expensive and time-demanding when there are a lot of archived objects, so the LTA may benefit from acquiring one Time-Stamp Token for many archived objects that aren't otherwise related to each other 💸. It's possible to collect many archive objects, build a hash tree to generate a single value to be Time-Stamped, and then reduce that hash tree to small subsets that give each archive object the necessary binding with the Time-Stamped hash value (see Section 3.2.1) 🌲.
For performance reasons, or in case of local Time-Stamp generation, building a hash tree (<HashTree> element) can be omitted. It's also possible to convert existing Time-Stamps into an ATS for renewal.
The case where only essential parts of documents or objects shall be protected is out of scope for this standard. An application that is not defined in this document must ensure that the correct, unambiguous extraction of binary data is made for the generation of an Evidence Record 🙅♀️.
An application may also provide evidence, such as certificates, revocation lists, etc., needed to verify and validate signed data objects or a data object group. This evidence may be added to the archive data object group and will be protected within the initial (and successive) Time-Stamp(s) ✅.
Note that the <CryptographicInformationList> element of an Evidence Record is not to be used to store and protect cryptographic material related to signed archive data. The use of this element is limited to cryptographic material related to the Time-Stamp(s). 🚫
2.3. Verification
The overall verification of an Evidence Record MUST be as follows:
- Select an archive object (a data object or a data object group).
- Re-encrypt the data object or data object group, if the encryption field is used (for details, see Section 5).
- Verify the Archive Time-Stamp Sequence (details in Sections 3.3 and 4.3) 🔍.
3. Archive Time-Stamp ✨
okay so an Archive Time-Stamp is a regular Time-Stamp with extra artifacts attached 🎀 that let you verify the existence of several data objects at a certain time. it's giving long-term receipts 🧾💅
the whole construction process has to support evidence over the long haul and prove that the archive object existed and was identical, at the time of the Time-Stamp, to the archive object that's sitting there when you verify it 👀 so to make that work, an ATS MUST be renewed before it becomes invalid 🔄 and yes, that can happen for a bunch of reasons, like the cryptographic algorithms getting weak over time, a digital certificate getting invalidated, or a TSA shutting down its business or ceasing its service 😭
3.1. Structure
an Archive Time-Stamp holds a Time-Stamp Token 🎫 plus useful data for validating it (the cryptographic info, like the certificate chain or Certificate Revocation Lists). it can also have an optional ordered set of ordered lists of hash values (a hash tree) that got protected along with the Time-Stamp Token, and optional info describing the renewal steps in an <Attributes> element 🧩 a hash tree is handy for storing the data you need to bind the Time-Stamped value to the protected objects. if there's no hash tree, the ATS just refers to a single object, either an input data object or a previous TS 🌸
3.1.1. Hash Tree
the hash tree is an optional container for the significant values you need to unambiguously relate a Time-Stamped value to the protected data objects 🌳 it's represented by the <HashTree> element. the root hash value generated from the values of the hash tree MUST be the same as the Time-Stamped value 🔥
<HashTree>
<Sequence Order>
<DigestValue>base64 encoded hash value</DigestValue> +
</Sequence> +
</HashTree>okay so here's how you get the root hash value from the <HashTree> element 🧠 you take the content of each <DigestValue> in the first <Sequence> element and base64 decode it ([RFC4648], using the base64 alphabet, not the base64url alphabet) to get a binary value (the hash value). then you sort all the collected hash values from that sequence in binary ascending order, concatenate them, and generate a new hash value from that string. there's one exception to this rule 🙈 if the first <Sequence> element has only one <DigestValue> element, its binary value gets added to the next list from the next <Sequence> element instead.
the newly calculated hash value gets added to the next list of hashes from the next <Sequence> element, and you keep repeating that until only one hash value is left, which is when there are no <Sequence> elements left ✨ the last calculated hash value is the root hash value 👑 when an archive object is a group made of more than one data object, the first hash list MUST contain the hash values of all of its data objects 💜
when one Time-Stamp covers a whole set of archive objects, the LTA MUST construct a hash tree to generate a single hash value that binds all the archive objects in that group 🫶 then a reduced hash tree MUST be calculated from that hash tree for each archive object separately (see Section 3.2.1) 🦋
for example 🌈 a SHA-1 digest value is a 160-bit string. the text value of the <DigestValue> element shall be the base64 encoding of that bit string, viewed as a 20-octet octet stream. and to keep going with the example, take the example message digest value A9993E364706816ABA3E25717850C26C9CD0D89D (this is a HEX encoded value of the 160-bit message digest). its base64 representation would be <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue> 🍓
3.1.2. Time-Stamp
a Time-Stamp Token is an attestation, generated by a TSA, that a data item existed at a certain time ⏰ it's a signed data object that contains the hash value, the identity of the TSA, and the exact time (obtained from a trusted time source) of the Time-Stamping 🕰️ this proves the given data existed before the time of the Time-Stamping. for example, [RFC3161] specifies a structure for signed Time-Stamp Tokens in ASN.1 format 📜 since there's no standard for an XML Time-Stamp at the time being, the following structure example is provided [TS-ENTRUST] 🧚 it's a digital signature compliant with the [XMLDSig] specification, containing Time-Stamp specific data, like the Time-Stamped value and the time, inside the <Object> element of a signature.
<element name="TimeStampInfo">
<complexType>
<sequence>
<element ref="Policy" />
<element ref="Digest" />
<element ref="SerialNumber" minOccurs="0" />
<element ref="CreationTime" />
<element ref="Accuracy" minOccurs="0" />
<element ref="Ordering" minOccurs="0" />
<element ref="Nonce" minOccurs="0" />
<element ref="Extensions" minOccurs="0" />
</sequence>
</complexType>
</element>a <TimeStamp> element of an ATS holds a complete Time-Stamp Token structure as provided by a TSA 🎀 the Time-Stamp Token can be in XML or ASN.1 format. the Attribute type MUST be used to indicate the format for processing purposes, with the values "XMLENTRUST" or "RFC3161" respectively 🫧 for an RFC3161 type Time-Stamp Token, the <TimeStamp> element MUST contain the base64 encoding of a DER-encoded ASN1 data 🙌 these type values are registered by IANA (see Section 10). and for support of future types of Time-Stamps (especially future XML Time-Stamp standards), those need to be registered there as well 🔮
for example:
<TimeStamp Type="RFC3161">MIAGCSqGSIb3DQEH...</TimeStamp>or
<TimeStamp Type="XMLENTRUST"><dsig:Signature>...</dsig:Signature>
</TimeStamp>3.1.3. Cryptographic Information List
digital certificates, CRLs (Certificate Revocation Lists), SCVP (Server-Based Certificate Validation Protocol) responses, or OCSP-Responses (Online Certificate Status Protocol) needed to verify the Time-Stamp Token SHOULD be stored in the Time-Stamp Token itself 💖 when that's not possible, such data MAY be stored in the <CryptographicInformationList> element. each data object goes into its own <CryptographicInformation> element, with a REQUIRED Order attribute 📦
the Type attribute is REQUIRED and stores processing info about the type of cryptographic information 🎯 the Type attribute MUST use a value registered with IANA, as one of these identifiers: CRL, OCSP, SCVP, or CERT. and for each type, the content MUST be encoded like this:
- for type CRL, a base64 encoding of a DER-encoded X.509 CRL [RFC5280]
- for type OCSP, a base64 encoding of a DER-encoded OCSPResponse [RFC2560]
- for type SCVP, a base64 encoding of a DER-encoded CVResponse; [RFC5055]
- for type CERT, a base64 encoding of a DER-encoded X.509 certificate [RFC5280]
the supported type identifiers are registered by IANA (see Section 10) 🌷 future supported types can be registered there too, for example to support future validation standards 🚀
3.2. Generation
an initial ATS relates to a data object or a data object group that represents an archive object 🗂️ the initial ATS element can be generated in a single process pass for one archived object or for many 🙌 it MUST be done as described in the following steps 📋
- Collect one or more archive objects to be Time-Stamped 🧺
- Select a canonicalization method C to be used for getting the binary representation of archive data and for the Archive Time-Stamp at a later stage in the renewing process (see Section 4) 🔍 note that the selected canonicalization method MUST be used for archive data also when the data is represented in XML format 💅
- Select a valid digest algorithm H 🔐 the selected secure hash algorithm MUST be the same as the hash algorithm used in the Time-Stamp Token and for the hash tree computations 💜
- Generate a hash tree for the selected archive object (see Section 3.2.1) 🌳
the hash tree may be omitted in the initial ATS when an archive object has a single data object. in that case, the Time-Stamped value MUST match the digest value of that single data object 🙈
- Acquire a Time-Stamp token from the TSA for the root hash value of the hash tree (see Section 3.1.1) 🎉 if the Time-Stamp token is valid, the initial Archive Time-Stamp may be generated 🦋
3.2.1. Generation of Hash Tree ✨
okay bestie, first things first 🫶 the <DigestValue> elements inside a <Sequence> element MUST be put in binary ascending order, because that's the only way the digest values come out right during renewal and later during verification 💅 Also, the text inside <DigestValue> is base64 encoded, so you MUST base64 decode it first to get the binary version of the hash value 🦋
A hash tree MUST be generated when the Time-Stamped value is not equal to the hash value of the input data object 🌳 That happens when either of these is true:
- When an archive object has more than one data object (aka an archive data object group), its digest value is the digest value of the binary ascending ordered and concatenated digest values of all its containing data objects 🍓 Note that in this case the first list of the hash tree MUST contain hash values of all data objects and only those values.
- When more than one archive object gets a single Time-Stamp Token, the hash tree is a reduced hash tree pulled out of the hash tree for that archive object (see Section 3.2.2) ✨
The hash tree for a set of archive objects is built from the leaves up to the root 🌿 First you collect the leaves, each one representing the digest value of an archive object. You MUST use the following procedure to calculate the hash tree:
- Collect archive objects and, for each archive object, its corresponding data objects 📦
- Pick a secure hash algorithm H and calculate the digest values for the data objects, then put them into the input list for the hash tree. A digest value of an archive object is the digest value of its data object if there is only one data object in the archive object. If there is more than one (an archive data object group), it's the digest value of the binary sorted, concatenated digest values of all its containing data objects 💖
Note that for an archive object group (having more than one data object), lists of their sub-digest values are stored, and later, when you create a reduced hash tree for that archive object, they become members of the first hash list 🧚
- Group together the items in the input list by the order of N (like pairs for a binary tree, triplets for a tertiary tree, and so on). For each group: binary ascending sort, concatenate, and calculate the hash value. The result becomes the new input for the next list. For improved processing it is RECOMMENDED to have the same number of children for each node 🎀 For this purpose you MAY extend the tree with arbitrary values to make every node have the same number of children.
- Repeat step 3 until only one digest value is left. That's the root value of the hash tree, and it's the one that gets Time-Stamped 🏁
Note that the selected secure hash algorithm MUST be the same as the one defined in the <DigestMethod> element of the ATSChain 🔐
Example time 🌟 Here's an input list with 18 hash values. The h'1 is generated for a group of data objects (d4, d5, d6, and d7) and has been grouped by 3. The group could be of any size (2, 3...). Note that the addition of the arbitrary values h''6 and h'''3 are OPTIONAL and can be used for improved processing as outlined in step 3 above.
----------
d1 -> h1 \
\
G1 d2 -> h2 |-> h''1
+--------+ / \
|d4 -> h4|\ d3 -> h3 / \
|d5 -> h5| \ ---------- |
| | | -> h'1\ |
|d6 -> h6| / \ |
|d7 -> h7|/ d8 -> h8 |-> h''2 |-> h'''1
+--------+ / | \
d9 -> h9 / | \
---------- | |
d10 -> h10\ / |
\ / |
d11 -> h11 |-> h''3 |
/ |
d12 -> h12/ |-> root hash value
---------- |
d13 -> h13\ |
\ |
d14 -> h14 |-> h''4 |
/ \ |
d15 -> h15/ \ |
---------- |-> h'''2 |
d16 -> h16\ | |
\ | |
d17 -> h17 |-> h''5 | |
/ | |
d18 -> h18/ | |
---------- / |
/ /
(any arbitrary) h''6 /
(any arbitrary) h'''3
Figure 1. Generation of the Merkle Hash TreeNote that there are no restrictions on the quantity of hash value lists and of their length 📚 Also note that it is beneficial but not required to build hash trees and reduce hash trees. An Archive Time-Stamp may consist only of one list of hash values and a Time-Stamp, or in an extreme case only a Time-Stamp with no hash value lists 🦄
3.2.2. Reduction of Hash Tree 🌲
The generated Merkle hash tree can be shrunk down to lists of hash values, which you need as a proof of existence for a single archive object. Here's how:
- For a selected archive object (AO), select its hash value h within the leaves of the hash tree.
- Put h as the base64 encoded text value of a new <DigestValue> element within a first <Sequence> element. If the selected AO is a data object group (i.e., has more than one data object), the first <Sequence> element MUST in this case be formed from the hash values of all AOs data objects, each within a separate <DigestValue> element.
- Select all hash values that have the same father node as hash value h. Place these hash values each as a base64 encoded text value of a new <DigestValue> element within a new <Sequence> element, increasing its Order attribute value by 1.
- Repeat step 3 for the parent node until the root hash value is reached, creating a new <Sequence> element each step and increasing its Order attribute by one. Note that node values are not saved, as they are computable.
The order of <DigestValue> elements within each <Sequence> element MUST be binary ascending (by base64 decoded values) 🧠
Reduced hash tree for data object d4 (from the previous example, presented in Figure 1):
<HashTree>
<Sequence Order='1'>
<DigestValue>base64 encoded h4</DigestValue>
<DigestValue>base64 encoded h5</DigestValue>
<DigestValue>base64 encoded h6</DigestValue>
<DigestValue>base64 encoded h7</DigestValue>
</Sequence>
<Sequence Order='2'>
<DigestValue>base64 encoded h8</DigestValue>
<DigestValue>base64 encoded h9</DigestValue>
</Sequence>
<Sequence Order='3'>
<DigestValue>base64 encoded h''1</DigestValue>
<DigestValue>base64 encoded h''3</DigestValue>
</Sequence>
<Sequence Order='4'>
<DigestValue>base64 encoded h'''2</DigestValue>
</Sequence>
</HashTree>Reduced hash tree for data object d2 (from the previous example, presented in Figure 1):
<HashTree>
<Sequence Order='1'>
<DigestValue>base64 encoded h2</DigestValue>
</Sequence>
<Sequence Order='2'>
<DigestValue>base64 encoded h1</DigestValue>
<DigestValue>base64 encoded h3</DigestValue>
</Sequence>
<Sequence Order='3'>
<DigestValue>base64 encoded h''2</DigestValue>
<DigestValue>base64 encoded h''3</DigestValue>
</Sequence>
<Sequence Order='4'>
<DigestValue>base64 encoded h'''2</DigestValue>
</Sequence>
</HashTree>3.3. Verification 🔍
The initial Archive Time-Stamp shall prove that an archive object existed at a certain time, indicated by its Time-Stamp Token. The verification procedure MUST be as follows:
- Identify hash algorithm H (from the <DigestMethod> element) and calculate the hash value for each data object of the archive object.
- If the hash tree is present, search for hash values in the first <Sequence> element. If hash values are not present, terminate the verification process with a negative result. If the verifying party also seeks additional proof that the Archive Time-Stamp relates to a data object group (e.g., a document and all its digital signatures), it SHOULD also be verified that only the hash values of the data objects that are members of the given data object group are in the first hash value list 🕵️♀️
- If the hash tree is present, calculate its root hash value. Compare the root hash value with the Time-Stamped value. If they are not equal, terminate the verification process with a negative result.
- If the hash tree is omitted, compare the hash value of the single data object with the Time-Stamped value. If they are not equal, terminate the verification process with a negative result. If an archive object has more data objects and the hash tree is omitted, also exit with a negative result.
- Check the validity of the Time-Stamp Token. If the information needed to verify the formal validity of the Time-Stamp Token is not available, or is not found within the <TimeStampToken> element, the <CryptographicInformationList> element, or the <SupportingInformationList> (see Section 9.4), exit with a negative result.
Information for formal verification of the Time-Stamp Token includes digital certificates, Certificate Revocation Lists, Online Certificate Status Protocol responses, etc. 📜 This information needs to be collected prior to the Time-Stamp renewal process and protected with the succeeding Time-Stamp, i.e., included in the <TimeStampToken> or <CryptographicInformation> element (see Section 9.4 for additional information and Section 4.2.1 for details on the Time-Stamp renewal process). For the current (latest) Time-Stamp), information for formal verification of the (latest) Time-Stamp should be provided by the Time-Stamping Authority. This information can also be provided with the Evidence Record within the <SupportingInformation> element, which is not protected by any Time-Stamp 🌈
4. Archive Time-Stamp Sequence and Archive Time-Stamp Chain ⏳✨
okay bestie, so an Archive Time-Stamp proves that single data objects (or a whole data object group) existed at a certain time 🕰️. but here's the tea 🫢: the very first Evidence Record can go stale, because the Time-Stamp Token can lose its validity for a bunch of reasons. the hash algorithms or public key algorithms in its hash tree or the Time-Stamp might get weak, or the validity period of the Time-Stamp authority certificate expires or gets revoked. yikes 💀
so to keep the Evidence Record valid before any of that happens, you gotta renew it 🫶. you do that by making a new ATS. depending on why you're renewing (the Time-Stamp is invalid, or the hash algorithm of the hash tree is weak), there are two renewal processes:
- Time-Stamp renewal: a new Archive Time-Stamp is generated and applied over the last Time-Stamp created. the process gives a series of Archive Time-Stamps, all living in one single Archive Time-Stamp Chain (ATSC) 🔗
- Hash tree renewal: a new Archive Time-Stamp is generated and applied to all existing Time-Stamps and data objects. the new one goes into a brand new Archive Time-Stamp Chain, so you end up with a series of Archive Time-Stamp Chains, all contained in one single Archive Time-Stamp Sequence (ATSSeq) 👑
after the renewal process, only the most recent (i.e., the last generated) Archive Time-Stamp has to be monitored for expiration or validity loss 👀🎀
4.1. Structure 🧱
Archive Time-Stamp Chain and Archive Time-Stamp Sequence are containers for sequences of Archive Time-Stamp(s) that get generated through renewal processes. the renewal process gives a series of Evidence Record elements: the <ArchiveTimeStampSequence> element contains an ordered sequence of <ArchiveTimeStampChain> elements, and the <ArchiveTimeStampChain> element contains an ordered sequence of <ArchiveTimeStamp> elements. Both elements MUST be sorted by time of the Time-Stamp in ascending order. Order is indicated by the Order attribute 📚
when an Archive Time-Stamp must be renewed, a new <ArchiveTimeStamp> element is generated and, depending on the generation process, it is either placed:
- as the last
<ArchiveTimeStamp>child element in a sequence of the last<ArchiveTimeStampChain>element in case of Time-Stamp renewal, or - as the first
<ArchiveTimeStamp>child element in a sequence of the newly created<ArchiveTimeStampChain>element in case of hash tree renewal.
the ATS with the largest Order attribute value within the ATSC with the largest Order attribute value is the latest ATS and MUST be valid at the present time. ✅
4.1.1. Digest Method 🔐
Digest method is a required element that identifies the digest algorithm used to calculate hash values of archive data (and node values of hash tree). it's specified in the <ArchiveTimeStampChain> element by the required <DigestMethod> element, and it indicates the digest algorithm that MUST be used for all hash value calculations related to the Archive Time-Stamps within the Archive Time-Stamp Chain 💖
The Algorithm attribute contains URIs [RFC3986] for identifiers that MUST be used as defined in [RFC3275] and [RFC4051]. for example, when the SHA-1 algorithm is used, the algorithm identifier is:
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>Within a single ATSC, the digest algorithms used for the hash trees of its Archive Time-Stamps and the Time-Stamp Tokens MUST be the same. when algorithms used by a TSA are changed (e.g., upgraded), a new ATSC MUST be started using an equal or stronger digest algorithm 🔥
4.1.2. Canonicalization Method 🧩
Prior to hash value calculations of an XML element, a proper binary representation must be extracted from its (abstract) XML data presentation. The binary representation is determined by UTF-8 [RFC3629] encoding and canonicalization of the XML element. The XML element includes the entire text of the start and end tags as well as all descendant markup and character data (i.e., the text and sub-elements) between those tags 🌸
<CanonicalizationMethod> is a required element that identifies the canonicalization algorithm used to obtain binary representation of an XML element or elements. Algorithm identifiers (URIs) MUST be used as defined in [RFC3275] and [RFC4051]. for example, when Canonical XML 1.0 (omits comments) is used, the algorithm identifier is:
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-
xml-c14n-20010315"/>Canonicalization MUST be applied over XML structured archive data and MUST be applied over elements of Evidence Record (namely, ATS and ATSC in the renewing process).
The canonicalization method is specified in the <Algorithm> attribute of the <CanonicalizationMethod> element within the <ArchiveTimeStampChain> element, and it indicates the canonicalization method that MUST be used for all binary representations of the Archive Time-Stamps within that Archive Time-Stamp Chain. in case of a succeeding ATSC, the canonicalization method indicated within the ATSC must also be used for the calculation of the digest value of the preceding ATSC. Note that the canonicalization method is unlikely to change over time, as it does not impose the same constraints as the digest method. In theory, the same canonicalization method can be used for a whole Archive Time-Stamp Sequence. Although alternative canonicalization methods may be used, it is recommended to use c14n-20010315 [XMLC14N] 🦋
4.2. Generation ⚙️
Before the cryptographic algorithms used within the most recent Archive Time-Stamp become weak or the Time-Stamp certificates are invalidated, the LTA has to renew the Archive Time-Stamps by generating a new Archive Time-Stamp using one of two procedures: Time-Stamp renewal or hash tree renewal 🔁
4.2.1. Time-Stamp Renewal ⏩
In case of Time-Stamp renewal, i.e., if the digest algorithm (H) to be used in the renewal process is the same as digest algorithm (H') used in the last Archive Time-Stamp, the complete content of the last <TimeStamp> element MUST be Time-Stamped and a new <ArchiveTimeStamp> element is created as follows 🧁
- If the current
<ArchiveTimeStamp>element does not contain needed proof for long-term formal validation of its Time-Stamp Token within the<TimeStamp>element, collect needed data such as root certificates, Certificate Revocation Lists, etc., and include them in the<CryptographicInformationList>element of the last Archive Time-Stamp (each data object into a separate<CryptographicInformation>element). - Select the canonicalization method from the
<CanonicalizationMethod>element and select the digest algorithm from the<DigestMethod>element. Calculate hash value from binary representation of the<TimeStamp>element of the last<ArchiveTimeStamp>element, including added cryptographic information. Acquire the Time-Stamp for the calculated hash value. If the Time-Stamp is valid, the new Archive Time-Stamp may be generated. - Increase the value order of the new ATS by one and place the new ATS into the last
<ArchiveTimeStampChain>element.
The new ATS and its hash tree MUST use the same digest algorithm as the preceding one, which is specified in the <DigestMethod> element within the <ArchiveTimeStampChain> element. Note that the new ATS MAY not contain a hash tree. However, the Time-Stamp renewal process may be optimized to acquire one Time-Stamp for many Archive Time-Stamps using a hash tree. Note that each hash of the <TimeStamp> element is treated as the document hash in Section 3.2.1 ✨
4.2.2. Hash Tree Renewal 🌳
The process of hash tree renewal occurs when the new digest algorithm is different from the one used in the last Archive Time-Stamp (H <> H'). In this case, the complete Archive Time-Stamp Sequence and the archive data objects covered by existing Archive Time-Stamp must be Time-Stamped as follows 🫧
- Select one or more archive objects to be renewed and their current
<ArchiveTimeStamp>elements. - For each archive object, check the current
<ArchiveTimeStamp>element. If it does not contain the proof needed for long-term formal validation of its Time-Stamp Token within the Time-Stamp Token, collect the needed data such as root certificates, Certificate Revocation Lists, etc., and include them in the<CryptographicInformationList>element of the last Archive Time-Stamp (each data object into a separate<CryptographicInformation>element). - Select a canonicalization method C and select a new secure hash algorithm H.
- For each archive object, select its data objects d(i). Generate hash values h(i) = H(d(i)), for example: h(1), h(2).., h(n).
- For each archive object, calculate a hash hseq=H(ATSSeq) from binary representation of the
<ArchiveTimeStampSequence>element, corresponding to that archive object. Note that Archive Time-Stamp Chains and Archive Time-Stamps MUST be chronologically ordered, each respectively to its Order attribute, and that the canonicalization method C MUST be applied. - For each archive object, sort in binary ascending order and concatenate all h(i) and the hseq. Generate a new digest value h(j)=H(h(1)..h(n),hseq).
- Build a new Archive Time-Stamp for each h(j) (hash tree generation and reduction is defined in Sections 3.2.1 and 3.2.2). Note that each h(j) is treated as the document hash in Section 3.2.1. The first hash value list in the reduced hash tree should only contain h(i) and hseq.
- Create the new
<ArchiveTimeStampChain>containing the new<ArchiveTimeStamp>element (with order number 1), and place it into the existing<ArchiveTimeStampSequence>as a last child, with the order number increased by one.
Example for an archive object with 3 data objects: Select a new hash algorithm and canonicalization method. Collect all 3 data objects and the currently generated Archive Time-Stamp Sequence 🍓
AO
/ | \
d1 d2 d3
ATSSeq
ATSChain1: ATS0, ATS1
ATSChain2: ATS0, ATS1, ATS2The hash values MUST be calculated with the new hash algorithm H for all data objects and for the whole ATSSeq. Note that ATSSeq MUST be chronologically ordered and canonicalized before retrieving its binary representation 💅
When generating the hash tree for the new ATS, the first sequence become values: H(d1), H(d2),..., H(dn), H(ATSSeq). Note: hash values MUST be sorted in binary ascending order 🧚
<HashTree>
<Sequence Order='1'>
<DigestValue>H(d1)</DigestValue>
<DigestValue>H(d2)</DigestValue>
<DigestValue>H(d3)</DigestValue>
<DigestValue>H(ATSSeq)</DigestValue>
</Sequence>
</HashTree>Note that if the group processing is being performed, the hash value of the concatenation of the first sequence is an input hash value into the hash tree 🌈
4.3. Verification 🔎
Okay bestie, so an Evidence Record shall prove that an archive object existed and has not been changed from the time of the initial Time-Stamp Token within the first ATS 🦋 To finish the non-repudiation proof for an archive object, the last ATS has to be valid, and the ATSCs and how they relate to each other also have to be proved ✨
- Select the archive object and re-encrypt its data object or data object group, if the
<EncryptionInformation>field is used 🔐 Select the initial digest algorithm specified within the first Archive Time-Stamp Chain and calculate the hash value of the archive object. Verify that the initial Archive Time-Stamp contains the (identical) hash value of the AO's data object (or the hash values of the AO's data object group) 💖 Note that when the hash tree is omitted, the calculated AO's value MUST match the Time-Stamped value 🫶 - Verify each Archive Time-Stamp Chain and each Archive Time-Stamp within it 💅 If the hash tree is present within the second and the next Archive Time-Stamps of an Archive Time-Stamp Chain, the first
<Sequence>MUST contain the hash value of the<TimeStamp>element before it 🌸 Each Archive Time-Stamp MUST be valid relative to the time of the succeeding Archive Time-Stamp ⏰ All Archive Time-Stamps within the Archive Time-Stamp Chain MUST use the same hash algorithm, which was secure at the time of the first Archive Time-Stamp of the succeeding Archive Time-Stamp Chain 🔥 - Verify that the first hash value list of the first Archive Time-Stamp of all succeeding Archive Time-Stamp Chains contains hash values of the data object and the hash value of the Archive Time-Stamp Sequence of the preceding Archive Time-Stamp Chains 🧚 Verify that the Archive Time-Stamp was created when the last Archive Time-Stamp of the preceding Archive Time-Stamp Chain was valid 🦋
- To prove the Archive Time-Stamp Sequence relates to a data object group, verify that the first Archive Time-Stamp of the first Archive Time-Stamp Chain does not contain other hash values in its first hash value list than the hash values of those data objects 🍓
For the non-repudiation proof for the data object, the last Archive Time-Stamp MUST be valid at the time of the verification process 👑
5. Encryption 🔒
In some archive service scenarios it may be required that clients send encrypted data only, preventing information disclosure to third parties, such as archive service providers 🙈 In such scenarios it must be clear that the Evidence Records generated refer to encrypted data objects 💜 Evidence Records in general protect the bit-stream (or binary representation of XML data), which freezes the bit structure at the time of archiving. Encryption schemes in such scenarios cannot be changed afterwards without losing the integrity proof 😭 Therefore, an ERS record must hold and preserve encryption information in a consistent manner ✨ To avoid problems when using Evidence Records in the future, additional special precautions have to be taken 💅
Encryption is a two-way process, whose result depends on the cryptographic material used, e.g., encryption keys and encryption algorithms 🌈 Encryption and decryption keys as well as algorithms must match in order to reconstruct the original message or data that was encrypted. Evidence generated to prove the existence of encrypted data cannot always be relied upon to prove the existence of unencrypted data 💀 It may be possible to choose different cryptographic material, i.e., an algorithm or a key for decryption that is not the algorithm or key used for encryption. In this case, the evidence record would not be a non-repudiation proof for the unencrypted data 🙈 Therefore, only encryption methods should be used that make it possible to prove that archive Time-Stamped encrypted data objects unambiguously represent unencrypted data objects 🎀 In cases when evidence was generated to prove the existence of encrypted data, the corresponding algorithm and decryption keys used for encryption must become a part of the Evidence Record, and they are used to unambiguously represent the original (unencrypted) data that was encrypted 🔑 (Note: In addition, the long-term security of the encryption schemes should be analyzed to determine if it could be used to create collision attacks.) 🔍
Cryptographic material may also be used in scenarios when a client submits encrypted data to the archive service provider for preservation but stores the data themselves only in an unencrypted form 🫧 In such scenarios, cryptographic material is used to re-encrypt the unencrypted data kept by a client for the purpose of performing validation of the Evidence Record, which is related to the encrypted form of the client's data 🦋
An OPTIONAL extensible structure <EncryptionInformation> is defined to store the necessary parameters of the encryption methods 🧁 Its <EncryptionInformationType> element is used to store the type of stored encryption information, e.g., whether it is an encryption algorithm or an encryption key 🍓 The <EncryptionInformationValue> element then contains the relevant encryption information itself 💖 The use of encryption elements heavily depends on the cryptographic mechanism and has to be defined by other specifications 📜
6. Version 🏷️
The numbering scheme for XMLERS versions is "<major>.<minor>". The major and minor numbers MUST be treated as separate integers, and each number MAY be incremented higher than a single digit 🔢 Thus, "2.4" would be a lower version than "2.13", which in turn would be lower than "12.3" 📈 Leading zeros (e.g., "6.01") MUST be ignored by recipients and MUST NOT be sent 🙅♀️
The major version number will be incremented only if the data format has changed so dramatically that an older version entity would not be able to interoperate with a newer version entity if it simply ignored the elements and attributes it did not understand and took the actions defined in the older specification 💥
The minor version number will be incremented if significant new capabilities have been added to the core format (e.g., new optional elements) ✨
7. Storage of Policies 📦
As explained above, policies can be stored in the Evidence Record in the <Attribute> or the <SupportingInformation> element 🎀 In the case of storing DSSC policies [RFC5698], the types to be used in the <Attribute> or <SupportingInformation> element are defined in Appendix A.2 of [RFC5698] for both ASN.1 and XML representation 🦋
8. XSD Schema for the Evidence Record ✨
Okay bestie, here's the XML Schema (XSD) that defines the Evidence Record structure 🎀 It's giving very precise, so read it like a blueprint 💅
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:ers"
targetNamespace="urn:ietf:params:xml:ns:ers"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="EvidenceRecord" type="EvidenceRecordType"/>
<!-- TYPE DEFINITIONS-->
<xs:complexType name="EvidenceRecordType">
<xs:sequence>
<xs:element name="EncryptionInformation"
type="EncryptionInfo" minOccurs="0"/>
<xs:element name="SupportingInformationList"
type="SupportingInformationType" minOccurs="0"/>
<xs:element name="ArchiveTimeStampSequence"
type="ArchiveTimeStampSequenceType"/>
</xs:sequence>
<xs:attribute name="Version" type="xs:decimal" use="required"
fixed="1.0"/>
</xs:complexType>
<xs:complexType name="EncryptionInfo">
<xs:sequence>
<xs:element name="EncryptionInformationType"
type="ObjectIdentifier"/>
<xs:element name="EncryptionInformationValue">
<xs:complexType mixed="true">
<xs:sequence>
<xs:any minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArchiveTimeStampSequenceType">
<xs:sequence>
<xs:element name="ArchiveTimeStampChain" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="DigestMethod"
type="DigestMethodType"/>
<xs:element name="CanonicalizationMethod"
type="CanonicalizationMethodType"/>
<xs:element name="ArchiveTimeStamp"
type="ArchiveTimeStampType"
maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArchiveTimeStampType">
<xs:sequence>
<xs:element name="HashTree" type="HashTreeType" minOccurs="0"/>
<xs:element name="TimeStamp" type="TimeStampType"/>
<xs:element name="Attributes" type="Attributes" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType" use="required"/>
</xs:complexType>
<xs:complexType name="DigestMethodType" mixed="true">
<xs:sequence>
<xs:any namespace="##other" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="CanonicalizationMethodType" mixed="true">
<xs:sequence minOccurs="0">
<xs:any namespace="##any" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="TimeStampType">
<xs:sequence>
<xs:element name="TimeStampToken">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="CryptographicInformationList"
type="CryptographicInformationType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="HashTreeType">
<xs:sequence>
<xs:element name="Sequence" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="DigestValue" type="xs:base64Binary"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Attributes">
<xs:sequence>
<xs:element name="Attribute" maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
<xs:attribute name="Type" type="xs:string"
use="optional"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="CryptographicInformationType">
<xs:sequence>
<xs:element name="CryptographicInformation"
maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="SupportingInformationType">
<xs:sequence>
<xs:element name="SupportingInformation"
maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Type" type="xs:string"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="ObjectIdentifier">
<xs:restriction base="xs:token">
<xs:pattern value="[0-2](\.[1-3]?[0-9]?(\.\d+)*)?"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="OrderType">
<xs:restriction base="xs:int">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>9. Security Considerations 🔥
This part is serious, so grab your iced matcha and let's go 🧋
9.1. Secure Algorithms 🔐
Okay so the cryptographic algorithms and parameters used inside Archive Time-Stamps must always be secure at the time they're generated, no cap 💀 That covers the hash algorithm used in the hash lists of the Archive Time-Stamp, and also the hash and public key algorithms of the Time-Stamps. Publications about whether cryptographic algorithms are still secure, namely [NIST.800-57-Part1.2006] and [ETSI-TS-102-176-1-V2.0.0], have to be checked during verification. And ngl, a generic way to automatically read security suitability policies in electronic form is not what this specification is about 🙈
9.2. Redundancy 🦋
Evidence Records can get affected by weakening cryptographic algorithms even before anyone publicly knows about it 😭 Looking back, that impacts the Archive Time-Stamps generated and renewed during the archival period. When that happens, the validity of Evidence Records that were already created may end, and there's no way to take retroactive action 💔
Here's the tea: lots of TSAs use the same cryptographic algorithms. If a TSA's private key gets compromised, only that one TSA is affected (and maybe only one Archive Time-Stamp, for example). But if the algorithms used to generate Time-Stamp Tokens get weakened, that hits many TSAs at the same time 💀
So to manage these risks and avoid losing Evidence Record validity because of weakening algorithms, it is RECOMMENDED to generate and manage at least two redundant Evidence Records for a single data object 🫶 In those setups, redundant Evidence Records SHOULD use different hash algorithms within the Archive Time-Stamp Sequences, and different TSAs using different cryptographic algorithms for their Time-Stamp Tokens. Main character energy for real 👑
9.3. Secure Time-Stamps ⏰
Archive Time-Stamps depend on the security of the normal Time-Stamping that the TSA provides and that's stated in security policies 🧚 So when they're renewed, the renewed Archive Time-Stamps MUST have the same or higher quality as the initial Archive Time-Stamp of the archive data. And for signed archive data, the Archive Time-Stamps SHOULD have the same or higher quality than the maximum quality of the signatures. Periodt 💅
9.4. Time-Stamp Verification 🕵️♀️
This one is super important for renewal and verification 😭 When a new Time-Stamp gets applied, it MUST be ascertained that, before the time of renewal (that is, when the new Time-Stamp is applied), the certificate of the Time-Stamp that was current before wasn't revoked because of a key compromise. Otherwise, if there was a key compromise, the authenticity of the Time-Stamp that was used, and therefore its security in the chain of evidence, can't be guaranteed. Other revocation reasons, like revocation because of cessation of activity, don't necessarily carry this risk, because in that case the private key of the Time-Stamp unit would already have been destroyed, so it can't be used or compromised 🌸
Both the <CryptographicInformationList> and <Attribute> elements are protected by future Archive Time-Stamp renewals. They can store information, as outlined in Section 2.1, that's available at or before the time of renewal of that specific Archive Time-Stamp. At renewal, all previous Archive Time-Stamp data structures become protected by the new Archive Time-Stamp and get frozen by it, which means no data MUST be added or modified in these elements afterwards 🧊
If some supporting information matters for the whole Evidence Record, or it's information that only becomes available later, it can go in the <SupportingInformationList> element instead 🍓 Data can be added to the <SupportingInformatonList> later on, but it has to rely on its own authenticity and integrity protection mechanism. For example, it could be signed with current strong cryptographic means and/or provided by a trusted source (say, the LTA providing its current system DSSC policy, signed with current strong cryptographic means) 🫶 Iykyk, and now you do too 🎀
10. IANA Considerations ✨
Okay bestie, for every IANA registration tied to this doc, the "Specification Required" [RFC5226] allocation policy MUST be used. 🎀
This doc defines the XML namespace urn:ietf:params:xml:ns:ers following the guidelines in [RFC3688]. It's already registered in the IANA XML Registry 💅
It also defines an XML schema (see Section 8) following the guidelines in [RFC3688]. That schema is registered in the IANA XML Registry too, and you can identify it with the URN urn:ietf:params:xml:schema:ers 🦋
This spec creates a brand new IANA registry called "XML Evidence Record Syntax (XMLERS)" 🌈 It has two sub-registries, "Time-Stamp Token Type" and "Cryptographic Information Type". The policy for future assignments to both sub-registries is "RFC Required" ✨
The "Time-Stamp Token Type" sub-registry holds textual names and descriptions, and each description should point to the spec or standard that defines that type. It's a big help when you're validating a Time-Stamp Token 🧚
When you register a new Time-Stamp Token type, the following information MUST be provided:
- The textual name of the Time-Stamp Token type (value). The value MUST conform to the XML datatype "xs:NMTOKEN".
- A reference to a publicly available specification that defines the Time-Stamp Token type (description).
The initial values for the "Time-Stamp Token Type" sub-registry are:
Value
Description
Reference
-------------
RFC3161
RFC3161 Time-Stamp
RFC 3161
XMLENTRUST
EnTrust XML Schema
http://www.si-tsa.gov.si/dokumenti/timestamp-protocol-20020207.xsdThe "Cryptographic Information Type" sub-registry holds textual names and descriptions too, and each description should refer to a specification or standard that defines that type. It helps when validating cryptographic information like digital certificates, CRLs, or OCSP-Responses 🔥
When you register a new cryptographic information type, the following information MUST be provided:
- The textual name of the cryptographic information type (value). The value MUST conform to the XML datatype "xs:NMTOKEN".
- A reference to a publicly available specification that defines the cryptographic information type (description).
The initial values for the "Cryptographic Information Type" sub-registry are:
Value Description Reference
----- ------------------ -----------------
CERT DER-encoded X.509 Certificate RFC 5280
CRL DER-encoded X.509 RFC 5280
Certificate Revocation List
OCSP DER-encoded OCSPResponse RFC 2560
SCVP DER-encoded SCVP response RFC 5055
(CVResponse)11. References
11.1. Normative References
Here's the normative crew 👑
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June
1999.
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible
Markup Language) XML-Signature Syntax and Processing",
RFC 3275, March 2002.
[RFC4051] Eastlake 3rd, D., "Additional XML Security Uniform
Resource Identifiers (URIs)", RFC 4051, April 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
Record Syntax (ERS)", RFC 4998, August 2007.
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and
W. Polk, "Server-Based Certificate Validation Protocol
(SCVP)", RFC 5055, December 2007.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[XMLC14N] Boyer, J., "Canonical XML", W3C Recommendation, March
2001.
[XMLDSig] Eastlake, D., Reagle, J., Solo, D., Hirsch, F.,
Roessler, T., "XML-Signature Syntax and Processing",
XMLDSig, W3C Recommendation, July 2006.
[XMLName] Layman, A., Hollander, D., Tobin, R., and T. Bray,
"Namespaces in XML 1.0 (Second Edition)", W3C
Recommendation, August 2006.
[XMLSchema] Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney,
"XML Schema Part 1: Structures Second Edition", W3C
Recommendation, October 2004.11.2. Informative References
And now the informative ones 🧚💖
[ANSI.X9-95.2005]
American National Standard for Financial Services,
"Trusted Timestamp Management and Security", ANSI X9.95,
June 2005.
[ETSI-TS-102-176-1-V2.0.0]
ETSI, "Electronic Signatures and Infrastructures (ESI);
Algorithms and Parameters for Secure Electronic
Signatures; Part 1: Hash functions and asymmetric
algorithms", ETSI TS 102 176-1 V2.0.0 (2007-11),
November 2007.
[ISO-18014-1.2002]
ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1:
Framework", ISO ISO-18014-1, February 2002.
[ISO-18014-2.2002]
ISO/IEC JTC 1/SC 27, "Time stamping services - Part 2:
Mechanisms producing independent tokens", ISO
ISO-18014-2, December 2002.
[ISO-18014-3.2004]
ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3:
Mechanisms producing linked tokens", ISO ISO-18014-3,
February 2004.
[MER1980] Merkle, R., "Protocols for Public Key Cryptosystems,
Proceedings of the 1980 IEEE Symposium on Security and
Privacy (Oakland, CA, USA)", pages 122-134, April 1980.
[NIST.800-57-Part1.2006]
National Institute of Standards and Technology,
"Recommendation for Key Management - Part 1: General
(Revised)", NIST 800-57 Part1, May 2006.
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines
for the Use of Extensible Markup Language (XML) within
IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term
Archive Service Requirements", RFC 4810, March 2007.
[RFC5126] Pinkas, D., Pope, N., and J. Ross, "CMS Advanced
Electronic Signatures (CAdES)", RFC 5126, March 2008.
[TS-ENTRUST] The Slovenian Time Stamping Authority, Entrust XML
Schema for Time-Stamp, http://www.si-tsa.gov.si/
dokumenti/timestamp-protocol-20020207.xsd.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[XAdES] Cruellas, J. C., Karlinger, G., Pinkas, D., Ross, J.,
"XML Advanced Electronic Signatures", XAdES, W3C Note,
February 2003.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD
70, RFC 5652, September 2009.
[RFC5698] Kunz, T., Okunick, S., and U. Pordesch, "Data Structure
for the Security Suitability of Cryptographic Algorithms
(DSSC)", RFC 5698, November 2009.Appendix A. Detailed Verification Process of an Evidence Record 🎀
okay bestie, this is the step-by-step for checking that an Evidence Record is valid 🔍💖
To verify an Evidence Record, start with the first ATS and go all the way to the last one (ordered by the Order attribute). Verify each ATS like this:
- Grab the matching archive object and its data object, or the group of data objects it covers. 📦
- If the
<EncryptionInformation>field is used, re-encrypt the data object or data object group. (Check Section 5 for the deets! 🔐) - Pull a canonicalization method C and a digest method H out of the
<DigestMethod>element of the current chain. 🧩 - Build a fresh list L of digest values. It holds the (binary representation of) objects (data, ATS, or sequence) that MUST be protected by this ATS. Here's how it goes 💅:
- a. If this ATS is the first one in the Archive Time-Stamp Chain:
- i. If it's the first ATS of the first ATSC (the initial ATS) in the ATSSeq, calculate digest values of the data objects with H and add each digest value to the list L. ✨
- ii. If it's not the initial ATS, calculate a digest value with H of the ordered ATSSeq without this and successive chains. Add the value H and the digest values of the data objects to the list L. 🌸
- b. If this ATS is not the first in the ATSC:
- i. Calculate the digest value with H of the previous
<TimeSatmp>element and add this digest value to the list L. 🦋
- i. Calculate the digest value with H of the previous
- a. If this ATS is the first one in the Archive Time-Stamp Chain:
- Verify the ATS's Time-Stamped value. Grab the first sequence of the hash tree for this ATS. 🌳
- a. If this ATS has no hash tree elements, then:
- ii. If this ATS is not the first in the ATSSeq (the initial ATS), the Time-Stamped value must be equal to the digest value of the previous Time-Stamp element. If not, exit with a negative result. 🙈
- iii. If this ATS is the initial ATS in the ATSC, there must be only one data object of the archive object. The digest value of that data object must be the same as its Time-Stamped value. If not, exit with a negative result. 🍓
- b. If this ATS has a hash tree, then: if there is a digest value in the list L of digest values of protected objects that cannot be found in the first sequence of the hash tree, or if there is a hash value in the first sequence of the hash tree that is not in the list L of digest values of protected objects, exit with a negative result. 😭
- i. Get the hash tree from the current ATS and use H to calculate the root hash value (see Sections 3.2.1 and 3.2.2). 🧮
- ii. Get the Time-Stamped value from the Time-Stamp Token. If the calculated root hash value from the hash tree does not match the Time-Stamped value, exit with a negative result. 🚫
- a. If this ATS has no hash tree elements, then:
- Verify the Time-Stamp cryptographically and formally. Validate the certificate that was used and its chain. That info might live inside the Time-Stamp Token itself or in the
<CryptographicInformation>element. 🔏 - If this ATS is the last ATS, check formal validity for the current time (now). Or get the "valid from" time of the next ATS and verify formal validity at that specific time. ⏰
- If the info needed to verify formal validity is not found within the Time-Stamp or within its Cryptographic Information section of the ATS, exit with a negative result. 💀
Authors' Addresses 💌
Aleksej Jerman Blazic
SETCCE
Tehnoloski park 21
1000 Ljubljana
Slovenia
Phone: +386 (0) 1 620 4500
Fax: +386 (0) 1 620 4509
EMail: aljosa@setcce.si
Svetlana Saljic
SETCCE
Tehnoloski park 21
1000 Ljubljana
Slovenia
Phone: +386 (0) 1 620 4506
Fax: +386 (0) 1 620 4509
EMail: svetlana.saljic@setcce.si
Tobias Gondrom
Kruegerstr. 5A
85716 Unterschleissheim
Germany
Phone: +49 (0) 89 320 5330
EMail: tobias.gondrom@gondrom.org📦 where this page comes from
- ietf: rfc6283 2011-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms