idnits 2.17.1 draft-ietf-ltans-xmlers-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4998]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1363 has weird spacing: '...:schema xmlns...' == Line 1674 has weird spacing: '... Schema http...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 24, 2011) is 4834 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0-2' is mentioned on line 1543, but not defined == Missing Reference: '1-3' is mentioned on line 1543, but not defined == Missing Reference: '0-9' is mentioned on line 1543, but not defined ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 4051 (Obsoleted by RFC 6931) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLC14N' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLDSig' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLName' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSchema' Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Long-term Archive And Notary A. Jerman Blazic 3 Services (LTANS) SETCCE 4 Internet Draft S. Saljic 5 Intended status: Standards Track SETCCE 6 Expires: July 24, 2011 T. Gondrom 7 January 24, 2011 9 Extensible Markup Language Evidence Record Syntax 10 draft-ietf-ltans-xmlers-11.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on March 18, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Abstract 61 In many scenarios, users must be able to demonstrate the (time of) 62 existence, integrity and validity of data including signed data for 63 long or undetermined periods of time. This document specifies XML 64 syntax and processing rules for creating evidence for long-term non- 65 repudiation of existence and integrity of data. ERS-XML provides 66 alternative syntax and processing rules to the ASN.1 (Abstract Syntax 67 Notation One) ERS (Evidence Record Syntax) [RFC4998] syntax by using 68 XML language. 70 Table of Contents 72 1. Introduction...................................................5 73 1.1. Motivation................................................5 74 1.2. General Overview and Requirements.........................7 75 1.3. Terminology...............................................8 76 1.4. Conventions Used in This Document........................10 77 2. Evidence Record...............................................11 78 2.1. Structure................................................11 79 2.2. Generation...............................................16 80 2.3. Verification.............................................17 81 3. Archive Time-Stamp............................................18 82 3.1. Structure................................................18 83 3.1.1. Hash Tree...........................................18 84 3.1.2. Time-Stamp..........................................20 85 3.1.3. Cryptographic Information List......................21 86 3.2. Generation...............................................22 87 3.2.1. Generation of Hash Tree.............................23 88 3.2.2. Reduction of hash tree..............................27 89 3.3. Verification.............................................29 90 4. Archive Time-Stamp Sequence and Archive Time-Stamp Chain......30 91 4.1. Structure................................................31 92 4.1.1. Digest Method.......................................32 93 4.1.2. Canonicalization Method.............................33 94 4.2. Generation...............................................34 95 4.2.1. Time-Stamp Renewal..................................34 96 4.2.2. Hash Tree Renewal...................................35 97 4.3. Verification.............................................37 98 5. Encryption....................................................39 99 6. Version.......................................................40 100 7. Storage of policies...........................................40 101 8. XSD Schema for the Evidence Record............................41 102 9. Security Considerations.......................................46 103 9.1. Secure Algorithms........................................46 104 9.2. Redundancy...............................................47 105 9.3. Secure Time-Stamps.......................................47 106 9.4. Time-Stamp verification..................................47 107 10. IANA Considerations..........................................48 108 11. References...................................................51 109 11.1. Normative References....................................51 110 11.2. Informative References..................................52 111 APPENDIX A: Detailed verification process of an Evidence Record..55 112 Author's Addresses...............................................57 114 1. Introduction 116 The purpose of the document is to define XML Schema and processing 117 rules for Evidence Record Syntax in XML (Extensible Markup Language) 118 format. The document is related to initial ASN.1 (Abstract Syntax 119 Notation One) syntax for Evidence Record Syntax as defined in 120 [RFC4998]. 122 1.1. Motivation 124 The evolution of electronic commerce and electronic data exchange in 125 general requires introduction of non-repudiable proof of data 126 existence as well as data integrity and authenticity. Such data and 127 non-repudiable proof of existence must endure for long periods of 128 time, even when the initial information to prove its existence and 129 integrity weakens or ceases to exist. Mechanisms such as digital 130 signatures defined in [RFC5652], for example, do not provide absolute 131 reliability on a long term basis. Algorithms and cryptographic 132 material used to create a signature can become weak in the course of 133 time and information needed to validate digital signatures may become 134 compromised or simply cease to exist due to for example the 135 disbanding of a certificate service provider. Providing a stable 136 environment for electronic data on a long term basis requires the 137 introduction of additional means to continually provide an 138 appropriate level of trust in evidence on data existence, integrity 139 and authenticity. 141 All integrity and authenticity protecting techniques used today 142 suffer from the problem of degrading reliability over time, including 143 techniques for Time-Stamping, which are generally recognized as data 144 existence and integrity proof mechanisms. Over long periods of time 145 cryptographic algorithms used may become weak or encryption keys 146 compromised. Some of the problems might not even be of technical 147 nature like a Time-Stamping authority going out of business and 148 ceasing its service. To create a stable environment where proof of 149 existence and integrity can endure well into the future a new 150 technical approach must be used. 152 Long term non-repudiation of data existence and demonstration of data 153 integrity techniques have been already introduced, for example, by 154 long term signature syntaxes like those defined in [RFC5126]. Long 155 term signature syntaxes and processing rules address only the long 156 term endurance of the digital signatures themselves, while Evidence 157 Record Syntax broadens this approach for data of any type or format 158 including digital signatures. 160 The XMLERS (Extensible Markup Language Evidence Record Syntax ) 161 syntax is based on Evidence Record Syntax as defined in [RFC4998] and 162 is addressing the same problem of long term non-repudiable proof of 163 data existence and demonstration of data integrity on a long term 164 basis. XMLERS does not supplement the [RFC4998] specification. 165 Following extensible markup language standards and [RFC3470] 166 guidelines it introduces the same approach but in a different format 167 and with adapted processing rules. 169 The use of eXtensible Markup Language (XML) format is already 170 recognized by a wide range of applications and services and is being 171 selected as the de-facto standard for many applications based on data 172 exchange. The introduction of Evidence Record Syntax in XML format 173 broadens the horizon of XML use and presents a harmonized syntax with 174 a growing community of XML based standards including those related to 175 security services such as [XMLDSig] or [XAdES]. 177 Due to the differences in XML processing rules and other 178 characteristics of XML language, XMLERS does not present a direct 179 transformation of ERS in ASN.1 syntax. The XMLERS syntax is based on 180 different processing rules as defined in [RFC4998] and it does not 181 support, for example, the import of ASN.1 values in XML tags. 182 Creating Evidence Records in XML syntax must follow the steps as 183 defined in this draft. XMLERS is a standalone draft and is based on 184 [RFC4998] conceptually only. 186 Evidence Record Syntax in XML format is based on long term archive 187 service requirements as defined in [RFC4810]. XMLERS syntax delivers 188 the same (level of) non-repudiable proof of data existence as ASN.1 189 ERS[RFC4998]. The XML syntax supports archive data grouping (and de- 190 grouping) together with simple or complex Time-Stamp renewal 191 processes. Evidence Records can be embedded in the data itself or 192 stored separately as a standalone XML file. 194 1.2. General Overview and Requirements 196 XMLERS specifies the XML syntax and processing rules for creating 197 evidence for the long-term non-repudiation of existence and integrity 198 of data in a unit called the "Evidence Record". The XMLERS syntax is 199 defined to meet the requirements for data structures as set out in 200 [RFC4810]. This document also refers to the ASN.1 ERS specification 201 as defined in [RFC4998]. 203 An Evidence Record may be generated and maintained for a single data 204 object or a group of data objects that form an archive object. A data 205 object (binary chunk or a file) may represent any kind of document or 206 part of it. Dependencies among data objects, their validation or any 207 other relationship than "a data object is a part of particular 208 archived object" are outside the scope of this draft. 210 Evidence Record is closely related to Time-Stamping techniques. 211 However, Time-Stamps as defined in [RFC3161], can cover only a single 212 unit of data and do not provide processing rules for maintaining a 213 long term stability of Time-Stamps applied over a data object. 214 Evidence for an archive object is created by acquiring a Time-Stamp 215 from a trustworthy authority for a specific value that is 216 unambiguously related to a single or more data objects. Relationship 217 between several data objects and a single time-stamped value is 218 addressed using a hash tree, a technique first described by Merkle 220 [MER1980] and later in [RFC4998], with data structures and procedures 221 as specified in this document. The Evidence Record Syntax enables 222 processing of several archive objects within a single processing pass 223 using a hash tree technique and acquiring only one Time-Stamp to 224 protect all archive objects. The leaves of the hash tree are hash 225 values of the data objects in a group. A timestamp is requested only 226 for the root hash of the hash tree. The deletion of a data object in 227 the tree does not influence the provability of others. For any 228 particular data object, the hash tree can be reduced to a few sets of 229 hash values, which are sufficient to prove the existence of a single 230 data object. Similarly, the hash tree can be reduced to prove 231 existence of a data group, provided all members of the data group 232 have the same parent node in the hash tree. Archive Timestamps are 233 comprised of an optional reduced hash tree and a timestamp. 235 Besides a Time-Stamp other artifacts are also preserved in Evidence 236 Record: data necessary to verify the relationship between a time- 237 stamped value and a specific data object, packed into a structure 238 called a "hash tree"; and long term proofs for the formal 239 verification of included Time-Stamp(s). 241 Due to the fact that digest algorithms or cryptographic methods used 242 may become weak or that certificates used within a Time-Stamp (and 243 signed data) may be revoked or expire, the collected evidence data 244 must be monitored and renewed before such events occur. This document 245 introduces XML based syntax and processing rules for the creation and 246 continuous renewal of evidence data. 248 1.3. Terminology 250 Archive data object: Data unit that is archived and has to be 251 preserved for a long time by the Long-term Archive Service. 253 Archive data object group: A set of archive data objects, which for 254 some reason (logically) belong together, e.g. a group of document 255 files or a document file and a signature file could represent an 256 archive data object group. 258 Archive object: an archive data object or an archive data object 259 group. 261 Archive Time-Stamp (ATS): An Archive Time-Stamp contains a Time-Stamp 262 Token, useful data for validation and optionally a set of ordered 263 lists of hash values (a hash tree). An Archive Time-Stamp relates to 264 a data object, if the hash value of this data object is part of the 265 first hash value list of the Archive Time-Stamp or its hash value 266 matches the time-stamped value. An Archive Time-Stamp relates to a 267 data object group, if it relates to every data object of the group 268 and no other data object (i.e. the hash values of all but no other 269 data objects of the group are part of the first hash value list of 270 the Archive Time-Stamp) (see section 3.). 272 Archive Time-Stamp Chain (ATSC): holds a sequence of Archive Time- 273 Stamps generated during the preservation period. 275 Archive Time-Stamp Sequence (ATSSeq): is a sequence of Archive Time- 276 Stamp Chains. 278 Canonicalization: Processing rules for transforming an XML document 279 into its canonical form. Two XML documents may have different 280 physical representations, but they may have the same canonical form. 281 For example a sort order of attributes does not change the meaning of 282 the document as defined in [XMLC14N]. 284 Cryptographic Information: Data or part of data related to the 285 validation process of signed data, e.g. digital certificates, digital 286 certificate chains, certificate revocation lists, etc. 288 Digest Method: Digest method is a digest algorithm, which is a strong 289 one-way function, for which it is computationally infeasible to find 290 an input that corresponds to a given output or to find two different 291 input values that correspond to the same output. A digest algorithm 292 transforms input data into a short value of fixed length. The output 293 is called digest value, hash value or data fingerprint. 295 Evidence: Information that may be used to resolve a dispute about 296 various aspects of authenticity, validity and existence of archived 297 data objects. 299 Evidence Record: Collection of evidence compiled for a given archive 300 object over time. An Evidence Record includes ordered collection of 301 ATSs, which are grouped into ATSCs and ATSSeqs. 303 Long-term Archive Service (LTA): A service responsible for 304 generation, collection and maintenance (renewal) of evidence data. A 305 LTA service may also preserve data for long periods of time, e.g. 306 storage of archive data and associated evidences. 308 Hash Tree: Collection of hash values of protected objects (input data 309 objects and generated evidence within archival period) that are 310 unambiguously related to the time-stamped value within an Archive 311 Time-Stamp. 313 Time-Stamp Token (TS): A cryptographically secure confirmation 314 generated by a Time-Stamping Authority (TSA) e.g. [RFC3161] which 315 specifies a structure for Time-Stamps and a protocol for 316 communicating with a Time-Stamp Authority. Besides this, other data 317 structures and protocols may also be appropriate, such as defined in 318 [ISO-18014-1.2002], [ISO-18014-2.2002], [ISO-18014-3.2004], and 319 [ANSI.X9-95.2005]. 321 1.4. Conventions Used in This Document 323 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 324 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 325 document are to be interpreted as described in [RFC2119]. 327 2. Evidence Record 329 An Evidence Record is a unit of data that is to be used to prove the 330 existence of an archive object (a single archive data object or a 331 archive data object group) at a certain time. Through the lifetime of 332 an archive object, an Evidence Record also demonstrates the data 333 objects' integrity and non-repudiability. To achieve this, 334 cryptographic means are used, i.e. the LTA obtains Time-Stamp Tokens 335 from the Time-Stamping Authority (TSA). It is possible to store the 336 Evidence Record separately from the archive object or to integrate it 337 into the data itself. 339 As cryptographic means are used to support Evidence Records, such 340 records may lose their value over time. Time-Stamps obtained from 341 Time-Stamping Authorities may become invalid for a number of reasons, 342 usually due to time constraints of Time-Stamp validity or when 343 cryptographic algorithms lose their security properties. Before the 344 used Time-Stamp Tokens become unreliable, the Evidence Record has to 345 be renewed. This may result in a series of Time-Stamp Tokens, which 346 are linked between themselves according to the cryptographic methods 347 and algorithms used. 349 Evidence Records can be supported with additional information, which 350 can be used to ease the processes of Evidence Record validation and 351 renewal. Information such as digital certificates and certificate 352 revocation lists as defined in [RFC5280] or other cryptographic 353 material can be collected, enclosed and processed together with 354 archive object data (i.e. time-stamped). 356 2.1. Structure 358 The Evidence Record contains one or several Archive Time-Stamps 359 (ATS). An ATS contains a Time-Stamp Token and optionally other useful 360 data for Time-Stamp validation, e.g. certificates, CRLs (certificate 361 revocation list) or OCSP (Online Certificate Status Protocol) 362 responses and also specific attributes such as service policies. 364 Initially, an ATS is acquired and later, before it expires or becomes 365 invalid a new ATS is acquired, which prolongs the validity of the 366 archived object (its data objects together with all previously 367 generated Archive Time-Stamps). This process MUST continue during the 368 desired archiving period of the archive data object(s). A series of 369 successive Archive Time-Stamps is collected in Archive Time-Stamp 370 Chains and a series of chains in Archive Time-Stamp Sequence. 372 In XML syntax the Evidence Record is represented by the 373 root element, which has the following structure 374 described in Pseudo-XML with the full XML schema defined in section 375 8. (where "?" denotes zero or one occurrences, "+" denotes one or 376 more occurrences and "*" denotes zero or more occurrences): 378 380 381 382 383 ? 384 385 + 386 ? 387 388 389 390 391 392 ? 393 394 395 396 + 397 ? 398 399 400 + 401 ? 402 + 403 + 404 405 407 The syntax of an evidence record is defined as an XML schema 408 [XMLSchema], see Section 8. The schema uses the following XML 409 namespace [XMLName] urn:ietf:params:xml:ns:ers as default namespace 410 with a detailed xml schema header listed in section 8. 412 The XML elements and attributes have the following meanings: 414 The "Version" attribute MUST be included and indicates the syntax 415 version, for compatibility with future revisions of this 416 specification and to distinguish it from earlier non-conformant or 417 proprietary versions of the XMLERS. Current version of the XMLERS 418 syntax is 1.0. The used versioning scheme is described in detail in 419 section 6. element is OPTIONAL and holds 420 information on cryptographic algorithms and cryptographic material 421 used to encrypt archive data (in case archive data is encrypted 422 e.g. for privacy purposes). This optional information is needed to 423 unambiguously re-encrypt data objects when processing Evidence 424 Records. When omitted, data objects are not encrypted or non- 425 repudiation proof is not needed for the unencrypted data. Details 426 on how to process encrypted archive data and generate Evidence 427 Record(s) are described in Section 5. 429 element is OPTIONAL and can hold 430 information to support processing of Evidence Records. An example 431 of this supporting information may be a processing policy, like a 432 cryptographic policy (e.g. [RFC5698]) or archiving policies, which 433 can provide input about preservation and evidence validation. Each 434 data object is put into a separate child element 435 , with an OPTIONAL Type attribute to 436 indicate its type for processing directions. As outlined, Types to 437 be used must be defined in the specification of the information 438 structure to be stored or in this standard. As outlined in section 439 9.4 Cryptographic information may also be stored in the 440 SupportingInformation element, in which case its in section 3.1.3 441 defined type MUST be used. Or as defined in section 7 cryptographic 442 policies [RFC5698] MAY be stored, in which case the used type is 443 defined in the relevant RFC. Note that if supporting information 444 and policies are relevant for and already available at or before 445 the time of individual renewal steps (e.g. to indicate the DSSC 446 crypto policy [RFC5698]) that was used at the time of the 447 individual renewal) they SHOULD be stored in the 448 element of the individual Archive Time-Stamp (see below) as this is 449 integrity protected by the Archive Time-Stamps. Supporting 450 information that is relevant for the whole Evidence Record (like 451 the LTA's current Cryptographic Algorithms Security Suitability 452 policy (DSSC, [RFC5698]) or that was not available at the time of 453 renewal (and therefore could not later be stored in the protected 454 element, can be stored in this 455 element. 457 is REQUIRED and contains a sequence of 458 one or more . 460 is a REQUIRED element that holds a sequence 461 of Archive Time-Stamps generated during the preservation period. 462 Details on Archive Time-Stamp Chains and Archive Time-Stamp 463 Sequences are described in section 4. The sequences of Archive 464 Time-Stamp Chains and Archive Time-Stamps MUST be ordered and the 465 order MUST be indicated with "Order" attribute of the 466 and element. 468 is a REQUIRED element and contains an attribute 469 "Algorithm" that identifies the digest algorithm used within one 470 Archive Time-Stamp chain to calculate digest values from archive 471 data object(s), previous Archive Time-Stamp sequence, Time-Stamps 472 and within a Time-Stamp Token. 474 is a REQUIRED element that specifies which 475 canonicalization algorithm is applied to the archive data for XML 476 data objects, or elements 477 prior to performing digest value calculations. 479 is an OPTIONAL element that holds a structure as 480 described in section 3.1.1. 482 is REQUIRED and holds a element with a 483 Time-Stamp Token (as defined in section 3.1.2.) provided by the 484 Time-Stamping Authority and an OPTIONAL element 485 . 487 is an OPTIONAL element that allows 488 the storage of data needed in the process of Time-Stamp Token 489 validation in case when such data is not provided by the Time-Stamp 490 Token itself. This could include possible trust anchors, 491 certificates, revocation information or the current definition of 492 the suitability of cryptographic algorithms, past and present. Each 493 data object is put into a separate child element 494 , with a REQUIRED Order attribute to 495 indicate the order within its parent element. These items may be 496 added based on the policy used. This data is protected by 497 successive Time-Stamps in the sequence of the Archive Time-Stamps. 499 element is OPTIONAL and contains additional 500 information that may be provided by an LTA used to support 501 processing of Evidence Records. An example of this supporting 502 information may be a processing policy, like a renewal, a 503 cryptographic (e.g. [RFC5698]) or an archiving policy. Such 504 policies can provide inputs, which are relevant for data object(s) 505 preservation and evidence validation at a later stage. Each data 506 object is put into a separate child element , with a 507 REQUIRED Order attribute to indicate the order within the parent 508 element and an OPTIONAL Type attribute to indicate processing 509 directions. The Type to be used must be defined in the 510 specification of the information structure. For example, the type 511 to be used when storing a cryptographic policy [RFC5698] is defined 512 in [RFC5698, section A.2]. 514 The Order attribute is REQUIRED in all cases when one or more XML 515 elements with the same name occur on the same level in the XMLERS' 516 structure. Although most of the XML 517 parsers will preserve the order of the sibling elements having the 518 same name, within XML structure there is no definition how to 519 unambiguously define such order. Preserving the correct order in 520 such cases is of significant importance for digest value 521 calculations over XML structures. 523 2.2. Generation 525 The generation of an element MUST be as follows: 527 1. Select an archive object (a data object or a data object group) to 528 archive. 530 2. Create the initial . This is the first ATS 531 within the initial element of the 532 element. 534 3. Refresh the when necessary by Time-Stamp 535 Renewal or Hash Tree Renewal (see Section 4.). 537 The Time-Stamping service may be, for a large number of archived 538 objects, expensive and time-demanding, so the LTA may benefit from 539 acquiring one Time-Stamp Token for many archived objects, which are 540 not otherwise related to each other. It is possible to collect many 541 archive objects, build a hash tree to generate a single value to be 542 time-stamped, and respectively reduce that hash tree to small subsets 543 that for each archive object provide necessary binding with the time- 544 stamped hash value (see Section 3.2.1). 546 For performance reasons or in case of local Time-Stamp generation, 547 building a hash tree ( element) can be omitted. It is also 548 possible to convert existing Time-Stamps into an ATS for renewal. 550 The case when only essential parts of documents or objects shall be 551 protected is out of scope for this standard, and an application that 552 is not defined in this draft must ensure that the correct unambiguous 553 extraction of binary data is made for the generation of Evidence 554 Record. 556 An application may also provide evidence such as certificates, 557 revocation lists etc., needed to verify and validate signed data 558 objects or a data object group. This evidence may be added to the 559 archived object data group and will be protected within initial (and 560 successive) Time-Stamp(s). 562 Note that the element of Evidence 563 Record is not to be used to store and protect cryptographic material 564 related to signed archive data. The use of this element is limited to 565 cryptographic material related to TS(s). 567 2.3. Verification 569 The overall verification of an Evidence Record MUST be as follows: 571 1. Select an archive object (a data object or a data object group) 573 2. Re-encrypt data object or data object group, if encryption field 574 is used (for details, see Section 5.). 576 3. Verify Archive Timestamp Sequence (details in Section 3.3. and 577 Section 4.3.). 579 3. Archive Time-Stamp 581 An Archive Time-Stamp is a timestamp with additional artifacts that 582 allow the verification of the existence of several data objects at a 583 certain time. 585 The process of construction of an ATS must support evidence on a long 586 term basis and prove that the archive object existed and was 587 identical, at the time of the Time-Stamp, to the currently present 588 archive object (at the time of verification). To achieve this, an ATS 589 MUST be renewed before it becomes invalid (which may happen for 590 several reasons such as e.g. weakening used cryptographic algorithms, 591 invalidation of digital certificate or a TSA terminating its business 592 or ceasing its service). 594 3.1. Structure 596 An Archive Time-Stamp contains a Time-Stamp Token, with useful data 597 for its validation (cryptographic information), such as the 598 certificate chain or certificate revocation lists, an optional 599 ordered set of ordered lists of hash values (a hash tree) that were 600 protected with the Time-Stamp Token and optional information 601 describing the renewal steps ( element). A hash tree may 602 be used to store data needed to bind the time-stamped value with 603 protected objects by the Archive Time-Stamp. If a hash tree is not 604 present, the ATS simply refers to a single object; either input data 605 object or a previous TS. 607 3.1.1. Hash Tree 609 Hash tree structure is an optional container for significant values, 610 needed to unambiguously relate a time-stamped value to protected data 611 objects, and is represented by the element. The root hash 612 value that is generated from the values of the hash tree MUST be the 613 same as the time-stamped value. 615 616 617 base64 encoded hash value + 618 + 619 621 The algorithm by which a root hash value is generated from the 622 element is as follows: the content of each 623 element within the first element is base64 ([RFC4648], 624 using the base64 alphabet not the base64url alphabet) decoded to 625 obtain a binary value (representing the hash value). All collected 626 hash values from the sequence are ordered in binary ascending order, 627 concatenated and a new hash value is generated from that string. With 628 one exception from this rule: when the first element has 629 only one element, then its binary value is added to the 630 next list obtained from the next element. 632 The newly calculated hash value is added to the next list of hashes 633 obtained from the next element and the previous step is 634 repeated until there is only one hash value left, i.e. when there are 635 no elements left. The last calculated hash value is the 636 root hash value. When an archive object is a group and composed of 637 more than one data object, the first hash list MUST contain the hash 638 values of all its data objects. 640 When a single Time-Stamp is obtained for a set of archive objects, 641 the LTA MUST construct a hash tree to generate a single hash value to 642 bind all archive objects from that group and then a reduced hash tree 643 MUST be calculated from the hash tree for each archive object 644 respectively (see Section 3.2.1). 646 For example: A SHA-1 digest value is a 160-bit string. The text value 647 of the element shall be the base64 encoding of this bit 648 string viewed as a 20-octet octet stream. And to continue the 649 example, using an example message digest value of 650 A9993E364706816ABA3E25717850C26C9CD0D89D (note this is a HEX encoded 651 value of the 160-bit message digest). Its base64 representation would 652 be: qZk+NkcGgWq6PiVxeFDCbJzQ2J0= 654 3.1.2. Time-Stamp 656 Time-Stamp Token is an attestation generated by a TSA that a data 657 item existed at a certain time. The Time-Stamp Token is a signed data 658 object that contains the hash value, the identity of the TSA, and the 659 exact time (obtained from trusted time source) of Time-Stamping. This 660 proves that the given data existed before the time of Time-Stamping. 661 For example, [RFC3161] specifies a structure for signed Time-Stamp 662 Tokens in ASN.1 format. Since at the time being there is no standard 663 for an XML Time-Stamp, the following structure example is provided 664 [TS-ENTRUST], which is a digital signature compliant to [XMLDSig] 665 specification containing Time-Stamp specific data, such as time- 666 stamped value and time within element of a signature. 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 A element of ATS holds a complete structure of Time-Stamp 683 Token as provided by a TSA. Time-Stamp Token may be in XML or ASN.1 684 format. The Attribute type MUST be used to indicate the format for 685 processing purposes, with values "XMLENTRUST" or "RFC3161" 686 respectively. For an RFC3161 type Time-Stamp Token, the 687 element MUST contain base64 encoding of a DER-encoded ASN1 data. 688 These type values are registered by IANA (see Section 10). For 689 support of future types of timestamps (in particular for future XML 690 time-stamp standards), these need to be registered there as well. 692 For example: 694 MIAGCSqGSIb3DQEH... 696 or 698 ... 699 . 701 3.1.3. Cryptographic Information List 703 Digital certificates, CRLs (Certificate Revocation List), SCVP 704 (Server-based Certificate Validation Protocol) or OCSP-Responses 705 (Online Certificate Status Protocol) needed to verify the Time-Stamp 706 Token SHOULD be stored in the Time-Stamp Token itself. When this is 707 not possible, such data MAY be stored in the 708 element, each data object is stored 709 into a separate element, with a REQUIRED 710 Order attribute. 712 The attribute Type is REQUIRED and is used to store processing 713 information about the type of stored cryptographic information. The 714 Type attribute MUST use a value registered with IANA, as identifiers: 715 CRL, OCSP, SCVP or CERT, and for each type the content MUST be 716 encoded respectively: 718 o for type CRL, a base64 encoding of a DER-encoded X.509 CRL 719 [RFC5280]; 721 o for type OCSP, a base64 encoding of a DER-encoded OCSPResponse 722 [RFC2560]; 724 o for type SCVP, a base64 encoding of a DER-encoded CVResponse; 725 [RFC5055]; 727 o for type CERT, a base64 encoding of a DER-encoded X.509 728 certificate [RFC5280];. 730 The supported type identifiers are registered by IANA (see Section 731 10). Future supported types can be registered there (for example to 732 support future validation standards). 734 3.2. Generation 736 An initial ATS relates to a data object or a data object group that 737 represents an archive object. The generation of the initial ATS 738 element can be done in a single process pass for one or for many 739 archived objects. It MUST be done as described in the following 740 steps: 742 1. Collect one or more archive objects to be time-stamped. 744 2. Select a canonicalization method C to be used for obtaining binary 745 representation of archive data and for Archive Time-Stamp at a 746 later stage in the renewing process (see section 4). Note that the 747 selected canonicalization method MUST be used also for archive 748 data when data is represented in XML format. 750 3. Select a valid digest algorithm H. The selected secure hash 751 algorithm MUST be the same as the hash algorithm used in the Time- 752 Stamp Token and for the hash tree computations. 754 4. Generate a hash tree for selected archive object (see 3.2.1). 756 The hash tree may be omitted in the initial ATS, when an archive 757 object has a single data object; then the time-stamped value MUST 758 match the digest value of that single data object. 760 5. Acquire Time-Stamp token from TSA for root hash value of a hash 761 tree (see 3.1.1). If the Time-Stamp token is valid, the initial 762 Archive Time-Stamp may be generated. 764 3.2.1. Generation of Hash Tree 766 The elements within the element MUST be 767 ordered in binary ascending order to ensure the correct calculation 768 of digest values at the time of renewal and later for verification 769 purposes. Note, that the text value of element is 770 base64 encoded, so it MUST be base64 decoded in order to obtain a 771 binary representation of the hash value. 773 A hash tree MUST be generated when the time-stamped value is not 774 equal to the hash value of the input data object. This is the case 775 when either of the following is true: 777 1. When an archive object has more than one data object (i.e. is an 778 archive data object group), its digest value is the digest value 779 of binary ascending ordered and concatenated digest values of all 780 its containing data objects. Note that in this case the first list 781 of the hash tree MUST contain hash values of all data objects and 782 only those values. 784 2. When for more than one archive object a single Time-Stamp Token is 785 generated, then the hash tree is a reduced hash tree extracted 786 from the hash tree for that archive object (see Section 3.2.2). 788 The hash tree for a set of archive objects is built from the leaves 789 to the root. First the leaves of the tree are collected, each leaf 790 representing the digest value of an archive object. You MUST use the 791 following procedure to calculate the hash tree: 793 1. Collect archive objects and for each archive object its 794 corresponding data objects. 796 2. Choose a secure hash algorithm H and calculate the digest values 797 for the data objects and put them into the input list for the hash 798 tree as follows: a digest value of an archive object is the digest 799 value of its data object, if there is only one data object in the 800 archive object; if there are more than one data objects in the 801 archive object (i.e. it is an archive data object group) the 802 digest value is the digest value of binary sorted, concatenated 803 digest values of all its containing data objects. 805 Note that for an archive object group (having more than one data 806 object), lists of their sub-digest values are stored and later, 807 when creating a reduced hash tree for that archive object, they 808 will become members of the first hash list. 810 3. Group together items in the input list by the order of N (e.g. for 811 a binary tree group in pairs, for a tertiary tree group in 812 triplets and so forth) and for each group: binary ascending sort, 813 concatenate and calculate the hash value. The result is a new 814 input for the next list. For improved processing it is RECOMMENDED 815 to have the same number of children for each node. For this 816 purpose you MAY extend the tree with arbitrary values to make 817 every node have the same number of children. 819 4. Repeat step 3, until only one digest value is left; this is the 820 root value of the hash tree, which is time-stamped. 822 Note that the selected secure hash algorithm MUST be the same as the 823 one defined in the element of the ATSChain. 825 Example: An input list with 18 hash values, where the h'1 is 826 generated for a group of data objects (d4, d5, d6 and d7) and has 827 been grouped by 3. The group could be of any size (2, 3...). Note, 828 the addition of the arbitrary values h''6 and h'''3 are OPTIONAL and 829 can be used for improved processing as outlined in step 3 above. 831 ---------- 832 d1 -> h1 \ 833 \ 834 G1 d2 -> h2 |-> h''1 835 +--------+ / \ 836 |d4 -> h4|\ d3 -> h3 / \ 837 |d5 -> h5| \ ---------- | 838 | | | -> h'1\ | 839 |d6 -> h6| / \ | 840 |d7 -> h7|/ d8 -> h8 |-> h''2 |-> h'''1 841 +--------+ / | \ 842 d9 -> h9 / | \ 843 ---------- | | 844 d10 -> h10\ / | 845 \ / | 846 d11 -> h11 |-> h''3 | 847 / | 848 d12 -> h12/ |-> root hash value 849 ---------- | 850 d13 -> h13\ | 851 \ | 852 d14 -> h14 |-> h''4 | 853 / \ | 854 d15 -> h15/ \ | 855 ---------- |-> h'''2 | 856 d16 -> h16\ | | 857 \ | | 858 d17 -> h17 |-> h''5 | | 859 / | | 860 d18 -> h18/ | | 861 ---------- / | 862 / / 863 (any arbitrary) h''6 / 864 (any arbitrary) h'''3 866 Figure 1 Generation of the Merkle Hash Tree. 868 Note that there are no restrictions on the quantity of hash value 869 lists and of their length. Also note that it is beneficial but not 870 required to build hash trees and reduce hash trees. An Archive Time- 871 Stamp may consist only of one list of hash values and a Time-Stamp or 872 in an extreme case only a Time-Stamp with no hash value lists. 874 3.2.2. Reduction of hash tree 876 The generated Merkle hash tree can be reduced to lists of hash 877 values, necessary as a proof of existence for a single archive object 878 as follows: 880 1. For a selected archive object (AO) select its hash value h within 881 the leaves of the hash tree. 883 2. Put h as base64 encoded text value of a new element 884 within a first element. If the selected archive object 885 AO is a data object group (i.e. has more than one data object), 886 the first element MUST in this case be formed from the 887 hash values of all AO's data objects, each within a separate 888 element. 890 3. Select all hash values, which have the same father node as hash 891 value h. Place these hash values each as a base64 encoded text 892 value of a new element within a new 893 element, increasing its Order attribute value by 1. 895 4. Repeat step 3 for the parent node until the root hash value is 896 reached, with each step create a new element and 897 increase its Order attribute by one. Note that node values are not 898 saved as they are computable. 900 The order of elements within each element 901 MUST be binary ascending (by base64 decoded values). 903 Reduced hash tree for data object d4 (from the previous example, 904 presented in Figure 1): 906 907 908 base64 encoded h4 909 base64 encoded h5 910 base64 encoded h6 911 base64 encoded h7 912 913 914 base64 encoded h8 915 base64 encoded h9 916 917 918 base64 encoded h''1 919 base64 encoded h''3 920 921 922 base64 encoded h'''2 923 924 926 Reduced Hash tree for data object d2 (from the previous example, 927 presented in Figure 1): 929 930 931 base64 encoded h2 932 933 934 base64 encoded h1 935 base64 encoded h3 936 937 938 base64 encoded h''2 939 base64 encoded h''3 940 941 942 base64 encoded h'''2 943 944 946 3.3. Verification 948 The initial Archive Timestamp shall prove that an archive object 949 existed at a certain time, indicated by its Time-Stamp token. The 950 verification procedure MUST be as follows: 952 1. Identify hash algorithm H (from element) and 953 calculate the hash value for each data object of the archive 954 object. 956 2. If the hash tree is present, search for hash values in the first 957 element. If hash values are not present, terminate 958 verification process with negative result. If the verifying party 959 also seeks additional proof that the Archive Time-Stamp relates to 960 a data object group (e.g. a document and all its digital 961 signatures), it SHOULD also be verified that only the hash values 962 of the data objects that are members of the given data object 963 group are in the first hash value list. 965 3. If the hash tree is present, calculate its root hash value. 966 Compare the root hash value with the time-stamped value. If they 967 are not equal, terminate the verification process with negative 968 result. 970 4. If the hash tree is omitted, compare the hash value of the single 971 data object with the time-stamped value. If they are not equal, 972 terminate the verification process with negative result. If an 973 archive object is having more data objects and the hash tree is 974 omitted, also exit with negative result. 976 5. Check the validity of the Time-Stamp token. If the needed 977 information to verify formal validity of the Time-Stamp token is 978 not available or found within the element or 979 within element or in 980 (see section 9.4), exit with a 981 negative result. 983 Information for formal verification of the Time-Stamp token includes 984 digital certificates, Certificate Revocation Lists, Online 985 Certificate Status Protocol responses, etc. This information needs to 986 be collected prior to the Time-Stamp renewal process and protected 987 with the succeeding Time-Stamp, i.e. included in the 988 or element (see section 9.4 for additional 989 information and section 4.2.1 for details on Time-Stamp renewal 990 process). For the current (latest) Time-Stamp), information for 991 formal verification of the (latest) Time-Stamp should be provided by 992 the Time-Stamping Authority. This information can also be provided 993 with the Evidence Record within element, 994 which is not protected by any Time-Stamp. 996 4. Archive Time-Stamp Sequence and Archive Time-Stamp Chain 998 An Archive Time-Stamp proves the existence of single data objects or 999 a data object group at a certain time. However, the initial Evidence 1000 Record created can become invalid due to loosing the validity of the 1001 Time-Stamp Token for a number of reasons: hash algorithms or public 1002 key algorithms used in its hash tree or the Time-Stamp may become 1003 weak or the validity period of the timestamp authority certificate 1004 expires or is revoked. 1006 To preserve the validity of an Evidence Record before such events 1007 occur, the Evidence Record has to be renewed. This can be done by 1008 creating a new ATS. Depending on the reason for renewing the Evidence 1009 Record (the Time-Stamp becomes invalid or the hash algorithm of the 1010 hash tree becomes weak) two types of renewal processes are possible: 1012 o Time-Stamp renewal: For this process a new Archive Time-Stamp is 1013 generated, which is applied over the last Time-Stamp created. The 1014 process results in a series of Archive Time-Stamps which are 1015 contained within a single Archive Time-Stamp Chain (ATSC). 1017 o Hash Tree renewal: For this process a new Archive Time-Stamp is 1018 generated, which is applied to all existing Time-Stamps and data 1019 objects. The newly generated Archive Time-Stamp is placed in a new 1020 Archive Time-Stamp Chain. The process results in a series of 1021 Archive Time-Stamp Chains which are contained within a single 1022 Archive Time-Stamp Sequence (ATSS). 1024 After the renewal process, only the most recent (i.e. the last 1025 generated) Archive Time-Stamp has to be monitored for expiration or 1026 validity loss. 1028 4.1. Structure 1030 Archive Time-Stamp Chain and Archive Time-Stamp Sequence are 1031 containers for sequences of archive Time-Stamp(s) which are generated 1032 through renewal processes. The renewal process results in a series of 1033 Evidence Record elements: element contains 1034 an ordered sequence of elements and 1035 element contains an ordered sequence of 1036 elements. Both elements MUST be sorted by time of 1037 the Time-Stamp in ascending order. Order is indicated by the Order 1038 attribute. 1040 When an Archive Time-Stamp must be renewed, a new 1041 element is generated and depending on the generation process, it is 1042 either placed: 1044 o as the last child element in a sequence of the 1045 last element in case of Time-Stamp renewal 1046 or 1048 o as the first child element in a sequence of the 1049 newly created element in case of hash tree 1050 renewal. 1052 The ATS with the largest Order attribute value within the ATSC with 1053 the largest Order attribute value is the latest ATS and MUST be valid 1054 at the present time. 1056 4.1.1. Digest Method 1058 Digest method is a required element that identifies the digest 1059 algorithm used to calculate hash values of archive data (and node 1060 values of hash tree). The digest method is specified in the 1061 element by the required 1062 element and indicates the digest algorithm that MUST be used for all 1063 hash value calculations related to the Archive Time-Stamps within the 1064 Archive Time-Stamp chain. 1066 The Algorithm attribute contains URIs [RFC3986] for identifiers which 1067 MUST be used as defined in [RFC3275] and [RFC4051]. For example when 1068 the SHA-1 algorithm is used, the algorithm identifier is: 1070 1072 Within a single ATSC the digest algorithms used for the hash trees of 1073 its Archive Time-Stamps and the Time-Stamp Token(s) MUST be the same. 1074 When algorithms used by a TSA are changed (e.g. upgraded) a new ATSC 1075 MUST be started using an equal or stronger digest algorithm. 1077 4.1.2. Canonicalization Method 1079 Prior to hash value calculations of an XML element, a proper binary 1080 representation must be extracted from its (abstract) XML data 1081 presentation. The binary representation is determined by UTF-8 1082 [RFC3629] encoding and canonicalization of the XML element. The XML 1083 element includes the entire text of the start and end tags as well as 1084 all descendant markup and character data (i.e. the text and sub- 1085 elements) between those tags. 1087 is a required element that identifies the 1088 canonicalization algorithm used to obtain binary representation of an 1089 XML element(s). Algorithm identifiers (URIs) MUST be used as defined 1090 in [RFC3275] and [RFC4051]. For example when Canonical XML 1.0 (omits 1091 comments) is used, algorithm identifier is 1093 . 1096 Canonicalization MUST be applied over XML structured archive data and 1097 MUST be applied over elements of Evidence Record (namely ATS and ATSC 1098 in the renewing process). 1100 The canonicalization method is specified in the attribute 1101 of the element within the 1102 element and indicates the canonicalization 1103 method that MUST be used for all binary representations of the 1104 Archive Time-Stamps within that Archive Time-Stamp chain. In case of 1105 succeeding ATSC the canonicalization method indicated within the ATSC 1106 must also be used for the calculation of the digest value of the 1107 preceding ATSC. Note that the canonicalization method is unlikely to 1108 change over time as it does not impose the same constrains as the 1109 digest method. In theory, the same canonicalization method can be 1110 used for a whole Archive Time-Stamp Sequence. Although alternative 1111 canonicalization methods may be used, it is recommended to use c14n- 1112 20010315 [XMLC14N]. 1114 4.2. Generation 1116 Before the cryptographic algorithms used within the most recent 1117 Archive Time-Stamp become weak or the Time-Stamp certificates are 1118 invalidated, the LTA has to renew the Archive Time-Stamps by 1119 generating a new Archive Time-Stamp using one of two procedures: 1120 time-stamp renewal or hash tree renewal. 1122 4.2.1. Time-Stamp Renewal 1124 In case of Time-Stamp renewal, i.e. if the digest algorithm (H) to be 1125 used in the renewal process is the same as digest algorithm (H') used 1126 in the last Archive Time-Stamp, the complete content of the last 1127 element MUST be time-stamped and new 1128 element created as follows: 1130 1. If the current element does not contain needed 1131 proof for long-term formal validation of its Time-Stamp Token 1132 within the element, collect needed data such as root 1133 certificates, certificate revocation lists, etc., and include them 1134 in element of the last Archive 1135 Time-Stamp (each data object into a separate 1136 element). 1138 2. Select canonicalization method from 1139 element and select digest algorithm from element. 1140 Calculate hash value from binary representation of the 1141 element of the last element including added 1142 cryptographic information. Acquire the Time-Stamp for the 1143 calculated hash value. If the Time-Stamp is valid, the new Archive 1144 Time-Stamp may be generated. 1146 3. Increase the value order of the new ATS by one and place the new 1147 ATS into the last element. 1149 The new ATS and its hash tree MUST use the same digest algorithm as 1150 the preceding one, which is specified in the element 1151 within element. Note that the new ATS MAY not 1152 contain a hash tree. However, Time-Stamp Renewal process may be 1153 optimized to acquire one Time-Stamp for many Archive Time-Stamps 1154 using a hash tree. Note that each hash of the element is 1155 treated as the document hash in Section 3.2.1. 1157 4.2.2. Hash Tree Renewal 1159 The process of hash tree renewal occurs when the new digest algorithm 1160 is different to the one used in the last Archive Time-Stamp (H <> 1161 H'). In this case the complete Archive Time-Stamp Sequence and the 1162 archive data objects covered by existing Archive Time-stamp must be 1163 time-stamped as follows: 1165 1. Select one or more archive objects to be renewed and their current 1166 elements. 1168 2. For each archive object check the current 1169 element. If it does not contain the proof needed for long-term 1170 formal validation of its Time-Stamp Token within the Time-Stamp 1171 Token, collect the needed data such as root certificates, 1172 certificate revocation lists, etc., and include them in the 1173 element of the last Archive Time- 1174 Stamp (each data object into a separate 1175 element). 1177 3. Select a canonicalization method C and select a new secure hash 1178 algorithm H. 1180 4. For each archive object select its data objects d(i). Generate 1181 hash values h(i) = H(d(i)), for example: h(1), h(2).., h(n). 1183 5. For each archive object calculate a hash hseq=H(ATSSeq) from 1184 binary representation of the element, 1185 corresponding to that archive object. Note that Archive Time-Stamp 1186 Chains and Archive Time-Stamps MUST be chronologically ordered, 1187 each respectively to its Order attribute, and that the 1188 canonicalization method C MUST be applied. 1190 6. For each archive object sort in binary ascending order and 1191 concatenate all h(i) and the hseq. Generate a new digest value 1192 h(j)=H(h(1)..h(n),hseq). 1194 7. Build a new Archive Time-Stamp for each h(j) (hash tree generation 1195 and reduction is defined in sections 3.2.1. and 3.2.2.). Note that 1196 each h(j) is treated as the document hash in section 3.2.1. The 1197 first hash value list in the reduced hash tree should only contain 1198 h(i) and hseq. 1200 8. Create the new containing the new 1201 element (with order number 1), and place it 1202 into the existing as a last child with 1203 the order number increased by one. 1205 Example for an archive object with 3 data objects: Select a new hash 1206 algorithm and canonicalization method. Collect all 3 data objects and 1207 currently generated Archive Time-Stamp sequence. 1209 AO 1211 / | \ 1213 d1 d2 d3 1215 ATSSeq 1216 ATSChain1: ATS0, ATS1 1218 ATSChain2: ATS0, ATS1, ATS2 1220 The hash values MUST be calculated with the new hash algorithm H for 1221 all data objects and for the whole ATSSeq. Note, that ATSSeq MUST be 1222 chronologically ordered and canonicalized before retrieving its 1223 binary representation. 1225 When generating the hash tree for the new ATS, the first sequence 1226 become values: H(d1), H(d2),..., H(dn), H(ATSSeq). Note: hash values 1227 MUST be sorted in binary ascending order. 1229 1230 1231 H(d1) 1232 H(d2) 1233 H(d3) 1234 H(ATSSeq) 1235 1236 1238 Note that if the group processing is being performed, the hash value 1239 of the concatenation of the first sequence is an input hash value 1240 into the hash tree. 1242 4.3. Verification 1244 An Evidence Record shall prove that an archive object existed and has 1245 not been changed from the time of the initial Time-Stamp Token within 1246 the first ATS. In order to complete the non-repudiation proof for an 1247 archive object, the last ATS has to be valid and ATSCs and their 1248 relations to each other have to be proved: 1250 1. Select archive object and re-encrypt its data object or data 1251 object group, if field is used. Select the 1252 initial digest algorithm specified within the first Archive Time- 1253 Stamp Chain and calculate hash value of the archive object. Verify 1254 that the initial Archive Time-Stamp contains (identical) hash 1255 value of the AO's data object (or hash values of AO's data object 1256 group). Note that when the hash tree is omitted, calculated AO's 1257 value MUST match the time-stamped value. 1259 2. Verify each Archive Time-Stamp Chain and each Archive Time-Stamp 1260 within. If the hash tree is present within the second and the next 1261 Archive Time-Stamps of an Archive Time-Stamp Chain, the first 1262 MUST contain the hash value of the element 1263 before. Each Archive Time-Stamp MUST be valid relative to the time 1264 of the succeeding Archive Time-Stamp. All Archive Time-Stamps with 1265 the Archive Time-Stamp Chain MUST use the same hash algorithm, 1266 which was secure at the time of the first Archive Time-Stamp of 1267 the succeeding Archive Time-Stamp Chain. 1269 3. Verify that the first hash value list of the first Archive Time- 1270 Stamp of all succeeding Archive Time-Stamp Chains contains hash 1271 values of data object and the hash value of Archive Time-Stamp 1272 Sequence of the preceding Archive Time-Stamp Chains. Verify that 1273 Archive Time-Stamp was created when the last Archive Time-Stamp of 1274 the preceding Archive Time-Stamp Chain was valid. 1276 4. To prove the Archive Time-Stamp Sequence relates to a data object 1277 group, verify that the first Archive Time-Stamp of the first 1278 Archive Time-Stamp Chain does not contain other hash values in its 1279 first hash value list than the hash values of those data objects. 1281 For non-repudiation proof for the data object, the last Archive Time- 1282 Stamp MUST be valid at the time of verification process. 1284 5. Encryption 1286 In some archive services scenarios it may be required that clients 1287 send encrypted data only, preventing information disclosure to third 1288 parties, such as archive service providers. In such scenarios it must 1289 be clear that Evidence Records generated refer to encrypted data 1290 objects. Evidence Records in general protect the bit-stream (or 1291 binary representation of XML data) which freezes the bit structure at 1292 the time of archiving. Encryption schemes in such scenarios cannot be 1293 changed afterwards without losing the integrity proof. Therefore, an 1294 ERS record must hold and preserve encryption information in a 1295 consistent manner. To avoid problems when using the evidence records 1296 in the future, additional special precautions have to be taken. 1298 Encryption is a two way process, whose result depends on the 1299 cryptographic material used, e.g. encryption keys and encryption 1300 algorithms. Encryption and decryption keys as well as algorithms must 1301 match in order to reconstruct the original message or data that was 1302 encrypted. Evidence generated to prove the existence of encrypted 1303 data cannot always be relied upon to prove the existence of 1304 unencrypted data. It may be possible to choose different 1305 cryptographic material, i.e. an algorithm or a key for decryption 1306 that is not the algorithm or key used for encryption. In this case, 1307 the evidence record would not be a non-repudiation proof for the 1308 unencrypted data. Therefore, only encryption methods should be used 1309 that make it possible to prove that archive-time-stamped encrypted 1310 data objects unambiguously represent unencrypted data objects. In 1311 cases when evidence was generated to prove the existence of encrypted 1312 data the corresponding algorithm and decryption keys used for 1313 encryption must become a part of the Evidence Record and is used to 1314 unambiguously represent original (unencrypted) data that was 1315 encrypted. (Note: In addition, the long-term security of the 1316 encryption schemes should be analyzed to determine if it could be 1317 used to create collision attacks.)Cryptographic material may also be 1318 used in scenarios when a client submits encrypted data to the archive 1319 service provider for preservation but stores himself the data only in 1320 an unencrypted form. In such scenarios cryptographic material is used 1321 to re-encrypt the unencrypted data kept by a client for the purpose 1322 of performing validation of Evidence Record, which is related to the 1323 encrypted form of client's data.An OPTIONAL extensible structure 1324 is defined to store the necessary parameters 1325 of the encryption methods. Its element is 1326 used to store the type of stored encryption information, e.g. whether 1327 it is an encryption algorithm or encryption key. The 1328 element then contains the relevant 1329 encryption information itself. The use of encryption elements heavily 1330 depends on the cryptographic mechanism and has to be defined by other 1331 specifications. 1333 6. Version 1335 The numbering scheme for XMLERS versions is ".". The 1336 major and minor numbers MUST be treated as separate integers and each 1337 number MAY be incremented higher than a single digit. Thus, "2.4" 1338 would be a lower version than "2.13", which in turn would be lower 1339 than "12.3". Leading zeros (e.g., "6.01") MUST be ignored by 1340 recipients and MUST NOT be sent. 1342 The major version number will be incremented only if the data format 1343 has changed so dramatically that an older version entity would not be 1344 able to interoperate with a newer version entity if it simply ignored 1345 the elements and attributes it did not understand and took the 1346 actions defined in the older specification. 1348 The minor version number will be incremented if significant new 1349 capabilities have been added to the core format (e.g. new optional 1350 elements). 1352 7. Storage of policies 1354 As explained above policies can be stored in the Evidence Record in 1355 the or the element. In the case 1356 of storing DSSC policies [RFC5698], the types to be used in the 1357 or element are defined in 1358 [RFC5698, section A.2] for both ASN.1 and XML representation. 1360 8. XSD Schema for the Evidence Record 1362 1363 1368 1370 1372 1373 1374 1376 1378 1380 1381 1383 1385 1386 1387 1389 1390 1391 1392 1393 1394 1395 1396 1397 1399 1400 1401 1402 1403 1404 1406 1408 1411 1412 1414 1415 1416 1417 1419 1420 1421 1422 1423 1424 1425 1427 1429 1430 1431 1432 1433 1434 1436 1437 1438 1439 1440 1441 1443 1444 1445 1446 1447 1448 1449 1450 1452 1453 1455 1456 1457 1458 1459 1461 1462 1463 1464 1465 1466 1467 1468 1470 1471 1473 1474 1475 1476 1478 1479 1480 1481 1482 1483 1484 1485 1487 1488 1490 1492 1493 1494 1495 1496 1497 1498 1499 1500 1502 1503 1504 1505 1506 1508 1509 1511 1513 1514 1515 1516 1517 1518 1520 1521 1522 1524 1525 1526 1527 1528 1530 1531 1534 1535 1536 1537 1538 1539 1541 1542 1543 1544 1545 1547 1548 1549 1550 1551 1552 1554 9. Security Considerations 1556 9.1. Secure Algorithms 1558 Cryptographic algorithms and parameters that are used within Archive 1559 Time-Stamps must always be secure at the time of generation. This 1560 concerns the hash algorithm used in the hash lists of Archive 1561 Timestamp as well as hash algorithms and public key algorithms of the 1562 timestamps. Publications regarding security suitability of 1563 cryptographic algorithms ([NIST.800-57-Part1.2006] and [ETSI TS 102 1564 176-1 V2.0.0]) have to be considered during the verification. A 1565 generic solution for automatic interpretation of security suitability 1566 policies in electronic form is not the subject of this specification. 1568 9.2. Redundancy 1570 Evidence Records may become affected by weakening cryptographic 1571 algorithms even before this is publicly known. Retrospectively this 1572 has an impact on Archive Time-Stamps generated and renewed during 1573 the archival period. In this case the validity of Evidence Records 1574 created may end without any options for retroactive action. 1576 Many TSAs are using the same cryptographic algorithms. While 1577 compromise of a private key of a TSA may compromise the security of 1578 only one TSA (and only on Archive Time-Stamp for example), weakening 1579 cryptographic algorithms used to generate Time-Stamp Tokens would 1580 affect many TSAs at the same time. 1582 To manage such risks and to avoid the loss of Evidence Record 1583 validity due to weakening cryptographic algorithms used, it is 1584 RECOMMENDED to generate and manage at least two redundant Evidence 1585 Records for a single data object. In such scenarios redundant 1586 Evidence Records SHOULD use different hash algorithms within Archive 1587 Time-Stamp Sequences and different TSAs using different 1588 cryptographic algorithms for Time-Stamp Tokens. 1590 9.3. Secure Time-Stamps 1592 Archive Time-Stamps depend upon the security of normal Time-Stamping 1593 provided by TSA and stated in security policies. Renewed Archive 1594 Time-Stamps MUST have the same or higher quality as the initial 1595 Archive Time-Stamp of archive data. Archive Time-Stamps used for 1596 signed archive data SHOULD have the same or higher quality than the 1597 maximum quality of the signatures. 1599 9.4. Time-Stamp verification 1601 It is important to consider for renewal and verification that when a 1602 new Time-Stamp is applied, it MUST be ascertained that prior the 1603 time of renewal (i.e. when the new Time-Stamp is applied) the 1604 certificate of the before current Time-Stamp was not revoked due to 1605 a key compromise. Otherwise, in the case of a key compromise, there 1606 is the risk that the authenticity of the used Time-Stamp and 1607 therefore its security in the chain of evidence cannot be 1608 guaranteed. Other revocation reasons like the revocation for 1609 cessation of activity do not necessarily pose this risk as in that 1610 case the private key of the Time-Stamp unit would have been 1611 previously destroyed and thus cannot be used nor compromised. 1613 Both elements and are 1614 protected by future Archive Time_Stamp renewals and can store 1615 information as outlined in section 2.1. that is available at or 1616 before the time of the renewal of the specific Archive Time-Stamp. At 1617 the time of renewal all previous Archive Time-Stamp data structures 1618 become protected by the new Archive Time-Stamp and frozen by it, i.e. 1619 no data MUST be added or modified in these elements afterwards. If 1620 however, some supporting information is relevant for the overall 1621 Evidence Record or information that only becomes available later, 1622 this can be provided in the Evidence Record in the 1623 element. Data in the 1624 can be added later to an Evidence Record, 1625 but it must rely on its own authenticity and integrity protection 1626 mechanism, like for example signed by current strong cryptographic 1627 means and/or provided by a trusted source (for example this could be 1628 the LTA providing its current system DSSC policy, signed with current 1629 strong cryptographic means). 1631 10. IANA Considerations 1633 For all IANA registrations related to this document the 1634 "Specification Required" [RFC5226] allocation policies MUST be used. 1636 This document defines the XML namespace "urn:ietf:params:xml:ns:ers" 1637 according to the guidelines in [RFC3688]. This namespace has been 1638 registered in the IANA XML Registry. 1640 This document defines an XML schema (see Section 8) according to the 1641 guidelines in [RFC3688]. This XML schema has been registered in the 1642 IANA XML Registry and can be identified with the URN 1643 "urn:ietf:params:xml:schema:ers". 1645 This specification defines a new IANA registry entitled "XML Evidence 1646 Record Syntax (ERSXML)". This registry contains two sub-registries 1647 entitled "Time-Stamp Token Type" and "Cryptographic Information 1648 Type". The policy for future assignments to both sub-registries is 1649 "RFC Required". 1651 The sub-registry "Time-Stamp Token Type" contains textual names and 1652 description, which should refer to the specification or standard 1653 defining that type. It serves as assistance when validating a time- 1654 stamp token. 1656 When registering a new Time-Stamp Token type, the following 1657 information MUST be provided: 1659 o The textual name of the Time-Stamp Token type (value) 1660 The value MUST be conform to the XML datatype "xs:NMTOKEN". 1662 o A reference to a publicly available specification that defines the 1663 Time-Stamp Token type (description) 1665 The initial values for the "Time-Stamp Token Type" sub-registry are: 1667 Value Description Reference 1669 ----- ------------- ------------------------ 1671 RFC3161 RFC3161 Time-Stamp RFC 3161 1672 Token 1674 XMLENTRUST EnTrust XML Schema http://www.entrust.com 1676 /schemas/timestamp 1678 19protocol-20020207 1680 The sub-registry "Cryptographic Information Type" contains textual 1681 names and description, which should refer to specification or 1682 standard defining that type. It serves as assistance when validating 1683 cryptographic information such as digital certificates, CRLs or OCSP- 1684 Responses. 1686 When registering a new cryptographic information type, the following 1687 information MUST be provided: 1689 o The textual name of the cryptographic information type (value) 1690 The value MUST be conform to the XML datatype "xs:NMTOKEN". 1692 o A reference to a publicly available specification that defines the 1693 cryptographic information type (description) 1695 The initial values for the "Cryptographic Information Type" sub- 1696 registry are: 1698 Value Description Reference 1700 ----- ------------------ ----------------- 1702 CERT DER-encoded X.509 Certificate RFC 5280 1704 CRL DER-encoded X.509 RFC 5280 1706 Certificate Revocation List 1708 OCSP DER-encoded OCSPResponse RFC 2560 1710 SCVP DER-encoded SCVP response RFC 5055 1712 (CVResponse) 1714 11. References 1716 11.1. Normative References 1718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1719 Requirement Levels", BPC 14, RFC 2119, March 1997. 1721 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1722 Adams, "X.509 Internet Public Key Infrastructure Online 1723 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1725 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 1726 "Internet X.509 Public Key Infrastructure Time-Stamp 1727 Protocol (TSP)", RFC 3161, August 2001. 1729 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1730 January 2004. 1732 [RFC3275] Eastlake, D., Reagle, J., Solo, D., "XML-Signature Syntax 1733 and Processing", RFC 3275, March 2002. 1735 [RFC4051] Eastlake, D., "Additional XML Security Uniform Resource 1736 Identifiers", RFC 4051, April 2005. 1738 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1739 Encodings", RFC 4648, October 2006. 1741 [RFC4998] Gondrom, T., Brandner, R., Pordesch, U., "Evidence Record 1742 Syntax (ERS)", RFC 4998, August 2007. 1744 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D. and Polk, 1745 W., "Server-Based Certificate Validation Protocol (SCVP)", 1746 RFC 5055, December 2007 1748 [RFC5280] Cooper, D., Santesson, S., Farell, S., Boyen, S., Housley, 1749 R.,Polk, W., "Internet X.509 Public Key Infrastructure 1750 Certificate and Certificate Revocation List (CRL) Profile", 1751 RFC 5280, May 2008. 1753 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1754 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 1755 2008. 1757 [XMLC14N] Boyer, J., "Canonical XML", W3C Recommendation, March 2001. 1759 [XMLDSig] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Roessler, 1760 T., "XML-Signature Syntax and Processing", XMLDSig, W3C 1761 Recommendation, July 2006. 1763 [XMLName] Layman, A., Hollander, D., Tobin, R., and T. Bray, 1764 "Namespaces in XML 1.0 (Second Edition)", W3C 1765 Recommendation, August 2006. 1767 [XMLSchema] Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney, 1768 "XML Schema Part 1: Structures Second Edition", W3C 1769 Recommendation, October 2004. 1771 11.2. Informative References 1773 [ANSI.X9-95.2005] American National Standard for Financial Services, 1774 "Trusted Timestamp Management and Security", ANSI X9.95, 1775 June 2005. 1777 [ETSI TS 102 176-1 V2.0.0] ETSI, "Electronic Signatures and 1778 Infrastructures (ESI); Algorithms and Parameters for Secure 1779 Electronic Signatures; Part 1: Hash functions and 1780 asymmetric algorithms", ETSI TS 102 176-1 V2.0.0 (2007-11), 1781 November 2007. 1783 [ISO-18014-1.2002] ISO/IEC JTC 1/SC 27, "Time stamping services - 1784 Part 1: Framework", ISO ISO-18014-1, February 2002. 1786 [ISO-18014-2.2002] ISO/IEC JTC 1/SC 27, "Time stamping services - 1787 Part 2: Mechanisms producing independent tokens", ISO ISO- 1788 18014-2, December 2002. 1790 [ISO-18014-3.2004] ISO/IEC JTC 1/SC 27, "Time stamping services - 1791 Part 3: Mechanisms producing linked tokens", ISO ISO-18014- 1792 3, February 2004. 1794 [MER1980] Merkle, R., "Protocols for Public Key Cryptosystems, 1795 Proceedings of the 1980 IEEE Symposium on Security and 1796 Privacy (Oakland, CA, USA)", pages 122-134, April 1980. 1798 [RFC3470] Hollenbeck, S., Rose, M., Masinter, L., "Guidelines for the 1799 Use of Extensible Markup Language (XML) within IETF 1800 Protocols", RFC 3470, January 2003. 1802 [RFC4810] Wallace, C., Pordesch, U., Brandner, R., "Long-Term Archive 1803 Service Requirements", RFC 4810, March 2007. 1805 [RFC5126] Pinkas, D., Popoe, N., Ross, J., "CMS Advanced Electronic 1806 Signatures (CAdES)", RFC 5126, February 2008. 1808 [TS-ENTRUST] Entrust XML Schema for Time-Stamp http://www.si- 1809 tsa.gov.si/dokumenti/timestamp-protocol-20020207.xsd 1811 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1812 STD 63, RFC 3629, November 2003. 1814 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1815 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1816 3986, January 2005. 1818 [XAdES] Cruellas, J. C., Karlinger, G., Pinkas, D., Ross, J., "XML 1819 Advanced Electronic Signatures", XAdES, W3C Note, February 1820 2003. 1822 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 1823 5652, September 2009. 1825 [RFC5698] Kunz, T., Okunick, S., Pordesch, U., "Data Structure for 1826 the Security Suitability of Cryptographic Algorithms 1827 (DSSC)", RFC 5698, November 2009 1829 APPENDIX A: Detailed verification process of an Evidence Record 1831 To verify the validity of an Evidence Record start with the first ATS 1832 till the last ATS (ordered by attribute Order) and perform 1833 verification for each ATS, as follows: 1835 1. Select corresponding archive object and its data object or a group 1836 of data objects. 1838 2. Re-encrypt data object or data object group, if 1839 field is used (see section 5. for more 1840 details) 1842 3. Get a canonicalization method C and a digest method H from the 1843 element of the current chain. 1845 4. Make a new list L of digest values of (binary representation of) 1846 objects (data, ATS or sequence) that MUST be protected with this 1847 ATS as follows: 1849 a. If this ATS is the first in the Archive Time-Stamp Chain: 1851 i. If this is the first ATS of the first ATSC (the initial 1852 ATS) in the ATSSeq, calculate digest values of data 1853 objects with H and add each digest value to the list L. 1855 ii. If this ATS is not the initial ATS, calculate a digest 1856 value with H of ordered ATSSeq without this and 1857 successive chains. Add value H and digest values of data 1858 objects to the list L. 1860 b. If this ATS is not the first in the ATSC: 1862 i. Calculate the digest value with H of the previous 1863 element and add this digest value to the list 1864 L. 1866 5. Verify the ATS's time-stamped value as follows. Get the first 1867 sequence of the hash tree for this ATS. 1869 a. If this ATS has no hash tree elements then: 1871 ii. If this ATS is not the first in the ATSSeq(the initial 1872 ATS), then the time-stamped value must be equal to digest 1873 value of previous Time-Stamp element. If not, exit with a 1874 negative result. 1876 iii. If this ATS is the initial ATS in ATSC, there must be 1877 only one data object of the archive object. The digest 1878 value of that data object must be the same as its time- 1879 stamped value. If not, exit with a negative result. 1881 b. If this ATS has a hash tree then: If there is a digest value 1882 in the list L of digest values of protected objects, which 1883 cannot be found in the first sequence of the hash tree or if 1884 there is a hash value in the first sequence of the hash tree 1885 which is not in the list L of digest values of protected 1886 objects, exit with a negative result. 1888 i. Get the hash tree from the current ATS and use H to 1889 calculate the root hash value (see sections 3.2.1. and 1890 3.2.2.) 1892 ii. Get time-stamped value from the Time-Stamp Token. If 1893 calculated root hash value from the hash tree does not 1894 match the time-stamped value, exit with a negative 1895 result. 1897 6. Verify Time-Stamp cryptographically and formally (validate the 1898 used certificate and its chain which may be available within the 1899 Time-Stamp Token itself or element). 1901 7. If this ATS is the last ATS, check formal validity for the current 1902 time (now), or get "valid from" time of the next ATS and verify 1903 formal validity at that specific time. 1905 8. If the needed information to verify formal validity is not found 1906 within the Time-Stamp or within its Cryptographic Information 1907 section of ATS, exit with a negative result. 1909 Author's Addresses 1911 Aleksej Jerman Blazic 1912 SETCCE 1913 Tehnoloski park 21 1914 1000 Ljubljana 1915 Slovenia 1917 Phone: +386 (0) 1 620 4500 1918 Fax: +386 (0) 1 620 4509 1919 Email: aljosa@setcce.si 1921 Svetlana Saljic 1922 SETCCE 1923 Tehnoloski park 21 1924 1000 Ljubljana 1925 Slovenia 1927 Phone: +386 (0) 1 620 4506 1928 Fax: +386 (0) 1 620 4509 1929 Email: svetlana.saljic@setcce.si 1930 Tobias Gondrom 1931 Kruegerstr. 5A 1932 85716 Unterschleissheim 1933 Germany 1935 Phone: +49 (0) 89 320 5330 1936 Email: tobias.gondrom@gondrom.org