idnits 2.17.1 draft-santoni-timestampeddata-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 1) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (April 19, 2009) is 5479 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 554 -- Looks like a reference, but probably isn't: '1' on line 555 -- Looks like a reference, but probably isn't: '2' on line 556 ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft A. Santoni 3 Intended status: Informational Actalis S.p.A. 4 Expires: October 2009 April 19, 2009 6 Syntax for binding documents with time stamps 8 draft-santoni-timestampeddata-06.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents in effect on the date of 38 publication of this document (http://trustee.ietf.org/license-info). 39 Please review these documents carefully, as they describe your rights 40 and restrictions with respect to this document. 42 This document may contain material from IETF Documents or IETF 43 Contributions published or made publicly available before November 44 10, 2008. The person(s) controlling the copyright in some of this 45 material may not have granted the IETF Trust the right to allow 46 modifications of such material outside the IETF Standards Process. 47 Without obtaining an adequate license from the person(s) controlling 48 the copyright in such materials, this document may not be modified 49 outside the IETF Standards Process, and derivative works of it may 50 not be created outside the IETF Standards Process, except to format 51 it for publication as an RFC or to translate it into languages other 52 than English. 54 Abstract 56 This document describes an envelope which can be used to bind a file 57 (not necessarily protected by means of cryptographic techniques) with 58 one or more time-stamp tokens obtained for that file, where "time- 59 stamp token" has the meaning defined in RFC 3161 or its successors. 60 Additional types of temporal evidence are also allowed. 62 The proposed envelope is based on the Cryptographic Message Syntax 63 as defined in RFC 3852. 65 Conventions used in this document 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [KWORDS]. 71 The terms "document" and "file" are used interchangeably. 73 Table of Contents 75 1. Introduction...................................................2 76 2. Syntax for TimeStampedData.....................................3 77 3. Compliance requirements........................................6 78 4. Recommended processing.........................................6 79 4.1. Generating a new TimeStampedData structure................6 80 4.2. Verifying an existing TimeStampedData structure...........7 81 4.3. Extending the validity of an existing TimeStampedData 82 structure......................................................8 83 5. Security Considerations........................................9 84 6. IANA Considerations............................................9 85 7. Normative references..........................................10 86 8. Informative references........................................10 87 9. Author's Address..............................................13 88 APPENDIX A: ASN.1 Module.........................................11 89 Acknowledgments..................................................13 91 1. Introduction 93 Time-stamping has become the standard technique for proving the 94 existence of a document before a certain point in time. Several 95 legislations around the world embrace the concept and provide for 96 time-stamping services, mainly for the purpose of extending the 97 validity of signed documents. However, while time-stamping enhances 98 digital signatures, its value does not depend on them. It can clearly 99 be useful to time-stamp a document even if this is not signed. And it 100 can also be useful, or even mandatory in some cases, to time-stamp a 101 signed document in its entirety, regardless of how many signatures it 102 contains. 104 When a time-stamp is related to a digital signature, there already 105 exists a way to keep the two pieces together: RFC 3161 describes how 106 one or more TimeStampTokens can be included in a SignerInfo structure 107 as unsigned attributes. On the other hand, there is no standard way 108 to keep together a time-stamped document, whether signed or not, and 109 the related time-stamps. 111 In such cases two approaches are typically being adopted: 113 o time-stamps are kept as separate files (keeping track of what 114 time-stamps belong to what documents is up to the user); 116 o an ad hoc solution is adopted for specific applications, like e.g. 117 a ZIP archive or a proprietary "envelope" of some kind. 119 Both solutions impede interoperability, the objective of this memo. 121 This document describes a simple syntax for binding one document 122 (actually, any kind of file) to the corresponding temporal evidence, 123 this latter being typically represented by one or more RFC 3161 124 TimeStampTokens. Additional types of temporal evidence, like e.g. an 125 RFC 4998 EvidenceRecord, are also supported via an "open" syntax. 126 However, for the sake of interoperability, the emphasis is given to 127 TimeStampTokens. 129 The proposed syntax is broadly based on the Cryptographic Message 130 Syntax (CMS) defined in RFC 3852 [CMS]. 132 2. Syntax for TimeStampedData 134 The proposed data structure is called TimeStampedData and it is based 135 on the ContentInfo envelope defined in [CMS]: 137 ContentInfo ::= SEQUENCE { 138 contentType ContentType, 139 content [0] EXPLICIT ANY DEFINED BY contentType } 141 ContentType ::= OBJECT IDENTIFIER 143 While CMS defines six content types (data, signed-data, enveloped- 144 data, digested-data, encrypted-data, and authenticated-data), this 145 memo defines an additional content type, timestamped-data, identified 146 by the following OID: 148 id-ct-timestampedData OBJECT IDENTIFIER ::= { 149 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 150 pkcs9(9) id-smime(16) id-ct(1) 31 } 152 This particular OID signals that the content field of the ContentInfo 153 has the following syntax: 155 TimeStampedData ::= SEQUENCE { 156 version INTEGER { v1(1) }, 157 dataUri IA5String OPTIONAL, 158 metaData MetaData OPTIONAL, 159 content OCTET STRING OPTIONAL, 160 temporalEvidence Evidence 161 } 163 MetaData ::= SEQUENCE { 164 hashProtected BOOLEAN, 165 fileName UTF8String OPTIONAL, 166 mediaType IA5String OPTIONAL, 167 otherMetaData Attributes OPTIONAL 168 } 170 Attributes ::= 171 SET SIZE(1..MAX) OF Attribute -- according to RFC 3852 173 Evidence ::= CHOICE { 174 tstEvidence [0] TimeStampTokenEvidence, -- see RFC 3161 175 ersEvidence [1] EvidenceRecord, -- see RFC 4998 176 otherEvidence [2] OtherEvidence 177 } 179 OtherEvidence ::= SEQUENCE { 180 oeType OBJECT IDENTIFIER, 181 oeValue ANY DEFINED BY oeType } 183 TimeStampTokenEvidence ::= 184 SEQUENCE SIZE(1..MAX) OF TimeStampAndCRL 186 TimeStampAndCRL ::= SEQUENCE { 187 timeStamp TimeStampToken, -- according to RFC 3161 188 crl CertificateList OPTIONAL -- according to RFC 5280 189 } 191 The version field contains the version number of the TimeStampedData 192 syntax. It SHALL be 1 for this version of the document. 194 The dataUri field contains a URI reference conforming to [URI]. When 195 the content field is absent, dataUri MUST be present and contain an 196 URI allowing to retrieve the document which was time-stamped (unless 197 the document is later moved). When the content field is present, this 198 field MAY also be present. 200 The metaData field contains metadata related to the document which 201 was time-stamped, if applicable. In particular: 203 The hashProtected field indicates whether the metadata have been 204 included in the computation of the digest within the first 205 TimeStampToken (see further on). This makes it possible to detect 206 a subsequent alteration of the metadata. 208 The fileName field contains the original filename of the document 209 which was time-stamped. 211 The mediaType field contains a media type/subtype and possible 212 parameters for the time-stamped document, according to [MIME]. 213 This information may help decide how to "open" or deal with the 214 time-stamped document. 216 The otherMetaData field contains further attributes of the time- 217 stamped document (like e.g. a description, claimed author, etc.), 218 where each attribute is specified by an object identifier and a 219 corresponding set of values, as described in [CMS]. When this 220 field is present, it MUST contain at least one Attribute. 222 Within the metaData field, if present, at least one of the fileName, 223 mediaType and otherMetaData subfields MUST be present. 225 The Attribute values within the otherMetaData field MUST be DER 226 encoded, even if the rest of the structure is BER encoded. 228 The content field, when present, carries the entire contents, in its 229 original format and encoding, of the document which was time-stamped. 230 This can actually be any kind of data like e.g. a text document, an 231 executable, a movie, a message, etc. The omission of the content 232 field makes it possible to bind the temporal evidence to external 233 data. In such a case, the temporal evidence is computed as though 234 the content field was present. 236 The temporalEvidence field carries the evidence that the time-stamped 237 document did exist before a certain point in time. Several types of 238 evidence are allowed, but compliant applications are only required to 239 support the RFC 3161 type, namely the tstEvidence choice. 241 The TimeStampTokenEvidence sequence MUST contain at least one element 242 of type TimeStampAndCRL. 244 The elements of the TimeStampTokenEvidence sequence MUST conform to 245 the following rule: 247 o if the metaData field is absent or the value of its hashProtected 248 field is FALSE, then the TimeStampToken within the first element 249 SHALL be computed over the value octets of the content field (if 250 this field is absent, use the octets retrieved via the dataUri 251 field); 253 o otherwise (the metaData field is present and the value of its 254 hashProtected field is TRUE), the TimeStampToken within the first 255 element SHALL be computed over the concatenation of the following 256 fields: 258 - the DER encoding of the metaData field; 260 - the value octets of the content field (if this field is 261 absent, use the octets retrieved via the dataUri field); 263 o the TimeStampToken within the second element SHALL be computed 264 over the first element; 266 o the TimeStampToken within each subsequent element SHALL be 267 computed over its preceding element in the sequence. 269 Within the TimeStampAndCRL construct, the optional crl field carries 270 a suitable CRL (Certificate Revocation List) demonstrating that the 271 certificate of the TSA that issued the TimeStampToken was not revoked 272 at the time when the subsequent element in the TimeStampTokenEvidence 273 sequence was added. See the Security Considerations section for 274 further discussion on this topic. 276 3. Compliance requirements 278 Compliant applications MUST support at least the RFC 3161-based type 279 of evidence (i.e. the tstEvidence CHOICE). 281 4. Recommended processing 283 This section is focused on the RFC 3161-based type of evidence. 284 Processing of the structure for other types of evidence would be done 285 in a similar manner. 287 4.1. Generating a new TimeStampedData structure 289 In this case, applications are supposed to behave like follows: 291 o populate the version field with the integer value v1(1); 293 o if a self-contained envelope is to be generated, always populate 294 the content field with the content of the file in its original 295 format and encoding; depending on the application, the dataUri 296 field may also be added; 298 o otherwise (a detached envelope is to be generated), always 299 populate the dataUri field with the URI of the time-stamped 300 document (e.g. http://foo.example.com/Contract12345.pdf); 301 using an absolute URI or a relative reference depends on the 302 application; 304 o if the metaData field is being added, decide on the value of its 305 hashProtected field; set its value to TRUE if the application 306 needs the remaining fields of the metaData construct to be hash- 307 protected as described in Section 2; otherwise set it to FALSE; 309 o if the metaData field is being added, optionally populate the 310 fileName field (e.g. "Contract12345.pdf"), the mediaType field 311 with a suitable media type/subtype and possible parameters 312 according to [MIME], and the otherMetaData field, depending on the 313 application; 315 o select a suitable one-way hash function and compute a hash value 316 using that function over the content, or the concatenation of the 317 meta data and the content, as described in Section 2; this hash 318 value will then be used for requesting the first TimeStampToken; 320 o obtain the first temporal evidence from a TSA and add it to the 321 temporalEvidence field; 323 o insert the TimeStampedData into a ContentInfo structure, with the 324 id-ct-timestampedData OID in the contentType field; 326 o BER-encode the ContentInfo structure (except for the fields which 327 are required to be DER encoded) and save it with a reasonable file 328 name (e.g. derived from the name of the time-stamped file). 330 4.2. Verifying an existing TimeStampedData structure 332 In this case, applications are supposed to behave like follows: 334 o check that the contentType field of the ContentInfo structure 335 has the expected value (id-ct-timestampedData) in its contentType 336 field; then, extract the inner TimeStampedData structure and 337 continue processing; 339 o check the version field (it should be v1); 341 o check that the temporalEvidence field is not empty; 343 o check if the content is present; if it is not, use the dataUri 344 field to retrieve the file; 346 o open the first element of the TimeStampTokenEvidence sequence, 347 open the time-stamp token within it and use the hash function 348 which was used to obtain it to re-compute the hash of the fields 349 indicated in Section 2; if the re-computed hash value matches the 350 one within the time-stamp token, continue processing; otherwise, 351 the TimeStampedData structure has been modified; 353 o validate the temporalEvidence by checking that: 355 - each TimeStampToken in the chain does contain the correct 356 digest value (according to the rule described in Section 2) and 357 it was signed by a trusted TSA, 359 - the corresponding TSA signing certificate was not revoked at 360 the time when the subsequent TimeStampToken has been issued, 361 based on the associated CRL; 363 o depending on the application, use the temporal evidence for 364 whatever purpose the application was designed for; 366 o depending on the application, show the dataUri, the fileName, 367 the mediaType, the otherMetaData, and the temporal evidence 368 to the user; 370 o depending on the application, save the content to a separate file; 372 o depending on the application, store at a different place the 373 content which has been retrieved using the dataUri field, then 374 update the dataUri field accordingly; 376 o depending on the application, show the time-stamped file to the 377 user, possibly by activating a suitable "viewer". 379 4.3. Extending the validity of an existing TimeStampedData structure 381 In this case, applications are supposed to behave like follows: 383 o validate the TimeStampedData structure as described above; 385 o select the time-stamp token from the last TimeStampAndCRL element 386 in the chain and obtain the latest available CRL for the 387 corresponding TSA certificate (if this CRL is not fresh enough, 388 wait until the next one is available), then store it in the 389 TimeStampAndCRL element; 391 o instantiate a new TimeStampAndCRL element and obtain a new time- 392 stamp token computed over the previous one, according to the rule 393 described in Section 2; insert the new time-stamp token into the 394 new TimeStampAndCRL element, then append this latter to the end of 395 the chain. 397 See the "Security Considerations" section for further discussion on 398 extending the validity of an existing TimeStampedData structure. 400 5. Security Considerations 402 When the metaData field is present and the hashProtected sub-field 403 is set to TRUE, the metadata are also included in the computation of 404 the digest within the first time-stamp token, so that any subsequent 405 alteration of the metadata will be easily detected. However, the 406 integrity of hash-protected metadata does not imply that the metadata 407 were correct at the time when the TimeStampedData object was created. 408 That can only be inferred by other means (e.g. from context). For 409 instance, when TimeStampedData objects are created by an archival 410 service provider, it may be reasonable to assume that the metadata 411 are correct at creation time. Instead, when a TimeStampedData object 412 is received from an unknown party, the recipient cannot safely assume 413 that the metadata are correct, lacking further information. 415 In general, a time-stamp token should not be considered valid after 416 the certificate of the issuing TSA is expired (also depending on the 417 legislation and the policy under which the TSA operates). However, a 418 time-stamp token can itself be time-stamped to extend the validity of 419 the TSA's signature. By repeatedly applying this technique, a whole 420 chain of time-stamp tokens can be grown to extend the validity of the 421 first one ad libitum. This approach can thus be adopted to extend the 422 validity of a TimeStampedData structure beyond the expiry date of the 423 first TimeStampToken within it, by adding further elements to the 424 TimeStampTokenEvidence sequence according to the rule described in 425 Section 2. Of course, each additional TimeStampToken must be added in 426 a timely manner (before the previous one is expired or has been 427 revoked). 429 The validity extension technique described above requires that the 430 TSA signing certificates can still be verified long after they have 431 expired, tipically by checking a CRL. This latter must be captured at 432 the suitable time, because expired certificates are tipically removed 433 from the CRL regardless of their being revoked. The TimeStampAndCRL 434 construct allows adding a CRL next to the related TimeStampToken, so 435 that the TSA certificate will still be verifiable at any later time. 436 The CRL must be captured at the time when another element is about 437 to be added to the TimeStampTokenEvidence sequence, or even later -- 438 to allow for a last-minute revocation request to be processed by the 439 CA (see the discussion about "grace periods" in [CADES]). 441 6. IANA Considerations 443 None. 445 7. Normative references 447 [KWORDS] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, March 1997. 449 http://www.ietf.org/rfc/rfc2119.txt 451 [TSP] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato, 452 "Internet X.509 Public Key Infrastructure Time-Stamp 453 Protocol (TSP)", RFC 3161, August 2001. 454 http://www.ietf.org/rfc/rfc3161.txt 456 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 457 RFC 3852, July 2004. 458 http://www.ietf.org/rfc/rfc3852.txt 460 [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail 461 Extensions (MIME) Part One: Format of Internet Message 462 Bodies", RFC 2045, November 1996. 463 http://www.ietf.org/rfc/rfc2045.txt 465 [ERS] Gondrom, T., Brandner, R., and Pordesch, U., "Evidence 466 Record Syntax (ERS)", RFC 4998, August 2007. 467 http://www.ietf.org/rfc/rfc4998.txt 469 [PKIX1] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 470 Housley, R., and W. Polk, "Internet X.509 Public Key 471 Infrastructure Certificate and Certificate Revocation List 472 (CRL) Profile", RFC 5280, May 2008. 473 http://www.ietf.org/rfc/rfc5280.txt 475 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, 476 "Uniform Resource Identifier (URI): Generic Syntax", 477 STD 66, RFC 3986, January 2005. 478 http://www.ietf.org/rfc/rfc3986.txt 480 8. Informative references 482 [CADES] Pinkas, D., Pope, N., and J. Ross, "CMS Advanced Electronic 483 Signatures (CAdES)", RFC 5126, February 2008. 484 http://www.ietf.org/rfc/rfc5126.txt 486 APPENDIX A: ASN.1 Module 488 The ASN.1 module contained in this appendix defines the structures 489 that are needed to implement this specification. It is expected to be 490 used in conjunction with the ASN.1 modules in [CMS], [TSP], [PKIX1], 491 and [ERS]. 493 TimeStampedDataModule 494 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 495 pkcs-9(9) smime(16) modules(0) 35 } 497 DEFINITIONS IMPLICIT TAGS ::= 498 BEGIN 500 IMPORTS 502 -- Imports from RFC 3852 [CMS] 503 Attribute 504 FROM CryptographicMessageSyntax2004 505 { iso(1) member-body(2) us(840) rsadsi(113549) 506 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } 508 -- Imports from RFC 3161 [TSP] 509 TimeStampToken 510 FROM PKIXTSP 511 { iso(1) identified-organization(3) dod(6) internet(1) 512 security(5) mechanisms(5) pkix(7) id-mod(0) 513 id-mod-tsp(13)} 515 -- Imports from RFC 5280 [PKIX1] 516 CertificateList 517 FROM PKIX1Explicit88 518 { iso(1) identified-organization(3) dod(6) internet(1) 519 security(5) mechanisms(5) pkix(7) id-mod(0) 520 id-pkix1-explicit-88(18)} 522 -- Imports from RFC 4998 [ERS] 523 EvidenceRecord 524 FROM ERS 525 { iso(1) identified-organization(3) dod(6) internet(1) 526 security(5) mechanisms(5) ltans(11) id-mod(0) 527 id-mod-ers88(2) id-mod-ers88-v1(1) }; 529 -- TimeStampedData Content Type and Object Identifier 531 id-ct-timestampedData OBJECT IDENTIFIER ::= { 532 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 533 id-smime(16) id-ct(1) 31 } 535 TimeStampedData ::= SEQUENCE { 536 version INTEGER { v1(1) }, 537 dataUri IA5String OPTIONAL, 538 metaData MetaData OPTIONAL, 539 content OCTET STRING OPTIONAL, 540 temporalEvidence Evidence 541 } 543 MetaData ::= SEQUENCE { 544 hashProtected BOOLEAN, 545 fileName UTF8String OPTIONAL, 546 mediaType IA5String OPTIONAL, 547 otherMetaData Attributes OPTIONAL 548 } 550 Attributes ::= 551 SET SIZE(1..MAX) OF Attribute -- according to RFC 3852 553 Evidence ::= CHOICE { 554 tstEvidence [0] TimeStampTokenEvidence, -- see RFC 3161 555 ersEvidence [1] EvidenceRecord, -- see RFC 4998 556 otherEvidence [2] OtherEvidence 557 } 559 OtherEvidence ::= SEQUENCE { 560 oeType OBJECT IDENTIFIER, 561 oeValue ANY DEFINED BY oeType } 563 TimeStampTokenEvidence ::= 564 SEQUENCE SIZE(1..MAX) OF TimeStampAndCRL 566 TimeStampAndCRL ::= SEQUENCE { 567 timeStamp TimeStampToken, -- according to RFC 3161 568 crl CertificateList OPTIONAL -- according to RFC 5280 569 } 571 END 573 Acknowledgments 575 Thanks to Stephen Kent for encouraging the author in the early stages 576 of this work. 578 Thanks to Russ Housley for reviewing this memo, suggesting useful 579 amendments and assigning a value to the OIDs herein defined. 581 Thanks are also due to other people who reviewed this memo and helped 582 improving it, but prefer not to be mentioned. 584 Author's Address 586 Adriano Santoni 587 Actalis S.p.A. 588 Via Taramelli 26 589 I-20124 Milano 591 E-mail: adriano.santoni@actalis.it