idnits 2.17.1 draft-ietf-pkix-tamp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 21, 2010) is 5119 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) -- Looks like a reference, but probably isn't: '1' on line 3436 -- Looks like a reference, but probably isn't: '2' on line 3422 -- Looks like a reference, but probably isn't: '0' on line 3466 -- Looks like a reference, but probably isn't: '3' on line 3343 -- Looks like a reference, but probably isn't: '4' on line 3344 -- Looks like a reference, but probably isn't: '5' on line 3345 == Missing Reference: 'CMS' is mentioned on line 3171, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-pkix-new-asn1-07 ** Downref: Normative reference to an Informational draft: draft-ietf-pkix-new-asn1 (ref. 'I-D.ietf-pkix-new-asn1') ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) == Outdated reference: A later version (-06) exists of draft-ietf-pkix-ta-mgmt-reqs-04 -- Obsolete informational reference (is this intentional?): RFC 3281 (Obsoleted by RFC 5755) -- Obsolete informational reference (is this intentional?): RFC 4049 (Obsoleted by RFC 6019) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley 3 Internet-Draft Vigil Security, LLC 4 Intended status: Standards Track S. Ashmore 5 Expires: October 23, 2010 National Security Agency 6 C. Wallace 7 Cygnacom Solutions 8 April 21, 2010 10 Trust Anchor Management Protocol (TAMP) 11 draft-ietf-pkix-tamp-08 13 Abstract 15 This document describes a transport independent protocol for the 16 management of trust anchors and community identifiers stored in a 17 trust anchor store. The protocol makes use of the Cryptographic 18 Message Syntax (CMS), and a digital signature is used to provide 19 integrity protection and data origin authentication. The protocol 20 can be used to manage trust anchor stores containing trust anchors 21 represented as Certificate, TBSCertificate or TrustAnchorInfo 22 objects. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on October 23, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.2. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 5 78 1.2.1. Apex Trust Anchors . . . . . . . . . . . . . . . . . . 7 79 1.2.2. Management Trust Anchors . . . . . . . . . . . . . . . 8 80 1.2.3. Identity Trust Anchors . . . . . . . . . . . . . . . . 8 81 1.3. Architectural Elements . . . . . . . . . . . . . . . . . . 8 82 1.3.1. Cryptographic Module . . . . . . . . . . . . . . . . . 8 83 1.3.2. Trust Anchor Store . . . . . . . . . . . . . . . . . . 9 84 1.3.3. TAMP Processing Dependencies . . . . . . . . . . . . . 10 85 1.3.4. Application-Specific Protocol Processing . . . . . . . 11 86 1.4. ASN.1 Encoding . . . . . . . . . . . . . . . . . . . . . . 12 87 2. Cryptographic Message Syntax Profile . . . . . . . . . . . . . 13 88 2.1. Content Info . . . . . . . . . . . . . . . . . . . . . . . 14 89 2.2. SignedData Info . . . . . . . . . . . . . . . . . . . . . 14 90 2.2.1. SignerInfo . . . . . . . . . . . . . . . . . . . . . . 15 91 2.2.2. EncapsulatedContentInfo . . . . . . . . . . . . . . . 17 92 2.2.3. Signed Attributes . . . . . . . . . . . . . . . . . . 17 93 2.2.4. Unsigned Attributes . . . . . . . . . . . . . . . . . 18 94 3. Trust Anchor Formats . . . . . . . . . . . . . . . . . . . . . 20 95 4. Trust Anchor Management Protocol Messages . . . . . . . . . . 21 96 4.1. TAMP Status Query . . . . . . . . . . . . . . . . . . . . 23 97 4.2. TAMP Status Query Response . . . . . . . . . . . . . . . . 26 98 4.3. Trust Anchor Update . . . . . . . . . . . . . . . . . . . 29 99 4.3.1. Trust Anchor List . . . . . . . . . . . . . . . . . . 34 100 4.4. Trust Anchor Update Confirm . . . . . . . . . . . . . . . 34 101 4.5. Apex Trust Anchor Update . . . . . . . . . . . . . . . . . 36 102 4.6. Apex Trust Anchor Update Confirm . . . . . . . . . . . . . 39 103 4.7. Community Update . . . . . . . . . . . . . . . . . . . . . 41 104 4.8. Community Update Confirm . . . . . . . . . . . . . . . . . 43 105 4.9. Sequence Number Adjust . . . . . . . . . . . . . . . . . . 45 106 4.10. Sequence Number Adjust Confirm . . . . . . . . . . . . . . 46 107 4.11. TAMP Error . . . . . . . . . . . . . . . . . . . . . . . . 47 108 5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . 49 109 6. Sequence Number Processing . . . . . . . . . . . . . . . . . . 54 110 7. Subordination Processing . . . . . . . . . . . . . . . . . . . 56 111 8. Implementation Considerations . . . . . . . . . . . . . . . . 59 112 9. Apex trust anchor info certificate extension . . . . . . . . . 60 113 10. Security Considerations . . . . . . . . . . . . . . . . . . . 61 114 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 116 12.1. Normative References . . . . . . . . . . . . . . . . . . . 65 117 12.2. Informative References . . . . . . . . . . . . . . . . . . 65 118 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 67 119 A.1. ASN.1 Module Using 1993 Syntax . . . . . . . . . . . . . . 67 120 A.2. ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . 76 122 Appendix B. Media Type Registrations . . . . . . . . . . . . . . 84 123 B.1. application/tamp-status-query . . . . . . . . . . . . . . 84 124 B.2. application/tamp-status-response . . . . . . . . . . . . . 85 125 B.3. application/tamp-update . . . . . . . . . . . . . . . . . 86 126 B.4. application/tamp-update-confirm . . . . . . . . . . . . . 87 127 B.5. application/tamp-apex-update . . . . . . . . . . . . . . . 88 128 B.6. application/tamp-apex-update-confirm . . . . . . . . . . . 89 129 B.7. application/tamp-community-update . . . . . . . . . . . . 90 130 B.8. application/tamp-community-update-confirm . . . . . . . . 91 131 B.9. application/tamp-sequence-adjust . . . . . . . . . . . . . 92 132 B.10. application/tamp-sequence-adjust-confirm . . . . . . . . . 93 133 B.11. application/tamp-error . . . . . . . . . . . . . . . . . . 94 134 Appendix C. TAMP Over HTTP . . . . . . . . . . . . . . . . . . . 95 135 C.1. TAMP Status Query Message . . . . . . . . . . . . . . . . 95 136 C.2. TAMP Status Response Message . . . . . . . . . . . . . . . 95 137 C.3. Trust Anchor Update Message . . . . . . . . . . . . . . . 96 138 C.4. Trust Anchor Update Confirm Message . . . . . . . . . . . 96 139 C.5. Apex Trust Anchor Update Message . . . . . . . . . . . . . 96 140 C.6. Apex Trust Anchor Update Confirm Message . . . . . . . . . 96 141 C.7. Community Update Message . . . . . . . . . . . . . . . . . 96 142 C.8. Community Update Confirm Message . . . . . . . . . . . . . 97 143 C.9. Sequence Number Adjust Message . . . . . . . . . . . . . . 97 144 C.10. Sequence Number Adjust Confirm Message . . . . . . . . . . 97 145 C.11. TAMP Error Message . . . . . . . . . . . . . . . . . . . . 97 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 98 148 1. Introduction 150 This document describes the Trust Anchor Management Protocol (TAMP). 151 TAMP may be used to manage the trust anchors and community 152 identifiers in any device that uses digital signatures; however, this 153 specification was written with the requirements of cryptographic 154 modules in mind. For example, TAMP can support signed firmware 155 packages [RFC4108], where the trust anchor public key can be used to 156 validate digital signatures on firmware packages or validate the 157 X.509 certification path [RFC5280][X.509] of the firmware package 158 signer. 160 Most TAMP messages are digitally signed to provide integrity 161 protection and data origin authentication. Both signed and unsigned 162 TAMP messages employ the Cryptographic Message Syntax (CMS) 163 [RFC3852]. The CMS is a data protection encapsulation syntax that 164 makes use of ASN.1 [X.680]. 166 This specification does not provide for confidentiality of TAMP 167 messages. If confidentiality is required, then the communications 168 environment that is used to transfer TAMP messages must provide it. 169 This specification is intended to satisfy the protocol-related 170 requirements expressed in Trust Anchor Management Requirements 171 [I-D.draft-ietf-pkix-ta-mgmt-reqs] and uses vocabulary from that 172 document. 174 TAMP messages may be exchanged in real time over a network, such as 175 via HTTP as described in appendix A, or may be stored and transferred 176 using other means. TAMP exchanges consist of a request message that 177 includes instructions for a trust anchor store and, optionally, a 178 corresponding response message that reports the result of carrying 179 out the instructions in the request. Response messages need not be 180 propagated in all cases. For example, a GPS receiver may be unable 181 to transmit a response and may instead use an attached display to 182 indicate the results of processing a TAMP request. 184 1.1. Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119 [RFC2119]. 190 1.2. Trust Anchors 192 TAMP manages trust anchors. A trust anchor contains a public key 193 that is used to validate digital signatures. TAMP recognizes three 194 formats for representing trust anchor information: Certificate 195 [RFC5280], TBSCertificate [RFC5280] and TrustAnchorInfo 197 [I-D.ietf-pkix-ta-format]. 199 All trust anchors are distinguished by the public key, and all trust 200 anchors consist of the following components: 202 o A public key signature algorithm identifier and associated public 203 key, which MAY include parameters 205 o A public key identifier 207 Other information may appear in a trust anchor, including 208 certification path processing controls and a human readable name. 210 TAMP recognizes three types of trust anchors based on functionality: 211 apex trust anchors, management trust anchors, and identity trust 212 anchors. 214 In addition to the information described above, apex trust anchors 215 and management trust anchors that sign TAMP messages have an 216 associated sequence number that is used for replay detection. 218 The public key is used to name a trust anchor, and the public key 219 identifier is used to identify the trust anchor as a signer of a 220 particular object, such as a SignedData object or a public key 221 certificate. This public key identifier can be stored with the trust 222 anchor, or in most public key identifier assignment methods, it can 223 be computed from the public key whenever needed. 225 A trust anchor public key can be used in two different ways to 226 support digital signature validation. In the first approach, the 227 trust anchor public key is used directly to validate the digital 228 signature. In the second approach, the trust anchor public key is 229 used to validate an X.509 certification path, and then the subject 230 public key in the final certificate in the certification path is used 231 to validate the digital signature. When the second approach is 232 employed, the certified public key may be used for things other than 233 digital signature validation; the other possible actions are 234 constrained by the key usage certificate extension. 236 TAMP implementations MUST support validation of TAMP messages that 237 are directly validated using a trust anchor. Support for TAMP 238 messages validated using an X.509 certificate validated using a trust 239 anchor, or using longer certification paths, is OPTIONAL. The CMS 240 provides a location to carry X.509 certificates, and this facility 241 can be used to transfer certificates to aid in the construction of 242 the certification path. 244 1.2.1. Apex Trust Anchors 246 Within the context of a single trust anchor store, one trust anchor 247 is superior to all others. This trust anchor is referred to as the 248 apex trust anchor. This trust anchor represents the ultimate 249 authority over the trust anchor store. Much of this authority can be 250 delegated to other trust anchors. 252 The apex trust anchor private key is expected to be controlled by an 253 entity with information assurance responsibility for the trust anchor 254 store. The apex trust anchor is by definition unconstrained and 255 therefore does not have explicit authorization information associated 256 with it. 258 Due to the special nature of the apex trust anchor, TAMP includes 259 separate facilities to change it. In particular, TAMP includes a 260 facility to securely replace the apex trust anchor. This action 261 might be taken for one or more of the following reasons: 263 o The crypto period for the apex trust anchor public/private key 264 pair has come to an end 266 o The apex trust anchor private key is no longer available 268 o The apex trust anchor public/private key pair needs to be revoked 270 o The authority has decided to use a different digital signature 271 algorithm or the same digital signature algorithm with different 272 parameters, such as a different elliptic curve 274 o The authority has decided to use a different key size 276 o The authority has decided to transfer control to another authority 278 To accommodate these requirements, the apex trust anchor MAY include 279 two public keys. Whenever the apex trust anchor is updated, both 280 public keys would be replaced. The first public key, called the 281 operational public key, is used in the same manner as other trust 282 anchors. Any type of TAMP message, including an Apex Trust Anchor 283 Update message, can be validated with the operational public key. 284 The second public key, called the contingency public key, can only be 285 used to update the apex trust anchor. The contingency private key 286 SHOULD be used at only one point in time; it is used only to sign an 287 Apex Trust Anchor Update message which results in its own replacement 288 (as well as the replacement of the operational public key). The 289 contingency public key is distributed in encrypted form. When the 290 contingency public key is used to validate an Apex Trust Anchor 291 Update message, the symmetric key needed to decrypt the contingency 292 public key is provided as part of the signed Apex Trust Anchor Update 293 message that is to be verified with the contingency public key. 295 1.2.2. Management Trust Anchors 297 Management trust anchors are used in the management of cryptographic 298 modules. For example, the TAMP messages specified in this document 299 are validated to a management trust anchor. Likewise, a signed 300 firmware package as specified in [RFC4108] is validated to a 301 management trust anchor. 303 1.2.3. Identity Trust Anchors 305 Identity trust anchors are used to validate certification paths, and 306 they represent the trust anchor for a public key infrastructure. 307 They are most often used in the validation of certificates associated 308 with non-management applications. 310 1.3. Architectural Elements 312 TAMP does not assume any particular architecture. However, TAMP 313 REQUIRES the following architectural elements: a cryptographic 314 module, a trust anchor store, TAMP protocol processing, and other 315 application-specific protocol processing. 317 A globally unique algorithm identifier MUST be assigned for each one- 318 way hash function, digital signature generation/validation algorithm, 319 and symmetric key unwrapping algorithm that is implemented. To 320 support CMS, an object identifier (OID) is assigned to name a one-way 321 hash function, and another OID is assigned to name each combination 322 of a one-way hash function when used with a digital signature 323 algorithm. Similarly, certificates associate OIDs assigned to public 324 key algorithms with subject public keys, and certificates make use of 325 an OID that names both the one-way hash function and the digital 326 signature algorithm for the certificate issuer digital signature. 327 [RFC3279], [RFC3370], [RFC5753] and [RFC5754] provide OIDs for a 328 number of commonly used algorithms, however, OIDs many be defined in 329 later or different specifications. 331 1.3.1. Cryptographic Module 333 The cryptographic module MUST include the following capabilities: 335 o The cryptographic module SHOULD support the secure storage of a 336 digital signature private key to sign TAMP responses and either a 337 certificate containing the associated public key or a certificate 338 designator. In the latter case, the certificate is stored 339 elsewhere but is available to parties that need to validate 340 cryptographic module digital signatures. The designator is a 341 public key identifier. 343 o The cryptographic module MUST support at least one one-way hash 344 function, one digital signature validation algorithm, one digital 345 signature generation algorithm, and, if contingency keys are 346 supported, one symmetric key unwrapping algorithm. If only one 347 one-way hash function is present, it MUST be consistent with the 348 digital signature validation and digital signature generation 349 algorithms. If only one digital signature validation algorithm is 350 present, it MUST be consistent with the apex trust anchor 351 operational public key. If only one digital signature generation 352 algorithm is present, it MUST be consistent with the cryptographic 353 module digital signature private key. These algorithms MUST be 354 available for processing TAMP messages, including the content 355 types defined in [RFC3852], and for validation of X.509 356 certification paths. As with similar specifications, such as RFC 357 5280, this specification does not mandate support for any 358 cryptographic algorithms. However, algorithm requirements may be 359 imposed by specifications that use trust anchors managed via TAMP. 361 1.3.2. Trust Anchor Store 363 The trust anchor store MUST include the following capabilities: 365 o Each trust anchor store MUST have a unique name. For example, a 366 cryptographic module containing a single trust anchor store may be 367 identified by a unique serial number with respect to other modules 368 within the same family where the family is represented as an ASN.1 369 object identifier (OID) and the unique serial number is 370 represented as a string of octets. Other means of establishing a 371 unique name are also possible. 373 o Each trust anchor store SHOULD have the capability to securely 374 store one or more community identifiers. The community identifier 375 is an OID, and it identifies a collection of cryptographic modules 376 that can be the target of a single TAMP message or the intended 377 recipients for a particular management message. 379 o The trust anchor store SHOULD support the use of an apex trust 380 anchor. If apex support is provided, the trust anchor store MUST 381 support the secure storage of exactly one apex trust anchor. The 382 trust anchor store SHOULD support the secure storage of at least 383 one additional trust anchor. Each trust anchor MUST contain a 384 unique public key. A public key MUST NOT appear more than once in 385 a trust anchor store. 387 o The trust anchor store MUST have the capability to securely store 388 a sequence number for each trust anchor authorized to generate 389 TAMP messages and be able to report the sequence number along with 390 the key identifier of the trust anchor. 392 1.3.3. TAMP Processing Dependencies 394 TAMP processing MUST include the following capabilities: 396 o TAMP processing MUST have a means of locating an appropriate trust 397 anchor. Two mechanisms are available. The first mechanism is 398 based on the public key identifier for digital signature 399 verification, and the second mechanism is based on the trust 400 anchor X.500 distinguished name and other X.509 certification path 401 controls for certificate path discovery and validation. The first 402 mechanism MUST be supported, but the second mechanism MAY be 403 supported. 405 o TAMP processing MUST be able to invoke the digital signature 406 validation algorithm using the public key held in secure storage 407 for trust anchors. 409 o TAMP processing MUST have read and write access to secure storage 410 for sequence numbers associated with each TAMP message signer as 411 described in Section 6. 413 o TAMP processing MUST have read and write access to secure storage 414 for trust anchors in order to update them. Update operations 415 include adding trust anchors, removing trust anchors, and 416 modifying trust anchors. Application-specific constraints MUST be 417 securely stored with each management trust anchor as described in 418 Section 1.3.4. 420 o TAMP processing MUST have read access to secure storage for the 421 community membership list, if any, to determine whether a targeted 422 message ought to be accepted. 424 o To implement the OPTIONAL community identifier update feature, 425 TAMP processing MUST have read and write access to secure storage 426 for the community membership list. 428 o To generate signed confirmation messages, TAMP processing MUST be 429 able to invoke the digital signature generation algorithm using 430 the cryptographic module digital signature private key, and it 431 MUST have read access to the cryptographic module certificate or 432 its designator. TAMP uses X.509 certificates [RFC5280]. 434 o The TAMP processing MUST have read access to the trust anchor 435 store unique name. 437 1.3.4. Application-Specific Protocol Processing 439 The apex trust anchor and management trust anchors managed with TAMP 440 can be used by the TAMP application. Other management applications 441 MAY make use of all three types of trust anchors, but non-management 442 applications SHOULD only make use of identity trust anchors. 443 Applications MUST ensure usage of a trust anchor is consistent with 444 any constraints associated with the trust anchor. For example, if 445 name constraints are associated with a trust anchor, certification 446 paths that start with the trust anchor and contain certificates with 447 names that violate the name constraints MUST be rejected. 449 The application-specific protocol processing MUST be provided with 450 the following services: 452 o The application-specific protocol processing MUST have a means of 453 locating an appropriate trust anchor. Two mechanisms are 454 available to applications. The first mechanism is based on the 455 public key identifier for digital signature verification, and the 456 second mechanism is based on the trust anchor X.500 distinguished 457 name and other X.509 certification path controls for certificate 458 path discovery and validation. 460 o The application-specific protocol processing MUST be able to 461 invoke the digital signature validation algorithm using the public 462 key held in secure storage for trust anchors. 464 o The application-specific protocol processing MUST have read access 465 to data associated with trust anchors to ensure constraints can be 466 enforced appropriately. For example, an application MUST have 467 read access to any name constraints associated with a TA to ensure 468 certification paths terminated by that TA do not include 469 certificates issued to entities outside the TA manager-designated 470 namespace. 472 o The application-specific protocol processing MUST have read access 473 to secure storage for the community membership list, if any, to 474 determine whether a targeted message ought to be accepted. 476 o If the application-specific protocol requires digital signatures 477 on confirmation messages or receipts, then the application- 478 specific protocol processing MUST be able to invoke the digital 479 signature generation algorithm with the cryptographic module 480 digital signature private key and its associated certificate or 481 certificate designator. Digital signature generation MUST be 482 controlled in a manner that ensures that the content type of 483 signed confirmation messages or receipts is appropriate for the 484 application-specific protocol processing. 486 o The application-specific protocol processing MUST have read access 487 to the trust anchor store unique name. 489 1.4. ASN.1 Encoding 491 The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is 492 a formal notation used for describing data protocols, regardless of 493 the programming language used by the implementation. Encoding rules 494 describe how the values defined in ASN.1 will be represented for 495 transmission. The Basic Encoding Rules (BER) [X.690] are the most 496 widely employed rule set, but they offer more than one way to 497 represent data structures. For example, definite length encoding and 498 indefinite length encoding are supported. This flexibility is not 499 desirable when digital signatures are used. As a result, the 500 Distinguished Encoding Rules (DER) [X.690] were invented. DER is a 501 subset of BER that ensures a single way to represent a given value. 502 For example, DER always employs definite length encoding. 504 Digitally signed structures MUST be encoded with DER. In other 505 specifications, structures that are not digitally signed do not 506 require DER, but in this specification, DER is REQUIRED for all 507 structures. By always using DER, the TAMP processor will have fewer 508 options to implement. 510 ASN.1 is used throughout the text of the document for illustrative 511 purposes. The authoritative source of ASN.1 for the structures 512 defined in this document is Appendix A. 514 2. Cryptographic Message Syntax Profile 516 TAMP makes use of signed and unsigned messages. The Cryptographic 517 Message Syntax (CMS) is used in both cases. A digital signature is 518 used to protect the message from undetected modification and provide 519 data origin authentication. TAMP makes no general provision for 520 encryption of content. 522 CMS is used to construct a signed TAMP message. The CMS ContentInfo 523 content type MUST always be present. For signed messages, 524 ContentInfo MUST encapsulate the CMS SignedData content type; for 525 unsigned messages, ContentInfo MUST encapsulate the TAMP message 526 directly. The CMS SignedData content type MUST encapsulate the TAMP 527 message. A unique content type identifier identifies the particular 528 type of TAMP message. The CMS encapsulation of a signed TAMP message 529 is summarized by: 531 ContentInfo { 532 contentType id-signedData, -- (1.2.840.113549.1.7.2) 533 content SignedData 534 } 536 SignedData { 537 version CMSVersion, -- Always set to 3 538 digestAlgorithms DigestAlgorithmIdentifiers, -- Only one 539 encapContentInfo EncapsulatedContentInfo, 540 certificates CertificateSet, -- OPTIONAL signer certificates 541 crls CertificateRevocationLists, -- OPTIONAL 542 signerInfos SET OF SignerInfo -- Only one 543 } 545 SignerInfo { 546 version CMSVersion, -- Always set to 3 547 sid SignerIdentifier, 548 digestAlgorithm DigestAlgorithmIdentifier, 549 signedAttrs SignedAttributes, 550 -- REQUIRED in TAMP messages 551 signatureAlgorithm SignatureAlgorithmIdentifier, 552 signature SignatureValue, 553 unsignedAttrs UnsignedAttributes -- OPTIONAL; may only be 554 } -- present in Apex Trust 555 -- Anchor Update messages 557 EncapsulatedContentInfo { 558 eContentType OBJECT IDENTIFIER, -- Names TAMP message type 559 eContent OCTET STRING -- Contains TAMP message 560 } 562 When a TAMP message is used to update the apex trust anchor, this 563 same structure is used; however, the digital signature will be 564 validated with either the apex trust anchor operational public key or 565 the contingency public key. When the contingency public key is used, 566 the symmetric key needed to decrypt the previously stored contingency 567 public key is provided as a contingency-public-key-decrypt-key 568 unsigned attribute. Section 4.5 of this document describes the Apex 569 Trust Anchor Update message. 571 CMS is also used to construct an unsigned TAMP message. The CMS 572 ContentInfo structure MUST always be present, and it MUST be the 573 outermost layer of encapsulation. A unique content type identifier 574 identifies the particular TAMP message. The CMS encapsulation of an 575 unsigned TAMP message is summarized by: 577 ContentInfo { 578 contentType OBJECT IDENTIFIER, -- Names TAMP message type 579 content OCTET STRING -- Contains TAMP message 580 } 582 2.1. Content Info 584 CMS requires the outer-most encapsulation to be ContentInfo 585 [RFC3852]. The fields of ContentInfo are used as follows: 587 o contentType indicates the type of the associated content, and for 588 TAMP, the encapsulated type is either SignedData or the content 589 type identifier associated with an unsigned TAMP message. When 590 the id-signedData (1.2.840.113549.1.7.2) object identifier is 591 present in this field, then a signed TAMP message is in the 592 content. Otherwise, an unsigned TAMP message is in the content. 594 o content holds the content, and for TAMP, the content is either a 595 SignedData content or an unsigned TAMP message. 597 2.2. SignedData Info 599 The SignedData content type [RFC3852] contains the signed TAMP 600 message and a digital signature value; the SignedData content type 601 MAY also contain the certificates needed to validate the digital 602 signature. The fields of SignedData are used as follows: 604 o version is the syntax version number, and for TAMP, the version 605 number MUST be set to 3. 607 o digestAlgorithms is a collection of one-way hash function 608 identifiers, and for TAMP, it contains a single one-way hash 609 function identifier. The one-way hash function employed by the 610 TAMP message originator in generating the digital signature MUST 611 be present. 613 o encapContentInfo is the signed content, consisting of a content 614 type identifier and the content itself. The use of the 615 EncapsulatedContentInfo type is discussed further in Section 616 2.2.2. 618 o certificates is an OPTIONAL collection of certificates. It MAY be 619 omitted, or it MAY include the X.509 certificates needed to 620 construct the certification path of the TAMP message originator. 621 For TAMP messages sent to a trust anchor store where an apex trust 622 anchor or management trust anchor is used directly to validate the 623 TAMP message digital signature, this field SHOULD be omitted. 624 When an apex trust anchor or management trust anchor is used to 625 validate an X.509 certification path [RFC5280], and the subject 626 public key from the final certificate in the certification path is 627 used to validate the TAMP message digital signature, the 628 certificate of the TAMP message originator SHOULD be included, and 629 additional certificates to support certification path construction 630 MAY be included. For TAMP messages sent by a trust anchor store, 631 this field SHOULD include only the signer's certificate or be 632 omitted. A TAMP message recipient MUST NOT reject a valid TAMP 633 message that contains certificates that are not needed to validate 634 the digital signature. PKCS#6 extended certificates [PKCS#6] and 635 attribute certificates (either version 1 or version 2) [RFC3281] 636 MUST NOT be included in the set of certificates; these certificate 637 formats are not used in TAMP. Certification Authority (CA) 638 certificates and end entity certificates MUST conform to the 639 profiles defined in [RFC5280]. 641 o crls is an OPTIONAL collection of certificate revocation lists 642 (CRLs). 644 o signerInfos is a collection of per-signer information, and for 645 TAMP, the collection MUST contain exactly one SignerInfo. The use 646 of the SignerInfo type is discussed further in Section 2.2.1. 648 2.2.1. SignerInfo 650 The TAMP message originator is represented in the SignerInfo type. 651 The fields of SignerInfo are used as follows: 653 o version is the syntax version number. With TAMP, the version MUST 654 be set to 3. 656 o sid identifies the TAMP message originator's public key. The 657 subjectKeyIdentifier alternative is always used with TAMP, which 658 identifies the public key directly. When the public key is 659 included in a TrustAnchorInfo object, this identifier is included 660 in the keyId field. When the public key is included in a 661 Certificate or TBSCertificate, this identifier is included in the 662 subjectKeyIdentifier certificate extension. 664 o digestAlgorithm identifies the one-way hash function, and any 665 associated parameters, used by the TAMP message originator. It 666 MUST contain the one-way hash functions employed by the 667 originator. This message digest algorithm identifier MUST match 668 the one carried in the digestAlgorithms field in SignedData. The 669 message digest algorithm identifier is carried in two places to 670 facilitate stream processing by the receiver. 672 o signedAttrs is an OPTIONAL set of attributes that are signed along 673 with the content. The signedAttrs are OPTIONAL in the CMS, but 674 signedAttrs is REQUIRED for all signed TAMP messages. The SET OF 675 Attribute MUST be encoded with the distinguished encoding rules 676 (DER) [X.690]. Section 2.2.3 of this document lists the signed 677 attributes that MUST be included in the collection. Other signed 678 attributes MAY be included, but any unrecognized signed attributes 679 MUST be ignored. 681 o signatureAlgorithm identifies the digital signature algorithm, and 682 any associated parameters, used by the TAMP message originator to 683 generate the digital signature. 685 o signature is the digital signature value generated by the TAMP 686 message originator. 688 o unsignedAttrs is an OPTIONAL set of attributes that are not 689 signed. For TAMP, this field is usually omitted. It is present 690 only in Apex Trust Anchor Update messages that are to be validated 691 using the apex trust anchor contingency public key. In this case, 692 the SET OF Attribute MUST include the symmetric key needed to 693 decrypt the contingency public key in the contingency-public-key- 694 decrypt-key unsigned attribute. Section 2.2.4 of this document 695 describes this unsigned attribute. 697 2.2.2. EncapsulatedContentInfo 699 The EncapsulatedContentInfo structure contains the TAMP message. The 700 fields of EncapsulatedContentInfo are used as follows: 702 o eContentType is an object identifier that uniquely specifies the 703 content type, and for TAMP, the value identifies the TAMP message. 704 The list of TAMP message content types is provided in Section 4. 706 o eContent is the TAMP message, encoded as an octet string. In 707 general, the CMS does not require the eContent to be DER-encoded 708 before constructing the octet string. However, TAMP messages MUST 709 be DER encoded. 711 2.2.3. Signed Attributes 713 The TAMP message originator MUST digitally sign a collection of 714 attributes along with the TAMP message. Each attribute in the 715 collection MUST be DER-encoded. The syntax for attributes is defined 716 in [I-D.ietf-pkix-new-asn1] 718 Each of the attributes used with this CMS profile has a single 719 attribute value. Even though the syntax is defined as a SET OF 720 AttributeValue, there MUST be exactly one instance of AttributeValue 721 present. 723 The SignedAttributes syntax within SignerInfo is defined as a SET OF 724 Attribute. The SignedAttributes MUST include only one instance of 725 any particular attribute. TAMP messages that violate this rule MUST 726 be rejected as malformed. 728 The TAMP message originator MUST include the content-type and 729 message-digest attributes. The TAMP message originator MAY also 730 include the binary-signing-time. 732 The TAMP message originator MAY include any other attribute that it 733 deems appropriate. The intent is to allow additional signed 734 attributes to be included if a future need is identified. This does 735 not cause an interoperability concern because unrecognized signed 736 attributes MUST be ignored. 738 The following summarizes the signed attribute requirements for TAMP 739 messages: 741 o content-type MUST be supported. 743 o message-digest MUST be supported. 745 o binary-signing-time MAY be supported. Generally ignored by the 746 recipient. 748 o other attributes MAY be supported. Unrecognized attributes MUST 749 be ignored by the recipient. 751 2.2.3.1. Content-Type Attribute 753 The TAMP message originator MUST include a content-type attribute; it 754 is an object identifier that uniquely specifies the content type. 755 Section 11.1 of [RFC3852] defines the content-type attribute. For 756 TAMP, the value identifies the TAMP message. The list of TAMP 757 message content types and their identifiers is provided in Section 4. 759 A content-type attribute MUST contain the same object identifier as 760 the content type contained in the EncapsulatedContentInfo. 762 2.2.3.2. Message-Digest Attribute 764 The TAMP message originator MUST include a message-digest attribute, 765 having as its value the output of a one-way hash function computed on 766 the TAMP message that is being signed. Section 11.2 of [RFC3852] 767 defines the message-digest attribute. 769 2.2.3.3. Binary-Signing-Time Attribute 771 The TAMP message originator MAY include a binary-signing-time 772 attribute, specifying the time at which the digital signature was 773 applied to the TAMP message. The binary-signing-time attribute is 774 defined in [RFC4049]. 776 No processing of the binary-signing-time attribute is REQUIRED of a 777 TAMP message recipient; however, the binary-signing-time attribute 778 MAY be included by the TAMP message originator as a form of message 779 identifier. 781 2.2.4. Unsigned Attributes 783 For TAMP, unsigned attributes are usually omitted. An unsigned 784 attribute is present only in Apex Trust Anchor Update messages that 785 are to be validated by the apex trust anchor contingency public key. 786 In this case, the symmetric key to decrypt the previous contingency 787 public key is provided in the contingency-public-key-decrypt-key 788 unsigned attribute. This attribute MUST be supported, and it is 789 described in Section 2.2.4.1. 791 The TAMP message originator SHOULD NOT include other unsigned 792 attributes, and any unrecognized unsigned attributes MUST be ignored. 794 The UnsignedAttributes syntax within SignerInfo is defined as a SET 795 OF Attribute. The UnsignedAttributes MUST include only one instance 796 of any particular attribute. TAMP messages that violate this rule 797 MUST be rejected as malformed. 799 2.2.4.1. Contingency Public Key Decrypt Key Attribute 801 The contingency-public-key-decrypt-key attribute provides the 802 plaintext symmetric key needed to decrypt the previously distributed 803 apex trust anchor contingency public key. The symmetric key MUST be 804 useable with the symmetric algorithm used to previously encrypt the 805 contingency public key. 807 The contingency-public-key-decrypt-key attribute has the following 808 syntax: 810 contingency-public-key-decrypt-key ATTRIBUTE ::= { 811 WITH SYNTAX PlaintextSymmetricKey 812 SINGLE VALUE TRUE 813 ID id-aa-TAMP-contingencyPublicKeyDecryptKey } 815 id-aa-TAMP-contingencyPublicKeyDecryptKey 816 OBJECT IDENTIFIER ::= { id-attributes 63 } 818 PlaintextSymmetricKey ::= OCTET STRING 820 3. Trust Anchor Formats 822 TAMP recognizes three formats for representing trust anchor 823 information within the protocol itself: Certificate [RFC5280], 824 TBSCertificate [RFC5280] and TrustAnchorInfo 825 [I-D.ietf-pkix-ta-format]. The TrustAnchorChoice structure, defined 826 in [I-D.ietf-pkix-ta-format], is used to select one of these options. 828 TrustAnchorChoice ::= CHOICE { 829 certificate Certificate, 830 tbsCert [1] EXPLICIT TBSCertificate, 831 taInfo [2] EXPLICIT TrustAnchorInfo } 833 The Certificate structure is commonly used to represent trust 834 anchors. Certificates include a signature, which removes the ability 835 for relying parties to customize the information within the structure 836 itself. TBSCertificate contains all of the information of the 837 Certificate structure except for the signature, enabling tailoring of 838 the information. TrustAnchorInfo is intended to serve as a 839 minimalist representation of trust anchor information for scenarios 840 where storage or bandwidth is highly constrained. 842 Implementations are not required to support all three options. The 843 unsupportedTrustAnchorFormat error code should be indicated when 844 generating a TAMPError due to receipt of an unsupported trust anchor 845 format. 847 4. Trust Anchor Management Protocol Messages 849 TAMP makes use of signed and unsigned messages. The CMS is used in 850 both cases. An object identifier is assigned to each TAMP message 851 type, and this object identifier is used as a content type in the 852 CMS. 854 TAMP specifies eleven message types. The following provides the 855 content type identifier for each TAMP message type, and it indicates 856 whether a digital signature is required. If the following indicates 857 that the TAMP message MUST be signed, then implementations MUST 858 reject a message of that type that is not signed. 860 o The TAMP Status Query message MUST be signed. It uses the 861 following object identifier: { id-tamp 1 }. 863 o The TAMP Status Response message SHOULD be signed. It uses the 864 following object identifier: { id-tamp 2 }. 866 o The Trust Anchor Update message MUST be signed. It uses the 867 following object identifier: { id-tamp 3 }. 869 o The Trust Anchor Update Confirm message SHOULD be signed. It uses 870 the following object identifier: { id-tamp 4 }. 872 o The Apex Trust Anchor Update message MUST be signed. It uses the 873 following object identifier: { id-tamp 5 }. 875 o The Apex Trust Anchor Update Confirm message SHOULD be signed. It 876 uses the following object identifier: { id-tamp 6 }. 878 o The Community Update message MUST be signed. It uses the 879 following object identifier: { id-tamp 7 }. 881 o The Community Update Confirm message SHOULD be signed. It uses 882 the following object identifier: { id-tamp 8 }. 884 o The Sequence Number Adjust MUST be signed. It uses the following 885 object identifier: { id-tamp 10 }. 887 o The Sequence Number Adjust Confirm message SHOULD be signed. It 888 uses the following object identifier: { id-tamp 11 }. 890 o The TAMP Error message SHOULD be signed. It uses the following 891 object identifier: { id-tamp 9 }. 893 Trust anchor managers generate TAMP Status Query, Trust Anchor 894 Update, Apex Trust Anchor Update, Community Update and Sequence 895 Number Adjust messages. Trust anchor stores generate TAMP Status 896 Response, Trust Anchor Update Confirm, Apex Trust Anchor Update 897 Confirm, Community Update Confirm, Sequence Number Adjust Confirm and 898 TAMP Error messages. 900 Support for Trust Anchor Update messages is REQUIRED. Support for 901 all other message formats is RECOMMENDED. Implementations that 902 support the HTTP binding described in Appendix C MUST additionally 903 support Trust Anchor Update Confirm and TAMP Error message and MAY 904 support 0 or more of the following pairs of messages: TAMP Status 905 Query and TAMP Status Query Response; Apex Trust Anchor Update and 906 Apex Trust Anchor Update Confirm; Community Update and Community 907 Update Confirm; Sequence Number Adjust and Sequence Number Adjust 908 Confirm. Implementations that operate in a disconnected manner MUST 909 NOT assume a response will be received from each consumer of a TAMP 910 message. 912 A typical interaction between a trust anchor manager and a trust 913 anchor store will follow the message flow shown in Figure 4-1. 914 Figure 4-1 does not illustrate a flow where an error occurs. 916 +---------+ +----------+ 917 | | Trust Anchor Status Query | | 918 | |------------------------------->| | 919 | | | | 920 | | Trust Anchor Status Response | | 921 | Trust |<-------------------------------| Trust | 922 | Anchor | | Anchor | 923 | Manager | Trust Anchor Update | Store | 924 | |------------------------------->| | 925 | | | | 926 | | Trust Anchor Update Confirm | | 927 | |<-------------------------------| | 928 | | | | 929 +---------+ +----------+ 931 Figure 4-1: Typical TAMP Message Flow 933 Each TAMP query and update message include an indication of the type 934 of response that is desired. The response can either be terse or 935 verbose. All trust anchor stores MUST support both the terse and 936 verbose responses and SHOULD generate a response of the type 937 indicated in the corresponding request. TAMP response processors 938 MUST support processing both terse and verbose responses 940 Trust anchor stores SHOULD be able to process and properly act upon 941 the valid payload of the TAMP Status Query message, the Trust Anchor 942 Update message, the Apex Trust Anchor Update message, and the 943 Sequence Number Adjust message. TAMP implementations MAY also 944 process and act upon the valid payload of the Community Update 945 message. 947 TAMP implementations SHOULD support generation of the TAMP Status 948 Response message, the Trust Anchor Update Confirm message, the Apex 949 Trust Anchor Update Confirm message, the Sequence Number Adjust 950 Confirm message, and the TAMP Error message. If a TAMP 951 implementation supports the Community Update message, then generation 952 of Community Update Confirm messages SHOULD also be supported. 954 4.1. TAMP Status Query 956 The TAMP Status Query message is used to request information about 957 the trust anchors that are currently installed in a trust anchor 958 store, and for the list of communities to which the store belongs. 959 The TAMP Status Query message MUST be signed. For the query message 960 to be valid, the trust anchor store MUST be an intended recipient of 961 the query, the sequence number checking described in Section 6 MUST 962 be successful when the TAMP message signer is a trust anchor, and the 963 digital signature MUST be validated by the apex trust anchor 964 operational public key, an authorized management trust anchor, or via 965 an authorized X.509 certification path originating with such a trust 966 anchor. 968 If the digital signature on the TAMP Status Query message is valid, 969 sequence number checking is successful, the signer is authorized, and 970 the trust anchor store is an intended recipient of the TAMP message, 971 then a TAMP Status Response message SHOULD be returned. If a TAMP 972 Status Response message is not returned, then a TAMP Error message 973 SHOULD be returned. 975 The TAMP Status Query content type has the following syntax: 977 CONTENT-TYPE ::= TYPE-IDENTIFIER 979 tamp-status-query CONTENT-TYPE ::= 980 { TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery } 982 id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 } 984 TAMPStatusQuery ::= SEQUENCE { 985 Version [0] TAMPVersion DEFAULT v2, 986 terse [1] TerseOrVerbose DEFAULT verbose, 987 query TAMPMsgRef } 989 TAMPVersion ::= INTEGER { v1(1), v2(2) } 991 TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) } 993 TAMPMsgRef ::= SEQUENCE { 994 target TargetIdentifier, 995 seqNum SeqNumber } 997 SeqNumber ::= INTEGER (0..9223372036854775807) 999 TargetIdentifier ::= CHOICE { 1000 hwModules [1] HardwareModuleIdentifierList, 1001 communities [2] CommunityIdentifierList, 1002 allModules [3] NULL, 1003 uri [4] IA5String, 1004 otherName [5] AnotherName} 1006 HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF 1007 HardwareModules 1009 HardwareModules ::= SEQUENCE { 1010 hwType OBJECT IDENTIFIER, 1011 hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry } 1013 HardwareSerialEntry ::= CHOICE { 1014 all NULL, 1015 single OCTET STRING, 1016 block SEQUENCE { 1017 low OCTET STRING, 1018 high OCTET STRING } } 1020 CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community 1022 Community ::= OBJECT IDENTIFIER 1024 The fields of TAMPStatusQuery are used as follows: 1026 o version identifies version of TAMP. For this version of the 1027 specification, the default value, v2, MUST be used. 1029 o terse indicates the type of response that is desired. A terse 1030 response is indicated by a value of 1, and a verbose response is 1031 indicated by a value of 2, which is omitted during encoding since 1032 it is the default value. 1034 o query contains two items: the target and the seqNum. target 1035 identifies the target(s) of the query message. seqNum is a single 1036 use value that will be used to match the TAMP Status Query message 1037 with the TAMP Status Response message. The sequence number is 1038 also used to detect TAMP message replay. The sequence number 1039 processing described in Section 6 MUST successfully complete 1040 before a response is returned. 1042 The fields of TAMPMsgRef are used as follows: 1044 o target identifies the target(s) of the query. Several 1045 alternatives for naming a target are provided. To identify a 1046 cryptographic module, a combination of a cryptographic type and 1047 serial number are used. The cryptographic type is represented as 1048 an ASN.1 object identifier, and the unique serial number is 1049 represented as a string of octets. To facilitate compact 1050 representation of serial numbers, a contiguous block can be 1051 specified by the lowest included serial number and the highest 1052 included serial number. When present, the high and low octet 1053 strings MUST have the same length. The 1054 HardwareModuleIdentifierList sequence MUST NOT contain duplicate 1055 hwType values, so that each member of the sequence names all of 1056 the cryptographic modules of this type. Object identifiers are 1057 also used to identify communities of trust anchor stores. A 1058 sequence of these object identifiers is used if more than one 1059 community is the target of the message. A trust anchor store is 1060 considered a target if it is a member of any of the listed 1061 communities. An explicit NULL value is used to identify all 1062 modules that consider the signer of the TAMP message to be an 1063 authorized source for that message type. The uri field can be 1064 used to identify a target, i.e., a trust anchor store, using a 1065 Uniform Resource Identifier [RFC3986]. Additional name types are 1066 supported via the otherName field, which is of type AnotherName. 1067 AnotherName is defined in [RFC5280]. The format and semantics of 1068 the name are indicated through the OBJECT IDENTIFIER in the 1069 type-id field. The name itself is conveyed as value field in 1070 otherName. Implementations MUST support the allModules option and 1071 SHOULD support all TargetIdentifier options. 1073 o seqNum contains a single use value that will be used to match the 1074 TAMP Status Query message with the successful TAMP Status Response 1075 message. The sequence number processing described in Section 6 1076 MUST successfully complete before a response is returned. 1078 To determine whether a particular cryptographic module serial number 1079 is considered part of a specified block, all of the following 1080 conditions MUST be met. First, the cryptographic module serial 1081 number MUST be the same length as both the high and low octet 1082 strings. Second, the cryptographic module serial number MUST be 1083 greater than or equal to the low octet string. Third, the 1084 cryptographic module serial number MUST be less than or equal to the 1085 high octet string. 1087 One octet string is equal to another if they are of the same length 1088 and are the same at each octet position. An octet string, S1, is 1089 greater than another, S2, where S1 and S2 have the same length, if 1090 and only if S1 and S2 have different octets in one or more positions, 1091 and in the first such position, the octet in S1 is greater than that 1092 in S2, considering the octets as unsigned binary numbers. Note that 1093 these octet string comparison definitions are consistent with those 1094 in clause 6 of [X.690]. 1096 4.2. TAMP Status Query Response 1098 The TAMP Status Response message is a reply by a trust anchor store 1099 to a valid TAMP Status Query message. The TAMP Status Response 1100 message provides information about the trust anchors that are 1101 currently installed in the trust anchor store and the list of 1102 communities to which the trust anchor store belongs, if any. The 1103 TAMP Status Response message MAY be signed or unsigned. A TAMP 1104 Status Response message MUST be signed if the implementation is 1105 capable of signing it. 1107 The TAMP Status Response content type has the following syntax: 1109 tamp-status-response CONTENT-TYPE ::= 1110 { TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse } 1112 id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 } 1114 TAMPStatusResponse ::= SEQUENCE { 1115 version [0] TAMPVersion DEFAULT v2, 1116 query TAMPMsgRef, 1117 response StatusResponse, 1118 usesApex BOOLEAN DEFAULT TRUE} 1120 StatusResponse ::= CHOICE { 1121 terseResponse [0] TerseStatusResponse, 1122 verboseResponse [1] VerboseStatusResponse } 1124 TerseStatusResponse ::= SEQUENCE { 1125 taKeyIds KeyIdentifiers, 1126 communities CommunityIdentifierList OPTIONAL } 1128 KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier 1130 VerboseStatusResponse ::= SEQUENCE { 1131 taInfo TrustAnchorChoiceList, 1132 continPubKeyDecryptAlg [0] AlgorithmIdentifier OPTIONAL, 1133 communities [1] CommunityIdentifierList OPTIONAL, 1134 tampSeqNumbers [2] TAMPSequenceNumbers OPTIONAL } 1136 TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF 1137 TrustAnchorChoice 1139 TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF TAMPSequenceNumber 1141 TAMPSequenceNumber ::= SEQUENCE { 1142 keyId KeyIdentifier, 1143 seqNumber SeqNumber } 1145 The fields of TAMPStatusResponse are used as follows: 1147 o version identifies version of TAMP. For this version of the 1148 specification, the default value, v2, MUST be used. 1150 o query identifies the TAMPStatusQuery to which the trust anchor 1151 store is responding. The query structure repeats the TAMPMsgRef 1152 from the TAMP Status Query message (see Section 4.1). The 1153 sequence number processing described in Section 6 MUST 1154 successfully complete before any response is returned. 1156 o response contains either a terse response or a verbose response. 1157 The terse response is represented by TerseStatusResponse, and the 1158 verbose response is represented by VerboseStatusResponse. 1160 o usesApex is a boolean value that indicates whether the first item 1161 in the TerseStatusResponse.taKeyIds or 1162 VerboseStatusResponse.taInfo field identifies the apex TA. 1164 The fields of TerseStatusResponse are used as follows: 1166 o taKeyIds contains a sequence of key identifiers. Each trust 1167 anchor contained in the trust anchor store is represented by one 1168 key identifier. When TAMPStatusResponse.usesApex is TRUE, the 1169 apex trust anchor is represented by the first key identifier in 1170 the sequence, which contains the key identifier of the operational 1171 public key. 1173 o communities is OPTIONAL. When present, it contains a sequence of 1174 object identifiers. Each object identifier names one community to 1175 which this trust anchor store belongs. When the trust anchor 1176 store belongs to no communities, this field is omitted. 1178 The fields of VerboseStatusResponse are used as follows: 1180 o taInfo contains a sequence of TrustAnchorChoice structures. One 1181 entry in the sequence is provided for each trust anchor contained 1182 in the trust anchor store. When TAMPStatusResponse.usesApex is 1183 TRUE, the apex trust anchor is the first trust anchor in the 1184 sequence. 1186 o continPubKeyDecryptAlg is OPTIONAL. When present, it indicates 1187 the decryption algorithm needed to decrypt the currently installed 1188 apex trust anchor contingency public key, if a contingency key is 1189 associated with the apex trust anchor. When present, 1190 TAMPStatusResponse.usesApex MUST be TRUE. 1192 o communities is OPTIONAL. When present, it contains a sequence of 1193 object identifiers. Each object identifier names one community to 1194 which this trust anchor store belongs. When the trust anchor 1195 store belongs to no communities, this field is omitted. 1197 o tampSeqNumbers is OPTIONAL. When present, it is used to indicate 1198 the currently held sequence number for each trust anchor 1199 authorized to sign TAMP messages. The keyId field identifies the 1200 trust anchor and the seqNumber field provides the current sequence 1201 number associated with the trust anchor. 1203 4.3. Trust Anchor Update 1205 The Trust Anchor Update message is used to add, remove, and change 1206 management and identity trust anchors. The Trust Anchor Update 1207 message cannot be used to update the apex trust anchor. The Trust 1208 Anchor Update message MUST be signed. For a Trust Anchor Update 1209 message to be valid, the trust anchor store MUST be an intended 1210 recipient of the update, the sequence number checking described in 1211 Section 6 MUST be successful when the TAMP message signer is a trust 1212 anchor, and the digital signature MUST be validated using the apex 1213 trust anchor operational public key, an authorized management trust 1214 anchor, or via an authorized X.509 certification path originating 1215 with such a trust anchor. 1217 If the digital signature on the Trust Anchor Update message is valid, 1218 sequence number checking is successful, the signer is authorized, and 1219 the trust anchor store is an intended recipient of the TAMP message, 1220 then the trust anchor store MUST perform the specified updates and 1221 return a Trust Anchor Update Confirm message. If a Trust Anchor 1222 Update Confirm message is not returned, then a TAMP Error message 1223 SHOULD be returned. 1225 The Trust Anchor Update content type has the following syntax: 1227 tamp-update CONTENT-TYPE ::= 1228 { TAMPUpdate IDENTIFIED BY id-ct-TAMP-update } 1230 id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 } 1232 TAMPUpdate ::= SEQUENCE { 1233 version [0] TAMPVersion DEFAULT v2, 1234 terse [1] TerseOrVerbose DEFAULT verbose, 1235 msgRef TAMPMsgRef, 1236 updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate, 1237 tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL } 1239 TrustAnchorUpdate ::= CHOICE { 1240 add [1] TrustAnchorChoice, 1241 remove [2] SubjectPublicKeyInfo, 1242 change [3] EXPLICIT TrustAnchorChangeInfoChoice } 1244 TrustAnchorChangeInfoChoice ::= CHOICE { 1245 tbsCertChange [0] TBSCertificateChangeInfo, 1246 taChange [1] TrustAnchorChangeInfo } 1248 TBSCertificateChangeInfo ::= SEQUENCE { 1249 serialNumber CertificateSerialNumber OPTIONAL, 1250 signature [0] AlgorithmIdentifier OPTIONAL, 1251 issuer [1] Name OPTIONAL, 1252 validity [2] Validity OPTIONAL, 1253 subject [3] Name OPTIONAL, 1254 subjectPublicKeyInfo [4] SubjectPublicKeyInfo, 1255 exts [5] EXPLICIT Extensions OPTIONAL } 1257 TrustAnchorChangeInfo ::= SEQUENCE { 1258 pubKey SubjectPublicKeyInfo, 1259 keyId KeyIdentifier OPTIONAL, 1260 taTitle TrustAnchorTitle OPTIONAL, 1261 certPath CertPathControls OPTIONAL, 1262 exts [1] Extensions OPTIONAL} 1264 The fields of TAMPUpdate are used as follows: 1266 o version identifies version of TAMP. For this version of the 1267 specification, the default value, v2, MUST be used. 1269 o terse indicates the type of response that is desired. A terse 1270 response is indicated by a value of 1, and a verbose response is 1271 indicated by a value of 2, which is omitted during encoding since 1272 it is the default value. 1274 o msgRef contains two items: the target and the seqNum. target 1275 identifies the target(s) of the update message. The 1276 TargetIdentifier syntax is described in Section 4.1. seqNum is a 1277 single use value that will be used to match the Trust Anchor 1278 Update message with the Trust Anchor Update Confirm message. The 1279 sequence number is also used to detect TAMP message replay. The 1280 sequence number processing described in Section 6 MUST 1281 successfully complete before any of the updates are processed. 1283 o updates contains a sequence of updates, which are used to add, 1284 remove, and change management or identity trust anchors. Each 1285 entry in the sequence represents one of these actions, and is 1286 indicated by an instance of TrustAnchorUpdate. The actions are a 1287 batch of updates that MUST be processed in the order that they 1288 appear, but each of the updates is processed independently. Each 1289 of the updates MUST satisfy the subordination checks described in 1290 Section 7. Even if one or more of the updates fail, then the 1291 remaining updates MUST be processed. These updates MUST NOT make 1292 any changes to the apex trust anchor. 1294 o tampSeqNumbers MAY be included to provide the initial or new 1295 sequence numbers for trust anchors added or changed by the updates 1296 field. Elements included in the tampSeqNumbers field that do not 1297 correspond to an element in the updates field are ignored. 1298 Elements included in the tampSeqNumbers field that do correspond 1299 to an element in the updates field and contain a sequence number 1300 less than or equal to the most recently stored sequence number for 1301 the trust anchor are ignored. Elements included in the 1302 tampSeqNumbers field that do correspond to an element in the 1303 updates field and contain a sequence number greater than the most 1304 recently stored sequence number for the indicated trust anchor are 1305 processed by setting the stored sequence number for the trust 1306 anchor equal to the new value. 1308 The TrustAnchorUpdate is a choice of three structures, and each 1309 alternative represents one of the three possible actions: add, 1310 remove, and change. A description of the syntax associated with each 1311 of these actions follows: 1313 o add is used to insert a new management or identity trust anchor 1314 into the trust anchor store. The TrustAnchorChoice structure is 1315 used to provide the trusted public key and all of the information 1316 associated with it. However, the action MUST fail with the error 1317 code notAuthorized if the subordination checks described in 1318 Section 7 are not satisfied. See Section 3 for a discussion of 1319 the TrustAnchorChoice structure. The apex trust anchor cannot be 1320 introduced into a trust anchor store using this action; therefore 1321 the id-pe-wrappedApexContinKey MUST NOT not be present in the 1322 extensions field. The constraints of the existing trust anchors 1323 are unchanged by this action. An attempt to add a management or 1324 identity trust anchor that is already in place with the same 1325 values for every field in the TrustAnchorChoice structure MUST be 1326 treated as a successful addition. An attempt to add a management 1327 or identity trust anchor that is already present with the same 1328 pubKey values, but with different values for any of the fields in 1329 the TrustAnchorChoice structure, MUST fail with the error code 1330 improperTAAddition. This means a trust anchor may not be added 1331 twice using different TrustAnchorChoice options. If a different 1332 format is desired, the existing trust anchor must be removed and 1333 the new format added. 1335 o remove is used to delete an existing management or identity trust 1336 anchor from the trust anchor store, including the deletion of the 1337 management trust anchor associated with the TAMP message signer. 1338 However, the action MUST fail with the error code notAuthorized if 1339 the subordination checks described in Section 7 are not satisfied. 1340 The public key contained in SubjectPublicKeyInfo names the 1341 management or identity trust anchor to be deleted. An attempt to 1342 delete a trust anchor that is not present MUST be treated as a 1343 successful deletion. The constraints of the deleted trust anchor 1344 are not distributed to other trust anchors in any manner. The 1345 apex trust anchor cannot be removed using this action, which 1346 ensures that this action cannot place the trust anchor store in an 1347 unrecoverable configuration. 1349 o change is used to update the information associated with an 1350 existing management or identity trust anchor in the trust anchor 1351 store. Attempts to change a trust anchor added as a Certificate 1352 MUST fail with the error code improperTAChange. The public key 1353 contained in the SubjectPublicKeyInfo field of 1354 TrustAnchorChangeInfo or in the subjectPublicKeyInfo field of a 1355 TBSCertificateChangeInfo names the to-be-updated trust anchor. 1356 However, the action MUST fail with the error code notAuthorized if 1357 the subordination checks described in Section 7 are not satisfied. 1358 An attempt to change a trust anchor that is not present MUST 1359 result in a failure with the trustAnchorNotFound status code. The 1360 TrustAnchorChangeInfo structure or the TBSCertificateChangeInfo 1361 structure is used to provide the revised configuration of the 1362 management or identity trust anchor. If the update fails for any 1363 reason, then the original trust anchor configuration MUST be 1364 preserved. The apex trust anchor information cannot be changed 1365 using this action. Attempts to change a trust anchor added as a 1366 TBSCertificate using a TrustAnchorChangeInfo MUST fail with an 1367 improperTAChange error. Attempts to change a trust anchor added 1368 as a TrustAnchorInfo using a TBSCertificateChangeInfo MUST fail 1369 with an improperTAChange error. 1371 The fields of TrustAnchorChangeInfo are used as follows: 1373 o pubKey contains the algorithm identifier and the public key of the 1374 management or identity trust anchor. It is used to locate the to- 1375 be-updated trust anchor in the trust anchor store. 1377 o keyId is OPTIONAL, and when present, it contains the public key 1378 identifier of the trust anchor public key, which is contained in 1379 the pubKey field. If this field is not present, then the public 1380 key identifier remains unchanged. If this field is present, the 1381 provided public key identifier replaces the previous one. 1383 o taTitle is OPTIONAL, and when present, it provides a human 1384 readable name for the management or identity trust anchor. When 1385 absent in a change trust anchor update, any title that was 1386 previously associated with the trust anchor is removed. 1387 Similarly, when present in a change trust anchor update, the title 1388 in the message is associated with the trust anchor. If a previous 1389 title was associated with the trust anchor, then the title is 1390 replaced. If a title was not previously associated with the trust 1391 anchor, then the title from the update message is added. 1393 o certPath is OPTIONAL, and when present, it provides the controls 1394 needed to construct and validate an X.509 certification path. 1395 When absent in a change trust anchor update, any controls that 1396 were previously associated with the management or identity trust 1397 anchor are removed, which means that delegation is no longer 1398 permitted. Similarly, when present in a change trust anchor 1399 update, the controls in the message are associated with the 1400 management or identity trust anchor. If previous controls, 1401 including the trust anchor distinguished name, were associated 1402 with the trust anchor, then the controls are replaced, which means 1403 that delegation continues to be supported, but that different 1404 certification paths will be valid. If controls were not 1405 previously associated with the management or identity trust 1406 anchor, then the controls from the update message are added, which 1407 enables delegation. The syntax and semantics of CertPathControls 1408 is discussed in [I-D.ietf-pkix-ta-format]. 1410 o exts is OPTIONAL, and when present, it provides the extensions 1411 values that are associated with the trust anchor. When absent in 1412 a change trust anchor update, any extensions that were previously 1413 associated with the trust anchor are removed. Similarly, when 1414 present in a change trust anchor update, the extensions in the 1415 message are associated with the trust anchor. Any extensions 1416 previously associated with the trust anchor are replaced or 1417 removed. 1419 The fields of TBSCertificateChangeInfo are used to alter the fields 1420 within a TBSCertificate structure. TBSCertificate is described in 1421 [RFC5280]. For all fields except exts, if the field is absent in a 1422 change trust anchor update, then any previous value associated with a 1423 trust anchor is unchanged. For the exts field, if the field is 1424 absent in a change trust anchor update, then any previous value 1425 associated with a trust anchor is removed. For all fields, if the 1426 field is present in a change trust anchor update, then any previous 1427 value associated with a trust anchor is replaced with the value from 1428 the update message. 1430 4.3.1. Trust Anchor List 1432 [I-D.ietf-pkix-ta-format] defines the TrustAnchorList structure to 1433 convey a list of trust anchors. TAMP implementations MAY process 1434 TrustAnchorList objects (with eContentType (or contentType) using the 1435 id-ct-trustAnchorList OID defined in [I-D.ietf-pkix-ta-format]) as 1436 equivalent to TAMPUpdate objects with terse set to terse, msgRef set 1437 to allModules (with a suitable sequence number) and all elements 1438 within the list contained within the add field. This alternative to 1439 TrustAnchorUpdate is provided for implementations that perform 1440 integrity and authorization checks out-of-band as a simple means of 1441 transferring trust anchors from one trust anchor store to another. 1442 It does not provide means of removing or changing trust anchors and 1443 has no HTTP binding. 1445 4.4. Trust Anchor Update Confirm 1447 The Trust Anchor Update Confirm message is a reply by a trust anchor 1448 store to a valid Trust Anchor Update message. The Trust Anchor 1449 Update Confirm message provides success and failure information for 1450 each of the requested updates. The Trust Anchor Update Confirm 1451 message MAY be signed or unsigned. A Trust Anchor Update Confirm 1452 message MUST be signed if the implementation is capable of signing 1453 it. 1455 The Trust Anchor Update Confirm content type has the following 1456 syntax: 1458 tamp-update-confirm CONTENT-TYPE ::= 1459 { TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm } 1461 id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 } 1463 TAMPUpdateConfirm ::= SEQUENCE { 1464 version [0] TAMPVersion DEFAULT v2, 1465 update TAMPMsgRef, 1466 confirm UpdateConfirm } 1468 UpdateConfirm ::= CHOICE 1469 terseConfirm [0] TerseUpdateConfirm, 1470 verboseConfirm [1] VerboseUpdateConfirm } 1472 TerseUpdateConfirm ::= StatusCodeList 1474 StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode 1476 VerboseUpdateConfirm ::= SEQUENCE { 1477 status StatusCodeList, 1478 taInfo TrustAnchorChoiceList, 1479 tampSeqNumbers TAMPSequenceNumbers OPTIONAL, 1480 usesApex BOOLEAN DEFAULT TRUE} 1482 The fields of TAMPUpdateConfirm are used as follows: 1484 o version identifies version of TAMP. For this version of the 1485 specification, the default value, v2, MUST be used. 1487 o update identifies the TAMPUpdate message to which the trust anchor 1488 store is responding. The update structure repeats the TAMPMsgRef 1489 from the Trust Anchor Update message (see Section 4.3). The 1490 sequence number processing described in Section 6 MUST 1491 successfully complete before any of the updates are processed. 1493 o confirm contains either a terse update confirmation or a verbose 1494 update confirmation. The terse update confirmation is represented 1495 by TerseUpdateConfirm, and the verbose response is represented by 1496 VerboseUpdateConfirm. 1498 The TerseUpdateConfirm contains a sequence of status codes, one for 1499 each TrustAnchorUpdate structure in the Trust Anchor Update message. 1500 The status codes MUST appear in the same order as the 1501 TrustAnchorUpdate structures to which they apply, and the number of 1502 elements in the status code list MUST be the same as the number of 1503 elements in the trust anchor update list. Each of the status codes 1504 is discussed in Section 5. 1506 The fields of VerboseUpdateConfirm are used as follows: 1508 o status contains a sequence of status codes, one for each 1509 TrustAnchorUpdate structure in the Trust Anchor Update message. 1510 The status codes appear in the same order as the TrustAnchorUpdate 1511 structures to which they apply, and the number of elements in the 1512 status code list MUST be the same as the number of elements in the 1513 trust anchor update list. Each of the status codes is discussed 1514 in Section 5. 1516 o taInfo contains a sequence of TrustAnchorChoice structures. One 1517 entry in the sequence is provided for each trust anchor contained 1518 in the trust anchor store. These represent the state of the trust 1519 anchors after the updates have been processed. When usesApex is 1520 true, the apex trust anchor is the first trust anchor in the 1521 sequence. 1523 o tampSeqNumbers is used to indicate the currently held sequence 1524 number for each trust anchor authorized to sign TAMP messages. 1525 The keyId field identifies the trust anchor and the seqNumber 1526 field provides the current sequence number associated with the 1527 trust anchor. 1529 o usesApex is a boolean value that indicates whether the first item 1530 in the taInfo field identifies the apex TA. 1532 4.5. Apex Trust Anchor Update 1534 The Apex Trust Anchor Update message replaces the operational public 1535 key and, optionally, the contingency public key associated with the 1536 apex trust anchor. Each trust anchor store has exactly one apex 1537 trust anchor. No constraints are associated with the apex trust 1538 anchor. The public key identifier of the operational public key is 1539 used to identify the apex trust anchor in subsequent TAMP messages. 1540 The digital signature on the Apex Trust Anchor Update message is 1541 validated with either the current operational public key or the 1542 current contingency public key. For the Apex Trust Anchor Update 1543 message that is validated with the operational public key to be 1544 valid, the trust anchor store MUST be a target of the update, the 1545 sequence number MUST be larger than the most recently stored sequence 1546 number for the operational public key, and the digital signature MUST 1547 be validated directly with the operational public key. That is, no 1548 delegation via a certification path is permitted. For the Apex Trust 1549 Anchor Update message that is validated with the contingency public 1550 key to be valid, the trust anchor store MUST be a target of the 1551 update, the provided decryption key MUST properly decrypt the 1552 contingency public key, and the digital signature MUST be validated 1553 directly with the decrypted contingency public key. Again, no 1554 delegation via a certification path is permitted. 1556 If the Apex Trust Anchor Update message is validated using the 1557 operational public key, then sequence number processing is handled 1558 normally, as described in Section 6. If the Apex Trust Anchor Update 1559 message is validated using the contingency public key, then the 1560 TAMPMsgRef sequence number MUST contain a zero value. A sequence 1561 number for subsequent messages that will be validated with the new 1562 operational public key can optionally be provided. If no value is 1563 provided, then the trust anchor store MUST be prepared to accept any 1564 sequence number in the next TAMP message validated with the newly- 1565 installed apex trust anchor operational public key. If the Apex 1566 Trust Anchor Update message is valid and the clearTrustAnchors flag 1567 is set to TRUE, then all of the management and identity trust anchors 1568 stored in the trust anchor store MUST be deleted. That is, the new 1569 apex trust anchor MUST be the only trust anchor remaining in the 1570 trust anchor store. If the Apex Trust Anchor Update message is valid 1571 and the clearCommunities flag is set to TRUE, then all community 1572 identifiers stored in the trust anchor store MUST be deleted. 1574 The SignedData structure includes a sid value, and it identifies the 1575 apex trust anchor public key that will be used to validate the 1576 digital signature on this TAMP message. The public key identifier 1577 for the operational public key is known in advance, and it is stored 1578 as part of the apex trust anchor. The public key identifier for the 1579 contingency public key is not known in advance; however, the presence 1580 of the unsigned attribute containing the symmetric key needed to 1581 decrypt the contingency public key unambiguously indicates that the 1582 TAMP message signer used the contingency private key to sign the Apex 1583 Trust Anchor Update message. 1585 If the digital signature on the Apex Trust Anchor Update message is 1586 valid using either the apex trust anchor operational public key or 1587 the apex trust anchor contingency public key, sequence number 1588 checking is successful, and the trust anchor store is an intended 1589 recipient of the TAMP message, then the trust anchor store MUST 1590 update the apex trust anchor and return an Apex Trust Anchor Update 1591 Confirm message. If an Apex Trust Anchor Update Confirm message is 1592 not returned, then a TAMP Error message SHOULD be returned. Note 1593 that the sequence number MUST be zero if the Apex Trust Anchor Update 1594 message is validated with the apex trust anchor contingency public 1595 key. 1597 The Apex Trust Anchor Update content type has the following syntax: 1599 tamp-apex-update CONTENT-TYPE ::= 1600 { TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate } 1602 id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 } 1604 TAMPApexUpdate ::= SEQUENCE { 1605 version [0] TAMPVersion DEFAULT v2, 1606 terse [1] TerseOrVerbose DEFAULT verbose, 1607 msgRef TAMPMsgRef, 1608 clearTrustAnchors BOOLEAN, 1609 clearCommunities BOOLEAN, 1610 seqNumber SeqNumber OPTIONAL, 1611 apexTA TrustAnchorChoice } 1613 The fields of TAMPApexUpdate are used as follows: 1615 o version identifies version of TAMP. For this version of the 1616 specification, the default value, v2, MUST be used. 1618 o terse indicates the type of response that is desired. A terse 1619 response is indicated by a value of 1, and a verbose response is 1620 indicated by a value of 2, which is omitted during encoding since 1621 it is the default value. 1623 o msgRef contains two items: the target and the seqNum. target 1624 identifies the target(s) of the Apex Trust Anchor Update message. 1625 The TargetIdentifier syntax as described in Section 4.1 is used. 1626 seqNum is a single use value that will be used to match the Apex 1627 Trust Anchor Update message with the Apex Trust Anchor Update 1628 Confirm message. The sequence number is also used to detect TAMP 1629 message replay if the message is validated with the apex trust 1630 anchor operational public key. The sequence number processing 1631 described in Section 6 MUST successfully complete before any 1632 action is taken. However, seqNum MUST contain a zero value if the 1633 message is validated with the apex trust anchor contingency public 1634 key. 1636 o clearTrustAnchors is a Boolean. If the value is set to TRUE, then 1637 all of the management and identity trust anchors stored in the 1638 trust anchor store MUST be deleted, leaving the newly installed 1639 apex trust anchor as the only trust anchor in the trust anchor 1640 store. If the value is set to FALSE, the other trust anchors MUST 1641 NOT be changed. 1643 o clearCommunities is a Boolean. If the value is set to TRUE, then 1644 all of the community identifiers stored in the trust anchor store 1645 MUST be deleted, leaving none. If the value is set to FALSE, the 1646 list of community identifiers MUST NOT be changed. 1648 o seqNumber is OPTIONAL, and when present, it provides the initial 1649 sequence number for the apex trust anchor, if present. If 1650 seqNumber is absent, the trust anchor store is prepared to accept 1651 any sequence number value for the apex trust anchor operational 1652 public key. 1654 o apexTA provides the information for the replacement apex trust 1655 anchor. The TrustAnchorChoice structure is used to provide the 1656 trusted public key and all of the information associated with it. 1657 The pubKey, keyId, taTitle, certPath and exts fields apply to the 1658 operational public key of the apex trust anchor. The 1659 ApexTrustAnchorInfo certificate extension MAY appear as an 1660 extension. Section 9 describes the ApexTrustAnchorInfo 1661 certificate extension. 1663 4.6. Apex Trust Anchor Update Confirm 1665 The Apex Trust Anchor Update Confirm message is a reply by a trust 1666 anchor store to a valid Apex Trust Anchor Update message. The Apex 1667 Trust Anchor Update Confirm message provides success or failure 1668 information for the apex trust anchor update. The Apex Trust Anchor 1669 Update Confirm message MAY be signed or unsigned. An Apex Trust 1670 Anchor Update Confirm message MUST be signed if the trust anchor 1671 store is capable of signing it. 1673 The Apex Trust Anchor Update Confirm content type has the following 1674 syntax: 1676 tamp-apex-update-confirm CONTENT-TYPE ::= 1677 { TAMPApexUpdateConfirm IDENTIFIED BY 1678 id-ct-TAMP-apexUpdateConfirm } 1680 id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 } 1682 TAMPApexUpdateConfirm ::= SEQUENCE { 1683 version [0] TAMPVersion DEFAULT v2, 1684 apexReplace TAMPMsgRef, 1685 apexConfirm ApexUpdateConfirm } 1687 ApexUpdateConfirm ::= CHOICE { 1688 terseApexConfirm [0] TerseApexUpdateConfirm, 1689 verboseApexConfirm [1] VerboseApexUpdateConfirm } 1691 TerseApexUpdateConfirm ::= StatusCode 1693 VerboseApexUpdateConfirm ::= SEQUENCE { 1694 status StatusCode, 1695 taInfo TrustAnchorChoiceList, 1696 communities [0] CommunityIdentifierList OPTIONAL, 1697 tampSeqNumbers [1] TAMPSequenceNumbers OPTIONAL } 1699 The fields of TAMPApexUpdateConfirm are used as follows: 1701 o version identifies version of TAMP. For this version of the 1702 specification, the default value, v2, MUST be used. 1704 o apexReplace identifies the Apex Trust Anchor Update message to 1705 which the trust anchor store is responding. The apexReplace 1706 structure repeats the TAMPMsgRef from the beginning of the Apex 1707 Trust Anchor Update message (see Section 4.5). When the Apex 1708 Trust Anchor Update message is validated with the operational 1709 public key, the sequence number processing described in Section 6 1710 MUST successfully complete before an Apex Trust Anchor Update 1711 Confirm message is generated. When the Apex Trust Anchor Update 1712 message is validated with the contingency public key, normal 1713 sequence number processing is ignored, but the seqNum MUST be 1714 zero. 1716 o apexConfirm contains either a terse update confirmation or a 1717 verbose update confirmation. The terse update confirmation is 1718 represented by TerseApexUpdateConfirm, and the verbose response is 1719 represented by VerboseApexUpdateConfirm. 1721 The TerseApexUpdateConfirm contains a single status code, indicating 1722 the success or failure of the apex trust anchor update. If the apex 1723 trust anchor update failed, then the status code provides the reason 1724 for the failure. Each of the status codes is discussed in Section 5. 1726 The fields of VerboseApexUpdateConfirm are used as follows: 1728 o status contains a single status code, indicating the success or 1729 failure of the apex trust anchor update. If the apex trust anchor 1730 update failed, then the status code provides the reason for the 1731 failure. Each of the status codes is discussed in Section 5. 1733 o taInfo contains a sequence of TrustAnchorChoice structures. One 1734 entry in the sequence is provided for each trust anchor contained 1735 in the trust anchor store. These represent the state of the trust 1736 anchors after the apex trust anchor update has been processed. 1737 See [I-D.ietf-pkix-ta-format] for a description of the 1738 TrustAnchorInfo structure. The apex trust anchor is the first 1739 trust anchor in the sequence. 1741 o communities is OPTIONAL. When present, it contains a sequence of 1742 object identifiers. Each object identifier names one community to 1743 which this trust anchor store belongs. When the trust anchor 1744 store belongs to no communities, this field is omitted. 1746 o tampSeqNumbers is used to indicate the currently held sequence 1747 number for each trust anchor authorized to sign TAMP messages. 1748 The keyId field identifies the trust anchor and the seqNumber 1749 field provides the current sequence number associated with the 1750 trust anchor. 1752 4.7. Community Update 1754 The trust anchor store maintains a list of identifiers for the 1755 communities of which it is a member. The Community Update message 1756 can be used to remove or add community identifiers from this list. 1757 The Community Update message MUST be signed. For the Community 1758 Update message to be valid, the trust anchor store MUST be a target 1759 of the update, the sequence number checking described in Section 6 1760 MUST be successful when the TAMP message signer is a trust anchor, 1761 and the digital signature MUST be validated by the apex trust anchor 1762 operational public key, an authorized management trust anchor, or via 1763 an authorized X.509 certification path originating with such a trust 1764 anchor. 1766 If the trust anchor store supports the Community Update message, the 1767 digital signature on the Community Update message is valid, sequence 1768 number checking is successful, the signer is authorized, and the 1769 trust anchor store is an intended recipient of the TAMP message, then 1770 the trust anchor store MUST make the specified updates and return a 1771 Community Update Confirm message. If a Community Update Confirm 1772 message is not returned, then, a TAMP Error message SHOULD be 1773 returned. 1775 The Community Update message contains a batch of updates, and all of 1776 the updates MUST be accepted for the trust anchor store to return a 1777 successful Community Update Confirm message. The remove updates, if 1778 present, MUST be processed before the add updates. Where remove is 1779 present with an empty list, all community identifiers MUST be 1780 removed. This approach prevents community identifiers that are 1781 intended to be mutually exclusive from being installed by a 1782 successful addition and a failed removal. Where add is present, at 1783 least one community identifier MUST appear in the list. 1785 The Community Update content type has the following syntax: 1787 tamp-community-update CONTENT-TYPE ::= 1788 { TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate } 1790 id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 } 1792 TAMPCommunityUpdate ::= SEQUENCE { 1793 version [0] TAMPVersion DEFAULT v2, 1794 terse [1] TerseOrVerbose DEFAULT verbose, 1795 msgRef TAMPMsgRef, 1796 updates CommunityUpdates } 1798 CommunityUpdates ::= SEQUENCE { 1799 remove [1] CommunityIdentifierList OPTIONAL, 1800 add [2] CommunityIdentifierList OPTIONAL } 1801 -- At least one MUST be present 1803 The fields of TAMPCommunityUpdate are used as follows: 1805 o version identifies version of TAMP. For this version of the 1806 specification, the default value, v2, MUST be used. 1808 o terse indicates the type of response that is desired. A terse 1809 response is indicated by a value of 1, and a verbose response is 1810 indicated by a value of 2, which is omitted during encoding since 1811 it is the default value. 1813 o msgRef contains two items: the target and the seqNum. target 1814 identifies the target(s) of the update message. The 1815 TargetIdentifier syntax as described in Section 4.1 is used. 1816 seqNum is a single use value that will be used to match the 1817 Community Update message with the Community Update Confirm 1818 message. The sequence number is also used to detect TAMP message 1819 replay. The sequence number processing described in Section 6 1820 MUST successfully complete before any of the updates are 1821 processed. 1823 o updates contains a sequence of community identifiers to be removed 1824 and a sequence of community identifiers to be added. These are 1825 represented by the CommunityUpdates structure. 1827 The CommunityUpdates is a sequence of two OPTIONAL sequences, but at 1828 least one of these sequences MUST be present. The first sequence 1829 contains community identifiers to be removed, and if there are none, 1830 it is absent. Where remove is present with an empty list, all 1831 community identifiers MUST be removed. The second sequence contains 1832 community identifiers to be added, and if there are none, it is 1833 absent. The remove updates, if present, MUST be processed before the 1834 add updates. An error is generated if any of the requested removals 1835 or additions cannot be accomplished. However, requests to remove 1836 community identifiers that are not present are treated as successful 1837 removals. Likewise, requests to add community identifiers that are 1838 already present are treated as successful additions. If an error is 1839 generated, the trust anchor store community list MUST NOT be changed. 1841 A description of the syntax associated with each of these actions 1842 follows: 1844 o remove is used to remove one, multiple or all community 1845 identifiers from the trust anchor store. 1847 o add is used to insert one or more new community identifiers into 1848 the trust anchor store. 1850 4.8. Community Update Confirm 1852 The Community Update Confirm message is a reply by a trust anchor 1853 store to a valid Community Update message. The Community Update 1854 Confirm message provides success or failure information for the 1855 requested updates. Success is returned only if the whole batch of 1856 updates is successfully processed. If any of the requested updates 1857 cannot be performed, then a failure is indicated, and the set of 1858 community identifiers stored in the trust anchor store is unchanged. 1859 The Community Update Confirm message MAY be signed or unsigned. A 1860 Community Update Confirm message MUST be signed if the trust anchor 1861 store is capable of signing it. 1863 The Community Update Confirm content type has the following syntax: 1865 tamp-community-update-confirm CONTENT-TYPE ::= 1866 { TAMPCommunityUpdateConfirm IDENTIFIED BY 1867 id-ct-TAMP-communityUpdateConfirm } 1869 id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= 1870 { id-tamp 8 } 1872 TAMPCommunityUpdateConfirm ::= SEQUENCE { 1873 version [0] TAMPVersion DEFAULT v2, 1874 update TAMPMsgRef, 1875 commConfirm CommunityConfirm } 1877 CommunityConfirm ::= CHOICE { 1878 terseCommConfirm [0] TerseCommunityConfirm, 1879 verboseCommConfirm [1] VerboseCommunityConfirm } 1881 TerseCommunityConfirm ::= StatusCode 1883 VerboseCommunityConfirm ::= SEQUENCE { 1884 status StatusCode, 1885 communities CommunityIdentifierList OPTIONAL } 1887 The fields of TAMPCommunityUpdateConfirm are used as follows: 1889 o version identifies version of TAMP. For this version of the 1890 specification, the default value, v2, MUST be used. 1892 o update identifies the Community Update message to which the trust 1893 anchor store is responding. The update structure repeats the 1894 TAMPMsgRef from the Community Update message (see Section 4.7). 1895 The sequence number processing described in Section 6 MUST 1896 successfully complete before any of the updates are processed. 1898 o commConfirm contains either a terse community update confirmation 1899 or a verbose community update confirmation. The terse response is 1900 represented by TerseCommunityConfirm, and the verbose response is 1901 represented by VerboseCommunityConfirm. 1903 The TerseCommunityConfirm contains a single status code, indicating 1904 the success or failure of the Community Update message has been 1905 processed. If the community update failed, then the status code 1906 indicates the reason for the failure. Each of the status codes is 1907 discussed in Section 5. 1909 The fields of VerboseCommunityConfirm are used as follows: 1911 o status contains a single status code, indicating the success or 1912 failure of the Community Update message has been processed. If 1913 the community update failed, then the status code indicates the 1914 reason for the failure. Each of the status codes is discussed in 1915 Section 5. 1917 o communities is OPTIONAL. When present it contains the sequence of 1918 community identifiers present in the trust anchor store after the 1919 update is processed. When the trust anchor store belongs to no 1920 communities, this field is omitted. 1922 4.9. Sequence Number Adjust 1924 The trust anchor store maintains the current sequence number for the 1925 apex trust anchor and each management trust anchor authorized for 1926 TAMP messages. Sequence number processing is discussed in Section 6. 1927 The Sequence Number Adjust message can be used provide the most 1928 recently used sequence number to one or more targets, thereby 1929 reducing the possibility of replay. The Sequence Number Adjust 1930 message MUST be signed. For the Sequence Number Adjust message to be 1931 valid, the trust anchor store MUST be an intended recipient of the 1932 Sequence Number Adjust message, the sequence number MUST be equal to 1933 or larger than the most recently stored sequence number for the 1934 originating trust anchor, and the digital signature MUST be validated 1935 by the apex trust anchor operational public key or an authorized 1936 management trust anchor. 1938 If the digital signature on the Sequence Number Adjust message is 1939 valid, the sequence number is equal to or larger than the most 1940 recently stored sequence number for the originating trust anchor, the 1941 signer is authorized, and the trust anchor store is an intended 1942 recipient of the TAMP message, then the trust anchor store MUST 1943 update the sequence number associated with the originating trust 1944 anchor and return a Sequence Number Adjust Confirm message. If a 1945 Sequence Number Adjust Confirm message is not returned, then a TAMP 1946 Error message SHOULD be returned. 1948 The Sequence Number Adjust message contains an adjustment for the 1949 sequence number of the TAMP message signer. 1951 The Sequence Number Adjust content type has the following syntax: 1953 tamp-sequence-number-adjust CONTENT-TYPE ::= 1954 { SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust } 1956 id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 } 1958 SequenceNumberAdjust ::= SEQUENCE { 1959 Version [0] TAMPVersion DEFAULT v2, 1960 msgRef TAMPMsgRef } 1962 The fields of SequenceNumberAdjust are used as follows: 1964 o version identifies version of TAMP. For this version of the 1965 specification, the default value, v2, MUST be used. 1967 o msgRef contains two items: the target and the seqNum. target 1968 identifies the target(s) of the sequence number adjust message. 1969 The TargetIdentifier syntax as described in Section 4.1 is used. 1970 The allModules target is expected to be used for Sequence Number 1971 Adjust messages. seqNum MUST be equal to or larger than the most 1972 recently stored sequence number for this TAMP message signer, and 1973 the value will be used to match the Sequence Number Adjust message 1974 with the Sequence Number Adjust Confirm message. The sequence 1975 number processing described in Section 6 applies, except that the 1976 sequence number in a Sequence Number Adjust message is acceptable 1977 if it matches the most recently stored sequence number for this 1978 TAMP message signer. If sequence number checking completes 1979 successfully, then the sequence number is adjusted, otherwise it 1980 remains unchanged. 1982 4.10. Sequence Number Adjust Confirm 1984 The Sequence Number Adjust Confirm message is a reply by a trust 1985 anchor store to a valid Sequence Number Adjust message. The Sequence 1986 Number Adjust Confirm message provides success or failure 1987 information. Success is returned only if the sequence number for the 1988 trust anchor that signed the Sequence Number Adjust message 1989 originator is adjusted. If the sequence number cannot be adjusted, 1990 then a failure is indicated, and the sequence number stored in the 1991 trust anchor store is unchanged. The Sequence Number Adjust Confirm 1992 message MAY be signed or unsigned. A Sequence Number Adjust Confirm 1993 message MUST be signed if the trust anchor store is capable of 1994 signing it. 1996 The Sequence Number Adjust Confirm content type has the following 1997 syntax: 1999 tamp-sequence-number-adjust-confirm CONTENT-TYPE ::= 2000 { SequenceNumberAdjustConfirm IDENTIFIED BY 2001 id-ct-TAMP-seqNumAdjustConfirm } 2003 id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= 2004 { id-tamp 11 } 2006 SequenceNumberAdjustConfirm ::= SEQUENCE { 2007 version [0] TAMPVersion DEFAULT v2, 2008 adjust TAMPMsgRef, 2009 status StatusCode } 2011 The fields of SequenceNumberAdjustConfirm are used as follows: 2013 o version identifies version of TAMP. For this version of the 2014 specification, the default value, v2, MUST be used. 2016 o adjust identifies the Sequence Number Adjust message to which the 2017 trust anchor store is responding. The adjust structure repeats 2018 the TAMPMsgRef from the Sequence Number Adjust message (see 2019 Section 4.9). The sequence number processing described in Section 2020 6 MUST successfully complete to adjust the sequence number 2021 associated with the Sequence Number Adjust message originator. 2023 o status contains a single status code, indicating the success or 2024 failure of the Sequence Number Adjust message processing. If the 2025 adjustment failed, then the status code indicates the reason for 2026 the failure. Each of the status codes is discussed in Section 5. 2028 4.11. TAMP Error 2030 The TAMP Error message is a reply by a trust anchor store to any 2031 invalid TAMP message. The TAMP Error message provides an indication 2032 of the reason for the error. The TAMP Error message MAY be signed or 2033 unsigned. A TAMP Error message MUST be signed if the trust anchor 2034 store is capable of signing it. For the request types defined in 2035 this specification, TAMP Error messages MUST NOT be used to indicate 2036 a request message was successfully processed. Each TAMP Error 2037 message identifies the type of TAMP message that caused the error. 2038 In cases where the TAMP message type cannot be determined, errors MAY 2039 be returned via other means, such as at the protocol level, via an 2040 attached display, etc. 2042 The TAMP Error message content type has the following syntax: 2044 tamp-error CONTENT-TYPE ::= 2045 { TAMPError IDENTIFIED BY id-ct-TAMP-error } 2047 id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 } 2049 TAMPError ::= SEQUENCE { 2050 version [0] TAMPVersion DEFAULT v2, 2051 msgType OBJECT IDENTIFIER, 2052 status StatusCode, 2053 msgRef TAMPMsgRef OPTIONAL } 2055 The fields of TAMPError are used as follows: 2057 o version identifies version of TAMP. For this version of the 2058 specification, the default value, v2, MUST be used. 2060 o msgType indicates the content type of the TAMP message that caused 2061 the error. 2063 o status contains a status code that indicates the reason for the 2064 error. Each of the status codes is discussed in Section 5. 2066 o msgRef is OPTIONAL, but whenever possible it SHOULD be present. 2067 It identifies the TAMP message that caused the error. It repeats 2068 the target and seqNum from the TAMP message that caused the error 2069 (see Sections 4.1, 4.3, 4.5, 4.7 and 4.9). 2071 5. Status Codes 2073 The Trust Anchor Update Confirm, the Apex Trust Anchor Update 2074 Confirm, the Community Update Confirm, the Sequence Number Adjust 2075 Confirm, and the TAMP Error messages include status codes. The 2076 syntax for the status codes is: 2078 StatusCode ::= ENUMERATED { 2079 success (0), 2080 decodeFailure (1), 2081 badContentInfo (2), 2082 badSignedData (3), 2083 badEncapContent (4), 2084 badCertificate (5), 2085 badSignerInfo (6), 2086 badSignedAttrs (7), 2087 badUnsignedAttrs (8), 2088 missingContent (9), 2089 noTrustAnchor (10), 2090 notAuthorized (11), 2091 badDigestAlgorithm (12), 2092 badSignatureAlgorithm (13), 2093 unsupportedKeySize (14), 2094 unsupportedParameters (15), 2095 signatureFailure (16), 2096 insufficientMemory (17), 2097 unsupportedTAMPMsgType (18), 2098 apexTAMPAnchor (19), 2099 improperTAAddition (20), 2100 seqNumFailure (21), 2101 contingencyPublicKeyDecrypt (22), 2102 incorrectTarget (23), 2103 communityUpdateFailed (24), 2104 trustAnchorNotFound (25), 2105 unsupportedTAAlgorithm (26), 2106 unsupportedTAKeySize (27), 2107 unsupportedContinPubKeyDecryptAlg (28), 2108 missingSignature (29), 2109 resourcesBusy (30), 2110 versionNumberMismatch (31), 2111 missingPolicySet (32), 2112 revokedCertificate (33), 2113 unsupportedTrustAnchorFormat (34), 2114 improperTAChange (35), 2115 malformed (36), 2116 cmsError (37), 2117 unsupportedTargetIdentifier (38), 2118 other (127) } 2120 The various values of StatusCode are used as follows: 2122 o success is used to indicate that an update, portion of an update, 2123 or adjust was processed successfully. 2125 o decodeFailure is used to indicate that the trust anchor store was 2126 unable to successfully decode the provided message. The specified 2127 content type and the provided content do not match. 2129 o badContentInfo is used to indicate that the ContentInfo syntax is 2130 invalid or that the contentType carried within the ContentInfo is 2131 unknown or unsupported. 2133 o badSignedData is used to indicate that the SignedData syntax is 2134 invalid, the version is unknown or unsupported, or more than one 2135 entry is present in digestAlgorithms. 2137 o badEncapContent is used to indicate that the 2138 EncapsulatedContentInfo syntax is invalid. This error can be 2139 generated due to problems located in SignedData. 2141 o badCertificate is used to indicate that the syntax for one or more 2142 certificates in CertificateSet is invalid. 2144 o badSignerInfo is used to indicate that the SignerInfo syntax is 2145 invalid, or the version is unknown or unsupported. 2147 o badSignedAttrs is used to indicate that the signedAttrs syntax 2148 within SignerInfo is invalid. 2150 o badUnsignedAttrs is used to indicate that the unsignedAttrs syntax 2151 within SignerInfo is invalid. 2153 o missingContent is used to indicate that the OPTIONAL eContent is 2154 missing in EncapsulatedContentInfo, which is REQUIRED in this 2155 specification. This error can be generated due to problems 2156 located in SignedData. 2158 o noTrustAnchor is used to indicate one of two possible error 2159 situations. In one case, the subjectKeyIdentifier does not 2160 identify the public key of a trust anchor or a certification path 2161 that terminates with an installed trust anchor. In the other 2162 case, the issuerAndSerialNumber is used to identify the TAMP 2163 message signer, which is prohibited by this specification. 2165 o notAuthorized is used to indicate one of two possible error 2166 situations. In one case the sid within SignerInfo leads to an 2167 installed trust anchor, but that trust anchor is not an authorized 2168 signer for the received TAMP message content type. Identity trust 2169 anchors are not authorized signers for any of the TAMP message 2170 content types. In the other case, the signer of a Trust Anchor 2171 Update message is not authorized to manage the to-be-updated trust 2172 anchor as determined by a failure of the subordination processing 2173 in Sec. 7. 2175 o badDigestAlgorithm is used to indicate that the digestAlgorithm in 2176 either SignerInfo or SignedData is unknown or unsupported. 2178 o badSignatureAlgorithm is used to indicate that the 2179 signatureAlgorithm in SignerInfo is unknown or unsupported. 2181 o unsupportedKeySize is used to indicate that the signatureAlgorithm 2182 in SignerInfo is known and supported, but the TAMP message digital 2183 signature could not be validated because an unsupported key size 2184 was employed by the signer. 2186 o unsupportedParameters is used to indicate that the 2187 signatureAlgorithm in SignerInfo is known, but the TAMP message 2188 digital signature could not be validated because unsupported 2189 parameters were employed by the signer. 2191 o signatureFailure is used to indicate that the signatureAlgorithm 2192 in SignerInfo is known and supported, but the digital signature in 2193 the signature field within SignerInfo could not be validated. 2195 o insufficientMemory indicates that the update could not be 2196 processed because the trust anchor store did not have sufficient 2197 memory to store the resulting trust anchor configuration or 2198 community identifier. 2200 o unsupportedTAMPMsgType indicates that the TAMP message could not 2201 be processed because the trust anchor store does not support the 2202 provided TAMP message type. This code will be used if the id-ct- 2203 TAMP-communityUpdate content type is provided and the trust anchor 2204 store does not support the Community Update message. This status 2205 code will also be used if the contentType value within 2206 eContentType is not one that is defined in this specification. 2208 o apexTAMPAnchor indicates that the update could not be processed 2209 because the Trust Anchor Update message tried to remove the apex 2210 trust anchor. 2212 o improperTAAddition indicates that a trust anchor update is trying 2213 to add a new trust anchor that may already exist, but some 2214 attributes of the to-be-added trust anchor are being modified in 2215 an improper manner. The desired trust anchor configuration may be 2216 attainable with a change operation instead of an add operation. 2218 o seqNumFailure indicates that the TAMP message could not be 2219 processed because the processing of the sequence number, which is 2220 described in Section 6, resulted in an error. 2222 o contingencyPublicKeyDecrypt indicates that the update could not be 2223 processed because an error occurred while decrypting the 2224 contingency public key. 2226 o incorrectTarget indicates that the query, update, or adjust 2227 message could not be processed because the trust anchor store is 2228 not the intended recipient. 2230 o communityUpdateFailed indicates that the community update 2231 requested the addition of a community identifier or the removal of 2232 a community identifier, but the request could not be honored. 2234 o trustAnchorNotFound indicates that a change to a trust anchor was 2235 requested, but the referenced trust anchor is not represented in 2236 the trust anchor store. 2238 o unsupportedTAAlgorithm indicates that an update message would 2239 result in the trust anchor with a public key associated with a 2240 digital signature validation algorithm that is not implemented. 2241 In addition, this status code is used if the algorithm is 2242 supported, but the parameters associated with the algorithm are 2243 not supported. 2245 o unsupportedTAKeySize indicates that the trust anchor would include 2246 a public key of a size that is not supported. 2248 o unsupportedContinPubKeyDecryptAlg indicates that the decryption 2249 algorithm for the apex trust anchor contingency public key is not 2250 supported. 2252 o missingSignature indicates that an unsigned TAMP message was 2253 received, but the received TAMP message type MUST be signed. 2255 o resourcesBusy indicates that the resources necessary to process 2256 the TAMP message are not available at the present time, but the 2257 resources might be available at some point in the future. 2259 o versionNumberMismatch indicates that the version number in a 2260 received TAMP message is not acceptable. 2262 o missingPolicySet indicates that the policyFlags associated with a 2263 trust anchor are set in a fashion that requires the policySet to 2264 be present, but the policySet is missing. 2266 o revokedCertificate indicates that one or more of the certificates 2267 needed to properly process the TAMP message has been revoked. 2269 o unsupportedTrustAnchorFormat indicates that an unsupported trust 2270 anchor format was presented or the version is unknown or 2271 unsupported. 2273 o improperTAChange indicates that a trust anchor update is trying to 2274 change a new trust anchor using a format different than the format 2275 of the existing trust anchor. 2277 o malformed indicates an error in the composition of the CMS 2278 structure encapsulating a TAMP message. 2280 o cmsError indicates an error processing a CMS structure that 2281 encapsulated a TAMP message, such as a errors processing 2282 ContentType or MessageDigest attributes. 2284 o unsupportedTargetIdentifier indicates a msgRef with an unsupported 2285 TargetIdentifier option was encounted. 2287 o other indicates that the update could not be processed, but the 2288 reason is not covered by any of the assigned status codes. Use of 2289 this status code SHOULD be avoided. 2291 6. Sequence Number Processing 2293 The sequence number processing facilities in TAMP represent a balance 2294 between replay protection, operational considerations, and trust 2295 anchor store memory management. The goal is to provide replay 2296 protection without making TAMP difficult to use, creating an 2297 environment where surprising error conditions occur on a regular 2298 basis, or imposing onerous memory management requirements on 2299 implementations. This balance is achieved by performing sequence 2300 number checking on TAMP messages that are validated directly using a 2301 trust anchor, and allowing these checks to be skipped whenever the 2302 TAMP message originator is not represented by a trust anchor. 2303 Implementations MUST perform sequence number checking on TAMP 2304 messages that are validated directly using a trust anchor and MAY 2305 perform sequence number checking for TAMP messages validated using a 2306 certification path. 2308 The TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update, 2309 Community Update, and Sequence Number Adjust messages include a 2310 sequence number. This single-use identifier is used to match a TAMP 2311 message with the response to that TAMP message. When the TAMP 2312 message is validated directly using a trust anchor, the sequence 2313 number is also used to detect TAMP message replay. 2315 To provide replay protection, each TAMP message originator MUST treat 2316 the sequence number as a monotonically increasing non-negative 2317 integer. The sequence number counter is associated with the signing 2318 operation performed by the private key. The trust anchor store MUST 2319 ensure that a newly received TAMP message that is validated directly 2320 by a trust anchor public key contains a sequence number that is 2321 greater than the most recent successfully processed TAMP message from 2322 that originator. Note that the Sequence Number Adjust message is 2323 considered valid if the sequence number is greater than or equal to 2324 the most recent successfully processed TAMP message from that 2325 originator. If the sequence number in a received TAMP message does 2326 not meet these conditions, then the trust anchor store MUST reject 2327 the TAMP message, returning a sequence number failure (seqNumFailure) 2328 error. 2330 Whenever a trust anchor is authorized for TAMP messages, either as a 2331 newly installed trust anchor or as a modification to an existing 2332 trust anchor, if a sequence number value is not provided in the Trust 2333 Anchor Update message, memory MUST be allocated for the sequence 2334 number and set to zero. The first TAMP message received that is 2335 validated using that trust anchor is not rejected based on sequence 2336 number checks, and the sequence number from that first TAMP message 2337 is stored. The TAMP message recipient MUST maintain a database of 2338 the most recent sequence number from a successfully processed TAMP 2339 message from a trust anchor. The index for this database is the 2340 trust anchor public key. This could be the apex trust anchor 2341 operational public key or a management trust anchor public key. In 2342 the first case, the apex trust anchor operational public key is used 2343 directly to validate the TAMP message digital signature. In the 2344 second case, a management trust anchor public key is used directly to 2345 validate the TAMP message digital signature. 2347 Sequence number values MUST be 64-bit non-negative integers. Since 2348 ASN.1 encoding of an INTEGER always includes a sign bit, a TAMP 2349 message signer can generate 9,223,372,036,854,775,807 TAMP messages 2350 before exhausting the 64-bit sequence number space, before which the 2351 TAMP message signer MUST transition to a different public/private key 2352 pair. The ability to reset a sequence number provided by the Trust 2353 Anchor Update and Sequence Number Adjust messages is not intended to 2354 avoid the transition to a different key pair; rather, it is intended 2355 to aid recovery from operational errors. A relatively small non- 2356 volatile storage requirement is imposed on the trust anchor store for 2357 the apex trust anchor and each management trust anchor authorized for 2358 TAMP messages. 2360 When the apex trust anchor or a management trust anchor is replaced 2361 or removed from the trust anchor store, the associated sequence 2362 number storage SHOULD be reclaimed. 2364 7. Subordination Processing 2366 When a TAMP update message is processed, several checks are 2367 performed: 2369 o TAMP message authentication is checked including, if necessary, 2370 building and validating a certification path to the signer. 2372 o The signer's authorization is checked, including authorization to 2373 manage trust anchors included in the update message. 2375 o Calculation of the trust anchor information to be stored. 2377 This section describes how to perform the second and third steps. 2378 Section 1.2 discusses authentication of TAMP messages. Where a trust 2379 anchor is represented as a certificate and the calculation of the 2380 trust anchor information to be stored is different than the 2381 information in the certificate, the TAMP update fails. The TAMP 2382 message signer may then wrap the certificate inside a TrustAnchorInfo 2383 structure to assert the intended information. 2385 The apex trust anchor is unconstrained, which means that 2386 subordination checking need not be performed on Trust Anchor Update 2387 messages signed with the apex trust anchor operational public key and 2388 that trust anchor information can be stored as it appears in the 2389 update message. Subordination checking is performed as part of the 2390 validation process of all other Trust Anchor Update messages. 2392 For a Trust Anchor Update message that is not signed with the apex 2393 trust anchor operational public key to be valid, the digital 2394 signature MUST be validated using an authorized trust anchor, either 2395 directly or via an X.509 certification path originating with the apex 2396 trust anchor operational public key or an authorized management trust 2397 anchor. The following subordination checks MUST also be performed as 2398 part of validation of the update message. 2400 Each Trust Anchor Update message contains one or more individual 2401 updates, each of which is used to add, modify or remove a trust 2402 anchor. For each individual update, the constraints of the TAMP 2403 message signer MUST be greater than or equal to the constraints of 2404 the trust anchor in the update. Specifically, constraints included 2405 in the CertPathControls field of a TrustAnchorInfo object (or 2406 equivalent extensions in Certificate or TBSCertificate objects) must 2407 be checked as described below. [RFC5280] describes how the 2408 intersection and union operations referenced below are performed. 2410 o The values of the policyFlags stored with a trust anchor as the 2411 result of a TAMPUpdate are either true or equal to the value of 2412 the policy flags associated with the TAMP message signer, i.e., an 2413 update may set a flag to false only if the value associated with 2414 the TAMP message signer is false. The policy flags associated 2415 with the TAMP message signer are read from the policyFlags field 2416 or policyConstraints and inhibitAnyPolicy extensions if the signer 2417 is represented as a trust anchor or from the explicit_policy, 2418 policy_mapping and inhibit_anyPolicy state variables following 2419 path validation if the signer is not represented as a trust 2420 anchor. 2422 o The certificate policies stored with a trust anchor as the result 2423 of a TAMPUpdate are equal to the intersection of the certificate 2424 policies value associated with the TAMP message signer and the 2425 value of the policySet field or certificatePolicies extension from 2426 the update. The certificate policies associated with the TAMP 2427 message signer are read from the policySet field in a 2428 TrustAnchorInfo or CertificatePolicies extension in a Certificate 2429 or TBSCertificate if the signer is represented as a trust anchor 2430 or from the valid_policy_tree returned following path validation 2431 if the signer is not represented by a trust anchor. Where the 2432 TAMP message signer is represented as a trust anchor, no policy 2433 mapping is performed. If the intersection is NULL and the to-be- 2434 stored requireExplicitPolicy value is true, the TAMP update fails. 2436 o The excluded names stored with a trust anchor as the result of a 2437 TAMPUpdate are equal to the union of the excluded names associated 2438 with the TAMP message signer and the value from the nameConstr 2439 field or nameConstraints extension from the update. The name 2440 constraints associated with the TAMP message signer are read from 2441 the nameConstr field in a TrustAnchorInfo or nameConstraints 2442 extension in a Certificate or TBSCertificate if the signer is a 2443 trust anchor or from the excludedSubtrees state variable following 2444 path validation if the signer is not a trust anchor. The name of 2445 the trust anchor included in the update MUST NOT fall within the 2446 excluded name space of the TAMP signer. If the name of the trust 2447 anchor falls within the excluded name space of the TAMP signer, 2448 the TAMP update fails. 2450 o The permitted names stored with a trust anchor as the result of a 2451 TAMPUpdate are equal to the intersection of the permitted names 2452 associated with the TAMP message signer and the value from the 2453 nameConstr field or nameConstraints extension from the update. 2454 The name constraints associated with the TAMP message signer are 2455 read from the nameConstr field in a TrustAnchorInfo or 2456 nameConstraints extension in a Certificate or TBSCertificate if 2457 the signer is a trust anchor or from the permittedSubtrees state 2458 variable following path validation if the signer is not a trust 2459 anchor. The name of the trust anchor included in the update MUST 2460 fall within the permitted name space of the TAMP signer. If the 2461 name of the trust anchor does not fall within the permitted name 2462 space of the TAMP signer, the TAMP update fails. If the 2463 intersection is NULL for all name forms, the TAMP update fails. 2465 No other extensions defined in RFC5280 must be processed as part of 2466 subordination processing. Other extensions may define subordination 2467 rules. 2469 8. Implementation Considerations 2471 A public key identifier is used to identify a TAMP message signer. 2472 Since there is no guarantee that the same public key identifier is 2473 not associated with more than one public key, implementations MUST be 2474 prepared for one or more trust anchor to have the same public key 2475 identifier. In practical terms, this means that when a digital 2476 signature validation fails, the implementation MUST see if there is 2477 another trust anchor with the same public key identifier that can be 2478 used to validate the digital signature. While duplicate public key 2479 identifiers are expected to be rare, implementations MUST NOT fail to 2480 find the correct trust anchor when they do occur. 2482 An X.500 distinguished name is used to identify certificate issuers 2483 and certificate subjects. The same X.500 distinguished name can be 2484 associated with more than one trust anchor. However, the trust 2485 anchor public key will be different. The probability that two trust 2486 anchors will have the same X.500 distinguished name and the same 2487 public key identifier but a different public key is diminishingly 2488 small. Therefore, the authority key identifier certificate extension 2489 can be used to resolve X.500 distinguished name collisions. 2491 TAMP assumes a reliable underlying transport protocol. 2493 9. Apex trust anchor info certificate extension 2495 An Apex trust anchor MAY contain contingency key information using 2496 the WrappedApexContingencyKey extension. The extension uses the 2497 ApexContingencyKey structure as defined below. 2499 ApexContingencyKey ::= SEQUENCE { 2500 wrapAlgorithm AlgorithmIdentifier OPTIONAL, 2501 wrappedContinPubKey OCTET STRING OPTIONAL} 2503 The fields of ApexContingencyKey are used as described below. When 2504 one field is present, both MUST be present. When one field is 2505 absent, both MUST be absent. The fields are allowed to be absent to 2506 enable usage of this extension as a means of indicating the 2507 corresponding public key is recognized as an apex trust anchor by 2508 some relying parties. 2510 o wrapAlgorithm identifies the symmetric algorithm used to encrypt 2511 the apex trust anchor contingency public key. If this public key 2512 is ever needed, the symmetric key needed to decrypt it will be 2513 provided in the message that is to be validated using it. The 2514 algorithm identifier is an AlgorithmIdentifier, which contains an 2515 object identifier and OPTIONAL parameters. The object identifier 2516 indicates the syntax of the parameters, if present. 2518 o wrappedContinPubKey is the encrypted apex trust anchor contingency 2519 public key. Once decrypted, it yields the PublicKeyInfo 2520 structure, which consists of the algorithm identifier followed by 2521 the public key itself. The algorithm identifier is an 2522 AlgorithmIdentifier that contains an object identifier and 2523 OPTIONAL parameters. The object identifier indicates the format 2524 of the public key and the syntax of the parameters, if present. 2525 The public key is encoded as a BIT STRING. 2527 The apex trust anchor info extension MAY be critical, and it MUST 2528 appear at most one time in a set of extensions. The apex trust 2529 anchor info extension is identified by the id-pe-wrappedApexContinKey 2530 object identifier: 2532 id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::= 2533 { iso(1) identified-organization(3) dod(6) internet(1) 2534 security(5) mechanisms(5) pkix(7) pe(1) 20 } 2536 10. Security Considerations 2538 The majority of this specification is devoted to the syntax and 2539 semantics of TAMP messages. It relies on other specifications, 2540 especially [I-D.ietf-pkix-ta-format], [RFC3852] and [RFC5280], for 2541 the syntax and semantics of trust anchors, CMS protecting content 2542 types and X.509 certificates, respectively. Since TAMP messages that 2543 change the trust anchor state of a trust anchor store are always 2544 signed by a Trust Anchor Manager, no further data integrity or data 2545 origin authentication mechanisms are needed; however, no 2546 confidentiality for these messages is provided. Similarly, 2547 certificates are digitally signed, and no additional data integrity 2548 or data origin authentication mechanisms are needed. Trust anchor 2549 configurations, Trust Anchor Manager certificates, and trust anchor 2550 store certificates are not intended to be sensitive. As a result, 2551 this specification does not provide for confidentiality of TAMP 2552 messages. 2554 Security factors outside the scope of this specification greatly 2555 affect the assurance provided. The procedures used by certification 2556 authorities (CAs) to validate the binding of the subject identity to 2557 their public key greatly affect the assurance associated with the 2558 resulting certificate. This is particularly important when issuing 2559 certificates to other CAs. In the context of TAMP, the issuance of 2560 an end entity certificate under a management trust anchor is an act 2561 of delegation. However, such end entities cannot further delegate. 2562 On the other hand, issuance of a CA certificate under a management 2563 trust anchor is an act of delegation where the CA can perform further 2564 delegation. The scope of the delegation can be constrained by 2565 including appropriate certificate extensions in a CA certificate. 2567 X.509 certification path construction involves comparison of X.500 2568 distinguished names. Inconsistent application of name comparison 2569 rules can result in acceptance of invalid X.509 certification paths 2570 or rejection of valid ones. Name comparison can be extremely 2571 complex. To avoid imposing this complexity on trust anchor stores, 2572 any certificate profile used with TAMP SHOULD employ simple name 2573 structures and impose rigorous restrictions on acceptable 2574 distinguished names, including the way that they are encoded. The 2575 goal of that certificate profile should be to enable simple binary 2576 comparison. That is, case conversion, character set conversion, 2577 white space compression, and leading and trailing white space 2578 trimming SHOULD be avoided. 2580 Some digital signature algorithms require the generation of random 2581 one-time values. For example, when generating a DSA digital 2582 signature, the signer MUST generate a random k value [DSS]. Also, 2583 the generation of public/private key pairs relies on random numbers. 2585 The use of an inadequate random number generator (RNG) or an 2586 inadequate pseudo-random number generator (PRNG) to generate such 2587 cryptographic values can result in little or no security. An 2588 attacker may find it much easier to reproduce the random number 2589 generation environment, searching the resulting small set of 2590 possibilities, rather than brute force searching the whole space. 2592 Compromise of an identity trust anchor private key permits 2593 unauthorized parties to issue certificates that will be acceptable to 2594 all trust anchor stores configured with the corresponding identity 2595 trust anchor. The unauthorized private key holder will be limited by 2596 the certification path controls associated with the identity trust 2597 anchor. For example, clearance constraints in the identity trust 2598 anchor will determine the clearances that will be accepted in 2599 certificates that are issued by the unauthorized private key holder. 2601 Compromise of a management trust anchor private key permits 2602 unauthorized parties to generate signed messages that will be 2603 acceptable to all trust anchor stores configured with the 2604 corresponding management trust anchor. All devices that include the 2605 compromised management trust anchor can be configured as desired by 2606 the unauthorized private key holder within the limits of the 2607 subordination checks described in Section 7. If the management trust 2608 anchor is associated with content types other than TAMP, then the 2609 unauthorized private key holder can generate signed messages of that 2610 type. For example, if the management trust anchor is associated with 2611 firmware packages, then the unauthorized private key holder can 2612 install different firmware. 2614 Compromise of the Apex Trust Anchor operational private key permits 2615 unauthorized parties to generate signed messages that will be 2616 acceptable to all trust anchor stores configured with the 2617 corresponding apex trust anchor. All devices that include that apex 2618 trust anchor can be configured as desired by the unauthorized private 2619 key holder, and the unauthorized private key holder can generate 2620 signed messages of any content type. The optional contingency 2621 private key offers a potential way to recover from such a compromise. 2623 The compromise of a CA's private key leads to the same type of 2624 problems as the compromise of an identity or a management trust 2625 anchor private key. The unauthorized private key holder will be 2626 limited by the certification path controls and extensions associated 2627 with the trust anchor. 2629 The compromise of an end entity private key leads to the same type of 2630 problems as the compromise of an identity or a management trust 2631 anchor private key, except that the end entity is unable to issue any 2632 certificates. The unauthorized private key holder will be limited by 2633 the certification path controls and extensions associated with the 2634 trust anchor. 2636 Compromise of a trust anchor store's digital signature private key 2637 permits unauthorized parties to generate signed TAMP response 2638 messages, masquerading as the trust anchor store. 2640 Premature disclosure of the key-encryption key used to encrypt the 2641 apex trust anchor contingency public key may result in early exposure 2642 of the apex trust anchor contingency public key. 2644 TAMP implementations need to be able to parse messages and 2645 certificates. Care must be taken to ensure that there are no 2646 implementation defects in the TAMP message parser or the processing 2647 that acts on the message content. A validation suite is one way to 2648 increase confidence in the parsing of TAMP messages, CMS content 2649 types, attributes, certificates and extensions. 2651 TrustAnchorList messages do not provide a replay detection mechanism. 2652 Where TrustAnchorList messages are accepted as an alternative means 2653 of adding trust anchors to a trust anchor store, applications may 2654 require additional mechanisms to address the risks associated with 2655 replay of old TrustAnchorList messages. 2657 As sequence number values are used to detect replay attempts, trust 2658 anchor store managers must take care to maintain their own sequence 2659 number state, i.e., knowledge of which sequence number to include in 2660 the next TAMP message generated by the trust anchor store manager. 2661 Loss of sequence number state can result in generation of TAMP 2662 messages that cannot be processed due to seqNumFailure. In the event 2663 of loss, sequence number state can be restored by inspecting the most 2664 recently generated TAMP message, provided the messages are logged, or 2665 in collaboration with a trust anchor store manager who can 2666 successfully issue a TAMPStatusQuery message. 2668 11. IANA Considerations 2670 The details of TAMP requests and responses are communicated using 2671 object identifiers (OIDs). The objects are defined in an arc 2672 delegated by IANA to the PKIX Working Group. This document also 2673 includes eleven media type registrations in Appendix B. No further 2674 action by IANA is necessary for this document or any anticipated 2675 updates. 2677 12. References 2679 12.1. Normative References 2681 [I-D.ietf-pkix-new-asn1] 2682 Hoffman, P. and J. Schaad, "New ASN.1 Modules for PKIX", 2683 draft-ietf-pkix-new-asn1-07 (work in progress), 2684 August 2009. 2686 [I-D.ietf-pkix-ta-format] 2687 Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 2688 Format", draft-ietf-pkix-ta-format-04 (work in progress), 2689 October 2009. 2691 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2692 Requirement Levels", BCP 14, RFC 2119, March 1997. 2694 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2695 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2696 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2698 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 2699 RFC 3852, July 2004. 2701 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2702 Resource Identifier (URI): Generic Syntax", STD 66, 2703 RFC 3986, January 2005. 2705 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2706 Housley, R., and W. Polk, "Internet X.509 Public Key 2707 Infrastructure Certificate and Certificate Revocation List 2708 (CRL) Profile", RFC 5280, May 2008. 2710 [X.680] "ITU-T Recommendation X.680: Information Technology - 2711 Abstract Syntax Notation One", 1997. 2713 [X.690] "ITU-T Recommendation X.690 Information Technology - ASN.1 2714 encoding rules: Specification of Basic Encoding Rules 2715 (BER), Canonical Encoding Rules (CER) and Distinguished 2716 Encoding Rules (DER)", 1997. 2718 12.2. Informative References 2720 [DSS] "FIPS Pub 186: Digital Signature Standard", May 1994. 2722 [I-D.draft-ietf-pkix-ta-mgmt-reqs] 2723 Reddy, R. and C. Wallace, "Trust Anchor Management 2724 Requirements", draft-ietf-pkix-ta-mgmt-reqs-04 (work in 2725 progress). 2727 [PKCS#6] "PKCS #6: Extended-Certificate Syntax Standard, Version 2728 1.5", November 1993. 2730 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 2731 Identifiers for the Internet X.509 Public Key 2732 Infrastructure Certificate and Certificate Revocation List 2733 (CRL) Profile", RFC 3279, April 2002. 2735 [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute 2736 Certificate Profile for Authorization", RFC 3281, 2737 April 2002. 2739 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 2740 Algorithms", RFC 3370, August 2002. 2742 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 2743 Representing Date and Time in ASN.1", RFC 4049, 2744 April 2005. 2746 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 2747 Protect Firmware Packages", RFC 4108, August 2005. 2749 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 2750 Cryptography (ECC) Algorithms in Cryptographic Message 2751 Syntax (CMS)", RFC 5753, January 2010. 2753 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 2754 Message Syntax", RFC 5754, January 2010. 2756 [X.208] "ITU-T Recommendation X.208 - Specification of Abstract 2757 Syntax Notation One (ASN.1)", 1988. 2759 [X.509] "ITU-T Recommendation X.509 - The Directory - 2760 Authentication Framework", 2000. 2762 Appendix A. ASN.1 Modules 2764 Appendix A.1 provides the normative ASN.1 definitions for the 2765 structures described in this specification using ASN.1 as defined in 2766 [X.680]. Appendix A.2 provides a module using ASN.1 as defined in 2767 [X.208]. The module in A.2 removes usage of newer ASN.1 features 2768 that provide support for limiting the types of elements that may 2769 appear in certain SEQUENCE and SET constructions. Otherwise, the 2770 modules are compatible in terms of encoded representation, i.e., the 2771 modules are bits-on-the-wire compatible aside from the limitations on 2772 SEQUENCE and SET constituents. Extension markers are not used due to 2773 lack of support in [X.208]. A.2 is included as a courtesy to 2774 developers using ASN.1 compilers that do not support current ASN.1. 2775 A.1 includes definitions imported from [RFC5280], 2776 [I-D.ietf-pkix-new-asn1] and [I-D.ietf-pkix-ta-format]. 2778 A.1. ASN.1 Module Using 1993 Syntax 2780 TAMP-Protocol-v2 2781 { joint-iso-ccitt(2) country(16) us(840) organization(1) 2782 gov(101) dod(2) infosec(1) modules(0) 30 } 2784 DEFINITIONS IMPLICIT TAGS ::= 2785 BEGIN 2787 IMPORTS 2788 TrustAnchorChoice, TrustAnchorTitle, CertPathControls 2789 FROM TrustAnchorInfoModule 2790 { joint-iso-ccitt(2) country(16) us(840) 2791 organization(1) gov(101) dod(2) infosec(1) 2792 modules(0) 33 } 2793 AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, KEY-WRAP 2794 FROM AlgorithmInformation-2009 2795 {iso(1) identified-organization(3) dod(6) internet(1) 2796 security(5) mechanisms(5) pkix(7) id-mod(0) 2797 id-mod-algorithmInformation-02(58)} 2798 Certificate, Name, TBSCertificate, 2799 CertificateSerialNumber, Validity, SubjectPublicKeyInfo 2800 FROM PKIX1Explicit-2009 -- from [I-D.ietf-pkix-new-asn1] 2801 {iso(1) identified-organization(3) dod(6) internet(1) 2802 security(5) mechanisms(5) pkix(7) id-mod(0) 2803 id-mod-pkix1-explicit-02(51)} 2804 KeyIdentifier, OTHER-NAME 2805 FROM PKIX1Implicit-2009 -- from [I-D.ietf-pkix-new-asn1] 2806 {iso(1) identified-organization(3) dod(6) internet(1) 2807 security(5) mechanisms(5) pkix(7) id-mod(0) 2808 id-mod-pkix1-implicit-02(59)} 2810 EXTENSION, Extensions {}, ATTRIBUTE, SingleAttribute{} 2811 FROM PKIX-CommonTypes-2009 -- from [I-D.ietf-pkix-new-asn1] 2812 { iso(1) identified-organization(3) dod(6) internet(1) 2813 security(5) mechanisms(5) pkix(7) id-mod(0) 2814 id-mod-pkixCommon-02(57) } ; 2816 -- Object Identifier Arc for TAMP Message Content Types 2818 id-tamp OBJECT IDENTIFIER ::= { 2819 joint-iso-ccitt(2) country(16) us(840) organization(1) 2820 gov(101) dod(2) infosec(1) formats(2) 77 } 2822 SupportedSigAlgorithms SIGNATURE-ALGORITHM ::= { 2823 -- add any locally defined algorithms here 2824 ... 2825 } 2827 SupportedWrapAlgorithms KEY-WRAP ::= { 2828 -- add any locally defined algorithms here 2829 ... 2830 } 2832 -- CMS Content Types 2834 CONTENT-TYPE ::= TYPE-IDENTIFIER 2836 TAMPContentTypes CONTENT-TYPE ::= { 2837 tamp-status-query | 2838 tamp-status-response | 2839 tamp-update | 2840 tamp-update-confirm | 2841 tamp-apex-update | 2842 tamp-apex-update-confirm | 2843 tamp-community-update | 2844 tamp-community-update-confirm | 2845 tamp-sequence-number-adjust | 2846 tamp-sequence-number-adjust-confirm | 2847 tamp-error, 2848 ... -- Expect additional content types -- 2849 } 2851 -- TAMP Status Query Message 2852 tamp-status-query CONTENT-TYPE ::= 2853 { TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery } 2855 id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 } 2856 TAMPStatusQuery ::= SEQUENCE { 2857 version [0] TAMPVersion DEFAULT v2, 2858 terse [1] TerseOrVerbose DEFAULT verbose, 2859 query TAMPMsgRef } 2861 TAMPVersion ::= INTEGER { v1(1), v2(2) } 2863 TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) } 2865 SeqNumber ::= INTEGER (0..9223372036854775807) 2867 TAMPMsgRef ::= SEQUENCE { 2868 target TargetIdentifier, 2869 seqNum SeqNumber } 2871 TargetIdentifier ::= CHOICE { 2872 hwModules [1] HardwareModuleIdentifierList, 2873 communities [2] CommunityIdentifierList, 2874 allModules [3] NULL, 2875 uri [4] IA5String, 2876 otherName [5] INSTANCE OF OTHER-NAME} 2878 HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF 2879 HardwareModules 2881 HardwareModules ::= SEQUENCE { 2882 hwType OBJECT IDENTIFIER, 2883 hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry } 2885 HardwareSerialEntry ::= CHOICE { 2886 all NULL, 2887 single OCTET STRING, 2888 block SEQUENCE { 2889 low OCTET STRING, 2890 high OCTET STRING } } 2892 CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community 2894 Community ::= OBJECT IDENTIFIER 2896 -- TAMP Status Response Message 2898 tamp-status-response CONTENT-TYPE ::= 2899 { TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse } 2901 id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 } 2902 TAMPStatusResponse ::= SEQUENCE { 2903 version [0] TAMPVersion DEFAULT v2, 2904 query TAMPMsgRef, 2905 response StatusResponse, 2906 usesApex BOOLEAN DEFAULT TRUE} 2908 StatusResponse ::= CHOICE { 2909 terseResponse [0] TerseStatusResponse, 2910 verboseResponse [1] VerboseStatusResponse } 2912 TerseStatusResponse ::= SEQUENCE { 2913 taKeyIds KeyIdentifiers, 2914 communities CommunityIdentifierList OPTIONAL } 2916 KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier 2918 VerboseStatusResponse ::= SEQUENCE { 2919 taInfo TrustAnchorChoiceList, 2920 continPubKeyDecryptAlg [0] AlgorithmIdentifier 2921 {KEY-WRAP, {SupportedWrapAlgorithms}} OPTIONAL, 2922 communities [1] CommunityIdentifierList OPTIONAL, 2923 tampSeqNumbers [2] TAMPSequenceNumbers OPTIONAL } 2925 TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF 2926 TrustAnchorChoice 2928 TAMPSequenceNumber ::= SEQUENCE { 2929 keyId KeyIdentifier, 2930 seqNumber SeqNumber } 2932 TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF TAMPSequenceNumber 2934 -- Trust Anchor Update Message 2936 tamp-update CONTENT-TYPE ::= 2937 { TAMPUpdate IDENTIFIED BY id-ct-TAMP-update } 2939 id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 } 2941 TAMPUpdate ::= SEQUENCE { 2942 version [0] TAMPVersion DEFAULT v2, 2943 terse [1] TerseOrVerbose DEFAULT verbose, 2944 msgRef TAMPMsgRef, 2945 updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate, 2946 tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL } 2948 TrustAnchorUpdate ::= CHOICE { 2949 add [1] TrustAnchorChoice, 2950 remove [2] SubjectPublicKeyInfo, 2951 change [3] EXPLICIT TrustAnchorChangeInfoChoice } 2953 TrustAnchorChangeInfoChoice ::= CHOICE { 2954 tbsCertChange [0] TBSCertificateChangeInfo, 2955 taChange [1] TrustAnchorChangeInfo } 2957 TBSCertificateChangeInfo ::= SEQUENCE { 2958 serialNumber CertificateSerialNumber OPTIONAL, 2959 signature [0] AlgorithmIdentifier 2960 {SIGNATURE-ALGORITHM, {SupportedSigAlgorithms}} OPTIONAL, 2961 issuer [1] Name OPTIONAL, 2962 validity [2] Validity OPTIONAL, 2963 subject [3] Name OPTIONAL, 2964 subjectPublicKeyInfo [4] SubjectPublicKeyInfo, 2965 exts [5] EXPLICIT Extensions{{...}} OPTIONAL } 2967 TrustAnchorChangeInfo ::= SEQUENCE { 2968 pubKey SubjectPublicKeyInfo, 2969 keyId KeyIdentifier OPTIONAL, 2970 taTitle TrustAnchorTitle OPTIONAL, 2971 certPath CertPathControls OPTIONAL, 2972 exts [1] Extensions{{...}} OPTIONAL} 2974 -- Trust Anchor Update Confirm Message 2976 tamp-update-confirm CONTENT-TYPE ::= 2977 { TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm } 2979 id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 } 2981 TAMPUpdateConfirm ::= SEQUENCE { 2982 version [0] TAMPVersion DEFAULT v2, 2983 update TAMPMsgRef, 2984 confirm UpdateConfirm } 2986 UpdateConfirm ::= CHOICE { 2987 terseConfirm [0] TerseUpdateConfirm, 2988 verboseConfirm [1] VerboseUpdateConfirm } 2990 TerseUpdateConfirm ::= StatusCodeList 2992 StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode 2994 VerboseUpdateConfirm ::= SEQUENCE { 2995 status StatusCodeList, 2996 taInfo TrustAnchorChoiceList, 2997 tampSeqNumbers TAMPSequenceNumbers OPTIONAL, 2998 usesApex BOOLEAN DEFAULT TRUE} 3000 -- Apex Trust Anchor Update Message 3002 tamp-apex-update CONTENT-TYPE ::= 3003 { TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate } 3005 id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 } 3007 TAMPApexUpdate ::= SEQUENCE { 3008 version [0] TAMPVersion DEFAULT v2, 3009 terse [1] TerseOrVerbose DEFAULT verbose, 3010 msgRef TAMPMsgRef, 3011 clearTrustAnchors BOOLEAN, 3012 clearCommunities BOOLEAN, 3013 seqNumber SeqNumber OPTIONAL, 3014 apexTA TrustAnchorChoice } 3016 -- Apex Trust Anchor Update Confirm Message 3018 tamp-apex-update-confirm CONTENT-TYPE ::= 3019 { TAMPApexUpdateConfirm IDENTIFIED BY 3020 id-ct-TAMP-apexUpdateConfirm } 3022 id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 } 3024 TAMPApexUpdateConfirm ::= SEQUENCE { 3025 version [0] TAMPVersion DEFAULT v2, 3026 apexReplace TAMPMsgRef, 3027 apexConfirm ApexUpdateConfirm } 3029 ApexUpdateConfirm ::= CHOICE { 3030 terseApexConfirm [0] TerseApexUpdateConfirm, 3031 verboseApexConfirm [1] VerboseApexUpdateConfirm } 3033 TerseApexUpdateConfirm ::= StatusCode 3035 VerboseApexUpdateConfirm ::= SEQUENCE { 3036 status StatusCode, 3037 taInfo TrustAnchorChoiceList, 3038 communities [0] CommunityIdentifierList OPTIONAL, 3039 tampSeqNumbers [1] TAMPSequenceNumbers OPTIONAL } 3041 -- Community Update Message 3043 tamp-community-update CONTENT-TYPE ::= 3044 { TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate } 3046 id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 } 3048 TAMPCommunityUpdate ::= SEQUENCE { 3049 version [0] TAMPVersion DEFAULT v2, 3050 terse [1] TerseOrVerbose DEFAULT verbose, 3051 msgRef TAMPMsgRef, 3052 updates CommunityUpdates } 3054 CommunityUpdates ::= SEQUENCE { 3055 remove [1] CommunityIdentifierList OPTIONAL, 3056 add [2] CommunityIdentifierList OPTIONAL } 3057 -- At least one must be present 3059 -- Community Update Confirm Message 3061 tamp-community-update-confirm CONTENT-TYPE ::= 3062 { TAMPCommunityUpdateConfirm IDENTIFIED BY 3063 id-ct-TAMP-communityUpdateConfirm } 3065 id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= 3066 { id-tamp 8 } 3068 TAMPCommunityUpdateConfirm ::= SEQUENCE { 3069 version [0] TAMPVersion DEFAULT v2, 3070 update TAMPMsgRef, 3071 commConfirm CommunityConfirm } 3073 CommunityConfirm ::= CHOICE { 3074 terseCommConfirm [0] TerseCommunityConfirm, 3075 verboseCommConfirm [1] VerboseCommunityConfirm } 3077 TerseCommunityConfirm ::= StatusCode 3079 VerboseCommunityConfirm ::= SEQUENCE { 3080 status StatusCode, 3081 communities CommunityIdentifierList OPTIONAL } 3083 -- Sequence Number Adjust Message 3085 tamp-sequence-number-adjust CONTENT-TYPE ::= 3086 { SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust } 3088 id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 } 3090 SequenceNumberAdjust ::= SEQUENCE { 3091 version [0] TAMPVersion DEFAULT v2, 3092 msgRef TAMPMsgRef } 3094 -- Sequence Number Adjust Message 3096 tamp-sequence-number-adjust-confirm CONTENT-TYPE ::= 3097 { SequenceNumberAdjustConfirm IDENTIFIED BY 3098 id-ct-TAMP-seqNumAdjustConfirm } 3100 id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= { id-tamp 11 } 3102 SequenceNumberAdjustConfirm ::= SEQUENCE { 3103 version [0] TAMPVersion DEFAULT v2, 3104 adjust TAMPMsgRef, 3105 status StatusCode } 3107 -- TAMP Error Message 3109 tamp-error CONTENT-TYPE ::= 3110 { TAMPError IDENTIFIED BY id-ct-TAMP-error } 3112 id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 } 3114 TAMPError ::= SEQUENCE { 3115 version [0] TAMPVersion DEFAULT v2, 3116 msgType OBJECT IDENTIFIER, 3117 status StatusCode, 3118 msgRef TAMPMsgRef OPTIONAL } 3120 -- Status Codes 3122 StatusCode ::= ENUMERATED { 3123 success (0), 3124 decodeFailure (1), 3125 badContentInfo (2), 3126 badSignedData (3), 3127 badEncapContent (4), 3128 badCertificate (5), 3129 badSignerInfo (6), 3130 badSignedAttrs (7), 3131 badUnsignedAttrs (8), 3132 missingContent (9), 3133 noTrustAnchor (10), 3134 notAuthorized (11), 3135 badDigestAlgorithm (12), 3136 badSignatureAlgorithm (13), 3137 unsupportedKeySize (14), 3138 unsupportedParameters (15), 3139 signatureFailure (16), 3140 insufficientMemory (17), 3141 unsupportedTAMPMsgType (18), 3142 apexTAMPAnchor (19), 3143 improperTAAddition (20), 3144 seqNumFailure (21), 3145 contingencyPublicKeyDecrypt (22), 3146 incorrectTarget (23), 3147 communityUpdateFailed (24), 3148 trustAnchorNotFound (25), 3149 unsupportedTAAlgorithm (26), 3150 unsupportedTAKeySize (27), 3151 unsupportedContinPubKeyDecryptAlg (28), 3152 missingSignature (29), 3153 resourcesBusy (30), 3154 versionNumberMismatch (31), 3155 missingPolicySet (32), 3156 revokedCertificate (33), 3157 unsupportedTrustAnchorFormat (34), 3158 improperTAChange (35), 3159 malformed (36), 3160 cmsError (37), 3161 unsupportedTargetIdentifier (38), 3162 other (127) } 3164 -- Object Identifier Arc for Attributes 3166 id-attributes OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) 3167 us(840) organization(1) gov(101) dod(2) infosec(1) 5 } 3169 -- TAMP Unsigned Attributes 3170 -- These attributes are unsigned attributes and go into the 3171 -- UnsignedAttributes set in [CMS] 3173 TAMPUnsignedAttributes ATTRIBUTE ::= { 3174 contingency-public-key-decrypt-key, 3175 ... -- Expect additional attributes -- 3176 } 3178 -- contingency-public-key-decrypt-key unsigned attribute 3180 contingency-public-key-decrypt-key ATTRIBUTE ::= { 3181 TYPE PlaintextSymmetricKey IDENTIFIED BY 3182 id-aa-TAMP-contingencyPublicKeyDecryptKey } 3184 id-aa-TAMP-contingencyPublicKeyDecryptKey OBJECT IDENTIFIER ::= { 3185 id-attributes 63 } 3187 PlaintextSymmetricKey ::= OCTET STRING 3189 -- id-pe-wrappedApexContinKey extension 3191 wrappedApexContinKey EXTENSION ::= { 3192 SYNTAX ApexContingencyKey 3193 IDENTIFIED BY id-pe-wrappedApexContinKey } 3195 id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::= 3196 { iso(1) identified-organization(3) dod(6) internet(1) 3197 security(5) mechanisms(5) pkix(7) pe(1) 20 } 3199 ApexContingencyKey ::= SEQUENCE { 3200 wrapAlgorithm 3201 AlgorithmIdentifier{KEY-WRAP, {SupportedWrapAlgorithms}}, 3202 wrappedContinPubKey OCTET STRING } 3204 END 3206 A.2. ASN.1 Module Using 1988 Syntax 3208 TAMP-Protocol-v2-88 3209 { joint-iso-ccitt(2) country(16) us(840) organization(1) 3210 gov(101) dod(2) infosec(1) modules(0) 31 } 3212 DEFINITIONS IMPLICIT TAGS ::= 3213 BEGIN 3215 IMPORTS 3216 TrustAnchorChoice, TrustAnchorTitle, CertPathControls 3217 FROM TrustAnchorInfoModule-88 -- from [I-D.ietf-pkix-ta-format] 3218 { joint-iso-ccitt(2) country(16) us(840) organization(1) 3219 gov(101) dod(2) infosec(1) modules(0) 33 } 3220 AlgorithmIdentifier, Certificate, Name, Attribute, TBSCertificate, 3221 SubjectPublicKeyInfo, CertificateSerialNumber, Validity 3222 FROM PKIX1Explicit88 -- from [RFC5280] 3223 { iso(1) identified-organization(3) dod(6) internet(1) 3224 security(5) mechanisms(5) pkix(7) id-mod(0) 3225 id-pkix1-explicit(18) } 3226 KeyIdentifier, AnotherName 3227 FROM PKIX1Implicit88 -- from [RFC5280] 3228 { iso(1) identified-organization(3) dod(6) internet(1) 3229 security(5) mechanisms(5) pkix(7) id-mod(0) 3230 id-pkix1-implicit(19) } ; 3232 -- Object Identifier Arc for TAMP Message Content Types 3234 id-tamp OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) 3235 us(840) organization(1) gov(101) dod(2) infosec(1) formats(2) 77 } 3237 -- CMS Content Types 3239 -- TAMP Status Query Message 3241 id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 } 3243 TAMPStatusQuery ::= SEQUENCE { 3244 version [0] TAMPVersion DEFAULT v2, 3245 terse [1] TerseOrVerbose DEFAULT verbose, 3246 query TAMPMsgRef } 3248 TAMPVersion ::= INTEGER { v1(1), v2(2) } 3250 TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) } 3252 SeqNumber ::= INTEGER (0..9223372036854775807) 3254 TAMPMsgRef ::= SEQUENCE { 3255 target TargetIdentifier, 3256 seqNum SeqNumber } 3258 TargetIdentifier ::= CHOICE { 3259 hwModules [1] HardwareModuleIdentifierList, 3260 communities [2] CommunityIdentifierList, 3261 allModules [3] NULL, 3262 uri [4] IA5String, 3263 otherName [5] AnotherName} 3265 HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF 3266 HardwareModules 3268 HardwareModules ::= SEQUENCE { 3269 hwType OBJECT IDENTIFIER, 3270 hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry } 3272 HardwareSerialEntry ::= CHOICE { 3273 all NULL, 3274 single OCTET STRING, 3275 block SEQUENCE { 3276 low OCTET STRING, 3277 high OCTET STRING } } 3279 CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community 3281 Community ::= OBJECT IDENTIFIER 3283 -- TAMP Status Response Message 3285 id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 } 3287 TAMPStatusResponse ::= SEQUENCE { 3288 version [0] TAMPVersion DEFAULT v2, 3289 query TAMPMsgRef, 3290 response StatusResponse, 3291 usesApex BOOLEAN DEFAULT TRUE} 3293 StatusResponse ::= CHOICE { 3294 terseResponse [0] TerseStatusResponse, 3295 verboseResponse [1] VerboseStatusResponse } 3297 TerseStatusResponse ::= SEQUENCE { 3298 taKeyIds KeyIdentifiers, 3299 communities CommunityIdentifierList OPTIONAL } 3301 KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier 3303 VerboseStatusResponse ::= SEQUENCE { 3304 taInfo TrustAnchorChoiceList, 3305 continPubKeyDecryptAlg [0] AlgorithmIdentifier OPTIONAL, 3306 communities [1] CommunityIdentifierList OPTIONAL, 3307 tampSeqNumbers [2] TAMPSequenceNumbers OPTIONAL } 3309 TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF 3310 TrustAnchorChoice 3312 TAMPSequenceNumber ::= SEQUENCE { 3313 keyId KeyIdentifier, 3314 seqNumber SeqNumber } 3316 TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF 3317 TAMPSequenceNumber 3319 -- Trust Anchor Update Message 3320 id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 } 3322 TAMPUpdate ::= SEQUENCE { 3323 version [0] TAMPVersion DEFAULT v2, 3324 terse [1] TerseOrVerbose DEFAULT verbose, 3325 msgRef TAMPMsgRef, 3326 updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate, 3327 tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL } 3329 TrustAnchorUpdate ::= CHOICE { 3330 add [1] TrustAnchorChoice, 3331 remove [2] SubjectPublicKeyInfo, 3332 change [3] EXPLICIT TrustAnchorChangeInfoChoice } 3334 TrustAnchorChangeInfoChoice ::= CHOICE { 3335 tbsCertChange [0] TBSCertificateChangeInfo, 3336 taChange [1] TrustAnchorChangeInfo } 3338 TBSCertificateChangeInfo ::= SEQUENCE { 3339 serialNumber CertificateSerialNumber OPTIONAL, 3340 signature [0] AlgorithmIdentifier OPTIONAL, 3341 issuer [1] Name OPTIONAL, 3342 validity [2] Validity OPTIONAL, 3343 subject [3] Name OPTIONAL, 3344 subjectPublicKeyInfo [4] SubjectPublicKeyInfo, 3345 exts [5] EXPLICIT Extensions OPTIONAL } 3347 TrustAnchorChangeInfo ::= SEQUENCE { 3348 pubKey SubjectPublicKeyInfo, 3349 keyId KeyIdentifier OPTIONAL, 3350 taTitle TrustAnchorTitle OPTIONAL, 3351 certPath CertPathControls OPTIONAL, 3352 exts [1] Extensions OPTIONAL} 3354 -- Trust Anchor Update Confirm Message 3356 id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 } 3358 TAMPUpdateConfirm ::= SEQUENCE { 3359 version [0] TAMPVersion DEFAULT v2, 3360 update TAMPMsgRef, 3361 confirm UpdateConfirm } 3363 UpdateConfirm ::= CHOICE { 3364 terseConfirm [0] TerseUpdateConfirm, 3365 verboseConfirm [1] VerboseUpdateConfirm } 3367 TerseUpdateConfirm ::= StatusCodeList 3368 StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode 3370 VerboseUpdateConfirm ::= SEQUENCE { 3371 status StatusCodeList, 3372 taInfo TrustAnchorChoiceList, 3373 tampSeqNumbers TAMPSequenceNumbers OPTIONAL, 3374 usesApex BOOLEAN DEFAULT TRUE} 3376 -- Apex Trust Anchor Update Message 3378 id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 } 3380 TAMPApexUpdate ::= SEQUENCE { 3381 version [0] TAMPVersion DEFAULT v2, 3382 terse [1] TerseOrVerbose DEFAULT verbose, 3383 msgRef TAMPMsgRef, 3384 clearTrustAnchors BOOLEAN, 3385 clearCommunities BOOLEAN, 3386 seqNumber SeqNumber OPTIONAL, 3387 apexTA TrustAnchorChoice } 3389 -- Apex Trust Anchor Update Confirm Message 3391 id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 } 3393 TAMPApexUpdateConfirm ::= SEQUENCE { 3394 version [0] TAMPVersion DEFAULT v2, 3395 apexReplace TAMPMsgRef, 3396 apexConfirm ApexUpdateConfirm } 3398 ApexUpdateConfirm ::= CHOICE { 3399 terseApexConfirm [0] TerseApexUpdateConfirm, 3400 verboseApexConfirm [1] VerboseApexUpdateConfirm } 3402 TerseApexUpdateConfirm ::= StatusCode 3404 VerboseApexUpdateConfirm ::= SEQUENCE { 3405 status StatusCode, 3406 taInfo TrustAnchorChoiceList, 3407 communities [0] CommunityIdentifierList OPTIONAL, 3408 tampSeqNumbers [1] TAMPSequenceNumbers OPTIONAL } 3410 -- Community Update Message 3412 id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 } 3414 TAMPCommunityUpdate ::= SEQUENCE { 3415 version [0] TAMPVersion DEFAULT v2, 3416 terse [1] TerseOrVerbose DEFAULT verbose, 3417 msgRef TAMPMsgRef, 3418 updates CommunityUpdates } 3420 CommunityUpdates ::= SEQUENCE { 3421 remove [1] CommunityIdentifierList OPTIONAL, 3422 add [2] CommunityIdentifierList OPTIONAL } 3423 -- At least one must be present 3425 -- Community Update Confirm Message 3427 id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 8 } 3429 TAMPCommunityUpdateConfirm ::= SEQUENCE { 3430 version [0] TAMPVersion DEFAULT v2, 3431 update TAMPMsgRef, 3432 commConfirm CommunityConfirm } 3434 CommunityConfirm ::= CHOICE { 3435 terseCommConfirm [0] TerseCommunityConfirm, 3436 verboseCommConfirm [1] VerboseCommunityConfirm } 3438 TerseCommunityConfirm ::= StatusCode 3440 VerboseCommunityConfirm ::= SEQUENCE { 3441 status StatusCode, 3442 communities CommunityIdentifierList OPTIONAL } 3444 -- Sequence Number Adjust Message 3446 id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 } 3448 SequenceNumberAdjust ::= SEQUENCE { 3449 version [0] TAMPVersion DEFAULT v2, 3450 msgRef TAMPMsgRef } 3452 -- Sequence Number Adjust Message 3454 id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= { id-tamp 11 } 3456 SequenceNumberAdjustConfirm ::= SEQUENCE { 3457 version [0] TAMPVersion DEFAULT v2, 3458 adjust TAMPMsgRef, 3459 status StatusCode } 3461 -- TAMP Error Message 3463 id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 } 3465 TAMPError ::= SEQUENCE { 3466 version [0] TAMPVersion DEFAULT v2, 3467 msgType OBJECT IDENTIFIER, 3468 status StatusCode, 3469 msgRef TAMPMsgRef OPTIONAL } 3471 -- Status Codes 3473 StatusCode ::= ENUMERATED { 3474 success (0), 3475 decodeFailure (1), 3476 badContentInfo (2), 3477 badSignedData (3), 3478 badEncapContent (4), 3479 badCertificate (5), 3480 badSignerInfo (6), 3481 badSignedAttrs (7), 3482 badUnsignedAttrs (8), 3483 missingContent (9), 3484 noTrustAnchor (10), 3485 notAuthorized (11), 3486 badDigestAlgorithm (12), 3487 badSignatureAlgorithm (13), 3488 unsupportedKeySize (14), 3489 unsupportedParameters (15), 3490 signatureFailure (16), 3491 insufficientMemory (17), 3492 unsupportedTAMPMsgType (18), 3493 apexTAMPAnchor (19), 3494 improperTAAddition (20), 3495 seqNumFailure (21), 3496 contingencyPublicKeyDecrypt (22), 3497 incorrectTarget (23), 3498 communityUpdateFailed (24), 3499 trustAnchorNotFound (25), 3500 unsupportedTAAlgorithm (26), 3501 unsupportedTAKeySize (27), 3502 unsupportedContinPubKeyDecryptAlg (28), 3503 missingSignature (29), 3504 resourcesBusy (30), 3505 versionNumberMismatch (31), 3506 missingPolicySet (32), 3507 revokedCertificate (33), 3508 unsupportedTrustAnchorFormat (34), 3509 improperTAChange (35), 3510 malformed (36), 3511 cmsError (37), 3512 unsupportedTargetIdentifier (38), 3513 other (127) } 3515 -- Object Identifier Arc for Attributes 3517 id-attributes OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) 3518 us(840) organization(1) gov(101) dod(2) infosec(1) 5 } 3520 -- id-aa-TAMP-contingencyPublicKeyDecryptKey uses 3521 -- PlaintextSymmetricKey syntax 3522 id-aa-TAMP-contingencyPublicKeyDecryptKey OBJECT IDENTIFIER ::= { 3523 id-attributes 63 } 3525 PlaintextSymmetricKey ::= OCTET STRING 3527 -- id-pe-wrappedApexContinKey extension 3529 id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::= 3530 { iso(1) identified-organization(3) dod(6) internet(1) 3531 security(5) mechanisms(5) pkix(7) pe(1) 20 } 3533 ApexContingencyKey ::= SEQUENCE { 3534 wrapAlgorithm AlgorithmIdentifier, 3535 wrappedContinPubKey OCTET STRING } 3537 END 3539 Appendix B. Media Type Registrations 3541 Eleven media type registrations are provided in this appendix. As 3542 noted in Section 2, in all cases TAMP messages are encapsulated 3543 within ContentInfo structures. Signed messages are additionally 3544 encapsulated within a SignedData structure. 3546 B.1. application/tamp-status-query 3548 To: ietf-types@iana.org 3550 Subject: Registration of media type application/tamp-status-query 3552 Media type name: application 3554 Subtype name: tamp-status-query 3556 Required parameters: None 3558 Optional parameters: None 3560 Encoding considerations: Binary 3562 Security considerations: Carries a signed request for status 3563 information. Integrity protection is discussed in section 4.1. 3564 Replay detection is discussed in section 6. 3566 Interoperability considerations: None 3568 Published specification: TBD 3570 Applications that use this media type: TAMP clients responding to 3571 requests for status information. 3573 Additional information: 3575 Magic number(s): None 3577 File extension(s): .tsq 3579 Macintosh File Type Code(s): 3581 Person & email address to contact for further information: 3583 Sam Ashmore - srashmo@radium.ncsc.mil 3585 Intended usage: COMMON 3586 Restrictions on usage: None 3588 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3590 Change controller: IESG 3592 B.2. application/tamp-status-response 3594 To: ietf-types@iana.org 3596 Subject: Registration of media type application/tamp-status-response 3598 Media type name: application 3600 Subtype name: tamp-status-response 3602 Required parameters: None 3604 Optional parameters: None 3606 Encoding considerations: Binary 3608 Security considerations: Carries optionally signed status 3609 information. Integrity protection is discussed in section 4.2. 3611 Interoperability considerations: None 3613 Published specification: TBD 3615 Applications that use this media type: TAMP clients responding to 3616 requests for status information. 3618 Additional information: 3620 Magic number(s): None 3622 File extension(s): .tsr 3624 Macintosh File Type Code(s): 3626 Person & email address to contact for further information: 3628 Sam Ashmore - srashmo@radium.ncsc.mil 3630 Intended usage: COMMON 3632 Restrictions on usage: None 3633 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3635 Change controller: IESG 3637 B.3. application/tamp-update 3639 To: ietf-types@iana.org 3641 Subject: Registration of media type application/tamp-update 3643 Media type name: application 3645 Subtype name: tamp-update 3647 Required parameters: None 3649 Optional parameters: None 3651 Encoding considerations: Binary 3653 Security considerations: Carries a signed trust anchor update 3654 message. Integrity protection is discussed in section 4.3. Replay 3655 detection is discussed in section 6. 3657 Interoperability considerations: None 3659 Published specification: TBD 3661 Applications that use this media type: TAMP clients responding to 3662 requests to update trust anchor information. 3664 Additional information: 3666 Magic number(s): None 3668 File extension(s): .tur 3670 Macintosh File Type Code(s): 3672 Person & email address to contact for further information: 3674 Sam Ashmore - srashmo@radium.ncsc.mil 3676 Intended usage: COMMON 3678 Restrictions on usage: None 3680 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3681 Change controller: IESG 3683 B.4. application/tamp-update-confirm 3685 To: ietf-types@iana.org 3687 Subject: Registration of media type application/tamp-update-confirm 3689 Media type name: application 3691 Subtype name: tamp-update-confirm 3693 Required parameters: None 3695 Optional parameters: None 3697 Encoding considerations: Binary 3699 Security considerations: Carries an optionally signed TAMP update 3700 response. Integrity protection is discussed in section 4.4. 3702 Interoperability considerations: None 3704 Published specification: TBD 3706 Applications that use this media type: TAMP clients responding to 3707 requests to update trust anchor information 3709 Additional information: 3711 Magic number(s): None 3713 File extension(s): .tuc 3715 Macintosh File Type Code(s): 3717 Person & email address to contact for further information: 3719 Sam Ashmore - srashmo@radium.ncsc.mil 3721 Intended usage: COMMON 3723 Restrictions on usage: None 3725 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3727 Change controller: IESG 3729 B.5. application/tamp-apex-update 3731 To: ietf-types@iana.org 3733 Subject: Registration of media type application/tamp-apex-update 3735 Media type name: application 3737 Subtype name: tamp-apex-update 3739 Required parameters: None 3741 Optional parameters: None 3743 Encoding considerations: Binary 3745 Security considerations: Carries a signed request to update an apex 3746 trust anchor information. Integrity protection is discussed in 3747 section 4.5. Replay detection is discussed in section 6. 3749 Interoperability considerations: None 3751 Published specification: TBD 3753 Applications that use this media type: TAMP clients responding to 3754 requests to update an apex trust anchor. 3756 Additional information: 3758 Magic number(s): None 3760 File extension(s): .tau 3762 Macintosh File Type Code(s): 3764 Person & email address to contact for further information: 3766 Sam Ashmore - srashmo@radium.ncsc.mil 3768 Intended usage: COMMON 3770 Restrictions on usage: None 3772 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3774 Change controller: IESG 3776 B.6. application/tamp-apex-update-confirm 3778 To: ietf-types@iana.org 3780 Subject: Registration of media type application/ 3781 tamp-apex-update-confirm 3783 Media type name: application 3785 Subtype name: tamp-apex-update-confirm 3787 Required parameters: None 3789 Optional parameters: None 3791 Encoding considerations: Binary 3793 Security considerations: Carries an optionally signed response to an 3794 apex update request. Integrity protection is discussed in section 3795 4.6. 3797 Interoperability considerations: None 3799 Published specification: TBD 3801 Applications that use this media type: TAMP clients responding to 3802 requests to update an apex trust anchor. 3804 Additional information: 3806 Magic number(s): None 3808 File extension(s): .auc 3810 Macintosh File Type Code(s): 3812 Person & email address to contact for further information: 3814 Sam Ashmore - srashmo@radium.ncsc.mil 3816 Intended usage: COMMON 3818 Restrictions on usage: None 3820 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3822 Change controller: IESG 3824 B.7. application/tamp-community-update 3826 To: ietf-types@iana.org 3828 Subject: Registration of media type application/tamp-community-update 3830 Media type name: application 3832 Subtype name: tamp-community-update 3834 Required parameters: None 3836 Optional parameters: None 3838 Encoding considerations: Binary 3840 Security considerations: Carries a signed request to update community 3841 membership information. Integrity protection is discussed in section 3842 4.7. Replay detection is discussed in section 6. 3844 Interoperability considerations: None 3846 Published specification: TBD 3848 Applications that use this media type: TAMP clients responding to 3849 requests to update community membership. 3851 Additional information: 3853 Magic number(s): None 3855 File extension(s): .tcu 3857 Macintosh File Type Code(s): 3859 Person & email address to contact for further information: 3861 Sam Ashmore - srashmo@radium.ncsc.mil 3863 Intended usage: COMMON 3865 Restrictions on usage: None 3867 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3869 Change controller: IESG 3871 B.8. application/tamp-community-update-confirm 3873 To: ietf-types@iana.org 3875 Subject: Registration of media type application/ 3876 tamp-community-update-confirm 3878 Media type name: application 3880 Subtype name: tamp-community-update-confirm 3882 Required parameters: None 3884 Optional parameters: None 3886 Encoding considerations: Binary 3888 Security considerations: Carries an optionally signed response to a 3889 community update request. Integrity protection is discussed in 3890 section 4.8. 3892 Interoperability considerations: None 3894 Published specification: TBD 3896 Applications that use this media type: TAMP clients responding to 3897 requests to update community membership. 3899 Additional information: 3901 Magic number(s): None 3903 File extension(s): .cuc 3905 Macintosh File Type Code(s): 3907 Person & email address to contact for further information: 3909 Sam Ashmore - srashmo@radium.ncsc.mil 3911 Intended usage: COMMON 3913 Restrictions on usage: None 3915 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3917 Change controller: IESG 3919 B.9. application/tamp-sequence-adjust 3921 To: ietf-types@iana.org 3923 Subject: Registration of media type application/tamp-sequence-adjust 3925 Media type name: application 3927 Subtype name: tamp-sequence-adjust 3929 Required parameters: None 3931 Optional parameters: None 3933 Encoding considerations: Binary 3935 Security considerations: Carries a signed request to update sequence 3936 number information. Integrity protection is discussed in section 3937 4.9. Replay detection is discussed in section 6. 3939 Interoperability considerations: None 3941 Published specification: TBD 3943 Applications that use this media type: TAMP clients responding to 3944 requests to update sequence number information. 3946 Additional information: 3948 Magic number(s): None 3950 File extension(s): .tsa 3952 Macintosh File Type Code(s): 3954 Person & email address to contact for further information: 3956 Sam Ashmore - srashmo@radium.ncsc.mil 3958 Intended usage: COMMON 3960 Restrictions on usage: None 3962 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3964 Change controller: IESG 3966 B.10. application/tamp-sequence-adjust-confirm 3968 To: ietf-types@iana.org 3970 Subject: Registration of media type application/ 3971 tamp-sequence-adjust-confirm 3973 Media type name: application 3975 Subtype name: tamp-sequence-adjust-confirm 3977 Required parameters: None 3979 Optional parameters: None 3981 Encoding considerations: Binary 3983 Security considerations: Carries an optionally signed sequence number 3984 adjust confirmation message. Integrity protection is discussed in 3985 section 4.10. 3987 Interoperability considerations: None 3989 Published specification: TBD 3991 Applications that use this media type: TAMP clients responding to 3992 requests to update sequence number information. 3994 Additional information: 3996 Magic number(s): None 3998 File extension(s): .sac 4000 Macintosh File Type Code(s): 4002 Person & email address to contact for further information: 4004 Sam Ashmore - srashmo@radium.ncsc.mil 4006 Intended usage: COMMON 4008 Restrictions on usage: None 4010 Author: Sam Ashmore - srashmo@radium.ncsc.mil 4012 Change controller: IESG 4014 B.11. application/tamp-error 4016 To: ietf-types@iana.org 4018 Subject: Registration of media type application/tamp-error 4020 Media type name: application 4022 Subtype name: tamp-error 4024 Required parameters: None 4026 Optional parameters: None 4028 Encoding considerations: Binary 4030 Security considerations: Carries optionally signed error information 4031 collecting during TAMP processing. Integrity protection is discussed 4032 in section 4.11. 4034 Interoperability considerations: None 4036 Published specification: TBD 4038 Applications that use this media type: TAMP clients processing TAMP 4039 messages. 4041 Additional information: 4043 Magic number(s): None 4045 File extension(s): .ter 4047 Macintosh File Type Code(s): 4049 Person & email address to contact for further information: 4051 Sam Ashmore - srashmo@radium.ncsc.mil 4053 Intended usage: COMMON 4055 Restrictions on usage: None 4057 Author: Sam Ashmore - srashmo@radium.ncsc.mil 4059 Change controller: IESG 4061 Appendix C. TAMP Over HTTP 4063 This appendix describes the formatting and transportation conventions 4064 for the TAMP messages when carried by HTTP [RFC2616]. Each TAMP 4065 message type is covered by a subsection below. Each TAMP request 4066 message sent via HTTP is responded to either with an HTTP response 4067 containing a TAMP response or error or, if failure occurs prior to 4068 invoking TAMP, an HTTP error. TAMP response, confirmation and error 4069 messages are not suitable for caching. In order for TAMP clients and 4070 servers using HTTP to interoperate, the following rules apply. 4072 o Clients MUST use the POST method to submit their requests. 4074 o Servers MUST use the 200 response code for successful responses. 4076 o Clients MAY attempt to send HTTPS requests using TLS 1.0 or later, 4077 although servers are not required to support TLS. 4079 o Servers MUST NOT assume client support for any type of HTTP 4080 authentication such as cookies, Basic authentication, or Digest 4081 authentication. 4083 o Clients and servers are expected to follow the other rules and 4084 restrictions in [RFC2616]. Note that some of those rules are for 4085 HTTP methods other than POST; clearly, only the rules that apply 4086 to POST are relevant for this specification. 4088 C.1. TAMP Status Query Message 4090 A TAMP Status Query Message using the POST method is constructed as 4091 follows: The Content-Type header MUST have the value "application/ 4092 tamp-status-query". 4094 The body of the message is the binary value of the DER encoding of 4095 the TAMPStatusQuery, wrapped in a CMS body as described in Section 2. 4097 C.2. TAMP Status Response Message 4099 An HTTP-based TAMP Status Response message is composed of the 4100 appropriate HTTP headers, followed by the binary value of the DER 4101 encoding of the TAMPStatusResponse, wrapped in a CMS body as 4102 described in Section 2. 4104 The Content-Type header MUST have the value "application/ 4105 tamp-status-response." 4107 C.3. Trust Anchor Update Message 4109 A Trust Anchor Update Message using the POST method is constructed as 4110 follows: The Content-Type header MUST have the value "application/ 4111 tamp-update". 4113 The body of the message is the binary value of the DER encoding of 4114 the TAMPUpdate, wrapped in a CMS body as described in Section 2. 4116 C.4. Trust Anchor Update Confirm Message 4118 An HTTP-based Trust Anchor Update Confirm message is composed of the 4119 appropriate HTTP headers, followed by the binary value of the DER 4120 encoding of the TAMPUpdateConfirm, wrapped in a CMS body as described 4121 in Section 2. 4123 The Content-Type header MUST have the value "application/ 4124 tamp-update-confirm". 4126 C.5. Apex Trust Anchor Update Message 4128 An Apex Trust Anchor Update Message using the POST method is 4129 constructed as follows: The Content-Type header MUST have the value 4130 "application/tamp-apex-update". 4132 The body of the message is the binary value of the DER encoding of 4133 the TAMPApexUpdate, wrapped in a CMS body as described in Section 2. 4135 C.6. Apex Trust Anchor Update Confirm Message 4137 An HTTP-based Apex Trust Anchor Update Confirm message is composed of 4138 the appropriate HTTP headers, followed by the binary value of the DER 4139 encoding of the TAMPApexUpdateConfirm, wrapped in a CMS body as 4140 described in Section 2. 4142 The Content-Type header MUST have the value "application/ 4143 tamp-apex-update-confirm". 4145 C.7. Community Update Message 4147 A Community Update Message using the POST method is constructed as 4148 follows: The Content-Type header MUST have the value "application/ 4149 tamp-community-update". 4151 The body of the message is the binary value of the DER encoding of 4152 the TAMPCommunityUpdate, wrapped in a CMS body as described in 4153 Section 2. 4155 C.8. Community Update Confirm Message 4157 An HTTP-based Community Update Confirm message is composed of the 4158 appropriate HTTP headers, followed by the binary value of the DER 4159 encoding of the TAMPCommunityUpdateConfirm, wrapped in a CMS body as 4160 described in Section 2. 4162 The Content-Type header MUST have the value "application/ 4163 tamp-community-update-confirm". 4165 C.9. Sequence Number Adjust Message 4167 A Sequence Number Adjust Message using the POST method is constructed 4168 as follows: The Content-Type header MUST have the value "application/ 4169 tamp-sequence-adjust". 4171 The body of the message is the binary value of the DER encoding of 4172 the SequenceNumberAdjust, wrapped in a CMS body as described in 4173 Section 2. 4175 C.10. Sequence Number Adjust Confirm Message 4177 An HTTP-based Sequence Number Adjust Confirm message is composed of 4178 the appropriate HTTP headers, followed by the binary value of the DER 4179 encoding of the SequenceNumberAdjustConfirm, wrapped in a CMS body as 4180 described in Section 2. 4182 The Content-Type header MUST have the value "application/ 4183 tamp-sequence-adjust-confirm". 4185 C.11. TAMP Error Message 4187 An HTTP-based TAMP Error message is composed of the appropriate HTTP 4188 headers, followed by the binary value of the DER encoding of the 4189 TAMPError, wrapped in a CMS body as described in Section 2. 4191 Authors' Addresses 4193 Russ Housley 4194 Vigil Security, LLC 4195 918 Spring Knoll Drive 4196 Herndon, VA 20170 4198 Email: housley@vigilsec.com 4200 Sam Ashmore 4201 National Security Agency 4202 Suite 6751 4203 9800 Savage Road 4204 Fort Meade, MD 20755 4206 Email: srashmo@radium.ncsc.mil 4208 Carl Wallace 4209 Cygnacom Solutions 4210 Suite 5200 4211 7925 Jones Branch Drive 4212 McLean, VA 22102 4214 Email: cwallace@cygnacom.com