summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6283.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6283.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6283.txt')
-rw-r--r--doc/rfc/rfc6283.txt2411
1 files changed, 2411 insertions, 0 deletions
diff --git a/doc/rfc/rfc6283.txt b/doc/rfc/rfc6283.txt
new file mode 100644
index 0000000..082e0f1
--- /dev/null
+++ b/doc/rfc/rfc6283.txt
@@ -0,0 +1,2411 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Jerman Blazic
+Request for Comments: 6283 S. Saljic
+Category: Standards Track SETCCE
+ISSN: 2070-1721 T. Gondrom
+ July 2011
+
+ Extensible Markup Language Evidence Record Syntax (XMLERS)
+
+Abstract
+
+ In many scenarios, users must be able to demonstrate the (time of)
+ existence, integrity, and validity of data including signed data for
+ long or undetermined periods of time. This document specifies XML
+ syntax and processing rules for creating evidence for long-term non-
+ repudiation of existence and integrity of data. The Extensible
+ Markup Language Evidence Record Syntax XMLERS provides alternative
+ syntax and processing rules to the ASN.1 (Abstract Syntax Notation
+ One) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ 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) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Blazic, et al. Standards Track [Page 1]
+
+RFC 6283 XMLERS July 2011
+
+
+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 ...41
+
+
+
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 2]
+
+RFC 6283 XMLERS July 2011
+
+
+1. Introduction
+
+ The purpose of the document is to define XML schema and processing
+ rules for Evidence Record Syntax in XML (Extensible Markup Language)
+ format. The document is related to initial ASN.1 (Abstract Syntax
+ Notation One) syntax for Evidence Record Syntax as defined in
+ [RFC4998].
+
+1.1. Motivation
+
+ The evolution of electronic commerce and electronic data exchange in
+ general requires introduction of non-repudiable proof of data
+ existence as well as data integrity and authenticity. Such data and
+ non-repudiable proof of existence must endure for long periods of
+ time, even when the initial information to prove its existence and
+ integrity weakens or ceases to exist. Mechanisms such as digital
+ signatures defined in [RFC5652], for example, do not provide absolute
+ reliability on a long-term basis. Algorithms and cryptographic
+ material used to create a signature can become weak in the course of
+ time, and information needed to validate digital signatures may
+ become compromised or simply cease to exist, for example, due to the
+ disbanding of a certificate service provider. Providing a stable
+ environment for electronic data on a long-term basis requires the
+ introduction of additional means to continually provide an
+ appropriate level of trust in evidence on data existence, integrity,
+ and authenticity.
+
+ All integrity and authenticity protecting techniques used today
+ suffer from the problem of degrading reliability over time, including
+ techniques for Time-Stamping, which are generally recognized as data
+ existence and integrity proof mechanisms. Over long periods of time
+ cryptographic algorithms used may become weak or encryption keys
+ compromised. Some of the problems might not even be of technical
+ nature like a Time-Stamping Authority going out of business and
+ ceasing its service. To create a stable environment where proof of
+ existence and integrity can endure well into the future a new
+ technical approach must be used.
+
+ Long-term non-repudiation of data existence and demonstration of data
+ integrity techniques have been already introduced, for example, by
+ long-term signature syntaxes like those defined in [RFC5126]. Long-
+ term signature syntaxes and processing rules address only the long-
+ term endurance of the digital signatures themselves, while Evidence
+ Record Syntax broadens this approach for data of any type or format
+ including digital signatures.
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 3]
+
+RFC 6283 XMLERS July 2011
+
+
+ XMLERS (Extensible Markup Language Evidence Record Syntax) is based
+ on Evidence Record Syntax as defined in [RFC4998] and is addressing
+ the same problem of long-term non-repudiable proof of data existence
+ and demonstration of data integrity on a long-term basis. XMLERS
+ does not supplement the [RFC4998] specification. Following
+ extensible markup language standards and [RFC3470] guidelines it
+ introduces the same approach but in a different format and with
+ adapted processing rules.
+
+ The use of Extensible Markup Language (XML) format is already
+ recognized by a wide range of applications and services and is being
+ selected as the de facto standard for many applications based on data
+ exchange. The introduction of Evidence Record Syntax in XML format
+ broadens the horizon of XML use and presents a harmonized syntax with
+ a growing community of XML-based standards including those related to
+ security services such as [XMLDSig] or [XAdES].
+
+ Due to the differences in XML processing rules and other
+ characteristics of XML, XMLERS does not present a direct
+ transformation of ERS in ASN.1 syntax. XMLERS is based on different
+ processing rules as defined in [RFC4998] and it does not support, for
+ example, the import of ASN.1 values in XML tags. Creating Evidence
+ Records in XML syntax must follow the steps as defined in this
+ document. XMLERS is a standalone document and is based on [RFC4998]
+ conceptually only. The content of this document provides enough
+ information for implementation of Evidence Record Syntax (represented
+ in XML format). References to [RFC4998] are for informative purposes
+ only.
+
+ Evidence Record Syntax in XML format is based on long-term archive
+ service requirements as defined in [RFC4810]. XMLERS delivers the
+ same (level of) non-repudiable proof of data existence as ASN.1 ERS
+ [RFC4998]. The XML syntax supports archive data grouping (and de-
+ grouping) together 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
+
+ XMLERS specifies the XML syntax and processing rules for creating
+ evidence for the long-term non-repudiation of existence and integrity
+ of data in a unit called the "Evidence Record". XMLERS is defined to
+ meet the requirements for data structures as set out in [RFC4810].
+ This document also refers to the ASN.1 ERS specification as defined
+ in [RFC4998].
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 4]
+
+RFC 6283 XMLERS July 2011
+
+
+ An Evidence Record may be generated and maintained for a single data
+ object or a group of data objects that form an archive object. A
+ data object (binary chunk or a file) may represent any kind of
+ document or part of it. Dependencies among data objects, their
+ validation, or any other relationship than "a data object is a part
+ of particular archived object" are outside the scope of this
+ document.
+
+ Evidence Record is closely related to Time-Stamping techniques.
+ However, Time-Stamps as defined in [RFC3161] can cover only a single
+ unit of data and do not provide processing rules for maintaining a
+ long-term stability of Time-Stamps applied over a data object.
+ Evidence for an archive object is created by acquiring a Time-Stamp
+ from a trustworthy authority for a specific value that is
+ unambiguously related to a single or more data objects. Relationship
+ between several data objects and a single Time-Stamped value is
+ addressed using a hash tree, a technique first described by Merkle
+ [MER1980] and later in [RFC4998], with data structures and procedures
+ as specified in this document. The Evidence Record Syntax enables
+ processing of several archive objects within a single processing pass
+ using a hash tree technique and acquiring only one Time-Stamp to
+ protect all archive objects. The leaves of the hash tree are hash
+ values of the data objects in a group. A Time-Stamp is requested
+ only for the root hash of the hash tree. The deletion of a data
+ object in the tree does not influence the provability of others. For
+ any particular data object, the hash tree can be reduced to a few
+ sets of hash values, which are sufficient to prove the existence of a
+ single data object. Similarly, the hash tree can be reduced to prove
+ existence of a data group, provided all members of the data group
+ have the same parent node in the hash tree. Archive Time-Stamps are
+ comprised of an optional reduced hash tree and a Time-Stamp.
+
+ Besides a Time-Stamp other artifacts are also preserved in Evidence
+ Record: data necessary 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).
+
+ Because digest algorithms or cryptographic methods used may become
+ weak or certificates used within a Time-Stamp (and signed data) may
+ be revoked or expire, the collected evidence data must be monitored
+ and renewed before such events occur. This document introduces XML-
+ based syntax and processing rules for the creation and continuous
+ renewal of evidence data.
+
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 5]
+
+RFC 6283 XMLERS July 2011
+
+
+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; e.g., 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 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 they may
+ have 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: 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
+
+
+
+
+
+Blazic, et al. Standards Track [Page 6]
+
+RFC 6283 XMLERS July 2011
+
+
+ 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 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
+ 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 to be used to prove the
+ existence of an archive object (a single archive data object or a
+ 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 is possible to store the
+ Evidence Record separately from the archive object or to integrate it
+ into the data itself.
+
+
+
+Blazic, et al. Standards Track [Page 7]
+
+RFC 6283 XMLERS July 2011
+
+
+ As cryptographic means are used to support Evidence Records, such
+ records may lose their value over time. Time-Stamps obtained from
+ Time-Stamping Authorities may become invalid for a number of reasons,
+ usually due to time constraints of 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, which
+ are linked between themselves according to the cryptographic methods
+ and algorithms used.
+
+ Evidence Records can be supported with additional information, which
+ can be used to ease the processes of Evidence Record validation and
+ renewal. 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
+
+ The Evidence Record contains one or several Archive Time-Stamps
+ (ATSs). An ATS contains a Time-Stamp Token and optionally other
+ useful data for Time-Stamp validation, e.g., certificates, CRLs
+ (Certificate Revocation Lists), or OCSP (Online Certificate Status
+ Protocol) responses and also specific attributes such as service
+ policies.
+
+ Initially, an ATS is acquired and later, before it expires or becomes
+ invalid, a new ATS is acquired, which prolongs the validity of the
+ archived object (its data objects together with all previously
+ generated Archive Time-Stamps). This process MUST continue during
+ the desired archiving period of the archive data object(s). A series
+ of successive Archive Time-Stamps is collected in Archive Time-Stamp
+ Chains and a series of chains in Archive Time-Stamp Sequence.
+
+ In XML syntax the Evidence Record is represented by the
+ <EvidenceRecord> root element, which has the following structure
+ described in Pseudo-XML with the full XML schema defined in Section 8
+ (where "?" denotes zero or one occurrences, "+" denotes one or more
+ occurrences, and "*" denotes zero or more occurrences):
+
+
+
+
+
+
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 8]
+
+RFC 6283 XMLERS July 2011
+
+
+ <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 following XML
+ namespace [XMLName] urn:ietf:params:xml:ns:ers as default namespace
+ with a detailed xml schema header listed in Section 8.
+
+ The XML elements and attributes have the following meanings:
+
+ The "Version" attribute MUST be included and indicates the syntax
+ version, for compatibility with future revisions of this
+ specification and to distinguish it from earlier non-conformant or
+ proprietary versions of XMLERS. Current version of XMLERS is 1.0.
+ The used versioning scheme is described in detail in Section 6.
+ <EncryptionInformation> element is OPTIONAL and holds information
+ on cryptographic algorithms and cryptographic material used to
+ encrypt archive data (in case archive data is encrypted, e.g., for
+ privacy purposes). This optional information is needed to
+ unambiguously re-encrypt data objects when processing Evidence
+ Records. When omitted, data objects are not encrypted or
+
+
+
+
+Blazic, et al. Standards Track [Page 9]
+
+RFC 6283 XMLERS July 2011
+
+
+ non-repudiation proof is not needed for the unencrypted data.
+ Details on how to process encrypted archive data and generate
+ Evidence Record(s) are described in Section 5.
+
+ <SupportingInformationList> element is OPTIONAL and can hold
+ information to support processing of Evidence Records. An example
+ of this supporting information may be a processing policy, like a
+ cryptographic policy (e.g., [RFC5698]) or archiving policies,
+ which can provide input about preservation and evidence
+ validation. Each data object is put into a separate child element
+ <SupportingInformation>, with an OPTIONAL Type attribute to
+ indicate its type for processing directions. As outlined, 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 the
+ SupportingInformation element, 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) as this
+ is integrity protected by the Archive Time-Stamps. Supporting
+ information that is relevant for the whole Evidence Record (like
+ the LTA's current Cryptographic Algorithms Security Suitability
+ policy (DSSC, [RFC5698]) or that was not available at the time of
+ renewal (and therefore could not later be stored in the protected
+ <Attributes> element) can be stored in this
+ <SupportingInformation> element.
+
+ <ArchiveTimeStampSequence> is REQUIRED and contains a sequence of
+ one or more <ArchiveTimeStampChain>.
+
+ <ArchiveTimeStampChain> is a REQUIRED element that holds a
+ sequence of Archive Time-Stamps generated during the preservation
+ period. Details on Archive Time-Stamp Chains and Archive Time-
+ Stamp Sequences are described in Section 4. The sequences of
+ Archive Time-Stamp Chains and Archive Time-Stamps MUST be ordered
+ and the order MUST be indicated with "Order" attribute of the
+ <ArchiveTimeStampChain> and <ArchiveTimeStamp> elements.
+
+ <DigestMethod> is a REQUIRED element and contains an attribute
+ "Algorithm" that identifies the digest algorithm used within one
+ Archive Time-Stamp Chain to calculate digest values from the
+ archive data object(s), previous Archive Time-Stamp Sequence,
+ Time-Stamps, and within a Time-Stamp Token.
+
+
+
+Blazic, et al. Standards Track [Page 10]
+
+RFC 6283 XMLERS July 2011
+
+
+ <CanonicalizationMethod> is a REQUIRED element that specifies
+ which canonicalization algorithm is applied to the archive data
+ for XML data objects or <ArchiveTimeStampSequence> or <TimeStamp>
+ elements prior to performing digest value calculations.
+
+ <HashTree> is an OPTIONAL element that holds a structure as
+ described in Section 3.1.1.
+
+ <TimeStamp> 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 and an OPTIONAL element
+ <CryptographicInformationList>.
+
+ <CryptographicInformationList> is an OPTIONAL element that allows
+ the storage of data needed in the process of Time-Stamp Token
+ validation in case when such data is not 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 is put into a separate 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.
+
+ <Attributes> element is OPTIONAL and contains additional
+ information that may be provided by an LTA used to support
+ processing of Evidence Records. An example of this supporting
+ information may be a processing policy, like a renewal, a
+ cryptographic (e.g., [RFC5698]), or an archiving policy. Such
+ policies can provide inputs, which are relevant for preservation
+ of the data object(s) and evidence validation at a later stage.
+ Each data object is put into a separate 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 when one or more XML
+ elements with the same name occur on the same level in XMLERS'
+ <ArchiveTimeStampSequence> structure. Although most of the XML
+ parsers will preserve the order of the sibling elements having the
+ same name, within XML structure there is no definition how to
+ unambiguously define such order. Preserving the correct order in
+ such cases is of significant importance for digest value
+ calculations over XML structures.
+
+
+
+Blazic, et al. Standards Track [Page 11]
+
+RFC 6283 XMLERS July 2011
+
+
+2.2. Generation
+
+ The generation of an <EvidenceRecord> element MUST be as follows:
+
+ 1. Select an archive object (a data object or a data object group) to
+ archive.
+
+ 2. Create the initial <ArchiveTimeStamp>. This is the first ATS
+ within the initial <ArchiveTimeStampChain> element of the
+ <ArchiveTimeStampSequence> element.
+
+ 3. Refresh the <ArchiveTimeStamp> when necessary by Time-Stamp
+ renewal or hash tree renewal (see Section 4).
+
+ The Time-Stamping service may be, for a large number of archived
+ objects, expensive and time-demanding, so the LTA may benefit from
+ acquiring one Time-Stamp Token for many archived objects, which are
+ not otherwise related to each other. It is possible to collect many
+ archive objects, build a hash tree to generate a single value to be
+ Time-Stamped, and respectively reduce that hash tree to small subsets
+ that for each archive object provide 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 is also
+ possible to convert existing Time-Stamps into an ATS for renewal.
+
+ The case when only essential parts of documents or objects shall be
+ protected is out of scope for this standard, and 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
+ 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 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).
+
+
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 12]
+
+RFC 6283 XMLERS July 2011
+
+
+2.3. Verification
+
+ The overall verification of an Evidence Record MUST be as follows:
+
+ 1. Select an archive object (a data object or a data object group).
+
+ 2. Re-encrypt data object or data object group, if encryption field
+ is used (for details, see Section 5).
+
+ 3. Verify Archive Time-Stamp Sequence (details in Sections 3.3 and
+ 4.3).
+
+3. Archive Time-Stamp
+
+ An Archive Time-Stamp is a Time-Stamp with additional artifacts that
+ allow the verification of the existence of several data objects at a
+ certain time.
+
+ The process of construction of an ATS must support evidence on a
+ long-term basis and prove that the archive object existed and was
+ identical, at the time of the Time-Stamp, to the currently present
+ archive object (at the time of verification). To achieve this, an
+ ATS MUST be renewed before it becomes invalid (which may happen for
+ several reasons such as, e.g., weakening used cryptographic
+ algorithms, invalidation of digital certificate, or a TSA terminating
+ its business or ceasing its service).
+
+3.1. Structure
+
+ An Archive Time-Stamp contains a Time-Stamp Token, with useful data
+ for its validation (cryptographic information), such as the
+ certificate chain or Certificate Revocation Lists, an optional
+ ordered set of ordered lists of hash values (a hash tree) that were
+ protected with the Time-Stamp Token and optional information
+ describing the renewal steps (<Attributes> element). A hash tree may
+ be used to store data needed to bind the Time-Stamped value with
+ protected objects by the Archive Time-Stamp. If a hash tree is not
+ present, the ATS simply refers to a single object, either input data
+ object or a previous TS.
+
+3.1.1. Hash Tree
+
+ Hash tree structure is an optional container for significant values,
+ needed to unambiguously relate a Time-Stamped value to protected data
+ objects, and is represented by the <HashTree> element. The root hash
+ value that is generated from the values of the hash tree MUST be the
+ same as the Time-Stamped value.
+
+
+
+
+Blazic, et al. Standards Track [Page 13]
+
+RFC 6283 XMLERS July 2011
+
+
+ <HashTree>
+ <Sequence Order>
+ <DigestValue>base64 encoded hash value</DigestValue> +
+ </Sequence> +
+ </HashTree>
+
+ The algorithm by which a root hash value is generated from the
+ <HashTree> element is as follows: the content of each <DigestValue>
+ element within the first <Sequence> element is base64 ([RFC4648],
+ using the base64 alphabet not the base64url alphabet) decoded to
+ obtain a binary value (representing the hash value). All collected
+ hash values from the sequence are ordered in binary ascending order,
+ concatenated and a new hash value is generated from that string.
+ With one exception to this rule: when the first <Sequence> element
+ has only one <DigestValue> element, then its binary value is added to
+ the next list obtained from the next <Sequence> element.
+
+ The newly calculated hash value is added to the next list of hashes
+ obtained from the next <Sequence> element and the previous step is
+ repeated until there is only one hash value left, i.e., when there
+ are no <Sequence> elements left. The last calculated hash value is
+ the root hash value. When an archive object is a group and composed
+ of more than one data object, the first hash list MUST contain the
+ hash values of all its data objects.
+
+ When a single Time-Stamp is obtained for a set of archive objects,
+ the LTA MUST construct a hash tree to generate a single hash value to
+ bind all archive objects from that group and then a reduced hash tree
+ MUST be calculated from the hash tree for each archive object
+ respectively (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
+ this bit string viewed as a 20-octet octet stream. And to continue
+ the example, using an example message digest value of
+ A9993E364706816ABA3E25717850C26C9CD0D89D (note 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
+
+ Time-Stamp Token is an attestation generated by a TSA that a data
+ item existed at a certain time. The Time-Stamp Token is a signed
+ data object that contains the hash value, the identity of the TSA,
+ and the exact time (obtained from trusted time source) of Time-
+ Stamping. This proves that the given data existed before the time of
+ Time-Stamping. For example, [RFC3161] specifies a structure for
+ signed Time-Stamp Tokens in ASN.1 format. Since at the time being
+
+
+
+Blazic, et al. Standards Track [Page 14]
+
+RFC 6283 XMLERS July 2011
+
+
+ there is no standard for an XML Time-Stamp, the following structure
+ example is provided [TS-ENTRUST], which is a digital signature
+ compliant to [XMLDSig] specification containing Time-Stamp specific
+ data, such as Time-Stamped value and time within 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 ATS holds a complete structure of Time-Stamp
+ Token as provided by a TSA. Time-Stamp Token may be in XML or ASN.1
+ format. The Attribute type MUST be used to indicate the format for
+ processing purposes, with values "XMLENTRUST" or "RFC3161"
+ respectively. For an RFC3161 type Time-Stamp Token, the <TimeStamp>
+ element MUST contain base64 encoding of a DER-encoded ASN1 data.
+ These type values are registered by IANA (see Section 10). For
+ support of future types of Time-Stamps (in particular for future XML
+ Time-Stamp standards), these 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), or OCSP-Responses
+ (Online Certificate Status Protocol) needed to verify the Time-Stamp
+ Token SHOULD be stored in the Time-Stamp Token itself. When this is
+ not possible, such data MAY be stored in the
+
+
+
+
+Blazic, et al. Standards Track [Page 15]
+
+RFC 6283 XMLERS July 2011
+
+
+ <CryptographicInformationList> element; each data object is stored
+ into a separate <CryptographicInformation> element, with a REQUIRED
+ Order attribute.
+
+ The attribute Type is REQUIRED and is used to store processing
+ information about the type of stored cryptographic information. The
+ Type attribute MUST use a value registered with IANA, as identifiers:
+ CRL, OCSP, SCVP, or CERT, and for each type the content MUST be
+ encoded respectively:
+
+ o for type CRL, a base64 encoding of a DER-encoded X.509 CRL
+ [RFC5280]
+
+ o for type OCSP, a base64 encoding of a DER-encoded OCSPResponse
+ [RFC2560]
+
+ o for type SCVP, a base64 encoding of a DER-encoded CVResponse;
+ [RFC5055]
+
+ o 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 (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 generation of the initial ATS
+ element can be done in a single process pass for one or for many
+ archived objects. It MUST be done as described in the following
+ steps:
+
+ 1. Collect one or more archive objects to be Time-Stamped.
+
+ 2. Select a canonicalization method C to be used for obtaining binary
+ representation of archive data and for Archive Time-Stamp at a
+ later stage in the renewing process (see Section 4). Note that
+ the selected canonicalization method MUST be used also for archive
+ data when data is represented in XML format.
+
+ 3. 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.
+
+ 4. Generate a hash tree for selected archive object (see Section
+ 3.2.1).
+
+
+
+Blazic, et al. Standards Track [Page 16]
+
+RFC 6283 XMLERS July 2011
+
+
+ The hash tree may be omitted in the initial ATS, when an archive
+ object has a single data object; then the Time-Stamped value MUST
+ match the digest value of that single data object.
+
+ 5. Acquire Time-Stamp token from TSA for root hash value of a 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
+
+ The <DigestValue> elements within the <Sequence> element MUST be
+ ordered in binary ascending order to ensure the correct calculation
+ of digest values at the time of renewal and later for verification
+ purposes. Note that the text value of the <DigestValue> element is
+ base64 encoded, so it MUST be base64 decoded in order to obtain a
+ binary representation 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. This is the case
+ when either of the following is true:
+
+ 1. When an archive object has more than one data object (i.e., is an
+ archive data object group), its digest value is the digest value
+ of 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.
+
+ 2. When for more than one archive object a single Time-Stamp Token is
+ generated, then the hash tree is a reduced hash tree extracted
+ from 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
+ to the root. First the leaves of the tree are collected, each leaf
+ representing the digest value of an archive object. You MUST use the
+ following procedure to calculate the hash tree:
+
+ 1. Collect archive objects and for each archive object its
+ corresponding data objects.
+
+ 2. Choose a secure hash algorithm H and calculate the digest values
+ for the data objects and put them into the input list for the hash
+ tree as follows: 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 data object in the
+ archive object (i.e., it is an archive data object group) the
+ digest value is the digest value of binary sorted, concatenated
+ digest values of all its containing data objects.
+
+
+
+Blazic, et al. Standards Track [Page 17]
+
+RFC 6283 XMLERS July 2011
+
+
+ Note that for an archive object group (having more than one data
+ object), lists of their sub-digest values are stored and later,
+ when creating a reduced hash tree for that archive object, they
+ will become members of the first hash list.
+
+ 3. Group together items in the input list by the order of N (e.g.,
+ for a binary tree group in pairs, for a tertiary tree group in
+ triplets, and so forth) and for each group: binary ascending sort,
+ concatenate, and calculate the hash value. The result is a 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.
+
+ 4. Repeat step 3, until only one digest value is left; this is the
+ root value of the hash tree, which is 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: An input list with 18 hash values, where 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 18]
+
+RFC 6283 XMLERS July 2011
+
+
+ ----------
+ 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 Tree
+
+ Note 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 reduced to lists of hash
+ values, necessary as a proof of existence for a single archive object
+ as follows:
+
+
+
+Blazic, et al. Standards Track [Page 19]
+
+RFC 6283 XMLERS July 2011
+
+
+ 1. For a selected archive object (AO) select its hash value h within
+ the leaves of the hash tree.
+
+ 2. Put h as 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.
+
+ 3. 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.
+
+ 4. Repeat step 3 for the parent node until the root hash value is
+ reached, with each step create a new <Sequence> element and
+ increase 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):
+
+
+
+Blazic, et al. Standards Track [Page 20]
+
+RFC 6283 XMLERS July 2011
+
+
+ <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:
+
+ 1. Identify hash algorithm H (from <DigestMethod> element) and
+ calculate the hash value for each data object of the archive
+ object.
+
+ 2. If the hash tree is present, search for hash values in the first
+ <Sequence> element. If hash values are not present, terminate
+ verification process with 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.
+
+ 3. 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 negative
+ result.
+
+ 4. 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 negative result. If an
+ archive object is having more data objects and the hash tree is
+ omitted, also exit with negative result.
+
+
+
+
+
+Blazic, et al. Standards Track [Page 21]
+
+RFC 6283 XMLERS July 2011
+
+
+ 5. Check the validity of the Time-Stamp Token. If the needed
+ information to verify formal validity of the Time-Stamp Token is
+ not available or found within the <TimeStampToken> element or
+ within the <CryptographicInformationList> element or in
+ <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
+
+ An Archive Time-Stamp proves the existence of single data objects or
+ a data object group at a certain time. However, the initial Evidence
+ Record created can become invalid due to losing the validity of the
+ Time-Stamp Token for a number of reasons: hash algorithms or public
+ key algorithms used in its hash tree or the Time-Stamp may become
+ weak or the validity period of the Time-Stamp authority certificate
+ expires or is revoked.
+
+ To preserve the validity of an Evidence Record before such events
+ occur, the Evidence Record has to be renewed. This can be done by
+ creating a new ATS. Depending on the reason for renewing the
+ Evidence Record (the Time-Stamp becomes invalid or the hash algorithm
+ of the hash tree becomes weak) two types of renewal processes are
+ possible:
+
+ o Time-Stamp renewal: For this process a new Archive Time-Stamp is
+ generated, which is applied over the last Time-Stamp created. The
+ process results in a series of Archive Time-Stamps, which are
+ contained within a single Archive Time-Stamp Chain (ATSC).
+
+ o Hash tree renewal: For this process a new Archive Time-Stamp is
+ generated, which is applied to all existing Time-Stamps and data
+ objects. The newly generated Archive Time-Stamp is placed in a
+
+
+
+
+
+Blazic, et al. Standards Track [Page 22]
+
+RFC 6283 XMLERS July 2011
+
+
+ new Archive Time-Stamp Chain. The process results in a series of
+ Archive Time-Stamp Chains, which are contained within a 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 are generated
+ through renewal processes. The renewal process results in 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:
+
+ o as the last <ArchiveTimeStamp> child element in a sequence of the
+ last <ArchiveTimeStampChain> element in case of Time-Stamp renewal
+ or
+
+ o 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). The digest method is specified in the
+ <ArchiveTimeStampChain> element by the required <DigestMethod>
+ element and 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.
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 23]
+
+RFC 6283 XMLERS July 2011
+
+
+ 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, 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 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
+ 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].
+
+
+
+
+Blazic, et al. Standards Track [Page 24]
+
+RFC 6283 XMLERS July 2011
+
+
+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 created as follows:
+
+ 1. 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).
+
+ 2. 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.
+
+ 3. 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.
+
+
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 25]
+
+RFC 6283 XMLERS July 2011
+
+
+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:
+
+ 1. Select one or more archive objects to be renewed and their current
+ <ArchiveTimeStamp> elements.
+
+ 2. 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).
+
+ 3. Select a canonicalization method C and select a new secure hash
+ algorithm H.
+
+ 4. 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).
+
+ 5. 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.
+
+ 6. 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).
+
+ 7. 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.
+
+ 8. 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.
+
+
+
+
+Blazic, et al. Standards Track [Page 26]
+
+RFC 6283 XMLERS July 2011
+
+
+ Example for an archive object with 3 data objects: Select a new hash
+ algorithm and canonicalization method. Collect all 3 data objects
+ and currently generated Archive Time-Stamp Sequence.
+
+ AO
+
+ / | \
+
+ d1 d2 d3
+
+ ATSSeq
+ ATSChain1: ATS0, ATS1
+
+ ATSChain2: ATS0, ATS1, ATS2
+
+ The 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
+
+ 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. In order to complete the non-repudiation proof for an
+ archive object, the last ATS has to be valid and ATSCs and their
+ relations to each other have to be proved:
+
+ 1. Select archive object and re-encrypt its data object or data
+ object group, if <EncryptionInformation> field is used. Select
+ the initial digest algorithm specified within the first Archive
+
+
+
+Blazic, et al. Standards Track [Page 27]
+
+RFC 6283 XMLERS July 2011
+
+
+ Time-Stamp Chain and calculate the hash value of the archive
+ object. Verify that the initial Archive Time-Stamp contains
+ (identical) hash value of the AO's data object (or hash values of
+ AO's data object group). Note that when the hash tree is omitted,
+ calculated AO's value MUST match the Time-Stamped value.
+
+ 2. Verify each Archive Time-Stamp Chain and each Archive Time-Stamp
+ within. 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. Each Archive Time-Stamp MUST be valid relative to the
+ time of the succeeding Archive Time-Stamp. All Archive Time-
+ Stamps with 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.
+
+ 3. Verify that the first hash value list of the first Archive Time-
+ Stamp of all succeeding Archive Time-Stamp Chains contains hash
+ values of data object and the hash value of Archive Time-Stamp
+ Sequence of the preceding Archive Time-Stamp Chains. Verify that
+ Archive Time-Stamp was created when the last Archive Time-Stamp of
+ the preceding Archive Time-Stamp Chain was valid.
+
+ 4. 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 non-repudiation proof for the data object, the last Archive Time-
+ Stamp MUST be valid at the time of verification process.
+
+5. Encryption
+
+ In some archive services 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 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.
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 28]
+
+RFC 6283 XMLERS July 2011
+
+
+ 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 is used to
+ unambiguously represent 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 himself the data
+ 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 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 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.
+
+
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 29]
+
+RFC 6283 XMLERS July 2011
+
+
+ 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
+
+ <?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">
+
+
+
+Blazic, et al. Standards Track [Page 30]
+
+RFC 6283 XMLERS July 2011
+
+
+ <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"/>
+
+
+
+Blazic, et al. Standards Track [Page 31]
+
+RFC 6283 XMLERS July 2011
+
+
+ </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"/>
+
+
+
+Blazic, et al. Standards Track [Page 32]
+
+RFC 6283 XMLERS July 2011
+
+
+ </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>
+
+
+
+Blazic, et al. Standards Track [Page 33]
+
+RFC 6283 XMLERS July 2011
+
+
+ </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
+
+9.1. Secure Algorithms
+
+ Cryptographic algorithms and parameters that are used within Archive
+ Time-Stamps must always be secure at the time of generation. This
+ concerns the hash algorithm used in the hash lists of Archive Time-
+ Stamp as well as hash algorithms and public key algorithms of the
+ Time-Stamps. Publications regarding security suitability of
+ cryptographic algorithms ([NIST.800-57-Part1.2006] and
+ [ETSI-TS-102-176-1-V2.0.0]) have to be considered during the
+ verification. A generic solution for automatic interpretation of
+ security suitability policies in electronic form is not the subject
+ of this specification.
+
+9.2. Redundancy
+
+ Evidence Records may become affected by weakening cryptographic
+ algorithms even before this is publicly known. Retrospectively this
+ has an impact on Archive Time-Stamps generated and renewed during the
+ archival period. In this case the validity of Evidence Records
+ created may end without any options for retroactive action.
+
+ Many TSAs are using the same cryptographic algorithms. While
+ compromise of a private key of a TSA may compromise the security of
+ only one TSA (and only one Archive Time-Stamp, for example),
+ weakening cryptographic algorithms used to generate Time-Stamp Tokens
+ would affect many TSAs at the same time.
+
+
+
+
+
+Blazic, et al. Standards Track [Page 34]
+
+RFC 6283 XMLERS July 2011
+
+
+ To manage such risks and to avoid the loss of Evidence Record
+ validity due to weakening cryptographic algorithms used, it is
+ RECOMMENDED to generate and manage at least two redundant Evidence
+ Records for a single data object. In such scenarios redundant
+ Evidence Records SHOULD use different hash algorithms within Archive
+ Time-Stamp Sequences and different TSAs using different cryptographic
+ algorithms for Time-Stamp Tokens.
+
+9.3. Secure Time-Stamps
+
+ Archive Time-Stamps depend upon the security of normal Time-Stamping
+ provided by TSA and stated in security policies. Renewed Archive
+ Time-Stamps MUST have the same or higher quality as the initial
+ Archive Time-Stamp of archive data. Archive Time-Stamps used for
+ signed archive data SHOULD have the same or higher quality than the
+ maximum quality of the signatures.
+
+9.4. Time-Stamp Verification
+
+ It is important to consider for renewal and verification that when a
+ new Time-Stamp is applied, it MUST be ascertained that prior to the
+ time of renewal (i.e., when the new Time-Stamp is applied) the
+ certificate of the before current Time-Stamp was not revoked due to a
+ key compromise. Otherwise, in the case of a key compromise, there is
+ the risk that the authenticity of the used Time-Stamp and therefore
+ its security in the chain of evidence cannot be guaranteed. Other
+ revocation reasons like the revocation for cessation of activity do
+ not necessarily pose this risk, as in that case the private key of
+ the Time-Stamp unit would have been previously destroyed and thus
+ cannot be used nor compromised.
+
+ Both elements <CryptographicInformationList> and <Attribute> are
+ protected by future Archive Time_Stamp renewals and can store
+ information as outlined in Section 2.1 that is available at or before
+ the time of the renewal of the specific Archive Time-Stamp. At the
+ time of renewal all previous Archive Time-Stamp data structures
+ become protected by the new Archive Time-Stamp and frozen by it,
+ i.e., no data MUST be added or modified in these elements afterwards.
+ If, however, some supporting information is relevant for the overall
+ Evidence Record or information that only becomes available later,
+ this can be provided in the Evidence Record in the
+ <SupportingInformationList> element. Data in the
+ <SupportingInformatonList> can be added later to an Evidence Record,
+ but it must rely on its own authenticity and integrity protection
+ mechanism, like, for example, signed by current strong cryptographic
+ means and/or provided by a trusted source (for example, this could be
+ the LTA providing its current system DSSC policy, signed with current
+ strong cryptographic means).
+
+
+
+Blazic, et al. Standards Track [Page 35]
+
+RFC 6283 XMLERS July 2011
+
+
+10. IANA Considerations
+
+ For all IANA registrations related to this document, the
+ "Specification Required" [RFC5226] allocation policies MUST be used.
+
+ This document defines the XML namespace "urn:ietf:params:xml:ns:ers"
+ according to the guidelines in [RFC3688]. This namespace has been
+ registered in the IANA XML Registry.
+
+ This document defines an XML schema (see Section 8) according to the
+ guidelines in [RFC3688]. This XML schema has been registered in the
+ IANA XML Registry and can be identified with the URN
+ "urn:ietf:params:xml:schema:ers".
+
+ This specification defines a new IANA registry entitled "XML Evidence
+ Record Syntax (XMLERS)". This registry contains two sub-registries
+ entitled "Time-Stamp Token Type" and "Cryptographic Information
+ Type". The policy for future assignments to both sub-registries is
+ "RFC Required".
+
+ The sub-registry "Time-Stamp Token Type" contains textual names and
+ description, which should refer to the specification or standard
+ defining that type. It serves as assistance when validating a Time-
+ Stamp Token.
+
+ When registering a new Time-Stamp Token type, the following
+ information MUST be provided:
+
+ o The textual name of the Time-Stamp Token type (value). The value
+ MUST conform to the XML datatype "xs:NMTOKEN".
+
+ o 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.xsd
+
+
+
+Blazic, et al. Standards Track [Page 36]
+
+RFC 6283 XMLERS July 2011
+
+
+ The sub-registry "Cryptographic Information Type" contains textual
+ names and description, which should refer to a specification or
+ standard defining that type. It serves as assistance when validating
+ cryptographic information such as digital certificates, CRLs, or
+ OCSP-Responses.
+
+ When registering a new cryptographic information type, the following
+ information MUST be provided:
+
+ o The textual name of the cryptographic information type (value).
+ The value MUST conform to the XML datatype "xs:NMTOKEN".
+
+ o 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
+
+ [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.
+
+
+
+
+
+Blazic, et al. Standards Track [Page 37]
+
+RFC 6283 XMLERS July 2011
+
+
+ [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.
+
+
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 38]
+
+RFC 6283 XMLERS July 2011
+
+
+11.2. Informative References
+
+ [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.
+
+
+
+
+
+Blazic, et al. Standards Track [Page 39]
+
+RFC 6283 XMLERS July 2011
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 40]
+
+RFC 6283 XMLERS July 2011
+
+
+Appendix A. Detailed Verification Process of an Evidence Record
+
+ To verify the validity of an Evidence Record start with the first ATS
+ till the last ATS (ordered by attribute Order) and perform
+ verification for each ATS, as follows:
+
+ 1. Select corresponding archive object and its data object or a group
+ of data objects.
+
+ 2. Re-encrypt data object or data object group, if the
+ <EncryptionInformation> field is used (see Section 5 for more
+ details)
+
+ 3. Get a canonicalization method C and a digest method H from the
+ <DigestMethod> element of the current chain.
+
+ 4. Make a new list L of digest values of (binary representation of)
+ objects (data, ATS, or sequence) that MUST be protected with this
+ ATS as follows:
+
+ a. If this ATS is the first in the Archive Time-Stamp Chain:
+
+ i. If this is the first ATS of the first ATSC (the initial ATS)
+ in the ATSSeq, calculate digest values of data objects with
+ H and add each digest value to the list L.
+
+ ii. If this ATS is not the initial ATS, calculate a digest value
+ with H of ordered ATSSeq without this and successive chains.
+ Add value H and digest values of 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.
+
+ 5. Verify the ATS's Time-Stamped value as follows. Get 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), then the Time-Stamped value must be equal to the
+ digest value of previous Time-Stamp element. If not, exit
+ with a negative result.
+
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 41]
+
+RFC 6283 XMLERS July 2011
+
+
+ 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, which 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 which 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 Time-Stamped value from the Time-Stamp Token. If
+ calculated root hash value from the hash tree does not match
+ the Time-Stamped value, exit with a negative result.
+
+ 6. Verify Time-Stamp cryptographically and formally (validate the
+ used certificate and its chain, which may be available within
+ the Time-Stamp Token itself or <CryptographicInformation>
+ element).
+
+ 7. If this ATS is the last ATS, check formal validity for the
+ current time (now), or get "valid from" time of the next ATS
+ and verify formal validity at that specific time.
+
+ 8. If the needed information to verify formal validity is not
+ found within the Time-Stamp or within its Cryptographic
+ Information section of ATS, exit with a negative result.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 42]
+
+RFC 6283 XMLERS July 2011
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blazic, et al. Standards Track [Page 43]
+