Extensible Markup Language Evidence Record Syntax (XMLERS) :: RFC6283
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
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
?
+
?
?
+
?
+
?
+
+
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.
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.
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
, 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
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
element) can be stored in this
element.
is REQUIRED and contains a sequence of
one or more .
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
and elements.
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
is a REQUIRED element that specifies
which canonicalization algorithm is applied to the archive data
for XML data objects or or
elements prior to performing digest value calculations.
is an OPTIONAL element that holds a structure as
described in Section 3.1.1.
is REQUIRED and holds a element with
a Time-Stamp Token (as defined in Section 3.1.2) provided by the
Time-Stamping Authority and an OPTIONAL element
.
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
, 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.
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 ,
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'
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 element MUST be as follows:
1. Select an archive object (a data object or a data object group) to
archive.
2. Create the initial . This is the first ATS
within the initial element of the
element.
3. Refresh the 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 ( 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 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 ( 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 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
base64 encoded hash value +
+
The algorithm by which a root hash value is generated from the
element is as follows: the content of each
element within the first 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 element
has only one element, then its binary value is added to
the next list obtained from the next element.
The newly calculated hash value is added to the next list of hashes
obtained from the next element and the previous step is
repeated until there is only one hash value left, i.e., when there
are no 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 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 qZk+NkcGgWq6PiVxeFDCbJzQ2J0=.
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
