idnits 2.17.1 draft-ietf-ltans-reqs-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 722. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2006) is 6375 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) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Long-term Archive And Notary C. Wallace 3 Services (LTANS) Cygnacom Solutions 4 Internet-Draft U. Pordesch 5 Expires: April 4, 2007 Fraunhofer Gesellschaft 6 R. Brandner 7 InterComponentWare AG 8 October 2006 10 Long-Term Archive Service Requirements 11 draft-ietf-ltans-reqs-10.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 4, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 There are many scenarios in which users must be able to prove the 45 existence of data at a specific point in time and be able to 46 demonstrate the integrity of data since that time, even when the 47 duration from time of existence to time of demonstration spans a 48 large period of time. Additionally, users must be able to verify 49 signatures on digitally signed data many years after the generation 50 of the signature. This document describes a class of long-term 51 archive services to support such scenarios and the technical 52 requirements for interacting with such services. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. General Principles . . . . . . . . . . . . . . . . . . . . . . 7 59 4. Technical Requirements . . . . . . . . . . . . . . . . . . . . 8 60 4.1. Enable submission, retrieval and deletion of archived 61 data objects . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.1.1. Functional Requirements . . . . . . . . . . . . . . . 8 63 4.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 8 64 4.2. Operate in accordance with a long-term archive policy . . 9 65 4.2.1. Functional Requirements . . . . . . . . . . . . . . . 9 66 4.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 10 67 4.3. Enable management of archived data objects . . . . . . . . 10 68 4.3.1. Functional Requirements . . . . . . . . . . . . . . . 10 69 4.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 11 70 4.4. Provide evidence records that support demonstration of 71 data integrity . . . . . . . . . . . . . . . . . . . . . . 11 72 4.4.1. Functional Requirements . . . . . . . . . . . . . . . 11 73 4.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 11 74 4.5. Support data confidentiality . . . . . . . . . . . . . . . 12 75 4.5.1. Functional Requirements . . . . . . . . . . . . . . . 12 76 4.5.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 12 77 4.6. Provide means to transfer data and evidence from one 78 service to another . . . . . . . . . . . . . . . . . . . . 12 79 4.6.1. Functional Requirements . . . . . . . . . . . . . . . 12 80 4.6.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 12 81 4.7. Support operations on groups of data objects . . . . . . . 13 82 4.7.1. Functional Requirements . . . . . . . . . . . . . . . 13 83 4.7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 13 84 5. Operational Considerations . . . . . . . . . . . . . . . . . . 14 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 87 8. Informative References . . . . . . . . . . . . . . . . . . . . 16 88 Appendix A. Application scenarios . . . . . . . . . . . . . . . . 17 89 A.1. Archive service supporting long-term non-repudiation . . . 17 90 A.2. Pure long-term non-repudiation service . . . . . . . . . . 17 91 A.3. Long-term Archive Service as part of an internal 92 network . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 A.4. Long-term Archive External Service . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 95 Intellectual Property and Copyright Statements . . . . . . . . . . 19 97 1. Introduction 99 Digital data durability is undermined by continual progress and 100 change on a number of fronts. The useful lifetime of data may exceed 101 the life span of formats and mechanisms used to store the data. The 102 lifetime of digitally signed data may exceed the validity periods of 103 public-key certificates used to verify signatures or the 104 cryptanalysis period of the cryptographic algorithms used to generate 105 the signatures, i.e., the time after which an algorithm no longer 106 provides the intended security properties. Technical and operational 107 means are required to mitigate these issues. A solution must address 108 issues such as storage media lifetime, disaster planning, advances in 109 cryptanalysis or computational capabilities, changes in software 110 technology and legal issues. 112 A long-term archive service aids in the preservation of data over 113 long periods of time through a regimen of technical and procedural 114 mechanisms designed to support claims regarding a data object. For 115 example, it might periodically perform activities to preserve data 116 integrity and the non-repudiability of data existence by a particular 117 point in time or take actions to ensure the availability of data. 118 Examples of periodic activities include refreshing time stamps or 119 transferring data to a new storage medium. 121 A long-term archive service may be used to provide evidence that 122 supports validation of the existence of documents or assertions of 123 agreements that were originally asserted with digital signatures. 124 Validation may occur at times in the future well beyond the validity 125 period of the private key originally used to generate the signature, 126 or even beyond the time when the algorithms available for digital 127 signatures, message digesting or data encryption cease to offer 128 effective protection because of improvements in computing speeds and 129 methods. 131 A long-term archive service may be located within an enterprise 132 network, communicating with local storage mechanisms and other 133 applications, or a long-term archive service may be implemented as an 134 external service accessible via the Internet. A long-term archive 135 service may use functionality, e.g. time stamping, provided by 136 independent service providers. 138 A primary goal of a long-term archive service is to support the 139 credible assertion of a claim that is currently asserted, at points 140 well into the future. A long-term archive service may support a 141 range of applications, including: wills, land records, medical data, 142 criminal case files, personnel files and contracts. A long-term 143 archive service may be used by any type of entity, e.g. 144 organizations, citizens, notaries. Examples of long-term archive 145 service usage by submitters include: 147 - A company stores contracts using a third party service 149 - A hospital stores medical data using an internal service 151 - An individual wants to generate evidence of data possession at a 152 particular point in time, e.g. for intellectual property purposes 153 or endorsement of a contract 155 - A law enforcement officer wants to store criminal data such that 156 integrity of the data can be demonstrated years later 158 For each of the above examples, there is a corresponding example 159 involving retrievers, e.g. a company retrieves a contract in the case 160 of a dispute or a law enforcement officer prepares information for a 161 criminal trial. 163 This document addresses the technical requirements for a long-term 164 archive service. 166 2. Terminology 168 We define the following terms based on their usage in the archiving 169 community, in order to provide a vocabulary for describing 170 requirements and the standards around them. 172 Arbitrator: Principal for whom the validity of archived data 173 characteristics, e.g., origin, integrity or time of existence, 174 must be demonstrated. 176 Archival Period: The period during which an archived data object is 177 preserved by a long-term archive service. 179 Archived Data Object: Data unit to be preserved by a long-term 180 archive service. 182 Archive Package: Collection of information including archived data 183 objects and associated Evidence Record. 185 Cryptographic Maintenance Policy: A set of rules that defines how to 186 maintain the validity of digitally signed objects should one of 187 the hash or asymmetric algorithms used to create a digital 188 signature become weak or one of the private keys used to create a 189 digital signature be compromised or become weak. 191 Evidence: Information that may be used to demonstrate the validity 192 an archived data object or related attestations. 194 Evidence Record: Collection of evidence compiled for one or more 195 archived data objects. An Evidence Record may include 196 acknowledgements from a long-term archive service, time stamps and 197 verification data, such as public-key certificates, revocation 198 information, trust anchors, policy details and role information. 200 Long-Term Archive Policy: A set of rules that define operational 201 characteristics of a long-term archive service. 203 Long-Term Archive Service (LTA): A service that is responsible for 204 preserving data for long periods. 206 Modifier: Principal who modifies attributes associated with an 207 archived data object and/or Evidence Record held by a long-term 208 archive service. 210 Originator: Principal who produces, and possibly digitally signs, an 211 archived data object. The Originator does not necessarily have 212 any relationship with a long-term archive service or any awareness 213 of an Evidence Record associated with the archived data object. 215 Retriever: Principal who retrieves archived data objects and/or 216 Evidence Records from a long-term archive service. 218 Submitter: Principal who submits data objects for archiving. 220 Time Stamp: An attestation generated by a Time Stamping Authority 221 (TSA) that a data item existed at a certain time. For example, 222 [RFC3161] specifies a structure for signed time stamp tokens as 223 part of a protocol for communicating with a Time Stamping 224 Authority (TSA). 226 Time Stamping Authority (TSA): A trusted service that provides 227 attestations of existence of data at particular points in time. 228 For example, [RFC3161] defines protocol elements for interacting 229 with a TSA. 231 3. General Principles 233 A long-term archive service may accept any type of data for 234 preservation. The data might be in any format, whether textual data, 235 images, documents, applications, or compound packages of multiple 236 components. The data may be digitally signed, time stamped, 237 encrypted, or not subject to any cryptographic processing. 239 A long-term archive service may preserve archived data objects as 240 opaque collections of bytes with the primary aim of data integrity. 242 A long-term archive service is not required to operate upon evidence 243 related to the content of archived data objects. Content-focused 244 operations, including data format migration or translation, may be 245 performed by another service. However, an LTA may incorporate 246 support for such services. 248 Different long-term archive services may establish policies and 249 procedures for archiving data objects over different lengths of time. 250 For example, an LTA may refuse to preserve archived data objects for 251 periods longer than 30 years. Similarly, LTAs may establish policies 252 that limit the types of data that will be accepted for deposit by a 253 particular LTA. 255 A long-term archive service provides evidence that may be used to 256 demonstrate the existence of an archived data object at a given time 257 and the integrity of the archived data object since that time. 258 Additionally, the evidence identifies the LTA(s) that have 259 participated in the preservation of the archived data object. If the 260 archived data object itself contains digitally signed data, 261 authentication of the signer is also possible. 263 A long-term archive service may be an adjunct component of a document 264 management system. In such cases, the Evidence Record generated and 265 maintained by the LTA is a property of data that is otherwise managed 266 by the document management system. 268 4. Technical Requirements 270 This section describes the requirements for the protocol for 271 accessing a long-term archive system and for the data formats 272 associated with data preservation. 274 4.1. Enable submission, retrieval and deletion of archived data objects 276 4.1.1. Functional Requirements 278 A long-term archive service must permit clients to request the 279 following basic operations: 281 - submit data objects for archive 283 - retrieve archived data objects 285 - delete archived data objects 287 Following submission, the service must provide an identifier that can 288 be used to retrieve the archived data and/or associated evidence. 289 For example, it may be possible to retrieve archive packages by using 290 a hash value of an archived data object. Possession of this value is 291 not necessarily an authorization to access the associated archived 292 data object or evidence record. 294 It must be possible to authenticate requests and responses, e.g. to 295 enable LTAs to render an authorization decision. This may be 296 accomplished using transport security mechanisms. Requests, in 297 particular retrieval or deletion requests, may be rejected if the 298 requestor is not authorized. An authorization policy must be defined 299 and observed by the long-term archive service. An LTA may disallow 300 deletion as a matter of policy. 302 The format for the acknowledgements must allow the identification of 303 the archiving provider and the participating client. 305 The LTA must provide an acknowledgement of deposit that permits the 306 submitter to confirm the correct data was accepted by the LTA. This 307 proof need not be provided immediately. 309 4.1.2. Rationale 311 Submission, retrieval, query state and deletion of archived data 312 objects are necessary basic functions of a long-term archive service. 314 Deletion may be disallowed due to procedural difficulties in 315 fulfilling the request. For example, an archived data object may be 316 stored on write-once media along with other records that are not 317 subject to deletion. 319 Acknowledgements may not be provided immediately due to 320 implementation of a grace period. A generic query state mechanism 321 should be provided to address such situations. For example, a 322 submission response may indicate that a submission has been accepted 323 and a subsequent query state response may indicate a submission has 324 completed all necessary preservation steps. 326 4.2. Operate in accordance with a long-term archive policy 328 4.2.1. Functional Requirements 330 A long-term archive service must operate in accordance with a long- 331 term archive service policy that defines characteristics of the 332 implementation of the long-term archive service. A long-term archive 333 service policy contains several components, including: 335 - Archived data object maintenance policy 337 - Authorization policy 339 - Service policy 341 A long-term archive service policy must include specifications of the 342 preservation activities performed for archived data objects subject 343 to the policy. A maintenance policy should define rules for the 344 following operational aspects: preservation activity triggers, 345 default archival period, default handling upon expiration of archival 346 period. 348 Maintenance policies should include mechanism-specific details 349 describing LTA operation. For example, where cryptographic 350 mechanisms are employed, a cryptographic maintenance policy ought to 351 be defined. 353 An authorization policy should define the entities permitted to 354 exercise services provided by the LTA, including who is permitted to 355 submit, retrieve or manage specific archived data objects. 357 A service policy defines the types of services provided by an LTA, 358 including acceptable data types, description of requests that may be 359 accepted and deletion procedures. 361 Policies must be unambiguously identified, e.g., by an object 362 identifier. Alternatively, an LTA may support a protocol that 363 permits clients to specify policy parameters explicitly instead of by 364 reference to a policy. 366 A long-term archive service must be able to provide information 367 identifying the policies relevant for a given archived data object. 369 4.2.2. Rationale 371 Similar to a certificate policies [RFC3647], which are identified 372 using object identifiers, a long-term archive policy provides a 373 shorthand means of technically identifying a set of rules that govern 374 operation of a long-term archive service. 376 Over the course of many years, the policies under which an LTA 377 operates may undergo modification. Thus, an evidence record may 378 feature multiple indications of policies active at various points 379 during the life of an archived data object. 381 4.3. Enable management of archived data objects 383 4.3.1. Functional Requirements 385 A long-term archive service must permit clients to request the 386 following basic operations: 388 - specify an archival period for submitted data objects 390 - extend or shorten the archival period for an archived data 391 object 393 - specify metadata associated with an archived data object 395 - specify an archive policy under which the submitted data should 396 be handled 398 It should be possible to express an archival period in terms of time, 399 an event or a combination of time and event. 401 Submitters should be able to specify metadata that, for example, can 402 be used to enable retrievers to render the data correctly, to locate 403 data in an archive or to place data in a particular context. 404 Examples include, classification codes, type of format, contributors, 405 title, author, date. Alternatively, such information may be included 406 in the content of an archived data object. 408 If a long-term archive service does not support a requested policy, 409 it must return an error indication. A service must provide an 410 indication of the archive policy enforced by the service. 412 4.3.2. Rationale 414 Submission, retrieval and deletion of archived data objects are 415 necessary basic functions of a long-term archive service. 416 Specification and management of the archival period is necessary to 417 avoid unnecessary preservation activities. 419 4.4. Provide evidence records that support demonstration of data 420 integrity 422 4.4.1. Functional Requirements 424 A long-term archive service must be capable of providing evidence 425 that can be used to demonstrate the integrity of data for which it is 426 responsible from the time it received the data until the expiration 427 of the archival period of the data. 429 This may be achieved by providing evidence records that support the 430 long-term non-repudiation of data existence at a point in time, e.g. 431 in the case of legal disputes. The evidence record should contain 432 sufficient information to enable the validity of an archived data 433 object's characteristics to be demonstrated to an arbitrator. The 434 characteristics subject to verification will vary. For example, 435 authentication of an originator may not be possible in all cases, 436 e.g., where the object submitted to the archive is not signed or 437 where the object does not include the necessary information to 438 authenticate the object's signer. 440 Evidence records must be structured such that modifications to an 441 archived data object or its evidence record can be detected, 442 including modifications made by administrators of an LTA. 444 4.4.2. Rationale 446 Supporting non-repudiation of data existence, integrity and origin is 447 a primary purpose of a long-term archive service. Evidence may be 448 generated, or otherwise obtained, by the service providing the 449 evidence to a retriever. A long-term archive service need not be 450 capable of providing all evidence necessary to produce a non- 451 repudiation proof and in some cases should not be trusted to provide 452 all necessary information. For example, trust anchors [RFC3280] and 453 algorithm security policies should be provided by other services. An 454 LTA that is trusted to provide trust anchors could forge an evidence 455 record verified by using those trust anchors. 457 Demonstration that data has not been altered while in the care of a 458 long-term archive service is a first step towards supporting non- 459 repudiation of data. Certification services support cases in which 460 data must be modified, e.g. translation or format migration. An LTA 461 may provide certification services. 463 4.5. Support data confidentiality 465 4.5.1. Functional Requirements 467 A long-term archive service must provide means to ensure 468 confidentiality of archived data objects, including confidentiality 469 between the submitter and the long-term archive service. An LTA must 470 provide a means for accepting encrypted data such that future 471 preservation activities apply to the original, unencrypted data. 472 Encryption or other methods of providing confidentiality must not 473 pose a risk to the associated evidence record. 475 A long-term archive service should maintain contact information for 476 the parties responsible for each archived data object so warning 477 messages can be sent when encryption algorithms require maintenance. 479 4.5.2. Rationale 481 Individuals may wish to use the services of a commercial long-term 482 service without disclosing data to the commercial service. However, 483 access to the original data may be necessary to perform some 484 preservation activities. 486 4.6. Provide means to transfer data and evidence from one service to 487 another 489 4.6.1. Functional Requirements 491 It must be possible to submit data along with previously generated 492 evidence, i.e. to support transfer of data from one archive to 493 another. A long-term archive service must support the transfer of 494 archived data objects, evidence and evidence records from one service 495 to another. It must be possible for evidence records to span 496 multiple providers over the course of time without losing value as 497 evidence. 499 4.6.2. Rationale 501 Before the end of an archived data object's archival period, a long- 502 term archive service may cease operation. In such cases, it must be 503 possible for the archived data object (and any associated evidence) 504 to be transferred to another service that will continue preservation 505 of the data until the end of the archival period. 507 Submitters may change service providers before the end of an archived 508 data object's archival period. In such cases, it must be possible 509 for the submitter to transfer an archived data object and all 510 associated evidence from the original LTA to a new LTA. 512 4.7. Support operations on groups of data objects 514 4.7.1. Functional Requirements 516 An LTA should support submission of groups of data objects. 517 Submitters should be able to indicate which data objects belong 518 together, i.e. comprise a group, and retrievers should be able to 519 retrieve one, some or all members of a group of data objects. 521 It should be possible to provide evidence for groups of archived data 522 objects. For example, it should be possible to archive a document 523 file and a signature file together such that they are covered by the 524 same evidence record. 526 Where an LTA operates upon groups of data objects, non-repudiation 527 proof must still be available for each archived data object 528 separately. 530 4.7.2. Rationale 532 In many cases data objects belong together. Examples include: 534 - a document file and an associated signature file, which are two 535 separate objects 537 - TIF-files representing pages of a document 539 - a document file and an evidence file (possibly generated by 540 another LTA) 542 - a document and its translation to another format or language 544 In these cases, it is to the best advantage to handle these data 545 objects as a group. 547 5. Operational Considerations 549 A long-term archive service must be able to work efficiently even for 550 large amounts of archived data objects. In order to limit expenses 551 and to achieve high performance, it may be desirable to minimize the 552 use of trusted third parties, e.g. LTA operations should be designed 553 to limit the number of time stamps required to provide the desired 554 level of service. 556 Necessity to access archived data objects should be minimized. It 557 may only be necessary to access the archived data objects if the 558 archived data objects are requested by users or if hash algorithms 559 used for indexing or evidence record generation become insecure. 561 An LTA must be capable of operating in accordance with any applicable 562 legal regime. For example, an LTA may be required to reject a 563 deletion request from an authorized requestor if the target of the 564 request has been subpoenaed by law enforcement authorities. 566 Some applications may require processing of a chain of archive 567 policies present in an evidence record, e.g. to ensure that 568 compatible policies were used throughout the lifetime of an archived 569 data objects. 571 6. Security Considerations 573 Data is the principal asset protected by a long-term archive service. 574 The principle threat that must be addressed by a long-term archive 575 service is undetected loss of data integrity. 577 In cases where signature verification relies on a PKI, certificate 578 revocation could retroactively invalidate previously verified 579 signatures. An LTA may implement measures to support such claims by 580 an alleged signer, e.g. collection of revocation information after a 581 grace period during which compromise can be reported or preservation 582 of subsequent revocation information. 584 When selecting access control mechanisms associated with data stored 585 by a LTA, the lifespan of the archived data object should be 586 considered. For example, the credentials of an entity that submitted 587 data to an archive may not be available or valid when the data needs 588 to be retrieved. 590 During lifespan of an archived data object, formats may cease to be 591 supported. Software components to process data, including content or 592 signatures, may no longer be available. This could be a problem 593 particularly if non-standard formats are used or proprietary 594 processing is employed. The submitter should take care to avoid such 595 problems. For example, the submitter (or other authorized entity) 596 could periodically retrieve data, convert the data and re-submit it 597 in new format. Additional mechanisms, applications or tools may be 598 needed to preserve the value of evidence records associated with 599 original archived data object. 601 A long-term archive system may require correlation of different 602 identities that represent the same entity at different points in 603 time. For example, an individual's identity may be represented by 604 different employers at different points in time. 606 A long-term archive system must perform maintenance activities on a 607 schedule that considers factors such as the strength of relevant 608 cryptographic algorithms, lifespan of relevant certification 609 authorities, and revocation status of relevant entities, e.g., 610 timestamp authorities. Standards for use of cryptographic algorithms 611 are expected to be established by organization or governmental 612 bodies, not by individual LTAs. 614 7. Acknowledgements 616 Thanks to members of the LTANS mailing list for review of earlier 617 drafts and many suggestions. In particular, thanks to Larry 618 Masinter, Denis Pinkas and Peter Sylvester for review and 619 suggestions. 621 8. Informative References 623 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 624 "Internet X.509 Public Key Infrastructure Time-Stamp 625 Protocol (TSP)", RFC 3161, August 2001. 627 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 628 X.509 Public Key Infrastructure Certificate and 629 Certificate Revocation List (CRL) Profile", RFC 3280, 630 April 2002. 632 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 633 Wu, "Internet X.509 Public Key Infrastructure Certificate 634 Policy and Certification Practices Framework", RFC 3647, 635 November 2003. 637 Appendix A. Application scenarios 639 Below are several example application scenarios demonstrating one or 640 more of the basic service features mentioned above. 642 A.1. Archive service supporting long-term non-repudiation 644 A long-term archive service may store data objects, such as signed or 645 unsigned documents, for authenticated users. It may generate time 646 stamps for these data objects and obtain verification data during the 647 archival period or until a deletion request is received from an 648 authorized entity. 650 A.2. Pure long-term non-repudiation service 652 A long-term archive service may only guarantee non-repudiation of 653 existence of data by periodically generating time stamps and 654 obtaining verification data. It stores data objects (e.g. documents 655 and signatures) locally only for the purpose of non-repudiation and 656 does not function as a document archive for users. It does not 657 support retrieval and deletion of data objects. 659 A.3. Long-term Archive Service as part of an internal network 661 A long-term archive service may be part of an enterprise network. 662 The network provider and archive service may be part of the same 663 institution. In this case, the service should obtain non-repudiation 664 evidence from a third party. An internally generated acknowledgement 665 may be viewed worthless. 667 A.4. Long-term Archive External Service 669 A long-term archive service may be provided over the Internet for 670 enterprises or consumers. In this case, archiving and providing 671 evidence (via time stamps or other means) may be adduced by one 672 organization and its own technical infrastructure without using 673 external services. 675 Authors' Addresses 677 Carl Wallace 678 Cygnacom Solutions 679 Suite 5200 680 7925 Jones Branch Drive 681 McLean, VA 22102 683 Fax: +1(703)848-0960 684 Email: cwallace@cygnacom.com 686 Ulrich Pordesch 687 Fraunhofer Gesellschaft 688 Dolivostrasse 15 689 Darmstadt, Germany D-64293 691 Email: ulrich.pordesch@zv.fraunhofer.de 693 Ralf Brandner 694 InterComponentWare AG 695 Otto-Hahn-Strabe 3 696 Walldorf, Germany 69190 698 Email: ralf.brandner@intercomponentware.com 700 Intellectual Property Statement 702 The IETF takes no position regarding the validity or scope of any 703 Intellectual Property Rights or other rights that might be claimed to 704 pertain to the implementation or use of the technology described in 705 this document or the extent to which any license under such rights 706 might or might not be available; nor does it represent that it has 707 made any independent effort to identify any such rights. Information 708 on the procedures with respect to rights in RFC documents can be 709 found in BCP 78 and BCP 79. 711 Copies of IPR disclosures made to the IETF Secretariat and any 712 assurances of licenses to be made available, or the result of an 713 attempt made to obtain a general license or permission for the use of 714 such proprietary rights by implementers or users of this 715 specification can be obtained from the IETF on-line IPR repository at 716 http://www.ietf.org/ipr. 718 The IETF invites any interested party to bring to its attention any 719 copyrights, patents or patent applications, or other proprietary 720 rights that may cover technology that may be required to implement 721 this standard. Please address the information to the IETF at 722 ietf-ipr@ietf.org. 724 Disclaimer of Validity 726 This document and the information contained herein are provided on an 727 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 728 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 729 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 730 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 731 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 732 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 734 Copyright Statement 736 Copyright (C) The Internet Society (2006). This document is subject 737 to the rights, licenses and restrictions contained in BCP 78, and 738 except as set forth therein, the authors retain all their rights. 740 Acknowledgment 742 Funding for the RFC Editor function is currently provided by the 743 Internet Society.