idnits 2.17.1 draft-ietf-pkix-tap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 32 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1256 -- Looks like a reference, but probably isn't: '1' on line 1206 -- Looks like a reference, but probably isn't: '2' on line 1183 == Unused Reference: 'RFC2028' is defined on line 1497, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) ** Obsolete normative reference: RFC 3369 (Obsoleted by RFC 3852) -- Obsolete informational reference (is this intentional?): RFC 3126 (Obsoleted by RFC 5126) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft C. Wallace 3 draft-ietf-pkix-tap-00.txt CygnaCom Solutions 4 February 2003 S. Chokhani 5 Expires August 2003 Orion Security 7 Trusted Archive Protocol (TAP) 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of [RFC2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced or made obsolete by other documents at 21 any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 A Trusted Archive Authority (TAA) is a service that supports long- 37 term non-repudiation by maintaining secure storage of 38 cryptographically refreshed information. This document defines a set 39 of transactions for interacting with a Trusted Archive Authority 40 (TAA) and establishes a means of representing archived information. 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in [RFC2119]. 48 Table of Contents 50 1. Introduction...................................................3 51 1.1 Terminology................................................3 52 1.2 Data.......................................................4 53 1.3 Entities...................................................4 54 1.4 Services...................................................4 55 1.5 Applications...............................................5 56 2. Trusted Archive Protocol.......................................5 57 2.1 Archive submission request format..........................7 58 2.2 Archive submission response format.........................9 59 2.3 Archive retrieval request format..........................11 60 2.4 Archive retrieval response................................13 61 2.5 Archive deletion request..................................15 62 2.6 Archive deletion response.................................16 63 3. Validation....................................................17 64 3.1 Submission................................................17 65 3.2 Retrieval.................................................18 66 3.3 Deletion..................................................19 67 4. Transports....................................................19 68 4.1 TAP over HTTP.............................................19 69 5. ArchiveControls, TrackingInfos and CryptoInfos................21 70 5.1 Archive Controls..........................................21 71 5.2 TrackingInfos.............................................22 72 5.3 CryptoInfos...............................................22 73 6. TAP ASN.1 Module..............................................23 74 7. Security Considerations.......................................28 75 7.1 Trust Anchors for Timestamp and Other Signature Verification 76 on Archive Retrieval..........................................28 77 7.2 Algorithm and Technology Advances.........................29 78 7.3 Authorizations............................................29 79 7.4 TSA Policy................................................30 80 7.5 Other.....................................................30 81 8. Intellectual Property.........................................30 82 Normative References.............................................32 83 Informative References...........................................32 84 Authors' Addresses...............................................33 85 Appendix A: Support for non-TAP aware clients and alternative 86 submission request formats.......................................34 88 1. Introduction 90 A Trusted Archive Authority (TAA) is a service that supports long- 91 term non-repudiation by maintaining secure storage of 92 cryptographically refreshed information. This document defines a 93 trusted archive protocol (TAP) that provides a set of transactions 94 for interactions with a TAA (i.e. submission, retrieval and deletion 95 of information). 97 1.1 Terminology 99 A TAA generates and maintains various data as part of the archive 100 process. Throughout this document, entities submitting data to the 101 TAA for archival are referred to as submitters and entities 102 requesting retrieval or deletion of data are referred to as 103 requestors. This document uses the following terms to describe the 104 artifacts of the archive process: 106 Archived data: archived data is the data presented to the TAA by the 107 submitter. 109 Archive token: an archive token is an object generated by the TAA 110 when data is submitted and accepted for archiving. The archive token 111 is returned to the submitter and may be used to request retrieval or 112 deletion of the archived data and associated cryptographic 113 information. For purposes of future retrieval or deletion, 114 applications may treat the archive token as an opaque blob. The 115 archive token includes: submitter DN, timestamp token, TAA date and 116 time upon submission and, optionally, tracking information. To 117 verify the accuracy of information archived by the TAA, submitters 118 MUST verify the contents of the archive token as described below in 119 section 3. 121 Archive record: an archive record contains the cryptographic refresh 122 history compiled by the TAA. The initial archive record is the 123 timestamp token obtained for the submitted data. The timestamp token 124 format is defined in [RFC3161] and consists of a ContentInfo object 125 containing a TSTInfo object. Upon each refresh, the most recent 126 archive record becomes the prevArchRecord field of a new 127 TimeStampedData object, a timestamp is obtained for the 128 TimeStampedData object and is placed in the timestamp field of a new 129 ArchiveRecordData and the entire ArchiveRecordData structure placed 130 in a ContentInfo object. The ContentInfo object serves as the new 131 archive record. When verifying an archive record, verification 132 terminates when the original timestamp token is verified against the 133 archived data. 135 Archive package: an archive package is an object containing, 136 minimally, the archive token, archive record and archived data. The 137 archive package MAY include additional cryptographic information. 139 1.2 Data 141 A TAA may be able to archive any data format or a TAA MAY implement 142 features that limit the types of data that will be accepted for 143 archiving. A TAA MAY implement additional support for some data 144 formats, e.g. a TAA could implement a CMS message verification 145 feature. Additional features SHOULD be implemented using an archive 146 control. 148 Data submitted to a TAA MAY include all, some or none of the 149 cryptographic information necessary for long-term dispute resolution. 150 Archived data MAY be submitted with or without type information 151 and/or instructions that request the TAA to act upon the data prior 152 to archival, i.e. an archive control. A TAA MAY implement features 153 that assist in the collection and/or validation of cryptographic 154 information or otherwise act upon the submitted data. Submitters MAY 155 submit data that is thought to be cryptographically valid or invalid. 156 Retrieval clients MAY submit information sufficient to identify 0 or 157 more archive records for retrieval. 159 1.3 Entities 161 This specification identifies four entities involved in TAP: TAA, 162 timestamp authority (TSA), submission client and retrieval/deletion 163 client. The TAA MAY be aware of the archived data format or not 164 aware. The submission client MAY be TAP-aware or non-TAP-aware. The 165 retrieval/deletion client MUST be TAP-aware and MAY be aware of the 166 archived data format or not aware. The TSA MAY be independent of the 167 TAA (i.e. the TAA acts as a timestamp client) or the TAA MAY be a 168 TSA. 170 The provision for non-TAP-aware submission clients is intended to 171 support simple, existing clients, such as a FTP client. In such 172 cases a TAP-aware client should be used to process the TAA response, 173 which may be delivered via a different transport. 175 TAA certificates MUST include an instance of the extendedKeyUsage 176 extension permitting operation as a TAA. The value must be set to 177 id-kp-trustedArchive. 179 1.4 Services 181 A TAA MUST provide the following services: 183 - Archived data preservation 184 - Archive token generation (including acquisition of a timestamp 185 for the archived data) 186 - Periodic refresh of archive record 187 - Trusted cryptographic information preservation for verification 188 of an archive record (i.e. trust anchors, certificates, CRLs, 189 OCSP responses, OCSP responder certificates, etc.) 190 - Archive package retrieval and deletion 192 A TAA MAY provide additional, optional services, for example: 194 - Historical trust anchor preservation 195 - PKI information collection and/or validation 196 - Cryptographic message validation 198 Like the RFC on Electronic Signature Formats for long-term electronic 199 signatures [RFC3126], this draft relies on CMS [RFC3369] and the Time 200 Stamp Protocol [RFC3161]. This specification defines the following: 202 - A data transfer protocol between TAAs and clients 203 - Artifacts that can be used to archive and preserve any 204 cryptographic service, such as digital signatures, and to archive 205 any non-cryptographic data. 207 TAP uses a timestamp refresh approach that greatly reduces (and can 208 be used to eliminate) the need to trust the TAA for the integrity of 209 the archive data. In other words, data modifications made to the 210 archive records by the TAA can be detected. 212 1.5 Applications 214 The TAA can be unaware of the data being archived and can be used to 215 archive cryptographic data or non-cryptographic data. Cryptographic 216 data can be signed, encrypted or both. 218 In support of long-term preservation of digital signatures, 219 submitters can package all the certificates, revocation information 220 (CRLs and OCSP responses) and, optionally, trust anchors in the 221 submitted data to facilitate signature verification at any time in 222 the future without needing the services of a repository or other 223 source for certificates and revocation information. If the retrieval 224 client uses another trusted source for trust anchors for signature 225 verification and for trusted timestamp verification, then the TAA 226 need not be trusted for the integrity of the data. The TSA MUST be 227 trusted in all cases. 229 2. Trusted Archive Protocol 231 The following sections describe the transaction formats that comprise 232 the TAP. Submission and retrieval requests sent to a TAA MAY be 233 signed, not authenticated or authenticated using other means such as 234 client-authenticated SSL/TLS. Deletion requests MUST be 235 authenticated. Messages sent from a TAA are always signed using the 236 CMS SignedData ([RFC3369]) format with a TAP response payload. All 237 response messages from a TAA MUST be signed and MUST NOT contain any 238 signatures other than the signature of the TAA. 240 Unsigned requests consist of an ArchiveSubmissionReq, 241 ArchiveRetrievalReq or ArchiveDeletionReq encapsulated in a 242 ContentInfo object. An overview of this structure is provided below. 243 Many details are not shown, but the way that TAP makes use of CMS is 244 clearly illustrated. 246 ContentInfo { 247 contentType, -- id-tap-archiveReq, id-tap-archiveRetrievalReq 248 -- or id-tap-archiveDeletionReq 250 content -- ArchiveSubmissionReq, ArchiveRetrievalReq 251 -- or ArchiveDeletionReq 252 } 254 Signed requests and signed responses consist of an 255 ArchiveSubmissionReq, ArchiveRetrievalReq, ArchiveDeletionReq, 256 ArchiveSubOrDelResp or ArchiveRetrievalResp encapsulated in a 257 SignedData, which is in turn encapsulated in a ContentInfo. An 258 overview of this structure is provided below. Again, many details are 259 not shown, but the way that TAP makes use of CMS is clearly 260 illustrated. 262 ContentInfo { 263 contentType, -- id-signedData (1.2.840.113549.1.7.2) 264 content -- SignedData 265 } 267 SignedData { 268 version, 269 digestAlgorithms, 270 encapContentInfo, -- contents as described below 271 certificates, -- (Optional) 272 crls, -- (Optional) 273 signerInfos -- (only one in TAP) 274 } 276 SignerInfo { 277 version, 278 sid, 279 digestAlgorithm, 280 signedAttrs, -- (Required) 281 signatureAlgorithm, 282 signature, 283 unsignedAttrs 285 } 287 EncapsulatedContentInfo { 288 eContentType, -- id-tap-archiveReq, 289 -- id-tap-archiveRetrievalReq, 290 -- id-tap-archiveDeletionReq, 291 -- id-tap-archiveSubOrDelResp or 292 -- id-tap-archiveRetrievalResp 294 eContent -- OCTET STRING containing 295 -- ArchiveSubmissionReq, ArchiveRetrievalReq, 296 -- ArchiveDeletionReq, ArchiveSubOrDelResp or 297 -- ArchiveRetrievalResp 298 } 300 The syntaxes for SignedData and ContentInfo are defined in [RFC3369]. 301 The syntaxes for all request and response types are defined below. 303 For all response messages, the TAA server MUST include its own 304 certificate in the certificates field within SignedData. Other 305 certificates MAY be included. The TAA server MAY provide one or more 306 CRLs in the crls field within SignedData. The signedAttrs within 307 SignerInfo MUST include the content-type and message-digest 308 attributes defined in [RFC3369] (because the content type of the 309 EncapsulatedContentInfo value is not id-data). 311 2.1 Archive submission request format 313 Archive submission requests are defined as follows: 315 ArchiveSubmissionReq ::= SEQUENCE 316 { 317 version TAPVersion DEFAULT v1, 318 submitterName GeneralName, 319 policy OBJECT IDENTIFIER OPTIONAL, 320 archiveControls [0] ArchiveControls OPTIONAL, 321 archivedData ArchivedData 322 } 324 TAA implementations MAY require authentication via CMS, SSL/TLS, or 325 other means. TAA implementations MAY support alternative submission 326 formats in addition to ArchiveSubmissionReq. 328 2.1.1 version 330 The version field (currently v1) describes the version of the archive 331 submission request. 333 TAPVersion ::= INTEGER { v1(0) } 335 2.1.2 submitterName 337 The submitterName field identifies the entity submitting the 338 associated data for archiving. If authentication is performed, TAA 339 implementations SHOULD confirm that the value in the submitterName 340 field is consistent with authenticated information. For successful 341 requests, TAAs MUST include the submitterName contained in a request 342 in the resulting archive token. 344 2.1.3 policy 346 The policy field, if present, indicates the policy under which the 347 archive service SHOULD operate with regard to the data submitted as 348 part of the request. 350 2.1.4 archiveControls 352 The archiveControls field may be used to request the TAA to perform 353 additional actions, for example, server-side validation of the data 354 field of archiveData or inclusion of a nonce in the response. 356 TAAs MUST reject requests containing unrecognized or unsupported 357 archive controls. Archive controls SHOULD be defined such that for 358 each control included in a request a corresponding control is 359 included in the response. 361 ArchiveControls ::= SEQUENCE SIZE (1..MAX) OF ArchiveControl 362 ArchiveControl ::= SEQUENCE 363 { 364 archiveControlType OBJECT IDENTIFIER 365 archiveControlValue ANY DEFINED BY archiveControlType OPTIONAL 366 } 368 2.1.5 archivedData 370 The archivedData field contains the data to be archived and, 371 optionally, type information. The type field of archivedData is 372 advisory and is for use when processing archiveControls and/or for 373 use by retrieval/deletion clients. The data field of archivedData 374 contains the data to archive. 376 ArchivedData ::= SEQUENCE 377 { 378 type ArchivedDataType OPTIONAL, 379 data OCTET STRING 380 } 382 ArchivedDataType ::= CHOICE 383 { 384 oid OBJECT IDENTIFIER, 385 mimeType UTF8String 386 } 388 When type information is included in a submission request, TAAs 389 SHOULD return type information in future retrieval responses 390 containing the associated archived data. 392 2.2 Archive submission response format 394 Archive submission responses are defined as follows: 396 ArchiveSubOrDelResp ::= SEQUENCE 397 { 398 version TAPVersion DEFAULT v1, 399 status ArchiveStatus, 400 archiveToken ArchiveToken OPTIONAL, 401 archiveControls [0] ArchiveControls OPTIONAL 402 } 404 ArchiveSubOrDelResp objects MUST be returned in the eContent field of 405 a CMS SignedData message. 407 2.2.1 version 409 The version field (currently v1) describes the version of the archive 410 submission response. 412 2.2.2 status 414 The status field indicates the outcome of request processing and is 415 comprised of a status code and an optional status string. 417 ArchiveStatus ::= SEQUENCE 418 { 419 code ArchiveStatusCode, 420 statusString UTF8String OPTIONAL 421 } 423 ArchiveStatusCode ::= ENUMERATED 424 { 425 success (0), -- success 426 genericFailure (1), -- misc. unspecified failure 427 authenticationFailed (2), -- authentication failed (or absent) 428 unauthorizedRequest (3), -- submitter(or request) not authorized 429 unrecognizedControl (4), -- unrecognized or disallowed control 430 controlFailure (5), -- control processing failed 431 policyFailure (6), -- policy not supported 432 timestampFailure (7), -- timestamp could not be obtained 433 retrievalDelayed (8),-- retrieval may require manual action 434 unsupportedDataFormat(9) -- format of submitted data not supported 435 -- add more status codes 436 } 438 2.2.3 archiveToken 440 The archiveToken field contains information that can be used to 441 request retrieval or deletion of the archived data in the future. An 442 archiveToken MUST be included in all successful submission responses. 443 Submitters MUST verify archive tokens as described in section 3 to 444 ensure that the archive token accurately reflects the submitted data, 445 i.e. the values in the submitterName, curTime and timestamp fields 446 are consistent with request. 448 ArchiveToken ::= ContentInfo 449 -- content type: id-tap-archiveToken 450 -- content: ArchiveTokenData 452 ArchiveTokenData ::= SEQUENCE 453 { 454 submitterName GeneralName, 455 timestamp TimeStampToken, 456 curTime GeneralizedTime, 457 trackingInfo TrackingInfos OPTIONAL 458 } 460 TrackingInfos ::= SEQUENCE SIZE (1..MAX) OF TrackingInfo 461 TrackingInfo ::= ContentInfo 463 The submitterName field contains the value from the submitterName 464 field in the request. 466 The timestamp field contains a timestamp generated for the archived 467 data. 469 The curTime field contains the TAA time when the archive token was 470 created. 472 The trackingInfo field, if present, MAY contain information relevant 473 only to the TAA and/or MAY contain information that identifies the 474 TAA, i.e. a URL. Submission clients and retrieval/deletion clients 475 are not required to process the contents of the trackingInfo field 476 but SHOULD be capable of processing the TAALocation TrackingInfo. 478 2.2.4 archiveControls 480 The archiveControls field is used to return information associated 481 with a control included in the request, for example, the outcome of 482 server-side validation or a nonce from the request. TAAs MUST NOT 483 include controls in a response that are not associated with controls 484 in a request. Submission clients SHOULD be able to process controls 485 in accordance with the control definition. 487 2.3 Archive retrieval request format 489 Archive retrieval requests are defined as follows: 491 ArchiveRetrievalReq ::= SEQUENCE 492 { 493 version TAPVersion DEFAULT v1, 494 requestorName GeneralName, 495 retrievalRequest ArchiveRetrievalInfo OPTIONAL, 496 archiveControls [0] ArchiveControls OPTIONAL 497 } 499 The request includes information identifying the archived data to 500 retrieve or to initiate a search. 502 TAA implementations MAY require authentication via CMS, SSL/TLS, or 503 other means. 505 2.3.1 version 507 The version field (currently v1) describes the version of the archive 508 retrieval request. 510 2.3.2 requestorName 512 The requestorName field identifies the entity requesting retrieval of 513 an archive package. If authentication is performed, TAA 514 implementations SHOULD confirm that the value in the requestorName 515 field is consistent with authenticated information. 517 2.3.3 retrievalRequest 518 The ArchiveRetrievalInfo structure permits clients to fully identify 519 an archive using an archive token, to initiate a search using a 520 partial set of information or to complete a delayed request using a 521 poll reference. The retrievalRequest field may be omitted when the 522 archiveControls field contains all necessary information, such as 523 when requesting only trust anchor information via a 524 TrustAnchorRequest control. 526 ArchiveRetrievalInfo ::= CHOICE 527 { 528 archiveToken [0] ArchiveToken, 529 archiveInfo [1] ArchiveInfo, 530 pollReference [2] OCTET STRING 531 } 533 The archiveToken field can be used to identify a specific archive 534 package for retrieval. ArchiveRetrievalResps associated with 535 ArchiveRetrievalReqs containing an archive token MUST contain a 536 single ArchivePackage. The archiveInfo field can be used to retrieve 537 a collection of tokens or archive packages. The pollReference field 538 can be used to complete a delayed request. The value included in 539 pollReference is the value returned by the TAA in an 540 ArchiveRetrievalResp with status set to retrievalDelayed. 542 ArchiveInfo::= SEQUENCE 543 { 544 tokensOnly BOOLEAN DEFAULT TRUE, 545 submitterName [0] GeneralName OPTIONAL, 546 timestamp [1] TimeStampToken OPTIONAL, 547 timeInfo [2] ArchiveTimeInfo OPTIONAL, 548 } 550 ArchiveTimeInfo ::= SEQUENCE 551 { 552 time GeneralizedTime, 553 accuracy Accuracy OPTIONAL 554 } 556 The tokensOnly field of ArchiveInfo can be used to avoid retrieving 557 data and cryptographic information for each archive that matches the 558 query. The fields of ArchiveInfo can be used to query for archive 559 tokens or archive packages that match the specified search 560 parameters. 562 The accuracy field in ArchiveTimeInfo is applied to the time field to 563 define a range of time used when searching. Accuracy is defined in 564 [RFC3161]. 566 2.3.4 archiveControls 568 The archiveControls field may be used to request additional, optional 569 services from a TAA, such as a limit on the number of returned 570 results, a nonce or an indication to return trust anchors known to 571 the TAA at the time an archive was created. 573 TAAs MUST reject requests containing unrecognized or unsupported 574 archive controls. 576 2.4 Archive retrieval response 578 Archive retrieval responses are defined as follows: 580 ArchiveRetrievalResp ::= SEQUENCE 581 { 582 version TAPVersion DEFAULT v1, 583 status ArchiveStatus, 584 archiveControls [0] ArchiveControls OPTIONAL, 585 results ArchiveRetrievalResults OPTIONAL 586 } 588 ArchiveRetrievalResp objects MUST be returned as the eContent field 589 of a CMS SignedData message. 591 2.4.1 version 593 The version field (currently v1) describes the version of the archive 594 retrieval response. 596 2.4.2 status 598 The status field indicates that outcome of the request processing and 599 is comprised of a status code and an optional status string. 601 2.4.3 archiveControls 603 The archiveControls field is used to return information associated 604 with a control included in the request. TAAs MUST NOT include 605 controls in a response that are not associated with controls in a 606 request. Retrieval/deletion clients SHOULD be able to process 607 controls in accordance with the control definition. 609 2.4.4 results 611 The results of a successful retrieval request are returned as a 612 sequence of at least one ArchivePackage, which contains the archive 613 token and (optionally) the archive package data. A pollReference MAY 614 be returned in cases where the archive package is not immediately 615 available, for example, when manual intervention is required to 616 retrieve an archive. 618 ArchiveRetrievalResults ::= SEQUENCE SIZE (1..MAX) OF ArchivePackage 620 ArchivePackage ::= SEQUENCE 621 { 622 archiveToken ArchiveToken, 623 packageData [0] ArchivePackageData OPTIONAL, 624 pollReference [1] OCTET STRING OPTIONAL 625 } 627 ArchivePackageData ::= SEQUENCE 628 { 629 digestAlgorithms DigestAlgorithmIdentifiers, 630 policy OBJECT IDENTIFIER OPTIONAL, 631 archiveRecord ArchiveRecord, 632 cryptoInfos [0] CryptoInfos OPTIONAL, 633 archivedData ArchivedData 634 } 636 The digestAlgorithms field identifies all digest algorithms that were 637 applied to the archived data over the lifetime of the archive record. 638 To successfully verify all archive record components, the archived 639 data MUST be hashed using each of the algorithms identified in the 640 digestAlgorithms field. 642 The archiveRecord field contains a nested structure with the complete 643 refresh history for the archived data. TAAs SHOULD store all 644 cryptographic information necessary to verify each layer of the 645 archive record in the certificates, crls and unsignedAttrs fields of 646 the timestamp token, i.e. each timestamp token in the history SHOULD 647 be self-contained for validation purposes under protection of the 648 next layer in the archive record. A CryptoInfos unsignedAttrs field 649 MAY be used to convey OCSP responses and/or trust anchor information. 650 The object identifier id-tap-cryptoInfos identifies the CryptoInfos 651 attribute. CryptoInfos attribute values have the ASN.1 type 652 CryptoInfos. 654 ArchiveRecord ::= ContentInfo 655 -- content type: id-tap-archiveRecordData 656 -- content: ArchiveRecordData 657 ArchiveRecordData ::= SEQUENCE 658 { 659 timestampedData TimeStampedData, -- covered by timestamp 660 timestamp TimeStampToken 661 } 663 TimeStampedData ::= SEQUENCE 664 { 665 prevArchRecord ContentInfo, -- previous record 666 messageImprint MessageImprint -- hash of archived data 667 } 669 The cryptoInfos field contains additional information that may be 670 useful when verifying the archived data. This information may be 671 included as a service by a TAA or due to collection of information 672 requested via an archive control, etc. Retrieval/deletion clients 673 are free to ignore any or all CryptoInfos contained in an archive 674 package. 676 CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF CryptoInfo 677 CryptoInfo ::= SEQUENCE 678 { 679 cryptoInfoType OBJECT IDENTIFIER 680 cryptoInfoValue ANY DEFINED BY cryptoInfoType 681 } 683 The archivedData field contains the data that was submitted to the 684 TAA and, optionally, type information. The data field within the 685 ArchivedData structure contains the data to hash using the algorithms 686 identified in the digestAlgorithms field of ArchivePackageData. 688 2.5 Archive deletion request 690 Archive deletion requests are defined as follows: 692 ArchiveDeletionReq ::= SEQUENCE 693 { 694 version TAPVersion DEFAULT v1, 695 requestorName GeneralName, 696 archiveToken ArchiveToken, 697 archiveControls [0] ArchiveControls OPTIONAL 698 } 700 The request includes information identifying the archived data to 701 delete. Deletion requests MUST be authenticated. 703 2.5.1 version 704 The version field (currently v1) describes the version of the archive 705 deletion request. 707 2.5.2 requestorName 709 The requestorName field identifies the entity requesting retrieval of 710 an archive package. If authentication is performed, TAA 711 implementations SHOULD confirm that the value in the requestorName 712 field is consistent with authenticated information. 714 2.5.3 archiveToken 716 The archive token field identifies the archived data to delete. 718 2.5.4 archiveControls 720 The archiveControls field may be used to request additional, optional 721 services from a TAA. 723 TAAs MUST reject requests containing unrecognized or unsupported 724 archive controls. 726 2.6 Archive deletion response 728 Archive deletion responses are of type ArchiveSubOrDelResp as defined 729 above. The meaning of each field in the context of a deletion 730 response is described below. 732 ArchiveSubOrDelResp objects MUST be returned in the eContent field of 733 a CMS SignedData message. 735 2.6.1 version 737 The version field (currently v1) describes the version of the archive 738 deletion response. 740 2.6.2 status 742 The status field indicates that outcome of the request processing and 743 is comprised of a status code and an optional status string. 745 2.6.3 archiveToken 747 The archiveToken field contains information identifying the deleted 748 archive data. Successful responses MUST include an archiveToken 749 identifying the archive that was deleted. The archiveToken MUST 750 match the archiveToken contained in the deletion request. 752 2.6.4 archiveControls 754 The archiveControls field is used to return information associated 755 with a control included in the request. TAAs MUST NOT include 756 controls in a response that are not associated with controls in a 757 request. Retrieval/deletion clients SHOULD be able to process 758 controls in accordance with the control definition. 760 3. Validation 762 The signature on all TAA responses MUST be verified. TAA signatures 763 on protocol transactions should be verified using current trust 764 anchors known to the client. This section discusses additional 765 validation steps for each type of transaction. 767 3.1 Submission 769 After verifying the signature of a successful ArchiveSubOrDelResp, 770 compliant submission clients MUST perform the following processing of 771 the submission response contents: 773 - Process each archive control per definition of control; 774 - Verify the signature of the Time Stamp Authority (TSA) on the 775 timestamp token contained in the archive token; 776 - Verify that the hash contained in the timestamp token 777 represents the hash of the data submitted by the client to the 778 TAA; and 779 - Verify that the time on the timestamp token is reasonably close 780 to the current time. 782 Verification that the curTime in the archive token is reasonably 783 close to the current time is RECOMMENDED and confirmation that the 784 submitterName is correct is RECOMMENDED. 786 For the signature verification of the TSA, the submitter can choose 787 to use the trust anchors returned by the TAA, if present, or rely on 788 its own list of trust anchors. 790 Controls that involve TAA-alteration of submitted data, i.e. 791 collection and inclusion of relevant cryptographic information in the 792 submitted data, may impact the verification of the timestamp field. 794 3.2 Retrieval 796 After verifying the signature of a successful ArchiveRetrievalResp, 797 compliant retrieval/deletion clients MUST perform the following 798 processing of the retrieval response contents: 800 - If an archive token was included in the request, the archive 801 token the ArchivePackage should be compared with the requested 802 archive token; 803 - Process each archive control per definition of control; 804 - Hash the data field of the archived data using each of the 805 algorithms identified in the digestAlgorithms field of the 806 ArchivePackage data structure; 807 - Verify the outermost timestamp token; 808 - Verify that the timestamp on the outermost token is current; 809 - Verify all remaining timestamp tokens; and 810 - Verify that in each instance a new timestamp token was applied 811 prior to the preceding timestamp token expiry. 813 See the security considerations section for additional information 814 regarding selection of the trust anchors to be used for timestamp 815 token verification. 817 The verification of the archived data is beyond the scope of this 818 specification. This specification provides mechanism to carry all 819 the data required to make such verification possible, but the TAA 820 need not be aware of the data format. For example, if a submitter 821 submits a signed CMS message with all the certificates, revocation 822 information (CRLs and OCSP responses), and trust anchors required to 823 verify the message, that message could be verified upon retrieval to 824 prove that the signature was valid at the time of the inner most 825 timestamp on the retrieved data. 827 The archiveRecord MUST be verified as described above by verifying 828 the timestamp present in each layer of the ArchiveRecord structure. 829 Layers should be validated in turn beginning with the outermost layer 830 and ending with the innermost layer. The innermost layer is simply 831 the timestamp obtained for the archived data; outer layers are 832 ArchiveRecord structures, which contain the previous record, a hash 833 of the archived data and a timestamp. When verifying the innermost 834 timestamp, verify that the hash contained in the timestamp token 835 represents the hash of the archived data. When verifying outer 836 timestamps, verify that the hash contained in the timestamp token 837 matches the hash of the corresponding TimeStampedData structure and 838 that the hash contained in the TimeStampedData structure represents a 839 hash of the archived data. 841 Timestamp token signatures MAY be verified using client-obtained 842 trust anchor and revocation information or using information provided 843 by the TAA. TAAs MAY provide relevant cryptographic information in 844 the CryptoInfos unsigned attribute of the SignerInfo structure and 845 the certificates and crls fields of the SignedData structure of each 846 timestamp token. 848 ArchiveRecord verification terminates when the innermost ContentInfo 849 object containing a timestamp token (covering the archived data) is 850 verified. 852 *---------------------------------------------------------------* 853 * ContentType: id-tap-archiveRecordData * 854 * Content: ArchiveRecordData w/ previous archive record * 855 * *-------------------------------------------------------* * 856 * * ContentType: id-tap-archiveRecordData * * 857 * * Content: ArchiveRecordData w/ previous archive record * * 858 * * *------------------------------------------* * * 859 * * * ContentType: id-ct-TSTInfo * * * 860 * * * Content: TSTInfo covering archived data * * * 861 * * *------------------------------------------* * * 862 * *-------------------------------------------------------* * 863 *---------------------------------------------------------------* 864 Figure 1: ArchiveRecord following two refresh operations 866 3.3 Deletion 868 Following receipt and verification of a successful 869 ArchiveSubOrDelResp no further validation steps need be performed. 870 However, inspection of the ArchiveControls and/or ArchiveToken 871 returned in the response SHOULD be performed. 873 Deletion requests MUST be authenticated; it is RECOMMENDED that 874 deletion requests be digitally signed in order to protect against 875 unauthorized parties from issuing or modifying deletion requests. 876 The deletion request client MUST perform the following processing of 877 the deletion response in order to be compliant with this 878 specification: 880 - Process each archive control per definition of control; 881 - Verify the signature of the TAA on the response; and 882 - Match the archive token returned with archive token requested. 884 4. Transports 886 There are no mandatory transport mechanisms for TAP messages. The 887 mechanisms described below are optional. 889 4.1 TAP over HTTP 890 This section describes the formatting conventions for TAP requests 891 and responses when carried by HTTP. 893 4.1.1 TAP Requests 895 HTTP-based TAP requests can use the POST method to submit their 896 requests. Where confidentiality is a requirement, TAP transactions 897 exchanged using HTTP MAY be protected using either TLS/SSL or some 898 other lower layer protocol. 900 When authentication is a requirement, the request could be signed or 901 the TAP transactions exchanged using HTTP MAY be protected using 902 client authenticated TLS/SSL or some other lower layer protocol. 904 A TAP request using the POST method is constructed as follows: 906 The Content-Type header MUST have the value "application/tap- 907 request". 909 The Content-Length header MUST be present and have the exact 910 length of the request. 912 The body of the message is the binary value of the DER encoding 913 of the request. Other HTTP headers MAY be present and MAY be 914 ignored if not understood by the requestor. 916 Sample Content-Type header: 917 Content-Type: application/tap-request 919 4.1.2 TAP Response 921 An HTTP-based TAP response is composed of the appropriate HTTP 922 headers, followed by the binary value of the DER encoding of the 923 response. 925 The Content-Type header MUST have the value "application/tap- 926 response". 928 The Content-Length header MUST be present and specify the 929 length of the response. 931 Other HTTP headers MAY be present and MAY be ignored if not 932 understood by the requestor. 934 5. ArchiveControls, TrackingInfos and CryptoInfos 936 5.1 Archive Controls 938 This document defines several ArchiveControls that MAY be supported 939 by TAA implementations. Additional controls MAY also be supported. 940 When a TAA receives a request with an unrecognized or unsupported 941 control a response indicating failure MUST be generated and returned 942 to the submitter of the request. Archive controls typically work in 943 a request/response fashion, i.e. when a client includes an 944 ArchiveControl in a request a corresponding control is expected in 945 the response. 947 5.1.1 Nonce 949 A nonce may be included in an ArchiveControls structure using the id- 950 tap-nonce object identifier and following ASN.1 structure: 952 Nonce ::= OCTET STRING 954 A successful, associated response message MUST include an archive 955 control with the archiveControlType field set to id-tap-nonce and the 956 nonce from the request in the archiveControlValue field. 958 5.1.2 TrustAnchorRequest 960 As part of an ArchiveRetrievalRequest, requestors may request the set 961 of trust anchors known to the TAA at a specific time using the id- 962 tap-trustAnchorRequest object identifier and following ASN.1 963 structure: 965 TrustAnchorRequest ::= GeneralizedTime 967 A successful, associated ArchiveRetrievalResponse MUST include an 968 archive control with the archiveControlType field set to id-tap- 969 trustAnchorResponse and a TrustAnchorResponse in the 970 archiveControlValue field. TrustAnchorResponse contains information 971 about the trust anchors that were known to the TAA at the specified 972 time. This information may be useful when verifying signatures 973 applied to archived data. 975 TrustAnchorResponse::= SEQUENCE SIZE (0..MAX) OF TrustAnchorInfo 977 TrustAnchorInfo ::= CHOICE 978 { 979 cert Certificate, 980 rawInfo [0] RawTrustAnchorInfo 981 } 982 RawTrustAnchorInfo ::= SEQUENCE 983 { 984 name Name, 985 algorithm AlgorithmIdentifier, 986 pubKey BIT STRING 987 } 989 5.1.3 TSA Policy 991 The TSAPolicy archive control can be used to request that the initial 992 timestamp obtained for an archived data submission be issued under a 993 specific policy. A policy may be included in an ArchiveControls 994 structure using the id-tap-tsaPolicy object identifier and following 995 ASN.1 structure: 997 TSAPolicy ::= OBJECT IDENTIFIER 999 The TSAPolicy ArchiveControl has no response component. 1001 5.2 TrackingInfos 1003 This specification defines a TrackingInfo. TAA implementations are 1004 free to define tracking information objects as necessary. Clients 1005 are not required to process tracking information but SHOULD be 1006 capable of processing the TAALocation TrackingInfo. 1008 5.2.1 TAALocation 1010 Long-term identification of a TAA may not be practical. TAAs MAY 1011 include a TAALocation TrackingInfo to assist bearers of an archive 1012 token to locate a TAA for retrieval or deletion purposes. 1014 TAALocations may be included in a TrackingInfos structure using the 1015 id-tap-taaLocation object identifier and following ASN.1 structure: 1017 TAALocation ::= GeneralName 1019 5.3 CryptoInfos 1021 Clients are not required to process CryptoInfos. This document 1022 defines several CryptoInfos that MAY be supported by client or TAA 1023 implementations. 1025 5.3.1 Certificates 1026 Certificates may be included in a CryptoInfos structure using the id- 1027 tap-certificates object identifier and following ASN.1 structure: 1029 Certificates ::= SEQUENCE SIZE (1..MAX) OF Certificate 1031 5.3.2 OCSPResponses 1033 OCSPResponses may be included in a CryptoInfos structure using the 1034 id-tap-ocspResponses object identifier and following ASN.1 structure: 1036 OCSPResponses ::= SEQUENCE SIZE (1..MAX) OF OCSPResponse 1038 5.3.3 CRLs 1040 CRLs may be included in a CryptoInfos structure using the id-tap-crls 1041 object identifier and following ASN.1 structure: 1043 CRLs ::= SEQUENCE SIZE (1..MAX) OF CertificateList 1045 6. TAP ASN.1 Module 1047 PKIXTAP 1048 -- {iso(1) identified-organization(3) dod(6) internet(1) 1049 -- security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tap(TBD) } 1051 DEFINITIONS IMPLICIT TAGS ::= 1053 BEGIN 1055 -- EXPORTS ALL -- 1057 IMPORTS 1059 TimeStampToken, Accuracy 1060 FROM 1061 PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) 1062 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13) } 1064 Name 1065 FROM 1066 InformationFramework { joint-iso-itu-t ds(5) module(1) 1067 informationFramework(1) 3 } 1069 ContentInfo 1070 FROM 1071 CryptographicMessageSyntax {iso(1) member-body(2) us(840) 1072 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} 1073 Certificate, CertificateList, AlgorithmIdentifier 1074 FROM 1075 AuthenticationFramework {joint-iso-itu-t ds(5) module(1) 1076 usefulDefinitions(0) 4} 1078 GeneralName 1079 FROM 1080 CertificateExtensions {joint-iso-itu-t ds(5) module(1) 1081 certificateExtensions(26) 4} 1083 OCSPResponse 1084 FROM 1085 OCSP; 1087 --Submission transactions 1088 ArchiveSubmissionReq ::= SEQUENCE 1089 { 1090 version TAPVersion DEFAULT v1, 1091 submitterName GeneralName, 1092 policy OBJECT IDENTIFIER OPTIONAL, 1093 archiveControls [0] ArchiveControls OPTIONAL, 1094 archivedData ArchivedData 1095 } 1097 TAPVersion ::= INTEGER { v1(0) } 1099 ArchiveControls ::= SEQUENCE SIZE (1..MAX) OF ArchiveControl 1100 ArchiveControl ::= SEQUENCE 1101 { 1102 archiveControlType OBJECT IDENTIFIER, 1103 archiveControlValue ANY DEFINED BY archiveControlType OPTIONAL 1104 } 1106 ArchivedData ::= SEQUENCE 1107 { 1108 type ArchivedDataType OPTIONAL, 1109 data OCTET STRING 1110 } 1112 ArchivedDataType ::= CHOICE 1113 { 1114 oid OBJECT IDENTIFIER, 1115 mimeType UTF8String 1116 } 1118 ArchiveSubOrDelResp ::= SEQUENCE 1119 { 1120 version TAPVersion DEFAULT v1, 1121 status ArchiveStatus, 1122 archiveToken ArchiveToken OPTIONAL, 1123 archiveControls [0] ArchiveControls OPTIONAL 1124 } 1126 ArchiveStatus ::= SEQUENCE 1127 { 1128 code ArchiveStatusCode, 1129 statusString UTF8String OPTIONAL 1130 } 1132 ArchiveStatusCode ::= ENUMERATED 1133 { 1134 success (0),-- success 1135 genericFailure (1),-- misc. unspecified failure 1136 authenticationFailed (2),-- authentication failed (or absent) 1137 unauthorizedRequest (3),-- submitter(or requestor) not authorized 1138 unrecognizedControl (4),-- unrecognized or disallowed control 1139 controlFailure (5),-- control processing failed 1140 policyFailure (6),-- policy not supported 1141 timestampFailure (7),-- timestamp could not be obtained 1142 retrievalDelayed (8),-- retrieval may require manual action 1143 unsupportedDataFormat(9) -- format of submitted data not supported 1144 -- add more status codes 1145 } 1147 ArchiveToken ::= ContentInfo 1148 -- content type: id-tap-archiveToken 1149 -- content: ArchiveTokenData 1151 ArchiveTokenData ::= SEQUENCE 1152 { 1153 submitterName GeneralName, 1154 timestamp TimeStampToken, 1155 curTime GeneralizedTime, 1156 trackingInfo TrackingInfos OPTIONAL 1157 } 1159 TrackingInfos ::= SEQUENCE SIZE (1..MAX) OF TrackingInfo 1160 TrackingInfo ::= ContentInfo 1162 --Retrieval transactions 1163 ArchiveRetrievalReq ::= SEQUENCE 1164 { 1165 version TAPVersion DEFAULT v1, 1166 requestorName GeneralName, 1167 retrievalRequest ArchiveRetrievalInfo OPTIONAL, 1168 archiveControls [0] ArchiveControls OPTIONAL 1169 } 1171 ArchiveRetrievalInfo ::= CHOICE 1172 { 1173 archiveToken [0] ArchiveToken, 1174 archiveInfo [1] ArchiveInfo, 1175 pollReference [2] OCTET STRING 1176 } 1178 ArchiveInfo::= SEQUENCE 1179 { 1180 tokensOnly BOOLEAN DEFAULT TRUE, 1181 submitterName [0] GeneralName OPTIONAL, 1182 timestamp [1] TimeStampToken OPTIONAL, 1183 timeInfo [2] ArchiveTimeInfo OPTIONAL 1184 } 1186 ArchiveTimeInfo ::= SEQUENCE 1187 { 1188 time GeneralizedTime, 1189 accuracy Accuracy OPTIONAL 1190 } 1192 ArchiveRetrievalResp ::= SEQUENCE 1193 { 1194 version TAPVersion DEFAULT v1, 1195 status ArchiveStatus, 1196 archiveControls [0] ArchiveControls OPTIONAL, 1197 results ArchiveRetrievalResults OPTIONAL 1198 } 1200 ArchiveRetrievalResults ::= SEQUENCE SIZE (1..MAX) OF ArchivePackage 1202 ArchivePackage ::= SEQUENCE 1203 { 1204 archiveToken ArchiveToken, 1205 packageData [0] ArchivePackageData OPTIONAL, 1206 pollReference [1] OCTET STRING OPTIONAL 1207 } 1209 ArchivePackageData ::= SEQUENCE 1210 { 1211 digestAlgorithms DigestAlgorithmIdentifiers, 1212 policy OBJECT IDENTIFIER OPTIONAL, 1213 archiveRecord ArchiveRecord, 1214 cryptoInfos [0] CryptoInfos OPTIONAL, 1215 archivedData ArchivedData 1216 } 1218 ArchiveRecord ::= ContentInfo 1219 -- content type: id-tap-archiveRecordData 1220 -- content: ArchiveRecordData 1221 CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF CryptoInfo 1222 CryptoInfo ::= ContentInfo 1224 ArchiveRecordData ::= SEQUENCE 1225 { 1226 timestampedData TimeStampedData, -- covered by timestamp 1227 timestamp TimeStampToken 1228 } 1230 TimeStampedData ::= SEQUENCE 1231 { 1232 prevArchRecord ContentInfo, -- previous record 1233 messageImprint MessageImprint -- hash of archived data 1234 } 1236 --Deletion transactions 1237 ArchiveDeletionReq ::= SEQUENCE 1238 { 1239 version TAPVersion DEFAULT v1, 1240 requestorName GeneralName, 1241 archiveToken ArchiveToken, 1242 archiveControls [0] ArchiveControls OPTIONAL 1243 } 1245 -- ArchiveControls, TrackingInfos and CryptoInfos 1246 Nonce ::= OCTET STRING 1248 TSAPolicy ::= OBJECT IDENTIFIER 1250 TrustAnchorRequest ::= GeneralizedTime 1251 TrustAnchorResponse::= SEQUENCE SIZE (0..MAX) OF TrustAnchorInfo 1253 TrustAnchorInfo ::= CHOICE 1254 { 1255 cert Certificate, 1256 rawInfo [0] RawTrustAnchorInfo 1257 } 1259 RawTrustAnchorInfo ::= SEQUENCE 1260 { 1261 name Name, 1262 algorithm AlgorithmIdentifier, 1263 pubKey BIT STRING 1264 } 1266 -- tracking infos 1267 TAALocation ::= GeneralName 1269 -- crypto infos 1270 Certificates ::= SEQUENCE SIZE (1..MAX) OF Certificate 1271 CRLs ::= SEQUENCE SIZE (1..MAX) OF CertificateList 1272 OCSPResponses ::= SEQUENCE SIZE (1..MAX) OF OCSPResponse 1273 TrustAnchorInfos::= SEQUENCE SIZE (1..MAX) OF TrustAnchorInfo 1275 -- oid categories 1276 -- id-tap OBJECT IDENTIFIER ::= {id-pkix 22} 1277 -- id-tap-msgs OBJECT IDENTIFIER ::= {id-tap 1} 1278 -- id-tap-types OBJECT IDENTIFIER ::= {id-tap 2} 1279 -- id-tap-cryptoInfos OBJECT IDENTIFIER ::= {id-tap 3} 1280 -- id-tap-controls OBJECT IDENTIFIER ::= {id-tap 4} 1281 -- id-tap-trackingInfos OBJECT IDENTIFIER ::= {id-tap 5} 1283 -- oids related to protocol messages 1284 -- id-tap-archiveReq OBJECT IDENTIFIER ::={id-tap-msgs 1} 1285 -- id-tap-archiveSubOrDelResp OBJECT IDENTIFIER ::={id-tap-msgs 2} 1286 -- id-tap-archiveRetrievalReq OBJECT IDENTIFIER ::={id-tap-msgs 3} 1287 -- id-tap-archiveRetrievalResp OBJECT IDENTIFIER ::={id-tap-msgs 4} 1288 -- id-tap-archiveDeletionReq OBJECT IDENTIFIER ::={id-tap-msgs 5} 1290 -- extended key usage oid 1291 -- id-kp-trustedArchive OBJECT IDENTIFIER ::= {id-kp 15} 1293 -- oids for content info or attribute types 1294 -- id-tap-archiveRecordData OBJECT IDENTIFIER::={id-tap-types 1} 1295 -- id-tap-cryptoInfos OBJECT IDENTIFIER::={id-tap-types 2} 1296 -- id-tap-archiveToken OBJECT IDENTIFIER::={id-tap-types 3} 1298 -- oids for crypto info types 1299 -- id-tap-certificates OBJECT IDENTIFIER ::={id-tap-cryptoInfos 1} 1300 -- id-tap-crls OBJECT IDENTIFIER ::={id-tap-cryptoInfos 2} 1301 -- id-tap-ocspResponses OBJECT IDENTIFIER ::={id-tap-cryptoInfos 3} 1302 -- id-tap-TAInfos OBJECT IDENTIFIER ::={id-tap-cryptoInfos 4} 1304 -- oids for archive controls 1305 -- id-tap-nonce OBJECT IDENTIFIER::={id-tap-controls 1} 1306 -- id-tap-trustAnchorRequest OBJECT IDENTIFIER::={id-tap-controls 2} 1307 -- id-tap-tsaPolicy OBJECT IDENTIFIER::={id-tap-controls 3} 1309 -- oids for tracking infos 1310 -- id-tap-taaLocation OBJECT IDENTIFIER ::= {id-tap-trackingInfos 1} 1312 END 1314 7. Security Considerations 1316 7.1 Trust Anchors for Timestamp and Other Signature Verification on 1317 Archive Retrieval 1319 TAAs can provide all or some of the trust anchors upon retrieval. 1320 These include all the trust anchors required to verify the various 1321 timestamps in the archive record and/or all the trust anchors known 1322 to the TAA at the time of the archive submission (i.e., the timestamp 1323 on the archived data). The latter set of trust anchors may be useful 1324 in digital signature verification on the archived data, if the data 1325 was signed. 1327 Trust anchors provided by the TAA upon archive retrieval are 1328 transmitted securely since they are included in the signed envelope 1329 of the retrieval response. The relying party (i.e., the retrieval 1330 client) MUST use a trust anchor it trusts independent of the trust 1331 anchors provided by the TAA to verify the TAA signature on the 1332 retrieval response. 1334 The relying party (i.e., the retrieval client) can trust the TAA 1335 provided trust anchors or can ignore them. In the latter case, only 1336 the TSA (and not the TAA) needs to be trusted for the integrity of 1337 the archived data. In other words, the relying party will be able to 1338 detect the modifications made to the archived data by the TAA. 1339 Refreshing the timestamp on the archived data before the latest 1340 (i.e., most current or outermost) timestamp expires ensures this. 1342 7.2 Algorithm and Technology Advances 1344 In order to protect against algorithm (i.e., hashing and digital 1345 signature) compromise and/or computing technology advances, 1346 timestamps are periodically refreshed. For each timestamp token 1347 refresh, the archived data is hashed using the latest secure hashing 1348 algorithm and a timestamp token generated using a current, secure 1349 digital signature algorithm. 1351 7.3 Authorizations 1353 Who is "authorized" to use the TAA is the matter of local policy. If 1354 an authorization model is implemented for any of the archive services 1355 (i.e., submission, deletion, and retrieval), the corresponding 1356 service request MUST be authenticated by the TAA in order to validate 1357 the requestor authorization. 1359 This specification does not mandate any authorization requirements. 1361 To claim compliance with this specification, the deletion request 1362 MUST be authenticated. 1364 It is RECOMMENDED that a prudent local policy be established to check 1365 the authorizations for deletion requests. For example, only the 1366 submitter or authorized requestors from submitting organizations 1367 should be able to delete the data. 1369 7.4 TSA Policy 1371 This specification does not mandate how a timestamp under a specific 1372 TSA policy is requested. It is left as a matter of local policy. 1373 Some of the examples for requesting specific TSA policy are: 1375 - Use of archive control (control identified by id-tap-tsaPolicy 1376 serves this purpose) 1377 - TAA not requesting any policy 1378 - TAA requesting specific policy based on its own requirements 1379 - TAA mapping the TAA policy to TSA policy 1381 7.5 Other 1383 Data formats archived by a TAA may have requirements that relate to 1384 long-term non-repudiation beyond those identified in this 1385 specification. 1387 TAAs should be operated with appropriate physical, procedural and 1388 personnel security controls. 1390 TAAs must be able to obtain a trusted timestamp (either by 1391 implementing timestamp functionality or by access to a timestamp 1392 service). Timestamp-related security considerations apply (see 1393 [RFC3161]). 1395 In support of dispute resolution, it may be desirable for TAAs to 1396 archive Certificate Policy and Certification Practice Statement 1397 documents. 1399 It may be desirable to maintain archive data on Write Once/Read Many 1400 (WORM) media. 1402 ArchiveControls that request server-side alteration of data, i.e. 1403 collection of certificates and CRLs, should use a response format 1404 that permits submitters to verify the timestamp contained in the 1405 archive token. 1407 8. Intellectual Property 1409 The IETF takes no position regarding the validity or scope of any 1410 intellectual property or other rights that might be claimed to 1411 pertain to the implementation or use of the technology described in 1412 this document or the extent to which any license under such rights 1413 might or might not be available; neither does it represent that it 1414 has made any effort to identify any such rights. Information on the 1415 IETF's procedures with respect to rights in standards-track and 1416 standards-related documentation can be found in [RFC2028]. Copies of 1417 claims of rights made available for publication and any assurances of 1418 licenses to be made available, or the result of an attempt made to 1419 obtain a general license or permission for the use of such 1420 proprietary rights by implementers or users of this specification can 1421 be obtained from the IETF Secretariat. 1423 The IETF invites any interested party to bring to its attention any 1424 copyrights, patents or patent applications, or other proprietary 1425 rights, which may cover technology that may be required to practice 1426 this standard. Please address the information to the IETF Executive 1427 Director. 1429 [RFC3161] identifies the following eight (8) United States Patents 1430 related to time stamping, listed in chronological order. This may 1431 not be an exhaustive list. Other patents MAY exist or be issued at 1432 any time. This list is provided for informational purposes; to date, 1433 the IETF has not been notified of intellectual property rights 1434 claimed in regard to any of the specification contained in this 1435 document. Should this situation change, the current status may be 1436 found at the online list of claimed rights (IETF Page of Intellectual 1437 Property Rights Notices). 1439 Implementers of this protocol SHOULD perform their own patent search 1440 and determine whether or not any encumbrances exist on their 1441 implementation. 1443 Users of this protocol SHOULD perform their own patent search and 1444 determine whether or not any encumbrances exist on the use of this 1445 standard. 1447 # 5,001,752 Public/Key Date-Time Notary Facility 1448 Filing date: October 13, 1989 1449 Issued: March 19, 1991 1450 Inventor: Addison M. Fischer 1452 # 5,022,080 Electronic Notary 1453 Filing date: April 16, 1989 1454 Issued: June 4, 1991 1455 Inventors: Robert T. Durst, Kevin D. Hunter 1457 # 5,136,643 Public/Key Date-Time Notary Facility 1458 Filing date: December 20, 1990 1459 Issued: August 4, 1992 1460 Inventor: Addison M. Fischer 1461 Note: This is a continuation of patent # 5,001,752.) 1463 # 5,136,646 Digital Document Time-Stamping with Catenate Certificate 1464 Filing date: August 2, 1990 1465 Issued: August 4, 1992 1466 Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. 1467 (assignee) Bell Communications Research, Inc., 1468 # 5,136,647 Method for Secure Time-Stamping of Digital Documents 1469 Filing date: August 2, 1990 1470 Issued: August 4, 1992 1471 Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. 1472 (assignee) Bell Communications Research, Inc., 1474 # 5,373,561 Method of Extending the Validity of a Cryptographic 1475 Certificate 1476 Filing date: December 21, 1992 1477 Issued: December 13, 1994 1478 Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. 1479 (assignee) Bell Communications Research, Inc., 1481 # 5,422,953 Personal Date/Time Notary Device 1482 Filing date: May 5, 1993 1483 Issued: June 6, 1995 1484 Inventor: Addison M. Fischer 1486 # 5,781,629 Digital Document Authentication System 1487 Filing date: February 21, 1997 1488 Issued: July 14, 1998 1489 Inventor: Stuart A. Haber, Wakefield S. Stornetta Jr. 1490 (assignee) Surety Technologies, Inc., 1492 Normative References 1494 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1495 3", BCP 9, RFC 2026, October 1996. 1497 [RFC2028] Bradner, S. and R. Hovey, "The Organizations Involved in 1498 the IETF Standards Process", BCP 11, RFC 2028, October 1499 1996. 1501 [RFC2119] Bradner, S. and , "Key words for use in RFCs to Indicate 1502 Requirement Levels", BCP 14, RFC 2119, March 1997. 1504 [RFC3161] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato, 1505 "Internet X.509 Public Key Infrastructure Time-Stamp 1506 Protocol (TSP)", RFC 3161, August 2001. 1508 [RFC3369] Housley, R., "Cryptographic Message Syntax", RFC 3369, 1509 August 2002. 1511 Informative References 1513 [RFC3126] Pinkas, D., Ross, J., and N. Pope, "Electronic Signature 1514 Formats for long term electronic signatures", RFC 3126, 1515 September 2001. 1517 Authors' Addresses 1519 Carl Wallace 1520 Cygnacom Solutions 1521 7927 Jones Branch Dr. Suite 100 West 1522 McLean, VA 22102-3305 1523 Email: cwallace@cygnacom.com 1525 Santosh Chokhani 1526 Orion Security Solutions 1527 3410 N. Buchanan Street 1528 Arlington, VA 22207 1529 Email: chokhani@orionsec.com 1531 Appendix A: Support for non-TAP aware clients and alternative submission 1532 request formats 1534 In some cases it may be desirable to accept archive submissions from 1535 clients that are not TAP-aware. The following table describes the 1536 submission alternatives. 1538 Client Auth. Message format Archive target 1539 software method 1541 TAP-aware Transport ContentInfo containing Contents of 1542 and/or CMS SignedData w/ data field in 1543 ArchiveSubmissionReq in ArchivedData 1544 encapContentInfo field structure 1546 TAP-aware Transport ContentInfo containing Contents of 1547 ArchiveSubmissionReq data field in 1548 ArchivedData 1549 structure 1551 Non-TAP- Transport Any other format Entire message 1552 aware and/or (possibly unknown or 1553 message determined from 1554 format transport, i.e. mime 1555 type, file extension, 1556 etc.) 1558 Retrieval and deletion requests are likely to be relatively rare 1559 compared to submission requests. In the interest of supporting a 1560 broad range of submission clients, it may be desirable to support 1561 alternative archive submission formats, for example, an XML 1562 submission request. Non-TAP-compliant submission formats MUST NOT 1563 use TAP-defined transport layer type information. TAA 1564 implementations could support alternative submission types via a 1565 plug-in architecture. Regardless of submission means, archive 1566 information MUST be represented using TAP-defined archive tokens, 1567 records and packages for retrieval and deletion requests.