idnits 2.17.1 draft-ietf-ltans-notareqs-03.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 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 501. ** 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 (December 20, 2005) is 6701 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) == Unused Reference: '1' is defined on line 431, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 435, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 442, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ltans-reqs-03 == Outdated reference: A later version (-15) exists of draft-ietf-ltans-ers-02 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Schmidt 3 Internet-Draft Fraunhofer SIT 4 Expires: June 23, 2006 T. Gondrom 5 Open Text Corporation 6 L. Masinter 7 Adobe Systems 8 December 20, 2005 10 Requirements for Data Validation and Certification Services 11 draft-ietf-ltans-notareqs-03.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 June 23, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document establishes the goals and requirements for protocols 45 and data structures for use with services that provide additional 46 means for users to ensure and prove the validity of data, especially 47 digitally signed data, in a common and reproducible way. The data 48 being validated may correspond to assertions about real-world facts 49 or events. This document establishes the need for components to be 50 used in addition to or in conjunction with long-term archive 51 services. It provides some use cases and scenarios, and establishes 52 technical requirements for protocols and data structures to support 53 them. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. General Requirements . . . . . . . . . . . . . . . . . . . . . 3 59 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Specific workflows . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Record transactions . . . . . . . . . . . . . . . . . . . 5 62 4.2. Archiving signed document . . . . . . . . . . . . . . . . 6 63 5. Technical Requirements . . . . . . . . . . . . . . . . . . . . 7 64 5.1. Representations for Assertions . . . . . . . . . . . . . . 7 65 5.2. Protocols for interaction . . . . . . . . . . . . . . . . 8 66 5.3. Logging of proceedings . . . . . . . . . . . . . . . . . . 8 67 5.4. Long-term archives of records . . . . . . . . . . . . . . 9 68 5.5. Validation of Digital Signatures and X.509 certificates . 9 69 6. Operational Considerations . . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 72 9. Informative References . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 74 Intellectual Property and Copyright Statements . . . . . . . . . . 12 76 1. Introduction 78 In many scenarios, users need to be able to ensure and prove the 79 existance and validity of documents and data, including digitally 80 signed data, in a common and reproducible way, over a long period of 81 time. A long-term archive service [3] may provide assurances about 82 the integrity of data and past validity of digital signatures. 83 However, additional mechanisms are required, in real workflows, to 84 provide the technical means to satisfy user requirements. In many 85 circumstances, the documents or data being validated or signed 86 corresponds to assertions about real-world facts or events; for 87 example, a contract or a business record. 89 Usually, the scenarios for long-term validation involve a trusted 90 third party who is willing, over a period of time, to accept data and 91 validate it, or to witness events; the trusted third party offers to 92 subsequently make assertions about those events or data. In many 93 legal jurisdictions, a 'notary' is a person with credentials 94 recognized by that jurisdiction to perform these services, in a way 95 that gives their certification a special legal standing. Indeed, 96 some types of transactions may require an official certification by 97 someone with specific notary credentials. 99 This document establishes the goals and requirements for protocols 100 and data structures for use with services that provide additional 101 means for users to ensure and prove the validity of data, especially 102 digitally signed data, in a common and reproducible way. It provides 103 some use cases and scenarios, and establishes technical requirements 104 for protocols and data structures to support them. 106 2. General Requirements 108 It is desirable that the protocols and data structures established be 109 usable by an official notary to provide appropriate assertions for 110 electronic documents. Of course, nothing in a technical document can 111 provide for legal standing of any such assertions. 113 Requirements for data certification services may vary widely across 114 different processes and jurisdictions. For this reason, the 115 technical standards for data certification should provide a common 116 base of mechanisms, useful across jurisdictions and work processes, 117 and the means for extending these to support particular additional 118 workflows. 120 Mitigating human error is a prime motivation to look for standardized 121 methods which lend themselves to automation. In particular in 122 complex scenarios the use of certification services can increase 123 trust in and the probative force of certified documents. 125 3. Use cases 127 This section gives some examples workflows where data certification 128 services and assertions by trusted third parties might be used, as a 129 way of motivating the subsequent requirements. 130 record transactions: In the case of an agreement between two (or 131 more) parties, a trusted third party records the transaction, and 132 the fact that all of the parties agreed to the final documents and 133 that all of the necessary information has been provided to all of 134 the involved parties. The trusted third party acts as a witness 135 to the agreement at the time it is made, and, at a later date, may 136 be called upon to attest to the validity of the agreement. This 137 kind of service might be used for a contract between individuals, 138 e.g., a private transfer of ownership of private property, or a 139 public transfer of ownership of land. 140 negotiation support: In some cases, a trusted third party is used 141 during the negotiation of a complex agreement in order to support 142 the mechanisms of coming to the agreement. For example, a trusted 143 third party might gather and store the documents during the course 144 of a negotiation, making it impossible for any party to delete the 145 document or repudiate a partial agreement; there might be time 146 deadlines established for submitting information or approvals, or 147 information may be held back from release until a particular time. 148 For example, this kind of service might be used for the awarding 149 of public contracts based on private bids. 150 certification of copies and conversions: In many cases, a trusted 151 third party or service is used to certify the validity of a 152 transformation or translation of a document from one form to 153 another. Classically, a notary might attest to the validity of a 154 paper copy of a document. The ability to attest to the validity 155 of a wide variety of transformations are important, including the 156 transformation of documents from one electronic format to another, 157 or possibly the validity of conversion between paper and 158 electronic forms. The third party should be able to attest that 159 one document contains the same information as another and the 160 validity of all contained digital signatures and the identity of 161 the signers. 162 record events: In this case, a trusted third party or service is 163 used to document and later provide proof that a certain event has 164 happened. Initially, the service identifies the involved entities 165 and verifies that all necessary preconditions are met. After 166 this, an event or ceremony is held; during the event, the service 167 ensures that all entities understood and received all appropriate 168 information about the event and its consequences. After the 169 event, a record of the event is issued to all of the entities; 170 additional copies are retained for later documentation. 171 administering of oaths: In some cases, the event being recorded is 172 the performance, by an individual, of a particular agreement or 173 'oath'. The trusted third party is used to document and later 174 provide proof that an individual has made a particular statement 175 or agreement, in a specified ceremony or event. 176 evidence management: Transactions between parties over the Internet 177 may have records of those transactions. In general, it is 178 desirable to have services which accept, verify, record, and later 179 provide evidence of those records. In many cases, this may 180 involve creating a certified archive of detailed and signed logs. 182 4. Specific workflows 184 This sections describes some concrete scenarios based on the use 185 cases introduced in the previous section. 187 4.1. Record transactions 189 The following example will show the additional benefits of a 190 certification service in the case of private transactions. We start 191 with a basic protocol that achieves, upon completion, a state of 192 mutual non-repudiation between two parties, A and B. Suppose, A wants 193 to offer an electronic contract (contract_A) to B, where "contract_A" 194 means that A has digitally signed the contract with her private key. 195 This is sent as an offer to B: 196 contract_A -> B 198 B, after receiving and accepting contract_A, counter-signs the 199 contract and sends it back to A as an acceptance of A's offer: 200 (contract_A)_B -> A 202 Now, A has to confirm reception of the acceptance. He signs 203 (contract_A)_B and sends it back to B: 204 ((contract_A)_B)_A -> B 206 After that, both parties have a document with at least two 207 signatures, and neither party can succeed in repudiating the validity 208 of the contract. 210 Now let's see what happens when we put a certification service N as a 211 trusted third party between A and B. When B gets the contract from A 212 and accepts it, he signs the contract and sends it to N: 213 (contract_A)_B -> N 215 The certification service confirms receipt of the contract with a 216 signature and sends it to both A and B: 218 ((contract_A)_B)_N -> A, B 220 After that, both parties have a document signed by A, B, and N. Since 221 N is trusted, A and B can be sure that the other party has a contract 222 which is signed by both. We have the same level of trust as in the 223 scenario without the certification service. However, an additional 224 benefit of using a certification service in this case can be the 225 archiving of the contract, as may be required by the law for certain 226 types of contracts. 228 In order to allow for N to provide documentation that all necessary 229 information has been provided to both parties, the scenario can be 230 extended as follows: 232 When A and B get the confirmation ((contract_A)_B)_N from N, both A 233 and B send an acknowledgement to N: 234 ack_A -> N ack_B -> N 236 After N received the two acknowledgements he sends a notification to 237 both A and B that confirms that the transaction is completed: 238 not_N -> A, B 240 For both ack_A/B and not_N it suffices to contain (sufficiently 241 secure) hash values of the pertaining original documents, and the 242 same is true for the third message sent from N in the protocol above, 243 but not for the second one, if the contract is to be archived by N. 245 The utility of certification services in these generic scenarios is 246 twofold: They can accomplish the fulfillment of technical 247 requirements, e.g., archiving of transaction records, which may in 248 turn be entailed by legal requirements. And they can be instrumental 249 in the fulfillment of genuine legal requirements, like documentation 250 that all necessary information has been provided to all involved 251 parties. 253 4.2. Archiving signed document 255 A signed document enters an archive. Initially, the signature is 256 validated (there is not much point to archive a document with invalid 257 signatures, although such scenarios are also possible). We need is a 258 fixation in time that signature (and document) existed at some point 259 in time (the archiving time). Providing evidence for a document is 260 not a problem; a signature there are some sequence issues. 262 Preserving signatures is based on reference information and evidence 263 record. Let's start with T1, when a CRL has been issued and the next 264 time the CRL is issued is marked with T5. Now we need to collect 265 some reference information (certificates, CRLs, etc.), validate the 266 signature and pack everything together before creating the evidence 267 record (timestamp). At time T2 a timestamp is requested for 268 collected data following by timestamp issued at T3. Until T5 we have 269 enough time to revoke the certificate related to digital signature 270 archived, which happens at T4 and we can end up with archived invalid 271 signature, although it was submitted to the archive before revocation 272 happened. 274 The problem with CRLs is that they might not be synchronized with 275 revocation mechanisms and there is no real information whether a 276 signature is valid or not at specific point in time. In theory CRLs 277 should be issued immediately after a certificate is revoked, but in 278 practice things are not the same, since the procedure itself already 279 has some timeframe (the ideal solution is to stop the time during the 280 validation process). 282 Now, there are options to use more than one evidence record for a 283 single data (signature) but such procedures might get overall concept 284 very complicated and bulky, especially when performing procedures 285 over groups of data. 287 The archive package should contain the CRL used to verify the 288 transaction. That coupled with other times will show when the 289 transaction was received and processed. 291 When speed is of not essence, the relying party can always wait for a 292 CRL issued after the transaction was received to verify. This will 293 ensure that the certificate was not revoked in the interim. Relying 294 party can use the later CRL for archiving the transaction. 296 An evidence record is relative to a single time T1, e.g. the time of 297 submission to the archive. Retroactive revocation would need to be 298 considered before committing the data to an archive and initiating an 299 evidence record. Even if a CRL were issued immediately when a cert 300 was revoked, it's revocation time might be before T1. It is unlikely 301 that retroactive revocation applied after several periodic refresh 302 operations (which should be relatively infrequent) at time T4 should 303 invalidate a signature generated at, or before, time T1. 305 5. Technical Requirements 307 This section describes some of technical requirements associated with 308 certification services 310 5.1. Representations for Assertions 312 The primary technical requirement is for a data structure that can 313 represent the assertion, by the certification service, that a 314 particular service has been performed. The data structure should 315 include the identity (as known) of the participants, the credentials 316 of the certification service and its operator, the date and time that 317 the service was performed, and other information relevant to the 318 acknowledgement of the service. 320 The data structure should be signed by the certification service to 321 authenticate the certified assertion. Additionally, the identity, 322 role, and authorisation of the certifier can be of importance, e.g., 323 notary public, authorised translator, or public official. Attribute 324 certificates could be used in conjunction with object identifiers to 325 satisfy this requirement. The appropriate credentials are determined 326 by the use-case. 328 To fix the semantic connection to the application context, the 329 assertion of the service must qualify its meaning. That is, the 330 purpose of the certification is to be noted correctly, in accordance 331 with the intended use of the target documents and certifications. 332 Only this enables the verification of the correctness of operations 333 at later times. 335 To be specific, consider the case of general transformations 336 including format conversions, partial copies, and even authorized 337 translations. There, the assertion is that of a certain agreement of 338 contents between original and certified target data. The required 339 kind and degree of agreement must be made explicit. 341 5.2. Protocols for interaction 343 Secondarily, there should be protocols for requesting services, 344 monitoring the progress of the service, participating in services 345 that require contemporaneous participation, cancelling ongoing 346 services. 348 5.3. Logging of proceedings 350 The ability to re-trace the certified events is crucial to the trust 351 in certification services. To enable such forensic inspection of the 352 proceedings carried out, the certification service should keep a log 353 or protocol of them. This log, or an excerpt thereof, should be 354 included in the signed assertion. The integrity of the log must be 355 maintained during the operation of the service. The log should be 356 detailed and explicit enough to allow for the re-tracing of the 357 certified events independently of the certification service. 359 5.4. Long-term archives of records 361 Some services also require the certification service to maintain a 362 long-term archive of records of events that it has certified; the 363 users of a certification service may request operations that cause 364 archived certificates to be accessed, forwarded, or possibly even 365 deleted. 367 5.5. Validation of Digital Signatures and X.509 certificates 369 One way in which participants in a transaction, negotation, or event 370 conducted over the Internet signal their intentions is through the 371 use of digital signatures. Digital signatures may use X.509 372 certificates to assert the validity of the public key of a named 373 participant in the transaction. A validation service should be able 374 to represent the fact of its testing the validity of digital 375 signatures, including the non-revocation of X.509 certificates used 376 within those signatures, as part of validating a transaction. This 377 way it might provide proof that the signatures attached to a given 378 document had been verified at a given date (different from the 379 signature date.) The details of a verification policy used by the 380 certification service should be determined by the use case. 382 It should be noted that signer authentication of handwritten 383 signatures is hardly ever done in practice. For instance in the case 384 of contract notarization the problem is resolved by the physical 385 presence of the signers. 387 6. Operational Considerations 389 Data validation and certification services may have strong 390 performance and scalability requirements. A certification service 391 must be able to work efficiently even for large amounts of data 392 objects and requests. 394 In order to limit expenses and to achieve high performance, the 395 involvement of other trusted third parties should be minimized. 397 7. Security Considerations 399 Trust is the principal asset of a certification service. The 400 implementation of such a service must be very careful so that no data 401 integrity can be lost or manipulation of the system can be done. 403 The protocols and data structures described in this document are 404 primarily intended to be useful to increase the trustworthiness of 405 networked transactions. As such, their primary value is in 406 resistance to any imaginable security threats. 408 The nature of the threats for long-term services are signficantly 409 greater and more difficult to protect against. In particular, it is 410 necessary to design protocols and data structures so that even if 411 currently acceptable secure one-way hash algorithms and encryption 412 algorithms are compromised, either through advancements in analysis 413 of their algorithms or through increased computational power and 414 novel computing architectures, that the overall security of the 415 application can be protected. 417 In many cases personal and other data must be collected in the course 418 of operation of a certification service. Some times it is necessary 419 to keep permanent records of such data for later inspection. In any 420 such case, personal data should be disclosed only to authorised 421 persons or entities. Personal data should be encrypted wherever 422 possible during and after operation of the service. 424 8. Acknowledgements 426 Thanks to members of the LTANS mailing list for review of earlier 427 drafts and many suggestions. 429 9. Informative References 431 [1] Adams, C., Sylvester, P., Zolotarev, M., and R. Zuccherato, 432 "Internet X.509 Public Key Infrastructure Data Validation and 433 Certification Server Protocols", RFC 3029, February 2001. 435 [2] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet 436 X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", 437 RFC 3161, August 2001. 439 [3] Wallace, C., "Long-Term Archive Service Requirements", 440 draft-ietf-ltans-reqs-03 (work in progress), October 2004. 442 [4] Brandner, R., "Evidence Record Syntax (ERS)", 443 draft-ietf-ltans-ers-02 (work in progress), April 2005. 445 Authors' Addresses 447 Andreas U. Schmidt 448 Fraunhofer SIT 449 Rheinstrasse 75 450 Darmstadt 64295 451 Germany 453 Phone: +49 (6151) 869 60 227 454 Fax: +49 (6151) 869 704 455 Email: Andreas.U.Schmidt@sit.fraunhofer.de 456 URI: http://www.math.uni-frankfurt.de/~aschmidt 458 Tobias Gondrom 459 Open Text Corporation 460 Technopark 2 461 Werner-von-Siemens-Ring 20 462 Grasbrunn, Munich D-85630 463 Germany 465 Phone: +49 (0) 89 4629-1816 466 Fax: +49 (0) 89 4629-33-1816 467 Email: tobias.gondrom@opentext.com 469 Larry Masinter 470 Adobe Systems 471 345 Park Ave 472 San Jose, CA 95110 473 US 475 Phone: +1 408 536 3024 476 Email: LMM@acm.org 477 URI: http://larry.masinter.net 479 Intellectual Property Statement 481 The IETF takes no position regarding the validity or scope of any 482 Intellectual Property Rights or other rights that might be claimed to 483 pertain to the implementation or use of the technology described in 484 this document or the extent to which any license under such rights 485 might or might not be available; nor does it represent that it has 486 made any independent effort to identify any such rights. Information 487 on the procedures with respect to rights in RFC documents can be 488 found in BCP 78 and BCP 79. 490 Copies of IPR disclosures made to the IETF Secretariat and any 491 assurances of licenses to be made available, or the result of an 492 attempt made to obtain a general license or permission for the use of 493 such proprietary rights by implementers or users of this 494 specification can be obtained from the IETF on-line IPR repository at 495 http://www.ietf.org/ipr. 497 The IETF invites any interested party to bring to its attention any 498 copyrights, patents or patent applications, or other proprietary 499 rights that may cover technology that may be required to implement 500 this standard. Please address the information to the IETF at 501 ietf-ipr@ietf.org. 503 Disclaimer of Validity 505 This document and the information contained herein are provided on an 506 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 507 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 508 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 509 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 510 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 511 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 513 Copyright Statement 515 Copyright (C) The Internet Society (2005). This document is subject 516 to the rights, licenses and restrictions contained in BCP 78, and 517 except as set forth therein, the authors retain all their rights. 519 Acknowledgment 521 Funding for the RFC Editor function is currently provided by the 522 Internet Society.