idnits 2.17.1 draft-ietf-pkix-tamp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 (October 5, 2009) is 5311 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 3338 -- Looks like a reference, but probably isn't: '2' on line 3324 -- Looks like a reference, but probably isn't: '0' on line 3368 -- Looks like a reference, but probably isn't: '3' on line 3244 -- Looks like a reference, but probably isn't: '4' on line 3245 -- Looks like a reference, but probably isn't: '5' on line 3246 == 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') == Outdated reference: A later version (-04) exists of draft-ietf-pkix-ta-format-03 ** 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) -- 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 (~~), 3 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: April 8, 2010 National Security Agency 6 C. Wallace 7 Cygnacom Solutions 8 October 5, 2009 10 Trust Anchor Management Protocol (TAMP) 11 draft-ietf-pkix-tamp-03 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 8, 2010. 46 Copyright Notice 48 Copyright (c) 2009 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 in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document describes a transport independent protocol for the 60 management of trust anchors and community identifiers stored in a 61 trust anchor store. The protocol makes use of the Cryptographic 62 Message Syntax (CMS), and a digital signature is used to provide 63 integrity protection and data origin authentication. The protocol 64 can be used to manage trust anchor stores containing trust anchors 65 represented as Certificate, TBSCertificate or TrustAnchorInfo 66 objects. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 72 1.2. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 5 73 1.2.1. Apex Trust Anchors . . . . . . . . . . . . . . . . . . 6 74 1.2.2. Management Trust Anchors . . . . . . . . . . . . . . . 7 75 1.2.3. Identity Trust Anchors . . . . . . . . . . . . . . . . 7 76 1.3. Architectural Elements . . . . . . . . . . . . . . . . . . 8 77 1.3.1. Cryptographic Module . . . . . . . . . . . . . . . . . 8 78 1.3.2. Trust Anchor Store . . . . . . . . . . . . . . . . . . 9 79 1.3.3. TAMP Processing Dependencies . . . . . . . . . . . . . 9 80 1.3.4. Application-Specific Protocol Processing . . . . . . . 10 81 1.4. ASN.1 Encoding . . . . . . . . . . . . . . . . . . . . . . 11 82 2. Cryptographic Message Syntax Profile . . . . . . . . . . . . . 12 83 2.1. Content Info . . . . . . . . . . . . . . . . . . . . . . . 13 84 2.2. SignedData Info . . . . . . . . . . . . . . . . . . . . . 13 85 2.2.1. SignerInfo . . . . . . . . . . . . . . . . . . . . . . 14 86 2.2.2. EncapsulatedContentInfo . . . . . . . . . . . . . . . 16 87 2.2.3. Signed Attributes . . . . . . . . . . . . . . . . . . 16 88 2.2.4. Unsigned Attributes . . . . . . . . . . . . . . . . . 18 89 3. Trust Anchor Formats . . . . . . . . . . . . . . . . . . . . . 20 90 4. Trust Anchor Management Protocol Messages . . . . . . . . . . 21 91 4.1. TAMP Status Query . . . . . . . . . . . . . . . . . . . . 22 92 4.2. TAMP Status Query Response . . . . . . . . . . . . . . . . 26 93 4.3. Trust Anchor Update . . . . . . . . . . . . . . . . . . . 29 94 4.3.1. Trust Anchor List . . . . . . . . . . . . . . . . . . 34 95 4.4. Trust Anchor Update Confirm . . . . . . . . . . . . . . . 34 96 4.5. Apex Trust Anchor Update . . . . . . . . . . . . . . . . . 36 97 4.6. Apex Trust Anchor Update Confirm . . . . . . . . . . . . . 39 98 4.7. Community Update . . . . . . . . . . . . . . . . . . . . . 41 99 4.8. Community Update Confirm . . . . . . . . . . . . . . . . . 43 100 4.9. Sequence Number Adjust . . . . . . . . . . . . . . . . . . 45 101 4.10. Sequence Number Adjust Confirm . . . . . . . . . . . . . . 46 102 4.11. TAMP Error . . . . . . . . . . . . . . . . . . . . . . . . 47 103 5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . 49 104 6. Sequence Number Processing . . . . . . . . . . . . . . . . . . 54 105 7. Subordination Processing . . . . . . . . . . . . . . . . . . . 56 106 8. Implementation Considerations . . . . . . . . . . . . . . . . 59 107 9. Apex trust anchor info certificate extension . . . . . . . . . 60 108 10. Security Considerations . . . . . . . . . . . . . . . . . . . 61 109 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 111 12.1. Normative References . . . . . . . . . . . . . . . . . . . 65 112 12.2. Informative References . . . . . . . . . . . . . . . . . . 65 113 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 67 114 A.1. ASN.1 Module Using 1993 Syntax . . . . . . . . . . . . . . 67 115 A.2. ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . 76 116 Appendix B. MIME Media Type Registrations . . . . . . . . . . . . 84 117 B.1. application/tamp-status-query . . . . . . . . . . . . . . 84 118 B.2. application/tamp-status-response . . . . . . . . . . . . . 85 119 B.3. application/tamp-update . . . . . . . . . . . . . . . . . 86 120 B.4. application/tamp-update-confirm . . . . . . . . . . . . . 87 121 B.5. application/tamp-apex-update . . . . . . . . . . . . . . . 88 122 B.6. application/tamp-apex-update-confirm . . . . . . . . . . . 89 123 B.7. application/tamp-community-update . . . . . . . . . . . . 90 124 B.8. application/tamp-community-update-confirm . . . . . . . . 91 125 B.9. application/tamp-sequence-adjust . . . . . . . . . . . . . 92 126 B.10. application/tamp-sequence-adjust-confirm . . . . . . . . . 93 127 B.11. application/tamp-error . . . . . . . . . . . . . . . . . . 94 128 Appendix C. TAMP Over HTTP . . . . . . . . . . . . . . . . . . . 95 129 C.1. TAMP Status Query Message . . . . . . . . . . . . . . . . 95 130 C.2. TAMP Status Response Message . . . . . . . . . . . . . . . 95 131 C.3. Trust Anchor Update Message . . . . . . . . . . . . . . . 95 132 C.4. Trust Anchor Update Confirm Message . . . . . . . . . . . 96 133 C.5. Apex Trust Anchor Update Message . . . . . . . . . . . . . 96 134 C.6. Apex Trust Anchor Update Confirm Message . . . . . . . . . 96 135 C.7. Community Update Message . . . . . . . . . . . . . . . . . 96 136 C.8. Community Update Confirm Message . . . . . . . . . . . . . 96 137 C.9. Sequence Number Adjust Message . . . . . . . . . . . . . . 97 138 C.10. Sequence Number Adjust Confirm Message . . . . . . . . . . 97 139 C.11. TAMP Error Message . . . . . . . . . . . . . . . . . . . . 97 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 98 142 1. Introduction 144 This document describes the Trust Anchor Management Protocol (TAMP). 145 TAMP may be used to manage the trust anchors and community 146 identifiers in any device that uses digital signatures; however, this 147 specification was written with the requirements of cryptographic 148 modules in mind. For example, TAMP can support signed firmware 149 packages [RFC4108], where the trust anchor public key can be used to 150 validate digital signatures on firmware packages or validate the 151 X.509 certification path [RFC5280][X.509] of the firmware package 152 signer. 154 Most TAMP messages are digitally signed to provide integrity 155 protection and data origin authentication. Both signed and unsigned 156 TAMP messages employ the Cryptographic Message Syntax (CMS) 157 [RFC3852]. The CMS is a data protection encapsulation syntax that 158 makes use of ASN.1 [X.680]. 160 This specification does not provide for confidentiality of TAMP 161 messages. If confidentiality is required, then the communications 162 environment that is used to transfer TAMP messages must provide it. 164 1.1. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 1.2. Trust Anchors 172 TAMP manages trust anchors. A trust anchor contains a public key 173 that is used to validate digital signatures. TAMP recognizes three 174 formats for representing trust anchor information: Certificate 175 [RFC5280], TBSCertificate [RFC5280] and TrustAnchorInfo 176 [I-D.ietf-pkix-ta-format]. 178 All trust anchors are distinguished by the public key, and all trust 179 anchors consist of the following components: 181 o A public key signature algorithm identifier and associated public 182 key, which MAY include parameters 184 o A public key identifier 186 Other information may appear in a trust anchor, including 187 certification path processing controls and a human readable name. 189 TAMP recognizes three types of trust anchors based on functionality: 191 apex trust anchors, management trust anchors, and identity trust 192 anchors. 194 In addition to the information described above, apex trust anchors 195 and management trust anchors that sign TAMP messages have an 196 associated sequence number that is used for replay detection. 198 The public key is used to name a trust anchor, and the public key 199 identifier is used to identify the trust anchor as a signer of a 200 particular object. This public key identifier can be stored with the 201 trust anchor, or in most public key identifier assignment methods, it 202 can be computed from the public key whenever needed. 204 A trust anchor public key can be used in two different ways to 205 support digital signature validation. In the first approach, the 206 trust anchor public key is used directly to validate the digital 207 signature. In the second approach, the trust anchor public key is 208 used to validate an X.509 certification path, and then the subject 209 public key in the final certificate in the certification path is used 210 to validate the digital signature. When the second approach is 211 employed, the certified public key may be used for things other than 212 digital signature validation; the other possible actions are 213 constrained by the key usage certificate extension. 215 TAMP implementations MUST support validation of TAMP messages that 216 are directly signed by a trust anchor. Support for TAMP messages 217 validated using an X.509 certificate signed by a trust anchor, or 218 using longer certification paths, is OPTIONAL. The CMS provides a 219 location to carry X.509 certificates, and this facility can be used 220 to transfer certificates to aid in the construction of the 221 certification path. 223 1.2.1. Apex Trust Anchors 225 Within the context of a single trust anchor store, one trust anchor 226 is superior to all others. This trust anchor is referred to as the 227 apex trust anchor. This trust anchor represents the ultimate 228 authority over the trust anchor store. Much of this authority can be 229 delegated to other trust anchors. 231 The apex trust anchor private key is expected to be controlled by an 232 entity with information assurance responsibility for the trust anchor 233 store. The apex trust anchor is by definition unconstrained and 234 therefore does not have explicit authorization information associated 235 with it. 237 Due to the special nature of the apex trust anchor, TAMP includes 238 separate facilities to change it. In particular, TAMP includes a 239 facility to securely replace the apex trust anchor. This action 240 might be taken for one or more of the following reasons: 242 o The crypto period for the apex trust anchor public/private key 243 pair has come to an end 245 o The apex trust anchor private key is no longer available 247 o The apex trust anchor public/private key pair needs to be revoked 249 o The authority has decided to use a different digital signature 250 algorithm or the same digital signature algorithm with different 251 parameters, such as a different elliptic curve 253 o The authority has decided to use a different key size 255 o The authority has decided to transfer control to another authority 257 To accommodate these requirements, the apex trust anchor MAY include 258 two public keys. Whenever the apex trust anchor is updated, both 259 public keys would be replaced. The first public key, called the 260 operational public key, is used in the same manner as other trust 261 anchors. Any type of TAMP message, including an Apex Trust Anchor 262 Update message, can be validated with the operational public key. 263 The second public key, called the contingency public key, can only be 264 used to update the apex trust anchor. The contingency private key 265 SHOULD be used at only one point in time; it is used only to sign an 266 Apex Trust Anchor Update message which results in its own replacement 267 (as well as the replacement of the operational public key). The 268 contingency public key is distributed in encrypted form. When the 269 contingency public key is used to validate an Apex Trust Anchor 270 Update message, the symmetric key needed to decrypt the contingency 271 public key is provided as part of the signed Apex Trust Anchor Update 272 message that is to be verified with the contingency public key. 274 1.2.2. Management Trust Anchors 276 Management trust anchors are used in the management of cryptographic 277 modules. For example, the TAMP messages specified in this document 278 are validated to a management trust anchor. Likewise, a signed 279 firmware package as specified in [RFC4108] is validated to a 280 management trust anchor. 282 1.2.3. Identity Trust Anchors 284 Identity trust anchors are used to validate certification paths, and 285 they represent the trust anchor for a public key infrastructure. 286 They are most often used in the validation of certificates associated 287 with non-management applications. 289 1.3. Architectural Elements 291 TAMP does not assume any particular architecture. However, TAMP 292 REQUIRES the following architectural elements: a cryptographic 293 module, a trust anchor store, TAMP protocol processing, and other 294 application-specific protocol processing. 296 A globally unique algorithm identifier MUST be assigned for each one- 297 way hash function, digital signature generation/validation algorithm, 298 and symmetric key unwrapping algorithm that is implemented. To 299 support CMS, an object identifier (OID) is assigned to name a one-way 300 hash function, and another OID is assigned to name each combination 301 of a one-way hash function when used with a digital signature 302 algorithm. Similarly, certificates associate OIDs assigned to public 303 key algorithms with subject public keys, and certificates make use of 304 an OID that names both the one-way hash function and the digital 305 signature algorithm for the certificate issuer digital signature. 307 1.3.1. Cryptographic Module 309 The cryptographic module MUST include the following capabilities: 311 o The cryptographic module SHOULD support the secure storage of a 312 digital signature private key to sign TAMP responses and either a 313 certificate containing the associated public key or a certificate 314 designator. In the latter case, the certificate is stored 315 elsewhere but is available to parties that need to validate 316 cryptographic module digital signatures. The designator is a 317 public key identifier. 319 o The cryptographic module MUST support at least one one-way hash 320 function, one digital signature validation algorithm, one digital 321 signature generation algorithm, and, if contingency keys are 322 supported, one symmetric key unwrapping algorithm. If only one 323 one-way hash function is present, it MUST be consistent with the 324 digital signature validation and digital signature generation 325 algorithms. If only one digital signature validation algorithm is 326 present, it must be consistent with the apex trust anchor 327 operational public key. If only one digital signature generation 328 algorithm is present, it must be consistent with the cryptographic 329 module digital signature private key. These algorithms MUST be 330 available for processing TAMP messages, including the content 331 types defined in [RFC3852], and for validation of X.509 332 certification paths. 334 1.3.2. Trust Anchor Store 336 The trust anchor store MUST include the following capabilities: 338 o Each trust anchor store MUST have a unique name. For example, a 339 cryptographic module containing a single trust anchor store may be 340 identified by a unique serial number with respect to other modules 341 within the same family where the family is represented as an ASN.1 342 object identifier (OID) and the unique serial number is 343 represented as a string of octets. Other means of establishing a 344 unique name are also possible. 346 o Each trust anchor store SHOULD have the capability to securely 347 store one or more community identifiers. The community identifier 348 is an OID, and it identifies a collection of cryptographic modules 349 that can be the target of a single TAMP message or the intended 350 recipients for a particular management message. 352 o The trust anchor store MUST support the secure storage of exactly 353 one apex trust anchor. The trust anchor store SHOULD support the 354 secure storage of at least one additional trust anchor. 356 1.3.3. TAMP Processing Dependencies 358 TAMP processing MUST include the following capabilities: 360 o TAMP processing MUST have a means of locating an appropriate trust 361 anchor. Two mechanisms are available. The first mechanism is 362 based on the public key identifier for digital signature 363 verification, and the second mechanism is based on the trust 364 anchor X.500 distinguished name and other X.509 certification path 365 controls for certificate path discovery and validation. The first 366 mechanism MUST be supported, but the second mechanism can also be 367 used. 369 o TAMP processing MUST be able to invoke the digital signature 370 validation algorithm using the public key held in secure storage 371 for trust anchors. 373 o TAMP processing MUST have read and write access to secure storage 374 for sequence numbers associated with each TAMP message signer as 375 described in Section 6. 377 o TAMP processing MUST have read and write access to secure storage 378 for trust anchors in order to update them. Update operations 379 include adding trust anchors, removing trust anchors, and 380 modifying trust anchors. Application-specific access controls 381 MUST be securely stored with each management trust anchor as 382 described in Section 1.3.4. 384 o TAMP processing MUST have read access to secure storage for the 385 community membership list, if any, to determine whether a targeted 386 message ought to be accepted. 388 o To implement the OPTIONAL community identifier update feature, 389 TAMP processing MUST have read and write access to secure storage 390 for the community membership list. 392 o To generate signed confirmation messages, TAMP processing MUST be 393 able to invoke the digital signature generation algorithm using 394 the cryptographic module digital signature private key, and it 395 MUST have read access to the cryptographic module certificate or 396 its designator. TAMP uses X.509 certificates [RFC5280]. 398 o The TAMP processing MUST have read access to the trust anchor 399 store unique name. 401 1.3.4. Application-Specific Protocol Processing 403 The apex trust anchor and management trust anchors managed with TAMP 404 can be used by the TAMP application. Other management applications 405 MAY make use of all three types of trust anchors, but non-management 406 applications SHOULD only make use of identity trust anchors. 407 Applications MUST ensure usage of a trust anchor is consistent with 408 any constraints associated with the trust anchor. For example, if 409 name constraints are associated with a trust anchor, certification 410 paths that start with the trust anchor and contain certificates with 411 names that violate the name constraints MUST be rejected. 413 The application-specific protocol processing MUST be provided the 414 following services: 416 o The application-specific protocol processing MUST have a means of 417 locating an appropriate trust anchor. Two mechanisms are 418 available to applications. The first mechanism is based on the 419 public key identifier for digital signature verification, and the 420 second mechanism is based on the trust anchor X.500 distinguished 421 name and other X.509 certification path controls for certificate 422 path discovery and validation. 424 o The application-specific protocol processing MUST be able to 425 invoke the digital signature validation algorithm using the public 426 key held in secure storage for trust anchors. 428 o The application-specific protocol processing MUST have read access 429 to data associated with trust anchors to ensure constraints can be 430 enforced appropriately. For example, an application MUST have 431 read access to any name constraints associated with a TA to ensure 432 certification paths terminated by that TA do not include 433 certificates issued to entities outside the TA manager-designated 434 namespace. 436 o The application-specific protocol processing MUST have read access 437 to secure storage for the community membership list, if any, to 438 determine whether a targeted message ought to be accepted. 440 o If the application-specific protocol requires digital signatures 441 on confirmation messages or receipts, then the application- 442 specific protocol processing MUST be able to invoke the digital 443 signature generation algorithm with the cryptographic module 444 digital signature private key and its associated certificate or 445 certificate designator. Digital signature generation MUST be 446 controlled in a manner that ensures that the content type of 447 signed confirmation messages or receipts is appropriate for the 448 application-specific protocol processing. 450 o The application-specific protocol processing MUST have read access 451 to the trust anchor store unique name. 453 1.4. ASN.1 Encoding 455 The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is 456 a formal notation used for describing data protocols, regardless of 457 the programming language used by the implementation. Encoding rules 458 describe how the values defined in ASN.1 will be represented for 459 transmission. The Basic Encoding Rules (BER) [X.690] are the most 460 widely employed rule set, but they offer more than one way to 461 represent data structures. For example, definite length encoding and 462 indefinite length encoding are supported. This flexibility is not 463 desirable when digital signatures are used. As a result, the 464 Distinguished Encoding Rules (DER) [X.690] were invented. DER is a 465 subset of BER that ensures a single way to represent a given value. 466 For example, DER always employs definite length encoding. 468 Digitally signed structures MUST be encoded with DER. In other 469 specifications, structures that are not digitally signed do not 470 require DER, but in this specification, DER is REQUIRED for all 471 structures. By always using DER, the TAMP processor will have fewer 472 options to implement. 474 ASN.1 is used throughout the text of the document for illustrative 475 purposes. The authoritative source of ASN.1 for the structures 476 defined in this document is Appendix A. 478 2. Cryptographic Message Syntax Profile 480 TAMP makes use of signed and unsigned messages. The Cryptographic 481 Message Syntax (CMS) is used in both cases. A digital signature is 482 used to protect the message from undetected modification and provide 483 data origin authentication. TAMP makes no general provision for 484 encryption of content. 486 CMS is used to construct a signed TAMP message. The CMS ContentInfo 487 content type MUST always be present, and it MUST encapsulate the CMS 488 SignedData content type. The CMS SignedData content type MUST 489 encapsulate the TAMP message. A unique content type identifier 490 identifies the particular type of TAMP message. The CMS 491 encapsulation of a signed TAMP message is summarized by: 493 ContentInfo { 494 contentType id-signedData, -- (1.2.840.113549.1.7.2) 495 content SignedData 496 } 498 SignedData { 499 version CMSVersion, -- Always set to 3 500 digestAlgorithms DigestAlgorithmIdentifiers, -- Only one 501 encapContentInfo EncapsulatedContentInfo, 502 certificates CertificateSet, -- OPTIONAL signer certificates 503 crls CertificateRevocationLists, -- OPTIONAL 504 signerInfos SET OF SignerInfo -- Only one 505 } 507 SignerInfo { 508 version CMSVersion, -- Always set to 3 509 sid SignerIdentifier, 510 digestAlgorithm DigestAlgorithmIdentifier, 511 signedAttrs SignedAttributes, 512 -- REQUIRED in TAMP messages 513 signatureAlgorithm SignatureAlgorithmIdentifier, 514 signature SignatureValue, 515 unsignedAttrs UnsignedAttributes -- OPTIONAL; may only be 516 } -- present in Apex Trust 517 -- Anchor Update messages 519 EncapsulatedContentInfo { 520 eContentType OBJECT IDENTIFIER, -- Names TAMP message type 521 eContent OCTET STRING -- Contains TAMP message 522 } 524 When a TAMP message is used to update the apex trust anchor, this 525 same structure is used; however, the digital signature will be 526 validated with either the apex trust anchor operational public key or 527 the contingency public key. When the contingency public key is used, 528 the symmetric key needed to decrypt the previously stored contingency 529 public key is provided as a contingency-public-key-decrypt-key 530 unsigned attribute. Section 4.5 of this document describes the Apex 531 Trust Anchor Update message. 533 CMS is also used to construct an unsigned TAMP message. The CMS 534 ContentInfo structure MUST always be present, and it MUST be the 535 outermost layer of encapsulation. A unique content type identifier 536 identifies the particular TAMP message. The CMS encapsulation of an 537 unsigned TAMP message is summarized by: 539 ContentInfo { 540 contentType OBJECT IDENTIFIER, -- Names TAMP message type 541 content OCTET STRING -- Contains TAMP message 542 } 544 2.1. Content Info 546 CMS requires the outer-most encapsulation to be ContentInfo 547 [RFC3852]. The fields of ContentInfo are used as follows: 549 o contentType indicates the type of the associated content, and for 550 TAMP, the encapsulated type is either SignedData or the content 551 type identifier associated with an unsigned TAMP message. When 552 the id-signedData (1.2.840.113549.1.7.2) object identifier is 553 present in this field, then a signed TAMP message is in the 554 content. Otherwise, an unsigned TAMP message is in the content. 556 o content holds the content, and for TAMP, the content is either a 557 SignedData content or an unsigned TAMP message. 559 2.2. SignedData Info 561 The SignedData content type [RFC3852] contains the signed TAMP 562 message and a digital signature value; the SignedData content type 563 MAY also contain the certificates needed to validate the digital 564 signature. The fields of SignedData are used as follows: 566 o version is the syntax version number, and for TAMP, the version 567 number MUST be set to 3. 569 o digestAlgorithms is a collection of one-way hash function 570 identifiers, and for TAMP, it contains a single one-way hash 571 function identifier. The one-way hash function employed by the 572 TAMP message originator in generating the digital signature MUST 573 be present. 575 o encapContentInfo is the signed content, consisting of a content 576 type identifier and the content itself. The use of the 577 EncapsulatedContentInfo type is discussed further in Section 578 2.2.2. 580 o certificates is an OPTIONAL collection of certificates. It MAY be 581 omitted, or it MAY include the X.509 certificates needed to 582 construct the certification path of the TAMP message originator. 583 For TAMP messages sent to a trust anchor store where an apex trust 584 anchor or management trust anchor is used directly to validate the 585 TAMP message digital signature, this field SHOULD be omitted. 586 When an apex trust anchor or management trust anchor is used to 587 validate an X.509 certification path [RFC5280], and the subject 588 public key from the final certificate in the certification path is 589 used to validate the TAMP message digital signature, the 590 certificate of the TAMP message originator SHOULD be included, and 591 additional certificates to support certification path construction 592 MAY be included. For TAMP messages sent by a trust anchor store, 593 this field SHOULD include only the signer's certificate or be 594 omitted. A TAMP message recipient MUST NOT reject a valid TAMP 595 message that contains certificates that are not needed to validate 596 the digital signature. PKCS#6 extended certificates [PKCS#6] and 597 attribute certificates (either version 1 or version 2) [RFC3281] 598 MUST NOT be included in the set of certificates; these certificate 599 formats are not used in TAMP. Certification Authority (CA) 600 certificates and end entity certificates MUST conform to the 601 profiles defined in [RFC5280]. 603 o crls is an OPTIONAL collection of certificate revocation lists 604 (CRLs). 606 o signerInfos is a collection of per-signer information, and for 607 TAMP, the collection MUST contain exactly one SignerInfo. The use 608 of the SignerInfo type is discussed further in Section 2.2.1. 610 2.2.1. SignerInfo 612 The TAMP message originator is represented in the SignerInfo type. 613 The fields of SignerInfo are used as follows: 615 o version is the syntax version number. With TAMP, the version MUST 616 be set to 3. 618 o sid identifies the TAMP message originator's public key. The 619 subjectKeyIdentifier alternative is always used with TAMP, which 620 identifies the public key directly. When the public key is 621 included in a TrustAnchorInfo object, this identifier is included 622 in the keyId field. When the public key is included in a 623 Certificate or TBSCertificate, this identifier is included in the 624 subjectKeyIdentifier certificate extension. 626 o digestAlgorithm identifies the one-way hash function, and any 627 associated parameters, used by the TAMP message originator. It 628 MUST contain the one-way hash functions employed by the 629 originator. This message digest algorithm identifier MUST match 630 the one carried in the digestAlgorithms field in SignedData. The 631 message digest algorithm identifier is carried in two places to 632 facilitate stream processing by the receiver. 634 o signedAttrs is an OPTIONAL set of attributes that are signed along 635 with the content. The signedAttrs are OPTIONAL in the CMS, but 636 signedAttrs is REQUIRED for all signed TAMP messages. The SET OF 637 Attribute MUST be encoded with the distinguished encoding rules 638 (DER) [X.690]. Section 2.2.3 of this document lists the signed 639 attributes that MUST be included in the collection. Other signed 640 attributes MAY be included, but any unrecognized signed attributes 641 MUST be ignored. 643 o signatureAlgorithm identifies the digital signature algorithm, and 644 any associated parameters, used by the TAMP message originator to 645 generate the digital signature. 647 o signature is the digital signature value generated by the TAMP 648 message originator. 650 o unsignedAttrs is an OPTIONAL set of attributes that are not 651 signed. For TAMP, this field is usually omitted. It is present 652 only in Apex Trust Anchor Update messages that are to be validated 653 using the apex trust anchor contingency public key. In this case, 654 the SET OF Attribute MUST include the symmetric key needed to 655 decrypt the contingency public key in the contingency-public-key- 656 decrypt-key unsigned attribute. Section 2.2.4 of this document 657 describes this unsigned attribute. 659 2.2.2. EncapsulatedContentInfo 661 The EncapsulatedContentInfo structure contains the TAMP message. The 662 fields of EncapsulatedContentInfo are used as follows: 664 o eContentType is an object identifier that uniquely specifies the 665 content type, and for TAMP, the value identifies the TAMP message. 666 The list of TAMP message content types is provided in Section 4. 668 o eContent is the TAMP message, encoded as an octet string. In 669 general, the CMS does not require the eContent to be DER-encoded 670 before constructing the octet string. However, TAMP messages MUST 671 be DER encoded. 673 2.2.3. Signed Attributes 675 The TAMP message originator MUST digitally sign a collection of 676 attributes along with the TAMP message. Each attribute in the 677 collection MUST be DER-encoded. The syntax for attributes is defined 678 in [I-D.ietf-pkix-new-asn1] 680 Each of the attributes used with this CMS profile has a single 681 attribute value. Even though the syntax is defined as a SET OF 682 AttributeValue, there MUST be exactly one instance of AttributeValue 683 present. 685 The SignedAttributes syntax within SignerInfo is defined as a SET OF 686 Attribute. The SignedAttributes MUST include only one instance of 687 any particular attribute. TAMP messages that violate this rule MUST 688 be rejected as malformed. 690 The TAMP message originator MUST include the content-type and 691 message-digest attributes. The TAMP message originator MAY also 692 include the binary-signing-time or content-hints signed attributes. 694 The TAMP message originator MAY include any other attribute that it 695 deems appropriate. The intent is to allow additional signed 696 attributes to be included if a future need is identified. This does 697 not cause an interoperability concern because unrecognized signed 698 attributes MUST be ignored. 700 The following summarizes the signed attribute requirements for TAMP 701 messages: 703 o content-type MUST be supported. 705 o message-digest MUST be supported. 707 o content-hints MAY be supported. Only present when more than one 708 layer of encapsulation is employed. 710 o binary-signing-time MAY be supported. Generally ignored by the 711 recipient. 713 o other attributes MAY be supported. Unrecognized attributes MUST 714 be ignored by the recipient. 716 2.2.3.1. Content-Type Attribute 718 The TAMP message originator MUST include a content-type attribute; it 719 is an object identifier that uniquely specifies the content type. 720 Section 11.1 of [RFC3852] defines the content-type attribute. For 721 TAMP, the value identifies the TAMP message. The list of TAMP 722 message content types and their identifiers is provided in Section 4. 724 A content-type attribute MUST contain the same object identifier as 725 the content type contained in the EncapsulatedContentInfo. 727 2.2.3.2. Message-Digest Attribute 729 The TAMP message originator MUST include a message-digest attribute, 730 having as its value the output of a one-way hash function computed on 731 the TAMP message that is being signed. Section 11.2 of [RFC3852] 732 defines the message-digest attribute. 734 2.2.3.3. Content-Hints Attribute 736 Many applications find it useful to have information that describes 737 the innermost content when multiple layers of encapsulation have been 738 applied. Since this version of TAMP only has one layer of 739 encapsulation, the encapContentInfo provides the content type of the 740 innermost content. To accommodate future versions of TAMP that might 741 include additional layers of encapsulation, the content-hints 742 attribute MUST be included in every instance of SignedData that does 743 not directly encapsulate a TAMP message. Section 2.9 of [RFC2634] 744 defines the content-hints attribute. 746 The content-hints attribute contains two fields: contentDescription 747 and contentType. The contentType field MUST be present, and the 748 contentDescription field MAY be present. The fields of the content- 749 hints attribute are used as follows: 751 o contentDescription is OPTIONAL. The TAMP message signer MAY 752 provide a brief description of the purpose of the TAMP message. 753 The text is intended for human consumption, not machine 754 processing. The text is encoded in UTF-8 [RFC3629], which 755 accommodates most of the world's writing systems. The 756 implementation MUST provide the capability to constrain the 757 character set. 759 o contentType is mandatory. This field indicates the content type 760 that will be discovered when CMS protection content types are 761 removed. 763 2.2.3.4. Binary-Signing-Time Attribute 765 The TAMP message originator MAY include a binary-signing-time 766 attribute, specifying the time at which the digital signature was 767 applied to the TAMP message. The binary-signing-time attribute is 768 defined in [RFC4049]. 770 No processing of the binary-signing-time attribute is REQUIRED of a 771 TAMP message recipient; however, the binary-signing-time attribute 772 MAY be included by the TAMP message originator as a form of message 773 identifier. 775 2.2.4. Unsigned Attributes 777 For TAMP, unsigned attributes are usually omitted. An unsigned 778 attribute is present only in Apex Trust Anchor Update messages that 779 are to be validated by the apex trust anchor contingency public key. 780 In this case, the symmetric key to decrypt the previous contingency 781 public key is provided in the contingency-public-key-decrypt-key 782 unsigned attribute. This attribute MUST be supported, and it is 783 described in Section 2.2.4.1. 785 The TAMP message originator SHOULD NOT include other unsigned 786 attributes, and any unrecognized unsigned attributes MUST be ignored. 788 The UnsignedAttributes syntax within SignerInfo is defined as a SET 789 OF Attribute. The UnsignedAttributes MUST include only one instance 790 of any particular attribute. TAMP messages that violate this rule 791 MUST be rejected as malformed. 793 2.2.4.1. Contingency Public Key Decrypt Key Attribute 795 The contingency-public-key-decrypt-key attribute provides the 796 plaintext symmetric key needed to decrypt the previously distributed 797 apex trust anchor contingency public key. The symmetric key MUST be 798 useable with the symmetric algorithm used to previously encrypt the 799 contingency public key. 801 The contingency-public-key-decrypt-key attribute has the following 802 syntax: 804 contingency-public-key-decrypt-key ATTRIBUTE ::= { 805 WITH SYNTAX PlaintextSymmetricKey 806 SINGLE VALUE TRUE 807 ID id-aa-TAMP-contingencyPublicKeyDecryptKey } 809 id-aa-TAMP-contingencyPublicKeyDecryptKey 810 OBJECT IDENTIFIER ::= { id-attributes 63 } 812 PlaintextSymmetricKey ::= OCTET STRING 814 3. Trust Anchor Formats 816 TAMP recognizes three formats for representing trust anchor 817 information within the protocol itself: Certificate [RFC5280], 818 TBSCertificate [RFC5280] and TrustAnchorInfo 819 [I-D.ietf-pkix-ta-format]. The TrustAnchorChoice structure, defined 820 in [I-D.ietf-pkix-ta-format], is used to select one of these options. 822 TrustAnchorChoice ::= CHOICE { 823 certificate Certificate, 824 tbsCert [1] EXPLICIT TBSCertificate, 825 taInfo [2] EXPLICIT TrustAnchorInfo } 827 The Certificate structure is commonly used to represent trust 828 anchors. Certificates include a signature, which removes the ability 829 for relying parties to customize the information within the structure 830 itself. TBSCertificate contains all of the information of the 831 Certificate structure except for the signature, enabling tailoring of 832 the information. TrustAnchorInfo is intended to serve as a 833 minimalist representation of trust anchor information for scenarios 834 where storage or bandwidth is highly constrained. 836 Implementations are not required to support all three options. The 837 unsupportedTrustAnchorFormat error code should be indicated when 838 generating a TAMPError due to receipt of an unsupported trust anchor 839 format. 841 4. Trust Anchor Management Protocol Messages 843 TAMP makes use of signed and unsigned messages. The CMS is used in 844 both cases. An object identifier is assigned to each TAMP message 845 type, and this object identifier is used as a content type in the 846 CMS. 848 TAMP specifies eleven message types. The following provides the 849 content type identifier for each TAMP message type, and it indicates 850 whether a digital signature is REQUIRED. If the following indicates 851 that the TAMP message MUST be signed, then implementations MUST 852 reject a message of that type that is not signed. 854 o The TAMP Status Query message MUST be signed. It uses the 855 following object identifier: { id-tamp 1 }. 857 o The TAMP Status Response message SHOULD be signed. It uses the 858 following object identifier: { id-tamp 2 }. 860 o The Trust Anchor Update message MUST be signed. It uses the 861 following object identifier: { id-tamp 3 }. 863 o The Trust Anchor Update Confirm message SHOULD be signed. It uses 864 the following object identifier: { id-tamp 4 }. 866 o The Apex Trust Anchor Update message MUST be signed. It uses the 867 following object identifier: { id-tamp 5 }. 869 o The Apex Trust Anchor Update Confirm message SHOULD be signed. It 870 uses the following object identifier: { id-tamp 6 }. 872 o The Community Update message MUST be signed. It uses the 873 following object identifier: { id-tamp 7 }. 875 o The Community Update Confirm message SHOULD be signed. It uses 876 the following object identifier: { id-tamp 8 }. 878 o The Sequence Number Adjust MUST be signed. It uses the following 879 object identifier: { id-tamp 10 }. 881 o The Sequence Number Adjust Confirm message SHOULD be signed. It 882 uses the following object identifier: { id-tamp 11 }. 884 o The TAMP Error message SHOULD be signed. It uses the following 885 object identifier: { id-tamp 9 }. 887 Support for TrustAnchorUpdate messages is REQUIRED. Support for all 888 other message formats is RECOMMENDED. 890 A typical interaction between a trust anchor manager and a trust 891 anchor store will follow the message flow shown in Figure 4-1. 892 Figure 4-1 does not illustrate a flow where an error occurs. 894 +---------+ +----------+ 895 | | Trust Anchor Status Query | | 896 | |------------------------------->| | 897 | | | | 898 | | Trust Anchor Status Response | | 899 | Trust |<-------------------------------| Trust | 900 | Anchor | | Anchor | 901 | Manager | Trust Anchor Update | Store | 902 | |------------------------------->| | 903 | | | | 904 | | Trust Anchor Update Confirm | | 905 | |<-------------------------------| | 906 | | | | 907 +---------+ +----------+ 909 Figure 4-1: Typical TAMP Message Flow 911 Each TAMP query and update message include an indication of the type 912 of response that is desired. The response can either be terse or 913 verbose. All trust anchor stores SHOULD support both the terse and 914 verbose responses and SHOULD generate a response of the type 915 indicated in the corresponding request. 917 Trust anchor stores SHOULD be able to process and properly act upon 918 the valid payload of the TAMP Status Query message, the Trust Anchor 919 Update message, the Apex Trust Anchor Update message, and the 920 Sequence Number Adjust message. TAMP implementations MAY also 921 process and act upon the valid payload of the Community Update 922 message. 924 TAMP implementations SHOULD support generation of the TAMP Status 925 Response message, the Trust Anchor Update Confirm message, the Apex 926 Trust Anchor Update Confirm message, the Sequence Number Adjust 927 Confirm message, and the TAMP Error message. If a TAMP 928 implementation supports the Community Update message, then generation 929 of Community Update Confirm messages SHOULD also be supported. 931 4.1. TAMP Status Query 933 The TAMP Status Query message is used to request information about 934 the trust anchors that are currently installed in a trust anchor 935 store, and for the list of communities to which the store belongs. 937 The TAMP Status Query message MUST be signed. For the query message 938 to be valid, the trust anchor store MUST be an intended recipient of 939 the query, the sequence number checking described in Section 6 MUST 940 be successful when the TAMP message signer is a trust anchor, and the 941 digital signature MUST be validated by the apex trust anchor 942 operational public key, an authorized management trust anchor, or via 943 an authorized X.509 certification path originating with such a trust 944 anchor. 946 If the digital signature on the TAMP Status Query message is valid, 947 sequence number checking is successful, the signer is authorized, and 948 the trust anchor store is an intended recipient of the TAMP message, 949 then a TAMP Status Response message SHOULD be returned. If a TAMP 950 Status Response message is not returned, then a TAMP Error message 951 SHOULD be returned. 953 The TAMP Status Query content type has the following syntax: 955 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 957 tamp-status-query PKCS7-CONTENT-TYPE ::= 958 { TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery } 960 id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 } 962 TAMPStatusQuery ::= SEQUENCE { 963 Version [0] TAMPVersion DEFAULT v2, 964 terse [1] TerseOrVerbose DEFAULT verbose, 965 query TAMPMsgRef } 967 TAMPVersion ::= INTEGER { v1(1), v2(2) } 969 TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) } 971 TAMPMsgRef ::= SEQUENCE { 972 target TargetIdentifier, 973 seqNum SeqNumber } 975 SeqNumber ::= INTEGER (0..9223372036854775807) 977 TargetIdentifier ::= CHOICE { 978 hwModules [1] HardwareModuleIdentifierList, 979 communities [2] CommunityIdentifierList, 980 allModules [3] NULL, 981 uri [4] IA5String, 982 otherName [5] AnotherName} 984 HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF 985 HardwareModules 987 HardwareModules ::= SEQUENCE { 988 hwType OBJECT IDENTIFIER, 989 hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry } 991 HardwareSerialEntry ::= CHOICE { 992 all NULL, 993 single OCTET STRING, 994 block SEQUENCE { 995 low OCTET STRING, 996 high OCTET STRING } } 998 CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community 1000 Community ::= OBJECT IDENTIFIER 1002 The fields of TAMPStatusQuery are used as follows: 1004 o version identifies version of TAMP. For this version of the 1005 specification, the default value, v2, MUST be used. 1007 o terse indicates the type of response that is desired. A terse 1008 response is indicated by a value of 1, and a verbose response is 1009 indicated by a value of 2, which is omitted during encoding since 1010 it is the default value. 1012 o query contains two items: the target and the seqNum. target 1013 identifies the target(s) of the query message. seqNum is a single 1014 use value that will be used to match the TAMP Status Query message 1015 with the TAMP Status Response message. The sequence number is 1016 also used to detect TAMP message replay. The sequence number 1017 processing described in Section 6 MUST successfully complete 1018 before a response is returned. 1020 The fields of TAMPMsgRef are used as follows: 1022 o target identifies the target(s) of the query. Several 1023 alternatives for naming a target are provided. To identify a 1024 cryptographic module, a combination of a cryptographic type and 1025 serial number are used. The cryptographic type is represented as 1026 an ASN.1 object identifier, and the unique serial number is 1027 represented as a string of octets. To facilitate compact 1028 representation of serial numbers, a contiguous block can be 1029 specified by the lowest included serial number and the highest 1030 included serial number. When present, the high and low octet 1031 strings MUST have the same length. The 1032 HardwareModuleIdentifierList sequence MUST NOT contain duplicate 1033 hwType values, so that each member of the sequence names all of 1034 the cryptographic modules of this type. Object identifiers are 1035 also used to identify communities of trust anchor stores. A 1036 sequence of these object identifiers is used if more than one 1037 community is the target of the message. A trust anchor store is 1038 considered a target if it is a member of any of the listed 1039 communities. An explicit NULL value is used to identify all 1040 modules that consider the signer of the TAMP message to be an 1041 authorized source for that message type. The uri field can be 1042 used to identify a target, i.e., a trust anchor store, using a 1043 Uniform Resource Identifier. Additional name types are supported 1044 via the otherName field, which is of type AnotherName. 1045 AnotherName is defined in [RFC5280]. The format and semantics of 1046 the name are indicated through the OBJECT IDENTIFIER in the 1047 type-id field. The name itself is conveyed as value field in 1048 otherName. 1050 o seqNum contains a single use value that will be used to match the 1051 TAMP Status Query message with the successful TAMP Status Response 1052 message. The sequence number processing described in Section 6 1053 MUST successfully complete before a response is returned. 1055 To determine whether a particular cryptographic module serial number 1056 is considered part of a specified block, all of the following 1057 conditions MUST be met. First, the cryptographic module serial 1058 number MUST be the same length as both the high and low octet 1059 strings. Second, the cryptographic module serial number MUST be 1060 greater than or equal to the low octet string. Third, the 1061 cryptographic module serial number MUST be less than or equal to the 1062 high octet string. 1064 One octet string is equal to another if they are of the same length 1065 and are the same at each octet position. An octet string, S1, is 1066 greater than another, S2, where S1 and S2 have the same length, if 1067 and only if S1 and S2 have different octets in one or more positions, 1068 and in the first such position, the octet in S1 is greater than that 1069 in S2, considering the octets as unsigned binary numbers. Note that 1070 these octet string comparison definitions are consistent with those 1071 in clause 6 of [X.690]. 1073 4.2. TAMP Status Query Response 1075 The TAMP Status Response message is a reply by a trust anchor store 1076 to a valid TAMP Status Query message. The TAMP Status Response 1077 message provides information about the trust anchors that are 1078 currently installed in the trust anchor store and the list of 1079 communities to which the trust anchor store belongs, if any. The 1080 TAMP Status Response message MAY be signed or unsigned. A TAMP 1081 Status Response message MUST be signed if the implementation is 1082 capable of signing it. 1084 The TAMP Status Response content type has the following syntax: 1086 tamp-status-response PKCS7-CONTENT-TYPE ::= 1087 { TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse } 1089 id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 } 1091 TAMPStatusResponse ::= SEQUENCE { 1092 version [0] TAMPVersion DEFAULT v2, 1093 query TAMPMsgRef, 1094 response StatusResponse, 1095 usesApex BOOLEAN DEFAULT TRUE} 1097 StatusResponse ::= CHOICE { 1098 terseResponse [0] TerseStatusResponse, 1099 verboseResponse [1] VerboseStatusResponse } 1101 TerseStatusResponse ::= SEQUENCE { 1102 taKeyIds KeyIdentifiers, 1103 communities CommunityIdentifierList OPTIONAL } 1105 KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier 1107 VerboseStatusResponse ::= SEQUENCE { 1108 taInfo TrustAnchorChoiceList, 1109 continPubKeyDecryptAlg [0] AlgorithmIdentifier OPTIONAL, 1110 communities [1] CommunityIdentifierList OPTIONAL, 1111 tampSeqNumbers [2] TAMPSequenceNumbers OPTIONAL } 1113 TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF 1114 TrustAnchorChoice 1115 } 1117 TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF TAMPSequenceNumber 1119 TAMPSequenceNumber ::= SEQUENCE { 1120 keyId KeyIdentifier, 1121 seqNumber SeqNumber } 1123 The fields of TAMPStatusResponse are used as follows: 1125 o version identifies version of TAMP. For this version of the 1126 specification, the default value, v2, MUST be used. 1128 o query identifies the TAMPStatusQuery to which the trust anchor 1129 store is responding. The query structure repeats the TAMPMsgRef 1130 from the TAMP Status Query message (see Section 4.1). The 1131 sequence number processing described in Section 6 MUST 1132 successfully complete before any response is returned. 1134 o response contains either a terse response or a verbose response. 1135 The terse response is represented by TerseStatusResponse, and the 1136 verbose response is represented by VerboseStatusResponse. 1138 o usesApex is a boolean value that indicates whether the first item 1139 in the TerseStatusResponse.taKeyIds or 1140 VerboseStatusResponse.taInfo field identifies the apex TA. 1142 The fields of TerseStatusResponse are used as follows: 1144 o taKeyIds contains a sequence of key identifiers. Each trust 1145 anchor contained in the trust anchor store is represented by one 1146 key identifier. When TAMPStatusResponse.usesApex is TRUE, the 1147 apex trust anchor is represented by the first key identifier in 1148 the sequence, which contains the key identifier of the operational 1149 public key. 1151 o communities is OPTIONAL. When present, it contains a sequence of 1152 object identifiers. Each object identifier names one community to 1153 which this trust anchor store belongs. When the trust anchor 1154 store belongs to no communities, this field is omitted. 1156 The fields of VerboseStatusResponse are used as follows: 1158 o taInfo contains a sequence of TrustAnchorChoice structures. One 1159 entry in the sequence is provided for each trust anchor contained 1160 in the trust anchor store. When TAMPStatusResponse.usesApex is 1161 TRUE, the apex trust anchor is the first trust anchor in the 1162 sequence. 1164 o continPubKeyDecryptAlg is OPTIONAL. When present, it indicates 1165 the decryption algorithm needed to decrypt the currently installed 1166 apex trust anchor contingency public key, if a contingency key is 1167 associated with the apex trust anchor. When present, 1168 TAMPStatusResponse.usesApex MUST be TRUE. 1170 o communities is OPTIONAL. When present, it contains a sequence of 1171 object identifiers. Each object identifier names one community to 1172 which this trust anchor store belongs. When the trust anchor 1173 store belongs to no communities, this field is omitted. 1175 o tampSeqNumbers is OPTIONAL. When present, it is used to indicate 1176 the currently held sequence number for each trust anchor 1177 authorized to sign TAMP messages. The keyId field identifies the 1178 trust anchor and the seqNumber field provides the current sequence 1179 number associated with the trust anchor. 1181 4.3. Trust Anchor Update 1183 The Trust Anchor Update message is used to add, remove, and change 1184 management and identity trust anchors. The Trust Anchor Update 1185 message cannot be used to update the apex trust anchor. The Trust 1186 Anchor Update message MUST be signed. For a Trust Anchor Update 1187 message to be valid, the trust anchor store MUST be an intended 1188 recipient of the update, the sequence number checking described in 1189 Section 6 MUST be successful when the TAMP message signer is a trust 1190 anchor, and the digital signature MUST be validated using the apex 1191 trust anchor operational public key, an authorized management trust 1192 anchor, or via an authorized X.509 certification path originating 1193 with such a trust anchor. 1195 If the digital signature on the Trust Anchor Update message is valid, 1196 sequence number checking is successful, the signer is authorized, and 1197 the trust anchor store is an intended recipient of the TAMP message, 1198 then the trust anchor store MUST perform the specified updates and 1199 return a Trust Anchor Update Confirm message. If a Trust Anchor 1200 Update Confirm message is not returned, then a TAMP Error message 1201 SHOULD be returned. 1203 The Trust Anchor Update content type has the following syntax: 1205 tamp-update PKCS7-CONTENT-TYPE ::= 1206 { TAMPUpdate IDENTIFIED BY id-ct-TAMP-update } 1208 id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 } 1210 TAMPUpdate ::= SEQUENCE { 1211 version [0] TAMPVersion DEFAULT v2, 1212 terse [1] TerseOrVerbose DEFAULT verbose, 1213 msgRef TAMPMsgRef, 1214 updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate, 1215 tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL } 1217 TrustAnchorUpdate ::= CHOICE { 1218 add [1] TrustAnchorChoice, 1219 remove [2] SubjectPublicKeyInfo, 1220 change [3] EXPLICIT TrustAnchorChangeInfoChoice } 1222 TrustAnchorChangeInfoChoice ::= CHOICE { 1223 tbsCertChange [0] TBSCertificateChangeInfo, 1224 taChange [1] TrustAnchorChangeInfo } 1226 TBSCertificateChangeInfo ::= SEQUENCE { 1227 serialNumber CertificateSerialNumber OPTIONAL, 1228 signature [0] AlgorithmIdentifier OPTIONAL, 1229 issuer [1] Name OPTIONAL, 1230 validity [2] Validity OPTIONAL, 1231 subject [3] Name OPTIONAL, 1232 subjectPublicKeyInfo [4] SubjectPublicKeyInfo, 1233 exts [5] EXPLICIT Extensions OPTIONAL } 1235 TrustAnchorChangeInfo ::= SEQUENCE { 1236 pubKey SubjectPublicKeyInfo, 1237 keyId KeyIdentifier OPTIONAL, 1238 taTitle TrustAnchorTitle OPTIONAL, 1239 certPath CertPathControls OPTIONAL, 1240 exts [1] Extensions OPTIONAL} 1242 The fields of TAMPUpdate are used as follows: 1244 o version identifies version of TAMP. For this version of the 1245 specification, the default value, v2, MUST be used. 1247 o terse indicates the type of response that is desired. A terse 1248 response is indicated by a value of 1, and a verbose response is 1249 indicated by a value of 2, which is omitted during encoding since 1250 it is the default value. 1252 o msgRef contains two items: the target and the seqNum. target 1253 identifies the target(s) of the update message. The 1254 TargetIdentifier syntax is described in Section 4.1. seqNum is a 1255 single use value that will be used to match the Trust Anchor 1256 Update message with the Trust Anchor Update Confirm message. The 1257 sequence number is also used to detect TAMP message replay. The 1258 sequence number processing described in Section 6 MUST 1259 successfully complete before any of the updates are processed. 1261 o updates contains a sequence of updates, which are used to add, 1262 remove, and change management or identity trust anchors. Each 1263 entry in the sequence represents one of these actions, and is 1264 indicated by an instance of TrustAnchorUpdate. The actions are a 1265 batch of updates that MUST be processed in the order that they 1266 appear, but each of the updates is processed independently. Each 1267 of the updates MUST satisfy the subordination checks described in 1268 Section 7. Even if one or more of the updates fail, then the 1269 remaining updates MUST be processed. These updates MUST NOT make 1270 any changes to the apex trust anchor. 1272 o tampSeqNumbers MAY be included to provide the initial or new 1273 sequence numbers for trust anchors added or changed by the updates 1274 field. Elements included in the tampSeqNumbers field that do not 1275 correspond to an element in the updates field are ignored. 1276 Elements included in the tampSeqNumbers field that do correspond 1277 to an element in the updates field and contain a sequence number 1278 less than or equal to the most recently stored sequence number for 1279 the trust anchor are ignored. Elements included in the 1280 tampSeqNumbers field that do correspond to an element in the 1281 updates field and contain a sequence number greater than the most 1282 recently stored sequence number for the indicated trust anchor are 1283 processed by setting the stored sequence number for the trust 1284 anchor equal to the new value. 1286 The TrustAnchorUpdate is a choice of three structures, and each 1287 alternative represents one of the three possible actions: add, 1288 remove, and change. A description of the syntax associated with each 1289 of these actions follows: 1291 o add is used to insert a new management or identity trust anchor 1292 into the trust anchor store. The TrustAnchorChoice structure is 1293 used to provide the trusted public key and all of the information 1294 associated with it. However, the action MUST fail if the 1295 subordination checks described in Section 7 are not satisfied. 1296 See Section 3 for a discussion of the TrustAnchorChoice structure. 1297 The apex trust anchor cannot be introduced into a trust anchor 1298 store using this action; therefore the id-pe-wrappedApexContinKey 1299 MUST NOT not be present in the extensions field. The constraints 1300 of the existing trust anchors are unchanged by this action. An 1301 attempt to add a management or identity trust anchor that is 1302 already in place with the same values for every field in the 1303 TrustAnchorChoice structure MUST be treated as a successful 1304 addition. An attempt to add a management or identity trust anchor 1305 that is already present with the same pubKey values, but with 1306 different values for any of the fields in the TrustAnchorChoice 1307 structure, MUST result in an error. This means a trust anchor may 1308 not be added twice using different TrustAnchorChoice options. If 1309 a different format is desired, the existing trust anchor must be 1310 removed and the new format added. 1312 o remove is used to delete an existing management or identity trust 1313 anchor from the trust anchor store, including the deletion of the 1314 management trust anchor associated with the TAMP message signer. 1315 However, the action MUST fail if the subordination checks 1316 described in Section 7 are not satisfied. The public key 1317 contained in SubjectPublicKeyInfo names the management or identity 1318 trust anchor to be deleted. An attempt to delete a trust anchor 1319 that is not present MUST be treated as a successful deletion. The 1320 constraints of the deleted trust anchor are not distributed to 1321 other trust anchors in any manner. The apex trust anchor cannot 1322 be removed using this action, which ensures that this action 1323 cannot place the trust anchor store in an unrecoverable 1324 configuration. 1326 o change is used to update the information associated with an 1327 existing management or identity trust anchor in the trust anchor 1328 store. Attempts to change a trust anchor added as a Certificate 1329 MUST fail. The public key contained in the SubjectPublicKeyInfo 1330 field of TrustAnchorChangeInfo or in the subjectPublicKeyInfo 1331 field of a TBSCertificateChangeInfo names the to-be-updated trust 1332 anchor. However, the action MUST fail if the subordination checks 1333 described in Section 7 are not satisfied. An attempt to change a 1334 trust anchor that is not present MUST result in a failure with the 1335 trustAnchorNotFound status code. The TrustAnchorChangeInfo 1336 structure or the TBSCertificateChangeInfo structure is used to 1337 provide the revised configuration of the management or identity 1338 trust anchor. If the update fails for any reason, then the 1339 original trust anchor configuration MUST be preserved. The apex 1340 trust anchor information cannot be changed using this action. 1341 Attempts to change a trust anchor added as a TBSCertificate using 1342 a TrustAnchorChangeInfo MUST fail. Attempts to change a trust 1343 anchor added as a TrustAnchorInfo using a TBSCertificateChangeInfo 1344 MUST fail. 1346 The fields of TrustAnchorChangeInfo are used as follows: 1348 o pubKey contains the algorithm identifier and the public key of the 1349 management or identity trust anchor. It is used to locate the to- 1350 be-updated trust anchor in the trust anchor store. 1352 o keyId is OPTIONAL, and when present, it contains the public key 1353 identifier of the trust anchor public key. If this field is not 1354 present, then the public key identifier remains unchanged. If 1355 this field is present, the provided public key identifier replaces 1356 the previous one. 1358 o taTitle is OPTIONAL, and when present, it provides a human 1359 readable name for the management or identity trust anchor. When 1360 absent in a change trust anchor update, any title that was 1361 previously associated with the trust anchor is removed. 1362 Similarly, when present in a change trust anchor update, the title 1363 in the message is associated with the trust anchor. If a previous 1364 title was associated with the trust anchor, then the title is 1365 replaced. If a title was not previously associated with the trust 1366 anchor, then the title from the update message is added. 1368 o certPath is OPTIONAL, and when present, it provides the controls 1369 needed to construct and validate an X.509 certification path. 1370 When absent in a change trust anchor update, any controls that 1371 were previously associated with the management or identity trust 1372 anchor are removed, which means that delegation is no longer 1373 permitted. Similarly, when present in a change trust anchor 1374 update, the controls in the message are associated with the 1375 management or identity trust anchor. If previous controls, 1376 including the trust anchor distinguished name, were associated 1377 with the trust anchor, then the controls are replaced, which means 1378 that delegation continues to be supported, but that different 1379 certification paths will be valid. If controls were not 1380 previously associated with the management or identity trust 1381 anchor, then the controls from the update message are added, which 1382 enables delegation. The syntax and semantics of CertPathControls 1383 is discussed in [I-D.ietf-pkix-ta-format]. 1385 o exts is OPTIONAL, and when present, it provides the extensions 1386 values that are associated with the trust anchor. When absent in 1387 a change trust anchor update, any extensions that were previously 1388 associated with the trust anchor are removed. Similarly, when 1389 present in a change trust anchor update, the extensions in the 1390 message are associated with the trust anchor. Any extensions 1391 previously associated with the trust anchor are replaced or 1392 removed. 1394 The fields of TBSCertificateChangeInfo are used to alter the fields 1395 within a TBSCertificate structure. TBSCertificate is described in 1396 [RFC5280]. For all fields except exts, if the field is absent in a 1397 change trust anchor update, then any previous value associated with a 1398 trust anchor is unchanged. For the exts field, if the field is 1399 absent in a change trust anchor update, then any previous value 1400 associated with a trust anchor is removed. For all fields, if the 1401 field is present in a change trust anchor update, then any previous 1402 value associated with a trust anchor is replaced with the value from 1403 the update message. 1405 4.3.1. Trust Anchor List 1407 [I-D.ietf-pkix-ta-format] defines the TrustAnchorList structure to 1408 convey a list of trust anchors. TAMP implementations MAY process 1409 TrustAnchorList objects as TAMPUpdate objects with terse set to 1410 terse, msgRef set to allModules (with a suitable sequence number) and 1411 all elements within the list contained within the add field. 1413 4.4. Trust Anchor Update Confirm 1415 The Trust Anchor Update Confirm message is a reply by a trust anchor 1416 store to a valid Trust Anchor Update message. The Trust Anchor 1417 Update Confirm message provides success and failure information for 1418 each of the requested updates. The Trust Anchor Update Confirm 1419 message MAY be signed or unsigned. A Trust Anchor Update Confirm 1420 message MUST be signed if the implementation is capable of signing 1421 it. 1423 The Trust Anchor Update Confirm content type has the following 1424 syntax: 1426 tamp-update-confirm PKCS7-CONTENT-TYPE ::= 1427 { TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm } 1429 id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 } 1431 TAMPUpdateConfirm ::= SEQUENCE { 1432 version [0] TAMPVersion DEFAULT v2, 1433 update TAMPMsgRef, 1434 confirm UpdateConfirm } 1436 UpdateConfirm ::= CHOICE 1437 terseConfirm [0] TerseUpdateConfirm, 1438 verboseConfirm [1] VerboseUpdateConfirm } 1440 TerseUpdateConfirm ::= StatusCodeList 1442 StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode 1444 VerboseUpdateConfirm ::= SEQUENCE { 1445 status StatusCodeList, 1446 taInfo TrustAnchorChoiceList, 1447 tampSeqNumbers TAMPSequenceNumbers OPTIONAL, 1448 usesApex BOOLEAN DEFAULT TRUE} 1450 The fields of TAMPUpdateConfirm are used as follows: 1452 o version identifies version of TAMP. For this version of the 1453 specification, the default value, v2, MUST be used. 1455 o update identifies the TAMPUpdate message to which the trust anchor 1456 store is responding. The update structure repeats the TAMPMsgRef 1457 from the Trust Anchor Update message (see Section 4.3). The 1458 sequence number processing described in Section 6 MUST 1459 successfully complete before any of the updates are processed. 1461 o confirm contains either a terse update confirmation or a verbose 1462 update confirmation. The terse update confirmation is represented 1463 by TerseUpdateConfirm, and the verbose response is represented by 1464 VerboseUpdateConfirm. 1466 The TerseUpdateConfirm contains a sequence of status codes, one for 1467 each TrustAnchorUpdate structure in the Trust Anchor Update message. 1468 The status codes appear in the same order as the TrustAnchorUpdate 1469 structures to which they apply, and the number of elements in the 1470 status code list MUST be the same as the number of elements in the 1471 trust anchor update list. Each of the status codes is discussed in 1472 Section 5. 1474 The fields of VerboseUpdateConfirm are used as follows: 1476 o status contains a sequence of status codes, one for each 1477 TrustAnchorUpdate structure in the Trust Anchor Update message. 1478 The status codes appear in the same order as the TrustAnchorUpdate 1479 structures to which they apply, and the number of elements in the 1480 status code list MUST be the same as the number of elements in the 1481 trust anchor update list. Each of the status codes is discussed 1482 in Section 5. 1484 o taInfo contains a sequence of TrustAnchorChoice structures. One 1485 entry in the sequence is provided for each trust anchor contained 1486 in the trust anchor store. These represent the state of the trust 1487 anchors after the updates have been processed. When usesApex is 1488 true, the apex trust anchor is the first trust anchor in the 1489 sequence. 1491 o tampSeqNumbers is used to indicate the currently held sequence 1492 number for each trust anchor authorized to sign TAMP messages. 1493 The keyId field identifies the trust anchor and the seqNumber 1494 field provides the current sequence number associated with the 1495 trust anchor. 1497 o usesApex is a boolean value that indicates whether the first item 1498 in the taInfo field identifies the apex TA. 1500 4.5. Apex Trust Anchor Update 1502 The Apex Trust Anchor Update message replaces the operational public 1503 key and, optionally, the contingency public key associated with the 1504 apex trust anchor. Each trust anchor store has exactly one apex 1505 trust anchor. No constraints are associated with the apex trust 1506 anchor. The public key identifier of the operational public key is 1507 used to identify the apex trust anchor in subsequent TAMP messages. 1508 The digital signature on the Apex Trust Anchor Update message is 1509 validated with either the current operational public key or the 1510 current contingency public key. For the Apex Trust Anchor Update 1511 message that is validated with the operational public key to be 1512 valid, the trust anchor store MUST be a target of the update, the 1513 sequence number MUST be larger than the most recently stored sequence 1514 number for the operational public key, and the digital signature MUST 1515 be validated directly with the operational public key. That is, no 1516 delegation via a certification path is permitted. For the Apex Trust 1517 Anchor Update message that is validated with the contingency public 1518 key to be valid, the trust anchor store MUST be a target of the 1519 update, the provided decryption key MUST properly decrypt the 1520 contingency public key, and the digital signature MUST be validated 1521 directly with the decrypted contingency public key. Again, no 1522 delegation via a certification path is permitted. 1524 If the Apex Trust Anchor Update message is validated using the 1525 operational public key, then sequence number processing is handled 1526 normally, as described in Section 6. If the Apex Trust Anchor Update 1527 message is validated using the contingency public key, then the 1528 TAMPMsgRef sequence number MUST contain a zero value. A sequence 1529 number for subsequent messages that will be validated with the new 1530 operational public key can optionally be provided. If no value is 1531 provided, then the trust anchor store MUST be prepared to accept any 1532 sequence number in the next TAMP message validated with the newly- 1533 installed apex trust anchor operational public key. If the Apex 1534 Trust Anchor Update message is valid and the clearTrustAnchors flag 1535 is set to TRUE, then all of the management and identity trust anchors 1536 stored in the trust anchor store MUST be deleted. That is, the new 1537 apex trust anchor MUST be the only trust anchor remaining in the 1538 trust anchor store. If the Apex Trust Anchor Update message is valid 1539 and the clearCommunities flag is set to TRUE, then all community 1540 identifiers stored in the trust anchor store MUST be deleted. 1542 The SignedData structure includes a sid value, and it identifies the 1543 apex trust anchor public key that will be used to validate the 1544 digital signature on this TAMP message. The public key identifier 1545 for the operational public key is known in advance, and it is stored 1546 as part of the apex trust anchor. The public key identifier for the 1547 contingency public key is not known in advance; however, the presence 1548 of the unsigned attribute containing the symmetric key needed to 1549 decrypt the contingency public key unambiguously indicates that the 1550 TAMP message signer used the contingency private key to sign the Apex 1551 Trust Anchor Update message. 1553 If the digital signature on the Apex Trust Anchor Update message is 1554 valid using either the apex trust anchor operational public key or 1555 the apex trust anchor contingency public key, sequence number 1556 checking is successful, and the trust anchor store is an intended 1557 recipient of the TAMP message, then the trust anchor store MUST 1558 update the apex trust anchor and return an Apex Trust Anchor Update 1559 Confirm message. If an Apex Trust Anchor Update Confirm message is 1560 not returned, then a TAMP Error message SHOULD be returned. Note 1561 that the sequence number MUST be zero if the Apex Trust Anchor Update 1562 message is validated with the apex trust anchor contingency public 1563 key. 1565 The Apex Trust Anchor Update content type has the following syntax: 1567 tamp-apex-update PKCS7-CONTENT-TYPE ::= 1568 { TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate } 1570 id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 } 1572 TAMPApexUpdate ::= SEQUENCE { 1573 version [0] TAMPVersion DEFAULT v2, 1574 terse [1] TerseOrVerbose DEFAULT verbose, 1575 msgRef TAMPMsgRef, 1576 clearTrustAnchors BOOLEAN, 1577 clearCommunities BOOLEAN, 1578 seqNumber SeqNumber OPTIONAL, 1579 apexTA TrustAnchorChoice } 1581 The fields of TAMPApexUpdate are used as follows: 1583 o version identifies version of TAMP. For this version of the 1584 specification, the default value, v2, MUST be used. 1586 o terse indicates the type of response that is desired. A terse 1587 response is indicated by a value of 1, and a verbose response is 1588 indicated by a value of 2, which is omitted during encoding since 1589 it is the default value. 1591 o msgRef contains two items: the target and the seqNum. target 1592 identifies the target(s) of the Apex Trust Anchor Update message. 1593 The TargetIdentifier syntax as described in Section 4.1 is used. 1594 seqNum is a single use value that will be used to match the Apex 1595 Trust Anchor Update message with the Apex Trust Anchor Update 1596 Confirm message. The sequence number is also used to detect TAMP 1597 message replay if the message is validated with the apex trust 1598 anchor operational public key. The sequence number processing 1599 described in Section 6 MUST successfully complete before any 1600 action is taken. However, seqNum MUST contain a zero value if the 1601 message is validated with the apex trust anchor contingency public 1602 key. 1604 o clearTrustAnchors is a Boolean. If the value is set to TRUE, then 1605 all of the management and identity trust anchors stored in the 1606 trust anchor store MUST be deleted, leaving the newly installed 1607 apex trust anchor as the only trust anchor in the trust anchor 1608 store. If the value is set to FALSE, the other trust anchors MUST 1609 NOT be changed. 1611 o clearCommunities is a Boolean. If the value is set to TRUE, then 1612 all of the community identifiers stored in the trust anchor store 1613 MUST be deleted, leaving none. If the value is set to FALSE, the 1614 list of community identifiers MUST NOT be changed. 1616 o seqNumber is OPTIONAL, and when present, it provides the initial 1617 sequence number for the apex trust anchor, if present. If 1618 seqNumber is absent, the trust anchor store is prepared to accept 1619 any sequence number value for the apex trust anchor operational 1620 public key. 1622 o apexTA provides the information for the replacement apex trust 1623 anchor. The TrustAnchorChoice structure is used to provide the 1624 trusted public key and all of the information associated with it. 1625 The pubKey, keyId, taTitle, certPath and exts fields apply to the 1626 operational public key of the apex trust anchor. The 1627 ApexTrustAnchorInfo certificate extension MAY appear as an 1628 extension. Section 9 describes the ApexTrustAnchorInfo 1629 certificate extension. 1631 4.6. Apex Trust Anchor Update Confirm 1633 The Apex Trust Anchor Update Confirm message is a reply by a trust 1634 anchor store to a valid Apex Trust Anchor Update message. The Apex 1635 Trust Anchor Update Confirm message provides success or failure 1636 information for the apex trust anchor update. The Apex Trust Anchor 1637 Update Confirm message MAY be signed or unsigned. An Apex Trust 1638 Anchor Update Confirm message MUST be signed if the trust anchor 1639 store is capable of signing it. 1641 The Apex Trust Anchor Update Confirm content type has the following 1642 syntax: 1644 tamp-apex-update-confirm PKCS7-CONTENT-TYPE ::= 1645 { TAMPApexUpdateConfirm IDENTIFIED BY 1646 id-ct-TAMP-apexUpdateConfirm } 1648 id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 } 1650 TAMPApexUpdateConfirm ::= SEQUENCE { 1651 version [0] TAMPVersion DEFAULT v2, 1652 apexReplace TAMPMsgRef, 1653 apexConfirm ApexUpdateConfirm } 1655 ApexUpdateConfirm ::= CHOICE { 1656 terseApexConfirm [0] TerseApexUpdateConfirm, 1657 verboseApexConfirm [1] VerboseApexUpdateConfirm } 1659 TerseApexUpdateConfirm ::= StatusCode 1661 VerboseApexUpdateConfirm ::= SEQUENCE { 1662 status StatusCode, 1663 taInfo TrustAnchorChoiceList, 1664 communities [0] CommunityIdentifierList OPTIONAL, 1665 tampSeqNumbers [1] TAMPSequenceNumbers OPTIONAL } 1667 The fields of TAMPApexUpdateConfirm are used as follows: 1669 o version identifies version of TAMP. For this version of the 1670 specification, the default value, v2, MUST be used. 1672 o apexReplace identifies the Apex Trust Anchor Update message to 1673 which the trust anchor store is responding. The apexReplace 1674 structure repeats the TAMPMsgRef from the beginning of the Apex 1675 Trust Anchor Update message (see Section 4.5). When the Apex 1676 Trust Anchor Update message is validated with the operational 1677 public key, the sequence number processing described in Section 6 1678 MUST successfully complete before an Apex Trust Anchor Update 1679 Confirm message is generated. When the Apex Trust Anchor Update 1680 message is validated with the contingency public key, normal 1681 sequence number processing is ignored, but the seqNum MUST be 1682 zero. 1684 o apexConfirm contains either a terse update confirmation or a 1685 verbose update confirmation. The terse update confirmation is 1686 represented by TerseApexUpdateConfirm, and the verbose response is 1687 represented by VerboseApexUpdateConfirm. 1689 The TerseApexUpdateConfirm contains a single status code, indicating 1690 the success or failure of the apex trust anchor update. If the apex 1691 trust anchor update failed, then the status code provides the reason 1692 for the failure. Each of the status codes is discussed in Section 5. 1694 The fields of VerboseApexUpdateConfirm are used as follows: 1696 o status contains a single status code, indicating the success or 1697 failure of the apex trust anchor update. If the apex trust anchor 1698 update failed, then the status code provides the reason for the 1699 failure. Each of the status codes is discussed in Section 5. 1701 o taInfo contains a sequence of TrustAnchorChoice structures. One 1702 entry in the sequence is provided for each trust anchor contained 1703 in the trust anchor store. These represent the state of the trust 1704 anchors after the apex trust anchor update has been processed. 1705 See [I-D.ietf-pkix-ta-format] for a description of the 1706 TrustAnchorInfo structure. The apex trust anchor is the first 1707 trust anchor in the sequence. 1709 o communities is OPTIONAL. When present, it contains a sequence of 1710 object identifiers. Each object identifier names one community to 1711 which this trust anchor store belongs. When the trust anchor 1712 store belongs to no communities, this field is omitted. 1714 o tampSeqNumbers is used to indicate the currently held sequence 1715 number for each trust anchor authorized to sign TAMP messages. 1716 The keyId field identifies the trust anchor and the seqNumber 1717 field provides the current sequence number associated with the 1718 trust anchor. 1720 4.7. Community Update 1722 The trust anchor store maintains a list of identifiers for the 1723 communities of which it is a member. The Community Update message 1724 can be used to remove or add community identifiers from this list. 1725 The Community Update message MUST be signed. For the Community 1726 Update message to be valid, the trust anchor store MUST be a target 1727 of the update, the sequence number checking described in Section 6 1728 MUST be successful when the TAMP message signer is a trust anchor, 1729 and the digital signature MUST be validated by the apex trust anchor 1730 operational public key, an authorized management trust anchor, or via 1731 an authorized X.509 certification path originating with such a trust 1732 anchor. 1734 If the trust anchor store supports the Community Update message, the 1735 digital signature on the Community Update message is valid, sequence 1736 number checking is successful, the signer is authorized, and the 1737 trust anchor store is an intended recipient of the TAMP message, then 1738 the trust anchor store MUST make the specified updates and return a 1739 Community Update Confirm message. If a Community Update Confirm 1740 message is not returned, then, a TAMP Error message SHOULD be 1741 returned. 1743 The Community Update message contains a batch of updates, and all of 1744 the updates MUST be accepted for the trust anchor store to return a 1745 successful Community Update Confirm message. The remove updates, if 1746 present, MUST be processed before the add updates. Where remove is 1747 present with an empty list, all community identifiers MUST be 1748 removed. This approach prevents community identifiers that are 1749 intended to be mutually exclusive from being installed by a 1750 successful addition and a failed removal. Where add is present, at 1751 least one community identifier MUST appear in the list. 1753 The Community Update content type has the following syntax: 1755 tamp-community-update PKCS7-CONTENT-TYPE ::= 1756 { TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate } 1758 id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 } 1760 TAMPCommunityUpdate ::= SEQUENCE { 1761 version [0] TAMPVersion DEFAULT v2, 1762 terse [1] TerseOrVerbose DEFAULT verbose, 1763 msgRef TAMPMsgRef, 1764 updates CommunityUpdates } 1766 CommunityUpdates ::= SEQUENCE { 1767 remove [1] CommunityIdentifierList OPTIONAL, 1768 add [2] CommunityIdentifierList OPTIONAL } 1769 -- At least one MUST be present 1771 The fields of TAMPCommunityUpdate are used as follows: 1773 o version identifies version of TAMP. For this version of the 1774 specification, the default value, v2, MUST be used. 1776 o terse indicates the type of response that is desired. A terse 1777 response is indicated by a value of 1, and a verbose response is 1778 indicated by a value of 2, which is omitted during encoding since 1779 it is the default value. 1781 o msgRef contains two items: the target and the seqNum. target 1782 identifies the target(s) of the update message. The 1783 TargetIdentifier syntax as described in Section 4.1 is used. 1784 seqNum is a single use value that will be used to match the 1785 Community Update message with the Community Update Confirm 1786 message. The sequence number is also used to detect TAMP message 1787 replay. The sequence number processing described in Section 6 1788 MUST successfully complete before any of the updates are 1789 processed. 1791 o updates contains a sequence of community identifiers to be removed 1792 and a sequence of community identifiers to be added. These are 1793 represented by the CommunityUpdates structure. 1795 The CommunityUpdates is a sequence of two OPTIONAL sequences, but at 1796 least one of these sequences MUST be present. The first sequence 1797 contains community identifiers to be removed, and if there are none, 1798 it is absent. Where remove is present with an empty list, all 1799 community identifiers MUST be removed. The second sequence contains 1800 community identifiers to be added, and if there are none, it is 1801 absent. The remove updates, if present, MUST be processed before the 1802 add updates. An error is generated if any of the requested removals 1803 or additions cannot be accomplished. However, requests to remove 1804 community identifiers that are not present are treated as successful 1805 removals. Likewise, requests to add community identifiers that are 1806 already present are treated as successful additions. If an error is 1807 generated, the trust anchor store community list MUST NOT be changed. 1809 A description of the syntax associated with each of these actions 1810 follows: 1812 o remove is used to remove one, multiple or all community 1813 identifiers from the trust anchor store. 1815 o add is used to insert one or more new community identifiers into 1816 the trust anchor store. 1818 4.8. Community Update Confirm 1820 The Community Update Confirm message is a reply by a trust anchor 1821 store to a valid Community Update message. The Community Update 1822 Confirm message provides success or failure information for the 1823 requested updates. Success is returned only if the whole batch of 1824 updates is successfully processed. If any of the requested updates 1825 cannot be performed, then a failure is indicated, and the set of 1826 community identifiers stored in the trust anchor store is unchanged. 1827 The Community Update Confirm message MAY be signed or unsigned. A 1828 Community Update Confirm message MUST be signed if the trust anchor 1829 store is capable of signing it. 1831 The Community Update Confirm content type has the following syntax: 1833 tamp-community-update-confirm PKCS7-CONTENT-TYPE ::= 1834 { TAMPCommunityUpdateConfirm IDENTIFIED BY 1835 id-ct-TAMP-communityUpdateConfirm } 1837 id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= 1838 { id-tamp 8 } 1840 TAMPCommunityUpdateConfirm ::= SEQUENCE { 1841 version [0] TAMPVersion DEFAULT v2, 1842 update TAMPMsgRef, 1843 commConfirm CommunityConfirm } 1845 CommunityConfirm ::= CHOICE { 1846 terseCommConfirm [0] TerseCommunityConfirm, 1847 verboseCommConfirm [1] VerboseCommunityConfirm } 1849 TerseCommunityConfirm ::= StatusCode 1851 VerboseCommunityConfirm ::= SEQUENCE { 1852 status StatusCode, 1853 communities CommunityIdentifierList OPTIONAL } 1855 The fields of TAMPCommunityUpdateConfirm are used as follows: 1857 o version identifies version of TAMP. For this version of the 1858 specification, the default value, v2, MUST be used. 1860 o update identifies the Community Update message to which the trust 1861 anchor store is responding. The update structure repeats the 1862 TAMPMsgRef from the Community Update message (see Section 4.7). 1863 The sequence number processing described in Section 6 MUST 1864 successfully complete before any of the updates are processed. 1866 o commConfirm contains either a terse community update confirmation 1867 or a verbose community update confirmation. The terse response is 1868 represented by TerseCommunityConfirm, and the verbose response is 1869 represented by VerboseCommunityConfirm. 1871 The TerseCommunityConfirm contains a single status code, indicating 1872 the success or failure of the Community Update message has been 1873 processed. If the community update failed, then the status code 1874 indicates the reason for the failure. Each of the status codes is 1875 discussed in Section 5. 1877 The fields of VerboseCommunityConfirm are used as follows: 1879 o status contains a single status code, indicating the success or 1880 failure of the Community Update message has been processed. If 1881 the community update failed, then the status code indicates the 1882 reason for the failure. Each of the status codes is discussed in 1883 Section 5. 1885 o communities is OPTIONAL. When present it contains the sequence of 1886 community identifiers present in the trust anchor store after the 1887 update is processed. When the trust anchor store belongs to no 1888 communities, this field is omitted. 1890 4.9. Sequence Number Adjust 1892 The trust anchor store maintains the current sequence number for the 1893 apex trust anchor and each management trust anchor authorized for 1894 TAMP messages. Sequence number processing is discussed in Section 6. 1895 The Sequence Number Adjust message can be used provide the most 1896 recently used sequence number to one or more targets, thereby 1897 reducing the possibility of replay. The Sequence Number Adjust 1898 message MUST be signed. For the Sequence Number Adjust message to be 1899 valid, the trust anchor store MUST be an intended recipient of the 1900 Sequence Number Adjust message, the sequence number MUST be equal to 1901 or larger than the most recently stored sequence number for the 1902 originating trust anchor, and the digital signature MUST be validated 1903 by the apex trust anchor operational public key or an authorized 1904 management trust anchor. 1906 If the digital signature on the Sequence Number Adjust message is 1907 valid, the sequence number is equal to or larger than the most 1908 recently stored sequence number for the originating trust anchor, the 1909 signer is authorized, and the trust anchor store is an intended 1910 recipient of the TAMP message, then the trust anchor store MUST 1911 update the sequence number associated with the originating trust 1912 anchor and return a Sequence Number Adjust Confirm message. If a 1913 Sequence Number Adjust Confirm message is not returned, then a TAMP 1914 Error message SHOULD be returned. 1916 The Sequence Number Adjust message contains an adjustment for the 1917 sequence number of the TAMP message signer. 1919 The Sequence Number Adjust content type has the following syntax: 1921 tamp-sequence-number-adjust PKCS7-CONTENT-TYPE ::= 1922 { SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust } 1924 id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 } 1926 SequenceNumberAdjust ::= SEQUENCE { 1927 Version [0] TAMPVersion DEFAULT v2, 1928 msgRef TAMPMsgRef } 1930 The fields of SequenceNumberAdjust are used as follows: 1932 o version identifies version of TAMP. For this version of the 1933 specification, the default value, v2, MUST be used. 1935 o msgRef contains two items: the target and the seqNum. target 1936 identifies the target(s) of the sequence number adjust message. 1937 The TargetIdentifier syntax as described in Section 4.1 is used. 1938 The allModules target is expected to be used for Sequence Number 1939 Adjust messages. seqNum MUST be equal to or larger than the most 1940 recently stored sequence number for this TAMP message signer, and 1941 the value will be used to match the Sequence Number Adjust message 1942 with the Sequence Number Adjust Confirm message. The sequence 1943 number processing described in Section 6 applies, except that the 1944 sequence number in a Sequence Number Adjust message is acceptable 1945 if it matches the most recently stored sequence number for this 1946 TAMP message signer. If sequence number checking completes 1947 successfully, then the sequence number is adjusted, otherwise it 1948 remains unchanged. 1950 4.10. Sequence Number Adjust Confirm 1952 The Sequence Number Adjust Confirm message is a reply by a trust 1953 anchor store to a valid Sequence Number Adjust message. The Sequence 1954 Number Adjust Confirm message provides success or failure 1955 information. Success is returned only if the sequence number for the 1956 trust anchor that signed the Sequence Number Adjust message 1957 originator is adjusted. If the sequence number cannot be adjusted, 1958 then a failure is indicated, and the sequence number stored in the 1959 trust anchor store is unchanged. The Sequence Number Adjust Confirm 1960 message MAY be signed or unsigned. A Sequence Number Adjust Confirm 1961 message MUST be signed if the trust anchor store is capable of 1962 signing it. 1964 The Sequence Number Adjust Confirm content type has the following 1965 syntax: 1967 tamp-sequence-number-adjust-confirm PKCS7-CONTENT-TYPE ::= 1968 { SequenceNumberAdjustConfirm IDENTIFIED BY 1969 id-ct-TAMP-seqNumAdjustConfirm } 1971 id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= 1972 { id-tamp 11 } 1974 SequenceNumberAdjustConfirm ::= SEQUENCE { 1975 version [0] TAMPVersion DEFAULT v2, 1976 adjust TAMPMsgRef, 1977 status StatusCode } 1979 The fields of SequenceNumberAdjustConfirm are used as follows: 1981 o version identifies version of TAMP. For this version of the 1982 specification, the default value, v2, MUST be used. 1984 o adjust identifies the Sequence Number Adjust message to which the 1985 trust anchor store is responding. The adjust structure repeats 1986 the TAMPMsgRef from the Sequence Number Adjust message (see 1987 Section 4.9). The sequence number processing described in Section 1988 6 MUST successfully complete to adjust the sequence number 1989 associated with the Sequence Number Adjust message originator. 1991 o status contains a single status code, indicating the success or 1992 failure of the Sequence Number Adjust message processing. If the 1993 adjustment failed, then the status code indicates the reason for 1994 the failure. Each of the status codes is discussed in Section 5. 1996 4.11. TAMP Error 1998 The TAMP Error message is a reply by a trust anchor store to any 1999 invalid TAMP message. The TAMP Error message provides an indication 2000 of the reason for the error. The TAMP Error message MAY be signed or 2001 unsigned. A TAMP Error message MUST be signed if the trust anchor 2002 store is capable of signing it. For the request types defined in 2003 this specification, TAMP Error messages MUST NOT be used to indicate 2004 a request message was successfully processed. 2006 The TAMP Error message content type has the following syntax: 2008 tamp-error PKCS7-CONTENT-TYPE ::= 2009 { TAMPError IDENTIFIED BY id-ct-TAMP-error } 2011 id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 } 2013 TAMPError ::= SEQUENCE { 2014 version [0] TAMPVersion DEFAULT v2, 2015 msgType OBJECT IDENTIFIER, 2016 status StatusCode, 2017 msgRef TAMPMsgRef OPTIONAL } 2019 The fields of TAMPError are used as follows: 2021 o version identifies version of TAMP. For this version of the 2022 specification, the default value, v2, MUST be used. 2024 o msgType indicates the content type of the TAMP message that caused 2025 the error. 2027 o status contains a status code that indicates the reason for the 2028 error. Each of the status codes is discussed in Section 5. 2030 o msgRef is OPTIONAL, but whenever possible it SHOULD be present. 2031 It identifies the TAMP message that caused the error. It repeats 2032 the target and seqNum from the TAMP message that caused the error 2033 (see Sections 4.1, 4.3, 4.5, 4.7 and 4.9). 2035 5. Status Codes 2037 The Trust Anchor Update Confirm, the Apex Trust Anchor Update 2038 Confirm, the Community Update Confirm, the Sequence Number Adjust 2039 Confirm, and the TAMP Error messages include status codes. The 2040 syntax for the status codes is: 2042 StatusCode ::= ENUMERATED { 2043 success (0), 2044 decodeFailure (1), 2045 badContentInfo (2), 2046 badSignedData (3), 2047 badEncapContent (4), 2048 badCertificate (5), 2049 badSignerInfo (6), 2050 badSignedAttrs (7), 2051 badUnsignedAttrs (8), 2052 missingContent (9), 2053 noTrustAnchor (10), 2054 notAuthorized (11), 2055 badDigestAlgorithm (12), 2056 badSignatureAlgorithm (13), 2057 unsupportedKeySize (14), 2058 unsupportedParameters (15), 2059 signatureFailure (16), 2060 insufficientMemory (17), 2061 unsupportedTAMPMsgType (18), 2062 apexTAMPAnchor (19), 2063 improperTAAddition (20), 2064 seqNumFailure (21), 2065 contingencyPublicKeyDecrypt (22), 2066 incorrectTarget (23), 2067 communityUpdateFailed (24), 2068 trustAnchorNotFound (25), 2069 unsupportedTAAlgorithm (26), 2070 unsupportedTAKeySize (27), 2071 unsupportedContinPubKeyDecryptAlg (28), 2072 missingSignature (29), 2073 resourcesBusy (30), 2074 versionNumberMismatch (31), 2075 missingPolicySet (32), 2076 revokedCertificate (33), 2077 unsupportedTrustAnchorFormat (34), 2078 other (127) } 2080 The various values of StatusCode are used as follows: 2082 o success is used to indicate that an update, portion of an update, 2083 or adjust was processed successfully. 2085 o decodeFailure is used to indicate that the trust anchor store was 2086 unable to successfully decode the provided message. The specified 2087 content type and the provided content do not match. 2089 o badContentInfo is used to indicate that the ContentInfo syntax is 2090 invalid or that the contentType carried within the ContentInfo is 2091 unknown or unsupported. 2093 o badSignedData is used to indicate that the SignedData syntax is 2094 invalid, the version is unknown or unsupported, or more than one 2095 entry is present in digestAlgorithms. 2097 o badEncapContent is used to indicate that the 2098 EncapsulatedContentInfo syntax is invalid. This error can be 2099 generated due to problems located in SignedData. 2101 o badCertificate is used to indicate that the syntax for one or more 2102 certificates in CertificateSet is invalid. 2104 o badSignerInfo is used to indicate that the SignerInfo syntax is 2105 invalid, or the version is unknown or unsupported. 2107 o badSignedAttrs is used to indicate that the signedAttrs syntax 2108 within SignerInfo is invalid. 2110 o badUnsignedAttrs is used to indicate that the unsignedAttrs within 2111 SignerInfo contains an attribute other than the contingency- 2112 public-key-decrypt-key unsigned attribute, which is the only 2113 unsigned attribute supported by this specification. 2115 o missingContent is used to indicate that the OPTIONAL eContent is 2116 missing in EncapsulatedContentInfo, which is REQUIRED in this 2117 specification. This error can be generated due to problems 2118 located in SignedData. 2120 o noTrustAnchor is used to indicate one of two possible error 2121 situations. In one case, the subjectKeyIdentifier does not 2122 identify the public key of a trust anchor or a certification path 2123 that terminates with an installed trust anchor. In the other 2124 case, the issuerAndSerialNumber is used to identify the TAMP 2125 message signer, which is prohibited by this specification. 2127 o notAuthorized is used to indicate one of two possible error 2128 situations. In one case the sid within SignerInfo leads to an 2129 installed trust anchor, but that trust anchor is not an authorized 2130 signer for the received TAMP message content type. Identity trust 2131 anchors are not authorized signers for any of the TAMP message 2132 content types. In the other case, the signer of a Trust Anchor 2133 Update message is not authorized to manage the to-be-updated trust 2134 anchor as determined by a failure of the subordination processing 2135 in Sec. 7. 2137 o badDigestAlgorithm is used to indicate that the digestAlgorithm in 2138 either SignerInfo or SignedData is unknown or unsupported. 2140 o badSignatureAlgorithm is used to indicate that the 2141 signatureAlgorithm in SignerInfo is unknown or unsupported. 2143 o unsupportedKeySize is used to indicate that the signatureAlgorithm 2144 in SignerInfo is known and supported, but the TAMP message digital 2145 signature could not be validated because an unsupported key size 2146 was employed by the signer. 2148 o unsupportedParameters is used to indicate that the 2149 signatureAlgorithm in SignerInfo is known, but the TAMP message 2150 digital signature could not be validated because unsupported 2151 parameters were employed by the signer. 2153 o signatureFailure is used to indicate that the signatureAlgorithm 2154 in SignerInfo is known and supported, but the digital signature in 2155 the signature field within SignerInfo could not be validated. 2157 o insufficientMemory indicates that the update could not be 2158 processed because the trust anchor store did not have sufficient 2159 memory to store the resulting trust anchor configuration or 2160 community identifier. 2162 o unsupportedTAMPMsgType indicates that the TAMP message could not 2163 be processed because the trust anchor store does not support the 2164 provided TAMP message type. This code will be used if the id-ct- 2165 TAMP-communityUpdate content type is provided and the trust anchor 2166 store does not support the Community Update message. This status 2167 code will also be used if the contentType value within 2168 eContentType is not one that is defined in this specification. 2170 o apexTAMPAnchor indicates that the update could not be processed 2171 because the Trust Anchor Update message tried to remove the apex 2172 trust anchor. 2174 o improperTAAddition indicates that a trust anchor update is trying 2175 to add a new trust anchor that may already exist, but some 2176 attributes of the to-be-added trust anchor are being modified in 2177 an improper manner. The desired trust anchor configuration may be 2178 attainable with a change operation instead of an add operation. 2180 o seqNumFailure indicates that the TAMP message could not be 2181 processed because the processing of the sequence number, which is 2182 described in Section 6, resulted in an error. 2184 o contingencyPublicKeyDecrypt indicates that the update could not be 2185 processed because an error occurred while decrypting the 2186 contingency public key. 2188 o incorrectTarget indicates that the query, update, or adjust 2189 message could not be processed because the trust anchor store is 2190 not the intended recipient. 2192 o communityUpdateFailed indicates that the community update 2193 requested the addition of a community identifier or the removal of 2194 a community identifier, but the request could not be honored. 2196 o trustAnchorNotFound indicates that a change to a trust anchor was 2197 requested, but the referenced trust anchor is not represented in 2198 the trust anchor store. 2200 o unsupportedTAAlgorithm indicates that an update message would 2201 result in the trust anchor with a public key associated with a 2202 digital signature validation algorithm that is not implemented. 2203 In addition, this status code is used if the algorithm is 2204 supported, but the parameters associated with the algorithm are 2205 not supported. 2207 o unsupportedTAKeySize indicates that the trust anchor would include 2208 a public key of a size that is not supported. 2210 o unsupportedContinPubKeyDecryptAlg indicates that the decryption 2211 algorithm for the apex trust anchor contingency public key is not 2212 supported. 2214 o missingSignature indicates that an unsigned TAMP message was 2215 received, but the received TAMP message type MUST be signed. 2217 o resourcesBusy indicates that the resources necessary to process 2218 the TAMP message are not available at the present time, but the 2219 resources might be available at some point in the future. 2221 o versionNumberMismatch indicates that the version number in a 2222 received TAMP message is not acceptable. 2224 o missingPolicySet indicates that the policyFlags associated with a 2225 trust anchor are set in a fashion that requires the policySet to 2226 be present, but the policySet is missing. 2228 o revokedCertificate indicates that one or more of the certificates 2229 needed to properly process the TAMP message has been revoked. 2231 o unsupportedTrustAnchorFormat indicates that an unsupported trust 2232 anchor format was presented or the version is unknown or 2233 unsupported. 2235 o other indicates that the update could not be processed, but the 2236 reason is not covered by any of the assigned status codes. Use of 2237 this status code SHOULD be avoided. 2239 6. Sequence Number Processing 2241 The sequence number processing facilities in TAMP represent a balance 2242 between replay protection, operational considerations, and trust 2243 anchor store memory management. The goal is to provide replay 2244 protection without making TAMP difficult to use, creating an 2245 environment where surprising error conditions occur on a regular 2246 basis, or imposing onerous memory management requirements on 2247 implementations. This balance is achieved by performing sequence 2248 number checking on TAMP messages that are signed directly by a trust 2249 anchor, and skipping these checks whenever the TAMP message 2250 originator is represented by a certificate. 2252 The TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update, 2253 Community Update, and Sequence Number Adjust messages include a 2254 sequence number. This single-use identifier is used to match a TAMP 2255 message with the response to that TAMP message. When the TAMP 2256 message is signed directly by a trust anchor, the sequence number is 2257 also used to detect TAMP message replay. 2259 To provide replay protection, each TAMP message originator MUST treat 2260 the sequence number as a monotonically increasing non-negative 2261 integer. The sequence number counter is associated with the signing 2262 operation performed by the private key. The trust anchor store MUST 2263 ensure that a newly received TAMP message that is validated directly 2264 by a trust anchor public key contains a sequence number that is 2265 greater than the most recent successfully processed TAMP message from 2266 that originator. Note that the Sequence Number Adjust message is 2267 considered valid if the sequence number is greater than or equal to 2268 the most recent successfully processed TAMP message from that 2269 originator. If the sequence number in a received TAMP message does 2270 not meet these conditions, then the trust anchor store MUST reject 2271 the TAMP message, returning a sequence number failure (seqNumFailure) 2272 error. 2274 Whenever a trust anchor is authorized for TAMP messages, either as a 2275 newly installed trust anchor or as a modification to an existing 2276 trust anchor, if a sequence number value is not provided in the Trust 2277 Anchor Update message, memory MUST be allocated for the sequence 2278 number and set to zero. The first TAMP message received that is 2279 signed by that trust anchor is not rejected based on sequence number 2280 checks, and the sequence number from that first TAMP message is 2281 stored. The TAMP message recipient MUST maintain a database of the 2282 most recent sequence number from a successfully processed TAMP 2283 message from each trust anchor. The index for this database is the 2284 trust anchor public key. This could be the apex trust anchor 2285 operational public key or a management trust anchor public key. In 2286 the first case, the apex trust anchor operational public key is used 2287 directly to validate the TAMP message digital signature. In the 2288 second case, a management trust anchor public key is used directly to 2289 validate the TAMP message digital signature. 2291 Sequence number values MUST be 64-bit non-negative integers. Since 2292 ASN.1 encoding of an INTEGER always includes a sign bit, a TAMP 2293 message signer can generate 9,223,372,036,854,775,807 TAMP messages 2294 before exhausting the 64-bit sequence number space, before which the 2295 TAMP message signer MUST transition to a different public/private key 2296 pair. The ability to reset a sequence number provided by the Trust 2297 Anchor Update and Sequence Number Adjust messages is not intended to 2298 avoid the transition to a different key pair; rather, it is intended 2299 to aid recovery from operational errors. A relatively small non- 2300 volatile storage requirement is imposed on the trust anchor store for 2301 the apex trust anchor and each management trust anchor authorized for 2302 TAMP messages. 2304 When the apex trust anchor or a management trust anchor is replaced 2305 or removed from the trust anchor store, the associated sequence 2306 number storage SHOULD be reclaimed. 2308 7. Subordination Processing 2310 When a TAMP update message is processed, several checks are 2311 performed: 2313 o TAMP message authentication is checked including, if necessary, 2314 building and validating a certification path to the signer. 2316 o The signer's authorization is checked, including authorization to 2317 manage trust anchors included in the update message. 2319 o Calculation of the trust anchor information to be stored. 2321 This section describes how to perform the second and third steps. 2322 Section 1.2 discusses authentication of TAMP messages. Where a trust 2323 anchor is represented as a certificate and the calculation of the 2324 trust anchor information to be stored is different than the 2325 information in the certificate, the TAMP update fails. The TAMP 2326 message signer may then wrap the certificate inside a TrustAnchorInfo 2327 structure to assert the intended information. 2329 The apex trust anchor is unconstrained, which means that 2330 subordination checking need not be performed on Trust Anchor Update 2331 messages signed with the apex trust anchor operational public key and 2332 that trust anchor information can be stored as it appears in the 2333 update message. Subordination checking is performed as part of the 2334 validation process of all other Trust Anchor Update messages. 2336 For a Trust Anchor Update message that is not signed with the apex 2337 trust anchor operational public key to be valid, the digital 2338 signature MUST be validated using an authorized trust anchor, either 2339 directly or via an X.509 certification path originating with the apex 2340 trust anchor operational public key or an authorized management trust 2341 anchor. The following subordination checks MUST also be performed as 2342 part of validation of the update message. 2344 Each Trust Anchor Update message contains one or more individual 2345 updates, each of which is used to add, modify or remove a trust 2346 anchor. For each individual update, the constraints of the TAMP 2347 message signer MUST be greater than or equal to the constraints of 2348 the trust anchor in the update. Specifically, constraints included 2349 in the CertPathControls field of a TrustAnchorInfo object (or 2350 equivalent extensions in Certificate or TBSCertificate objects) must 2351 be checked as described below. [RFC5280] describes how the 2352 intersection and union operations referenced below are performed. 2354 o The values of the policyFlags stored with a trust anchor as the 2355 result of a TAMPUpdate are either true or equal to the value of 2356 the policy flags associated with the TAMP message signer, i.e., an 2357 update may set a flag to false only if the value associated with 2358 the TAMP message signer is false. The policy flags associated 2359 with the TAMP message signer are read from the policyFlags field 2360 or policyConstraints and inhibitAnyPolicy extensions if the signer 2361 is a trust anchor or from the explicit_policy, policy_mapping and 2362 inhibit_anyPolicy state variables following path validation if the 2363 signer is not a trust anchor. 2365 o The certificate policies stored with a trust anchor as the result 2366 of a TAMPUpdate are equal to the intersection of the certificate 2367 policies value associated with the TAMP message signer and the 2368 value of the policySet field or certificatePolicies extension from 2369 the update. The certificate policies associated with the TAMP 2370 message signer are read from the policySet field in a 2371 TrustAnchorInfo or CertificatePolicies extension in a Certificate 2372 or TBSCertificate if the signer is a trust anchor or from the 2373 valid_policy_tree returned following path validation if the signer 2374 is not a trust anchor. Where the TAMP message signer is a trust 2375 anchor, no policy mapping is performed. If the intersection is 2376 NULL and the to-be-stored requireExplicitPolicy value is true, the 2377 TAMP update fails. 2379 o The excluded names stored with a trust anchor as the result of a 2380 TAMPUpdate are equal to the union of the excluded names associated 2381 with the TAMP message signer and the value from the nameConstr 2382 field or nameConstraints extension from the update. The name 2383 constraints associated with the TAMP message signer are read from 2384 the nameConstr field in a TrustAnchorInfo or nameConstraints 2385 extension in a Certificate or TBSCertificate if the signer is a 2386 trust anchor or from the excludedSubtrees state variable following 2387 path validation if the signer is not a trust anchor. The name of 2388 the trust anchor included in the update MUST NOT fall within the 2389 excluded name space of the TAMP signer. If the name of the trust 2390 anchor falls within the excluded name space of the TAMP signer, 2391 the TAMP update fails. 2393 o The permitted names stored with a trust anchor as the result of a 2394 TAMPUpdate are equal to the intersection of the permitted names 2395 associated with the TAMP message signer and the value from the 2396 nameConstr field or nameConstraints extension from the update. 2397 The name constraints associated with the TAMP message signer are 2398 read from the nameConstr field in a TrustAnchorInfo or 2399 nameConstraints extension in a Certificate or TBSCertificate if 2400 the signer is a trust anchor or from the permittedSubtrees state 2401 variable following path validation if the signer is not a trust 2402 anchor. The name of the trust anchor included in the update MUST 2403 fall within the permitted name space of the TAMP signer. If the 2404 name of the trust anchor does not fall within the permitted name 2405 space of the TAMP signer, the TAMP update fails. If the 2406 intersection is NULL for all name forms, the TAMP update fails. 2408 No other extensions defined in RFC5280 must be processed as part of 2409 subordination processing. Other extensions may define subordination 2410 rules. 2412 8. Implementation Considerations 2414 A public key identifier is used to identify a TAMP message signer. 2415 Since there is no guarantee that the same public key identifier is 2416 not associated with more than one public key, implementations MUST be 2417 prepared for one or more trust anchor to have the same public key 2418 identifier. In practical terms, this means that when a digital 2419 signature validation fails, the implementation MUST see if there is 2420 another trust anchor with the same public key identifier that can be 2421 used to validate the digital signature. While duplicate public key 2422 identifiers are expected to be rare, implementations MUST NOT fail to 2423 find the correct trust anchor when they do occur. 2425 An X.500 distinguished name is used to identify certificate issuers 2426 and certificate subjects. The same X.500 distinguished name can be 2427 associated with more than one trust anchor. However, the trust 2428 anchor public key will be different. The probability that two trust 2429 anchors will have the same X.500 distinguished name and the same 2430 public key identifier but a different public key is diminishingly 2431 small. Therefore, the authority key identifier certificate extension 2432 can be used to resolve X.500 distinguished name collisions. 2434 9. Apex trust anchor info certificate extension 2436 An Apex trust anchor MAY contain contingency key information using 2437 the WrappedApexContingencyKey extension. The extension uses the 2438 ApexContingencyKey structure as defined below. 2440 ApexContingencyKey ::= SEQUENCE { 2441 wrapAlgorithm AlgorithmIdentifier OPTIONAL, 2442 wrappedContinPubKey OCTET STRING OPTIONAL} 2444 The fields of ApexContingencyKey are used as described below. When 2445 one field is present, both MUST be present. When one field is 2446 absent, both MUST be absent. The fields are allowed to be absent to 2447 enable usage of this extension as a means of indicating the 2448 corresponding public key is recognized as an apex trust anchor by 2449 some relying parties. 2451 o wrapAlgorithm identifies the symmetric algorithm used to encrypt 2452 the apex trust anchor contingency public key. If this public key 2453 is ever needed, the symmetric key needed to decrypt it will be 2454 provided in the message that is to be validated using it. The 2455 algorithm identifier is an AlgorithmIdentifier, which contains an 2456 object identifier and OPTIONAL parameters. The object identifier 2457 indicates the syntax of the parameters, if present. 2459 o wrappedContinPubKey is the encrypted apex trust anchor contingency 2460 public key. Once decrypted, it yields the PublicKeyInfo 2461 structure, which consists of the algorithm identifier followed by 2462 the public key itself. The algorithm identifier is an 2463 AlgorithmIdentifier that contains an object identifier and 2464 OPTIONAL parameters. The object identifier indicates the format 2465 of the public key and the syntax of the parameters, if present. 2466 The public key is encoded as a BIT STRING. 2468 The apex trust anchor info extension MAY be critical, and it MUST 2469 appear at most one time in a set of extensions. The apex trust 2470 anchor info extension is identified by the id-pe-wrappedApexContinKey 2471 object identifier: 2473 id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::= 2474 { iso(1) identified-organization(3) dod(6) internet(1) 2475 security(5) mechanisms(5) pkix(7) pe(1) 20 } 2477 10. Security Considerations 2479 The majority of this specification is devoted to the syntax and 2480 semantics of TAMP messages. It relies on other specifications, 2481 especially [I-D.ietf-pkix-ta-format], [RFC3852] and [RFC5280], for 2482 the syntax and semantics of trust anchors, CMS protecting content 2483 types and X.509 certificates, respectively. Since TAMP messages that 2484 change the trust anchor state of a trust anchor store are always 2485 signed by a Trust Anchor Manager, no further data integrity or data 2486 origin authentication mechanisms are needed; however, no 2487 confidentiality for these messages is provided. Similarly, 2488 certificates are digitally signed, and no additional data integrity 2489 or data origin authentication mechanisms are needed. Trust anchor 2490 configurations, Trust Anchor Manager certificates, and trust anchor 2491 store certificates are not intended to be sensitive. As a result, 2492 this specification does not provide for confidentiality of TAMP 2493 messages. 2495 Security factors outside the scope of this specification greatly 2496 affect the assurance provided. The procedures used by certification 2497 authorities (CAs) to validate the binding of the subject identity to 2498 their public key greatly affect the assurance associated with the 2499 resulting certificate. This is particularly important when issuing 2500 certificates to other CAs. In the context of TAMP, the issuance of 2501 an end entity certificate under a management trust anchor is an act 2502 of delegation. However, such end entities cannot further delegate. 2503 On the other hand, issuance of a CA certificate under a management 2504 trust anchor is an act of delegation where the CA can perform further 2505 delegation. The scope of the delegation can be constrained by 2506 including appropriate certificate extensions in a CA certificate. 2508 X.509 certification path construction involves comparison of X.500 2509 distinguished names. Inconsistent application of name comparison 2510 rules can result in acceptance of invalid X.509 certification paths 2511 or rejection of valid ones. Name comparison can be extremely 2512 complex. To avoid imposing this complexity on trust anchor stores, 2513 any certificate profile used with TAMP SHOULD employ simple name 2514 structures and impose rigorous restrictions on acceptable 2515 distinguished names, including the way that they are encoded. The 2516 goal of that certificate profile should be to enable simple binary 2517 comparison. That is, case conversion, character set conversion, 2518 white space compression, and leading and trailing white space 2519 trimming SHOULD be avoided. 2521 Some digital signature algorithms require the generation of random 2522 one-time values. For example, when generating a DSA digital 2523 signature, the signer MUST generate a random k value [DSS]. Also, 2524 the generation of public/private key pairs relies on random numbers. 2526 The use of an inadequate random number generator (RNG) or an 2527 inadequate pseudo-random number generator (PRNG) to generate such 2528 cryptographic values can result in little or no security. An 2529 attacker may find it much easier to reproduce the random number 2530 generation environment, searching the resulting small set of 2531 possibilities, rather than brute force searching the whole space. 2533 Compromise of an identity trust anchor private key permits 2534 unauthorized parties to issue certificates that will be acceptable to 2535 all trust anchor stores configured with the corresponding identity 2536 trust anchor. The unauthorized private key holder will be limited by 2537 the certification path controls associated with the identity trust 2538 anchor. For example, clearance constraints in the identity trust 2539 anchor will determine the clearances that will be accepted in 2540 certificates that are issued by the unauthorized private key holder. 2542 Compromise of a management trust anchor private key permits 2543 unauthorized parties to generate signed messages that will be 2544 acceptable to all trust anchor stores configured with the 2545 corresponding management trust anchor. All devices that include the 2546 compromised management trust anchor can be configured as desired by 2547 the unauthorized private key holder within the limits of the 2548 subordination checks described in Section 7. If the management trust 2549 anchor is associated with content types other than TAMP, then the 2550 unauthorized private key holder can generate signed messages of that 2551 type. For example, if the management trust anchor is associated with 2552 firmware packages, then the unauthorized private key holder can 2553 install different firmware. 2555 Compromise of the Apex Trust Anchor operational private key permits 2556 unauthorized parties to generate signed messages that will be 2557 acceptable to all trust anchor stores configured with the 2558 corresponding apex trust anchor. All devices that include that apex 2559 trust anchor can be configured as desired by the unauthorized private 2560 key holder, and the unauthorized private key holder can generate 2561 signed messages of any content type. The optional contingency 2562 private key offers a potential way to recover from such a compromise. 2564 The compromise of a CA's private key leads to the same type of 2565 problems as the compromise of an identity or a management trust 2566 anchor private key. The unauthorized private key holder will be 2567 limited by the certification path controls and extensions associated 2568 with the trust anchor. 2570 The compromise of an end entity private key leads to the same type of 2571 problems as the compromise of an identity or a management trust 2572 anchor private key, except that the end entity is unable to issue any 2573 certificates. The unauthorized private key holder will be limited by 2574 the certification path controls and extensions associated with the 2575 trust anchor. 2577 Compromise of a trust anchor store's digital signature private key 2578 permits unauthorized parties to generate signed TAMP response 2579 messages, masquerading as the trust anchor store. 2581 Premature disclosure of the key-encryption key used to encrypt the 2582 apex trust anchor contingency public key may result in early exposure 2583 of the apex trust anchor contingency public key. 2585 TAMP implementations need to be able to parse messages and 2586 certificates. Care must be taken to ensure that there are no 2587 implementation defects in the TAMP message parser or the processing 2588 that acts on the message content. A validation suite is one way to 2589 increase confidence in the parsing of TAMP messages, CMS content 2590 types, attributes, certificates and extensions. 2592 TrustAnchorList messages do not provide a replay detection mechanism. 2593 Where TrustAnchorList messages are accepted as an alternative means 2594 of adding trust anchors to a trust anchor store, applications may 2595 require additional mechanisms to address the risks associated with 2596 replay of old TrustAnchorList messages. 2598 11. IANA Considerations 2600 There are no IANA considerations. Please delete this section prior 2601 to RFC publication. 2603 12. References 2605 12.1. Normative References 2607 [I-D.ietf-pkix-new-asn1] 2608 Hoffman, P. and J. Schaad, "New ASN.1 Modules for PKIX", 2609 draft-ietf-pkix-new-asn1-07 (work in progress), 2610 August 2009. 2612 [I-D.ietf-pkix-ta-format] 2613 Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 2614 Format", draft-ietf-pkix-ta-format-03 (work in progress), 2615 May 2009. 2617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2618 Requirement Levels", BCP 14, RFC 2119, March 1997. 2620 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2621 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2622 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2624 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", 2625 RFC 2634, June 1999. 2627 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2628 10646", STD 63, RFC 3629, November 2003. 2630 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 2631 RFC 3852, July 2004. 2633 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2634 Housley, R., and W. Polk, "Internet X.509 Public Key 2635 Infrastructure Certificate and Certificate Revocation List 2636 (CRL) Profile", RFC 5280, May 2008. 2638 [X.680] "ITU-T Recommendation X.680: Information Technology - 2639 Abstract Syntax Notation One", 1997. 2641 [X.690] "ITU-T Recommendation X.690 Information Technology - ASN.1 2642 encoding rules: Specification of Basic Encoding Rules 2643 (BER), Canonical Encoding Rules (CER) and Distinguished 2644 Encoding Rules (DER)", 1997. 2646 12.2. Informative References 2648 [DSS] "FIPS Pub 186: Digital Signature Standard", May 1994. 2650 [PKCS#6] "PKCS #6: Extended-Certificate Syntax Standard, Version 2651 1.5", November 1993. 2653 [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute 2654 Certificate Profile for Authorization", RFC 3281, 2655 April 2002. 2657 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 2658 Representing Date and Time in ASN.1", RFC 4049, 2659 April 2005. 2661 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 2662 Protect Firmware Packages", RFC 4108, August 2005. 2664 [X.208] "ITU-T Recommendation X.208 - Specification of Abstract 2665 Syntax Notation One (ASN.1)", 1988. 2667 [X.509] "ITU-T Recommendation X.509 - The Directory - 2668 Authentication Framework", 2000. 2670 Appendix A. ASN.1 Modules 2672 Appendix A.1 provides the normative ASN.1 definitions for the 2673 structures described in this specification using ASN.1 as defined in 2674 [X.680]. Appendix A.2 provides a module using ASN.1 as defined in 2675 [X.208]. The module in A.2 removes usage of newer ASN.1 features 2676 that provide support for limiting the types of elements that may 2677 appear in certain SEQUENCE and SET constructions. Otherwise, the 2678 modules are compatible in terms of encoded representation, i.e., the 2679 modules are bits-on-the-wire compatible aside from the limitations on 2680 SEQUENCE and SET constituents. A.2 is included as a courtesy to 2681 developers using ASN.1 compilers that do not support current ASN.1. 2682 A.1 includes definitions imported from [RFC5280], 2683 [I-D.ietf-pkix-new-asn1] and [I-D.ietf-pkix-ta-format]. 2685 A.1. ASN.1 Module Using 1993 Syntax 2687 TAMP-Protocol-v2 2688 { joint-iso-ccitt(2) country(16) us(840) organization(1) 2689 gov(101) dod(2) infosec(1) modules(0) 30 } 2691 DEFINITIONS IMPLICIT TAGS ::= 2692 BEGIN 2694 IMPORTS 2695 TrustAnchorChoice, TrustAnchorTitle, CertPathControls 2696 FROM TrustAnchorInfoModule 2697 { joint-iso-ccitt(2) country(16) us(840) 2698 organization(1) gov(101) dod(2) infosec(1) 2699 modules(0) 33 } 2700 AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, KEY-WRAP 2701 FROM AlgorithmInformation-2009 2702 {iso(1) identified-organization(3) dod(6) internet(1) 2703 security(5) mechanisms(5) pkix(7) id-mod(0) 2704 id-mod-algorithmInformation-02(58)} 2705 Certificate, Name, TBSCertificate, 2706 CertificateSerialNumber, Validity, SubjectPublicKeyInfo, 2707 FROM PKIX1Explicit-2009 -- from [I-D.ietf-pkix-new-asn1] 2708 {iso(1) identified-organization(3) dod(6) internet(1) 2709 security(5) mechanisms(5) pkix(7) id-mod(0) 2710 id-mod-pkix1-explicit-02(51)} 2711 KeyIdentifier, OTHER-NAME 2712 FROM PKIX1Implicit-2009 -- from [I-D.ietf-pkix-new-asn1] 2713 {iso(1) identified-organization(3) dod(6) internet(1) 2714 security(5) mechanisms(5) pkix(7) id-mod(0) 2715 id-mod-pkix1-implicit-02(59)} 2716 EXTENSION, Extensions, ATTRIBUTE, Attribute 2717 FROM PKIX-CommonTypes-2009 -- from [I-D.ietf-pkix-new-asn1] 2718 { iso(1) identified-organization(3) dod(6) internet(1) 2719 security(5) mechanisms(5) pkix(7) id-mod(0) 2720 id-mod-pkixCommon-02(57) } ; 2722 -- Object Identifier Arc for TAMP Message Content Types 2724 id-tamp OBJECT IDENTIFIER ::= { 2725 joint-iso-ccitt(2) country(16) us(840) organization(1) 2726 gov(101) dod(2) infosec(1) formats(2) 77 } 2728 SupportedSigAlgorithms SIGNATURE-ALGORITHM ::= { 2729 -- add any locally defined algorithms here 2730 ... 2731 } 2733 SupportedWrapAlgorithms KEY-WRAP ::= { 2734 -- add any locally defined algorithms here 2735 ... 2736 } 2738 -- CMS Content Types 2740 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 2742 TAMPContentTypes PKCS7-CONTENT-TYPE ::= { 2743 tamp-status-query | 2744 tamp-status-response | 2745 tamp-update | 2746 tamp-update-confirm | 2747 tamp-apex-update | 2748 tamp-apex-update-confirm | 2749 tamp-community-update | 2750 tamp-community-update-confirm | 2751 tamp-sequence-number-adjust | 2752 tamp-sequence-number-adjust-confirm | 2753 tamp-error, 2754 ... -- Expect additional content types -- 2755 } 2757 -- TAMP Status Query Message 2758 tamp-status-query PKCS7-CONTENT-TYPE ::= 2759 { TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery } 2761 id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 } 2763 TAMPStatusQuery ::= SEQUENCE { 2764 version [0] TAMPVersion DEFAULT v2, 2765 terse [1] TerseOrVerbose DEFAULT verbose, 2766 query TAMPMsgRef } 2768 TAMPVersion ::= INTEGER { v1(1), v2(2) } 2770 TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) } 2772 SeqNumber ::= INTEGER (0..9223372036854775807) 2774 TAMPMsgRef ::= SEQUENCE { 2775 target TargetIdentifier, 2776 seqNum SeqNumber } 2778 TargetIdentifier ::= CHOICE { 2779 hwModules [1] HardwareModuleIdentifierList, 2780 communities [2] CommunityIdentifierList, 2781 allModules [3] NULL, 2782 uri [4] IA5String, 2783 otherName [5] INSTANCE OF OTHER-NAME} 2785 OTHER-NAME ::= TYPE-IDENTIFIER 2787 HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF 2788 HardwareModules 2790 HardwareModules ::= SEQUENCE { 2791 hwType OBJECT IDENTIFIER, 2792 hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry } 2794 HardwareSerialEntry ::= CHOICE { 2795 all NULL, 2796 single OCTET STRING, 2797 block SEQUENCE { 2798 low OCTET STRING, 2799 high OCTET STRING } } 2801 CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community 2803 Community ::= OBJECT IDENTIFIER 2805 -- TAMP Status Response Message 2807 tamp-status-response PKCS7-CONTENT-TYPE ::= 2808 { TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse } 2810 id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 } 2811 TAMPStatusResponse ::= SEQUENCE { 2812 version [0] TAMPVersion DEFAULT v2, 2813 query TAMPMsgRef, 2814 response StatusResponse, 2815 usesApex BOOLEAN DEFAULT TRUE} 2817 StatusResponse ::= CHOICE { 2818 terseResponse [0] TerseStatusResponse, 2819 verboseResponse [1] VerboseStatusResponse } 2821 TerseStatusResponse ::= SEQUENCE { 2822 taKeyIds KeyIdentifiers, 2823 communities CommunityIdentifierList OPTIONAL } 2825 KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier 2827 VerboseStatusResponse ::= SEQUENCE { 2828 taInfo TrustAnchorChoiceList, 2829 continPubKeyDecryptAlg [0] AlgorithmIdentifier 2830 {{SupportedWrapAlgorithms}} OPTIONAL, 2831 communities [1] CommunityIdentifierList OPTIONAL, 2832 tampSeqNumbers [2] TAMPSequenceNumbers OPTIONAL } 2834 TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF 2835 TrustAnchorChoice 2837 TAMPSequenceNumber ::= SEQUENCE { 2838 keyId KeyIdentifier, 2839 seqNumber SeqNumber } 2841 TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF TAMPSequenceNumber 2843 -- Trust Anchor Update Message 2845 tamp-update PKCS7-CONTENT-TYPE ::= 2846 { TAMPUpdate IDENTIFIED BY id-ct-TAMP-update } 2848 id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 } 2850 TAMPUpdate ::= SEQUENCE { 2851 version [0] TAMPVersion DEFAULT v2, 2852 terse [1] TerseOrVerbose DEFAULT verbose, 2853 msgRef TAMPMsgRef, 2854 updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate, 2855 tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL } 2857 TrustAnchorUpdate ::= CHOICE { 2858 add [1] TrustAnchorChoice, 2859 remove [2] SubjectPublicKeyInfo, 2860 change [3] EXPLICIT TrustAnchorChangeInfoChoice } 2862 TrustAnchorChangeInfoChoice ::= CHOICE { 2863 tbsCertChange [0] TBSCertificateChangeInfo, 2864 taChange [1] TrustAnchorChangeInfo } 2866 TBSCertificateChangeInfo ::= SEQUENCE { 2867 serialNumber CertificateSerialNumber OPTIONAL, 2868 signature [0] AlgorithmIdentifier 2869 {{SupportedSigAlgorithms}} OPTIONAL, 2870 issuer [1] Name OPTIONAL, 2871 validity [2] Validity OPTIONAL, 2872 subject [3] Name OPTIONAL, 2873 subjectPublicKeyInfo [4] SubjectPublicKeyInfo, 2874 exts [5] EXPLICIT Extensions OPTIONAL } 2876 TrustAnchorChangeInfo ::= SEQUENCE { 2877 pubKey SubjectPublicKeyInfo, 2878 keyId KeyIdentifier OPTIONAL, 2879 taTitle TrustAnchorTitle OPTIONAL, 2880 certPath CertPathControls OPTIONAL, 2881 exts [1] Extensions OPTIONAL} 2883 -- Trust Anchor Update Confirm Message 2885 tamp-update-confirm PKCS7-CONTENT-TYPE ::= 2886 { TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm } 2888 id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 } 2890 TAMPUpdateConfirm ::= SEQUENCE { 2891 version [0] TAMPVersion DEFAULT v2, 2892 update TAMPMsgRef, 2893 confirm UpdateConfirm } 2895 UpdateConfirm ::= CHOICE { 2896 terseConfirm [0] TerseUpdateConfirm, 2897 verboseConfirm [1] VerboseUpdateConfirm } 2899 TerseUpdateConfirm ::= StatusCodeList 2901 StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode 2903 VerboseUpdateConfirm ::= SEQUENCE { 2904 status StatusCodeList, 2905 taInfo TrustAnchorChoiceList, 2906 tampSeqNumbers TAMPSequenceNumbers OPTIONAL, 2907 usesApex BOOLEAN DEFAULT TRUE} 2909 -- Apex Trust Anchor Update Message 2911 tamp-apex-update PKCS7-CONTENT-TYPE ::= 2912 { TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate } 2914 id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 } 2916 TAMPApexUpdate ::= SEQUENCE { 2917 version [0] TAMPVersion DEFAULT v2, 2918 terse [1] TerseOrVerbose DEFAULT verbose, 2919 msgRef TAMPMsgRef, 2920 clearTrustAnchors BOOLEAN, 2921 clearCommunities BOOLEAN, 2922 seqNumber SeqNumber OPTIONAL, 2923 apexTA TrustAnchorChoice } 2925 -- Apex Trust Anchor Update Confirm Message 2927 tamp-apex-update-confirm PKCS7-CONTENT-TYPE ::= 2928 { TAMPApexUpdateConfirm IDENTIFIED BY 2929 id-ct-TAMP-apexUpdateConfirm } 2931 id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 } 2933 TAMPApexUpdateConfirm ::= SEQUENCE { 2934 version [0] TAMPVersion DEFAULT v2, 2935 apexReplace TAMPMsgRef, 2936 apexConfirm ApexUpdateConfirm } 2938 ApexUpdateConfirm ::= CHOICE { 2939 terseApexConfirm [0] TerseApexUpdateConfirm, 2940 verboseApexConfirm [1] VerboseApexUpdateConfirm } 2942 TerseApexUpdateConfirm ::= StatusCode 2944 VerboseApexUpdateConfirm ::= SEQUENCE { 2945 status StatusCode, 2946 taInfo TrustAnchorChoiceList, 2947 communities [0] CommunityIdentifierList OPTIONAL, 2948 tampSeqNumbers [1] TAMPSequenceNumbers OPTIONAL } 2950 -- Community Update Message 2952 tamp-community-update PKCS7-CONTENT-TYPE ::= 2953 { TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate } 2955 id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 } 2957 TAMPCommunityUpdate ::= SEQUENCE { 2958 version [0] TAMPVersion DEFAULT v2, 2959 terse [1] TerseOrVerbose DEFAULT verbose, 2960 msgRef TAMPMsgRef, 2961 updates CommunityUpdates } 2963 CommunityUpdates ::= SEQUENCE { 2964 remove [1] CommunityIdentifierList OPTIONAL, 2965 add [2] CommunityIdentifierList OPTIONAL } 2966 -- At least one must be present 2968 -- Community Update Confirm Message 2970 tamp-community-update-confirm PKCS7-CONTENT-TYPE ::= 2971 { TAMPCommunityUpdateConfirm IDENTIFIED BY 2972 id-ct-TAMP-communityUpdateConfirm } 2974 id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= 2975 { id-tamp 8 } 2977 TAMPCommunityUpdateConfirm ::= SEQUENCE { 2978 version [0] TAMPVersion DEFAULT v2, 2979 update TAMPMsgRef, 2980 commConfirm CommunityConfirm } 2982 CommunityConfirm ::= CHOICE { 2983 terseCommConfirm [0] TerseCommunityConfirm, 2984 verboseCommConfirm [1] VerboseCommunityConfirm } 2986 TerseCommunityConfirm ::= StatusCode 2988 VerboseCommunityConfirm ::= SEQUENCE { 2989 status StatusCode, 2990 communities CommunityIdentifierList OPTIONAL } 2992 -- Sequence Number Adjust Message 2994 tamp-sequence-number-adjust PKCS7-CONTENT-TYPE ::= 2995 { SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust } 2997 id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 } 2999 SequenceNumberAdjust ::= SEQUENCE { 3000 version [0] TAMPVersion DEFAULT v2, 3001 msgRef TAMPMsgRef } 3003 -- Sequence Number Adjust Message 3005 tamp-sequence-number-adjust-confirm PKCS7-CONTENT-TYPE ::= 3006 { SequenceNumberAdjustConfirm IDENTIFIED BY 3007 id-ct-TAMP-seqNumAdjustConfirm } 3009 id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= { id-tamp 11 } 3011 SequenceNumberAdjustConfirm ::= SEQUENCE { 3012 version [0] TAMPVersion DEFAULT v2, 3013 adjust TAMPMsgRef, 3014 status StatusCode } 3016 -- TAMP Error Message 3018 tamp-error PKCS7-CONTENT-TYPE ::= 3019 { TAMPError IDENTIFIED BY id-ct-TAMP-error } 3021 id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 } 3023 TAMPError ::= SEQUENCE { 3024 version [0] TAMPVersion DEFAULT v2, 3025 msgType OBJECT IDENTIFIER, 3026 status StatusCode, 3027 msgRef TAMPMsgRef OPTIONAL } 3029 -- Status Codes 3031 StatusCode ::= ENUMERATED { 3032 success (0), 3033 decodeFailure (1), 3034 badContentInfo (2), 3035 badSignedData (3), 3036 badEncapContent (4), 3037 badCertificate (5), 3038 badSignerInfo (6), 3039 badSignedAttrs (7), 3040 badUnsignedAttrs (8), 3041 missingContent (9), 3042 noTrustAnchor (10), 3043 notAuthorized (11), 3044 badDigestAlgorithm (12), 3045 badSignatureAlgorithm (13), 3046 unsupportedKeySize (14), 3047 unsupportedParameters (15), 3048 signatureFailure (16), 3049 insufficientMemory (17), 3050 unsupportedTAMPMsgType (18), 3051 apexTAMPAnchor (19), 3052 improperTAAddition (20), 3053 seqNumFailure (21), 3054 contingencyPublicKeyDecrypt (22), 3055 incorrectTarget (23), 3056 communityUpdateFailed (24), 3057 trustAnchorNotFound (25), 3058 unsupportedTAAlgorithm (26), 3059 unsupportedTAKeySize (27), 3060 unsupportedContinPubKeyDecryptAlg (28), 3061 missingSignature (29), 3062 resourcesBusy (30), 3063 versionNumberMismatch (31), 3064 missingPolicySet (32), 3065 revokedCertificate (33), 3066 unsupportedTrustAnchorFormat (34), 3067 other (127) } 3069 -- Object Identifier Arc for Attributes 3071 id-attributes OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) 3072 us(840) organization(1) gov(101) dod(2) infosec(1) 5 } 3074 -- TAMP Unsigned Attributes 3076 TAMPUnsignedAttributes ATTRIBUTE ::= { 3077 contingency-public-key-decrypt-key, 3078 ... -- Expect additional attributes -- 3079 } 3081 -- contingency-public-key-decrypt-key unsigned attribute 3083 contingency-public-key-decrypt-key ATTRIBUTE ::= { 3084 TYPE PlaintextSymmetricKey IDENTIFIED BY 3085 id-aa-TAMP-contingencyPublicKeyDecryptKey } 3087 id-aa-TAMP-contingencyPublicKeyDecryptKey OBJECT IDENTIFIER ::= { 3088 id-attributes 63 } 3090 PlaintextSymmetricKey ::= OCTET STRING 3091 -- id-pe-wrappedApexContinKey extension 3093 wrappedApexContinKey EXTENSION ::= { 3094 SYNTAX ApexContingencyKey 3095 IDENTIFIED BY id-pe-wrappedApexContinKey } 3097 id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::= 3098 { iso(1) identified-organization(3) dod(6) internet(1) 3099 security(5) mechanisms(5) pkix(7) pe(1) 20 } 3101 ApexContingencyKey ::= SEQUENCE { 3102 wrapAlgorithm AlgorithmIdentifier{{SupportedWrapAlgorithms}}, 3103 wrappedContinPubKey OCTET STRING } 3105 END 3107 A.2. ASN.1 Module Using 1988 Syntax 3109 TAMP-Protocol-v2-88 3110 { joint-iso-ccitt(2) country(16) us(840) organization(1) 3111 gov(101) dod(2) infosec(1) modules(0) 31 } 3113 DEFINITIONS IMPLICIT TAGS ::= 3114 BEGIN 3116 IMPORTS 3117 TrustAnchorChoice, TrustAnchorTitle, CertPathControls 3118 FROM TrustAnchorInfoModule-88 -- from [I-D.ietf-pkix-ta-format] 3119 { joint-iso-ccitt(2) country(16) us(840) organization(1) 3120 gov(101) dod(2) infosec(1) modules(0) 33 } 3121 AlgorithmIdentifier, Certificate, Name, Attribute, TBSCertificate, 3122 SubjectPublicKeyInfo, CertificateSerialNumber, Validity 3123 FROM PKIX1Explicit88 -- from [RFC5280] 3124 { iso(1) identified-organization(3) dod(6) internet(1) 3125 security(5) mechanisms(5) pkix(7) id-mod(0) 3126 id-pkix1-explicit(18) } 3127 KeyIdentifier, AnotherName 3128 FROM PKIX1Implicit88 -- from [RFC5280] 3129 { iso(1) identified-organization(3) dod(6) internet(1) 3130 security(5) mechanisms(5) pkix(7) id-mod(0) 3131 id-pkix1-implicit(19) } ; 3133 -- Object Identifier Arc for TAMP Message Content Types 3135 id-tamp OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) 3136 us(840) organization(1) gov(101) dod(2) infosec(1) formats(2) 77 } 3138 -- CMS Content Types 3140 -- TAMP Status Query Message 3142 id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 } 3144 TAMPStatusQuery ::= SEQUENCE { 3145 version [0] TAMPVersion DEFAULT v2, 3146 terse [1] TerseOrVerbose DEFAULT verbose, 3147 query TAMPMsgRef } 3149 TAMPVersion ::= INTEGER { v1(1), v2(2) } 3151 TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) } 3153 SeqNumber ::= INTEGER (0..9223372036854775807) 3155 TAMPMsgRef ::= SEQUENCE { 3156 target TargetIdentifier, 3157 seqNum SeqNumber } 3159 TargetIdentifier ::= CHOICE { 3160 hwModules [1] HardwareModuleIdentifierList, 3161 communities [2] CommunityIdentifierList, 3162 allModules [3] NULL, 3163 uri [4] IA5String, 3164 otherName [5] AnotherName} 3166 HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF 3167 HardwareModules 3169 HardwareModules ::= SEQUENCE { 3170 hwType OBJECT IDENTIFIER, 3171 hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry } 3173 HardwareSerialEntry ::= CHOICE { 3174 all NULL, 3175 single OCTET STRING, 3176 block SEQUENCE { 3177 low OCTET STRING, 3178 high OCTET STRING } } 3180 CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community 3182 Community ::= OBJECT IDENTIFIER 3183 -- TAMP Status Response Message 3185 id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 } 3187 TAMPStatusResponse ::= SEQUENCE { 3188 version [0] TAMPVersion DEFAULT v2, 3189 query TAMPMsgRef, 3190 response StatusResponse, 3191 usesApex BOOLEAN DEFAULT TRUE} 3193 StatusResponse ::= CHOICE { 3194 terseResponse [0] TerseStatusResponse, 3195 verboseResponse [1] VerboseStatusResponse } 3197 TerseStatusResponse ::= SEQUENCE { 3198 taKeyIds KeyIdentifiers, 3199 communities CommunityIdentifierList OPTIONAL } 3201 KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier 3203 VerboseStatusResponse ::= SEQUENCE { 3204 taInfo TrustAnchorChoiceList, 3205 continPubKeyDecryptAlg [0] AlgorithmIdentifier OPTIONAL, 3206 communities [1] CommunityIdentifierList OPTIONAL, 3207 tampSeqNumbers [2] TAMPSequenceNumbers OPTIONAL } 3209 TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF 3210 TrustAnchorChoice 3212 TAMPSequenceNumber ::= SEQUENCE { 3213 keyId KeyIdentifier, 3214 seqNumber SeqNumber } 3216 TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF 3217 TAMPSequenceNumber 3219 -- Trust Anchor Update Message 3221 id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 } 3223 TAMPUpdate ::= SEQUENCE { 3224 version [0] TAMPVersion DEFAULT v2, 3225 terse [1] TerseOrVerbose DEFAULT verbose, 3226 msgRef TAMPMsgRef, 3227 updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate, 3228 tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL } 3230 TrustAnchorUpdate ::= CHOICE { 3231 add [1] TrustAnchorChoice, 3232 remove [2] SubjectPublicKeyInfo, 3233 change [3] EXPLICIT TrustAnchorChangeInfoChoice } 3235 TrustAnchorChangeInfoChoice ::= CHOICE { 3236 tbsCertChange [0] TBSCertificateChangeInfo, 3237 taChange [1] TrustAnchorChangeInfo } 3239 TBSCertificateChangeInfo ::= SEQUENCE { 3240 serialNumber CertificateSerialNumber OPTIONAL, 3241 signature [0] AlgorithmIdentifier OPTIONAL, 3242 issuer [1] Name OPTIONAL, 3243 validity [2] Validity OPTIONAL, 3244 subject [3] Name OPTIONAL, 3245 subjectPublicKeyInfo [4] SubjectPublicKeyInfo, 3246 exts [5] EXPLICIT Extensions OPTIONAL } 3248 TrustAnchorChangeInfo ::= SEQUENCE { 3249 pubKey SubjectPublicKeyInfo, 3250 keyId KeyIdentifier OPTIONAL, 3251 taTitle TrustAnchorTitle OPTIONAL, 3252 certPath CertPathControls OPTIONAL, 3253 exts [1] Extensions OPTIONAL} 3255 -- Trust Anchor Update Confirm Message 3257 id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 } 3259 TAMPUpdateConfirm ::= SEQUENCE { 3260 version [0] TAMPVersion DEFAULT v2, 3261 update TAMPMsgRef, 3262 confirm UpdateConfirm } 3264 UpdateConfirm ::= CHOICE { 3265 terseConfirm [0] TerseUpdateConfirm, 3266 verboseConfirm [1] VerboseUpdateConfirm } 3268 TerseUpdateConfirm ::= StatusCodeList 3270 StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode 3272 VerboseUpdateConfirm ::= SEQUENCE { 3273 status StatusCodeList, 3274 taInfo TrustAnchorChoiceList, 3275 tampSeqNumbers TAMPSequenceNumbers OPTIONAL, 3276 usesApex BOOLEAN DEFAULT TRUE} 3278 -- Apex Trust Anchor Update Message 3280 id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 } 3282 TAMPApexUpdate ::= SEQUENCE { 3283 version [0] TAMPVersion DEFAULT v2, 3284 terse [1] TerseOrVerbose DEFAULT verbose, 3285 msgRef TAMPMsgRef, 3286 clearTrustAnchors BOOLEAN, 3287 clearCommunities BOOLEAN, 3288 seqNumber SeqNumber OPTIONAL, 3289 apexTA TrustAnchorChoice } 3291 -- Apex Trust Anchor Update Confirm Message 3293 id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 } 3295 TAMPApexUpdateConfirm ::= SEQUENCE { 3296 version [0] TAMPVersion DEFAULT v2, 3297 apexReplace TAMPMsgRef, 3298 apexConfirm ApexUpdateConfirm } 3300 ApexUpdateConfirm ::= CHOICE { 3301 terseApexConfirm [0] TerseApexUpdateConfirm, 3302 verboseApexConfirm [1] VerboseApexUpdateConfirm } 3304 TerseApexUpdateConfirm ::= StatusCode 3306 VerboseApexUpdateConfirm ::= SEQUENCE { 3307 status StatusCode, 3308 taInfo TrustAnchorChoiceList, 3309 communities [0] CommunityIdentifierList OPTIONAL, 3310 tampSeqNumbers [1] TAMPSequenceNumbers OPTIONAL } 3312 -- Community Update Message 3314 id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 } 3316 TAMPCommunityUpdate ::= SEQUENCE { 3317 version [0] TAMPVersion DEFAULT v2, 3318 terse [1] TerseOrVerbose DEFAULT verbose, 3319 msgRef TAMPMsgRef, 3320 updates CommunityUpdates } 3322 CommunityUpdates ::= SEQUENCE { 3323 remove [1] CommunityIdentifierList OPTIONAL, 3324 add [2] CommunityIdentifierList OPTIONAL } 3325 -- At least one must be present 3327 -- Community Update Confirm Message 3329 id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 8 } 3331 TAMPCommunityUpdateConfirm ::= SEQUENCE { 3332 version [0] TAMPVersion DEFAULT v2, 3333 update TAMPMsgRef, 3334 commConfirm CommunityConfirm } 3336 CommunityConfirm ::= CHOICE { 3337 terseCommConfirm [0] TerseCommunityConfirm, 3338 verboseCommConfirm [1] VerboseCommunityConfirm } 3340 TerseCommunityConfirm ::= StatusCode 3342 VerboseCommunityConfirm ::= SEQUENCE { 3343 status StatusCode, 3344 communities CommunityIdentifierList OPTIONAL } 3346 -- Sequence Number Adjust Message 3348 id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 } 3350 SequenceNumberAdjust ::= SEQUENCE { 3351 version [0] TAMPVersion DEFAULT v2, 3352 msgRef TAMPMsgRef } 3354 -- Sequence Number Adjust Message 3356 id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= { id-tamp 11 } 3358 SequenceNumberAdjustConfirm ::= SEQUENCE { 3359 version [0] TAMPVersion DEFAULT v2, 3360 adjust TAMPMsgRef, 3361 status StatusCode } 3363 -- TAMP Error Message 3365 id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 } 3367 TAMPError ::= SEQUENCE { 3368 version [0] TAMPVersion DEFAULT v2, 3369 msgType OBJECT IDENTIFIER, 3370 status StatusCode, 3371 msgRef TAMPMsgRef OPTIONAL } 3373 -- Status Codes 3375 StatusCode ::= ENUMERATED { 3376 success (0), 3377 decodeFailure (1), 3378 badContentInfo (2), 3379 badSignedData (3), 3380 badEncapContent (4), 3381 badCertificate (5), 3382 badSignerInfo (6), 3383 badSignedAttrs (7), 3384 badUnsignedAttrs (8), 3385 missingContent (9), 3386 noTrustAnchor (10), 3387 notAuthorized (11), 3388 badDigestAlgorithm (12), 3389 badSignatureAlgorithm (13), 3390 unsupportedKeySize (14), 3391 unsupportedParameters (15), 3392 signatureFailure (16), 3393 insufficientMemory (17), 3394 unsupportedTAMPMsgType (18), 3395 apexTAMPAnchor (19), 3396 improperTAAddition (20), 3397 seqNumFailure (21), 3398 contingencyPublicKeyDecrypt (22), 3399 incorrectTarget (23), 3400 communityUpdateFailed (24), 3401 trustAnchorNotFound (25), 3402 unsupportedTAAlgorithm (26), 3403 unsupportedTAKeySize (27), 3404 unsupportedContinPubKeyDecryptAlg (28), 3405 missingSignature (29), 3406 resourcesBusy (30), 3407 versionNumberMismatch (31), 3408 missingPolicySet (32), 3409 revokedCertificate (33), 3410 unsupportedTrustAnchorFormat (34), 3411 other (127) } 3413 -- Object Identifier Arc for Attributes 3415 id-attributes OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) 3416 us(840) organization(1) gov(101) dod(2) infosec(1) 5 } 3418 -- id-aa-TAMP-contingencyPublicKeyDecryptKey uses 3419 -- PlaintextSymmetricKey syntax 3420 id-aa-TAMP-contingencyPublicKeyDecryptKey OBJECT IDENTIFIER ::= { 3421 id-attributes 63 } 3423 PlaintextSymmetricKey ::= OCTET STRING 3425 -- id-pe-wrappedApexContinKey extension 3427 id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::= 3428 { iso(1) identified-organization(3) dod(6) internet(1) 3429 security(5) mechanisms(5) pkix(7) pe(1) 20 } 3431 ApexContingencyKey ::= SEQUENCE { 3432 wrapAlgorithm AlgorithmIdentifier, 3433 wrappedContinPubKey OCTET STRING } 3435 END 3437 Appendix B. MIME Media Type Registrations 3439 Eleven MIME media type registrations are provided in this appendix. 3441 B.1. application/tamp-status-query 3443 To: ietf-types@iana.org 3445 Subject: Registration of MIME media type application/ 3446 tamp-status-query 3448 MIME media type name: application 3450 MIME subtype name: tamp-status-query 3452 Required parameters: None 3454 Optional parameters: None 3456 Encoding considerations: Binary 3458 Security considerations: Carries a request for status information. 3460 Interoperability considerations: None 3462 Published specification: TBD 3464 Applications that use this media type: TAMP clients responding to 3465 requests for status information. 3467 Additional information: 3469 Magic number(s): None 3471 File extension(s): .TSQ 3473 Macintosh File Type Code(s): none 3475 Person & email address to contact for further information: 3477 Sam Ashmore - srashmo@radium.ncsc.mil 3479 Intended usage: COMMON 3481 Restrictions on usage: None 3483 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3484 Change controller: IESG 3486 B.2. application/tamp-status-response 3488 To: ietf-types@iana.org 3490 Subject: Registration of MIME media type application/ 3491 tamp-status-response 3493 MIME media type name: application 3495 MIME subtype name: tamp-status-response 3497 Required parameters: None 3499 Optional parameters: None 3501 Encoding considerations: Binary 3503 Security considerations: Carries status information. 3505 Interoperability considerations: None 3507 Published specification: TBD 3509 Applications that use this media type: TAMP clients responding to 3510 requests for status information. 3512 Additional information: 3514 Magic number(s): None 3516 File extension(s): .TSR 3518 Macintosh File Type Code(s): none 3520 Person & email address to contact for further information: 3522 Sam Ashmore - srashmo@radium.ncsc.mil 3524 Intended usage: COMMON 3526 Restrictions on usage: None 3528 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3530 Change controller: IESG 3532 B.3. application/tamp-update 3534 To: ietf-types@iana.org 3536 Subject: Registration of MIME media type application/tamp-update 3538 MIME media type name: application 3540 MIME subtype name: tamp-update 3542 Required parameters: None 3544 Optional parameters: None 3546 Encoding considerations: Binary 3548 Security considerations: Carries a trust anchor update information. 3550 Interoperability considerations: None 3552 Published specification: TBD 3554 Applications that use this media type: TAMP clients responding to 3555 requests to update trust anchor information. 3557 Additional information: 3559 Magic number(s): None 3561 File extension(s): .TUR 3563 Macintosh File Type Code(s): none 3565 Person & email address to contact for further information: 3567 Sam Ashmore - srashmo@radium.ncsc.mil 3569 Intended usage: COMMON 3571 Restrictions on usage: None 3573 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3575 Change controller: IESG 3577 B.4. application/tamp-update-confirm 3579 To: ietf-types@iana.org 3581 Subject: Registration of MIME media type application/ 3582 tamp-update-confirm 3584 MIME media type name: application 3586 MIME subtype name: tamp-update-confirm 3588 Required parameters: None 3590 Optional parameters: None 3592 Encoding considerations: Binary 3594 Security considerations: Carries a results of TAMP update processing. 3596 Interoperability considerations: None 3598 Published specification: TBD 3600 Applications that use this media type: TAMP clients responding to 3601 requests to update trust anchor information 3603 Additional information: 3605 Magic number(s): None 3607 File extension(s): .TUC 3609 Macintosh File Type Code(s): none 3611 Person & email address to contact for further information: 3613 Sam Ashmore - srashmo@radium.ncsc.mil 3615 Intended usage: COMMON 3617 Restrictions on usage: None 3619 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3621 Change controller: IESG 3623 B.5. application/tamp-apex-update 3625 To: ietf-types@iana.org 3627 Subject: Registration of MIME media type application/tamp-apex-update 3629 MIME media type name: application 3631 MIME subtype name: tamp-apex-update 3633 Required parameters: None 3635 Optional parameters: None 3637 Encoding considerations: Binary 3639 Security considerations: Carries a request to update an apex trust 3640 anchor information. 3642 Interoperability considerations: None 3644 Published specification: TBD 3646 Applications that use this media type: TAMP clients responding to 3647 requests to update an apex trust anchor. 3649 Additional information: 3651 Magic number(s): None 3653 File extension(s): .TAU 3655 Macintosh File Type Code(s): none 3657 Person & email address to contact for further information: 3659 Sam Ashmore - srashmo@radium.ncsc.mil 3661 Intended usage: COMMON 3663 Restrictions on usage: None 3665 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3667 Change controller: IESG 3669 B.6. application/tamp-apex-update-confirm 3671 To: ietf-types@iana.org 3673 Subject: Registration of MIME media type application/ 3674 tamp-apex-update-confirm 3676 MIME media type name: application 3678 MIME subtype name: tamp-apex-update-confirm 3680 Required parameters: None 3682 Optional parameters: None 3684 Encoding considerations: Binary 3686 Security considerations: Carries a response to an apex update 3687 request. 3689 Interoperability considerations: None 3691 Published specification: TBD 3693 Applications that use this media type: TAMP clients responding to 3694 requests to update an apex trust anchor. 3696 Additional information: 3698 Magic number(s): None 3700 File extension(s): .AUC 3702 Macintosh File Type Code(s): none 3704 Person & email address to contact for further information: 3706 Sam Ashmore - srashmo@radium.ncsc.mil 3708 Intended usage: COMMON 3710 Restrictions on usage: None 3712 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3714 Change controller: IESG 3716 B.7. application/tamp-community-update 3718 To: ietf-types@iana.org 3720 Subject: Registration of MIME media type application/ 3721 tamp-community-update 3723 MIME media type name: application 3725 MIME subtype name: tamp-community-update 3727 Required parameters: None 3729 Optional parameters: None 3731 Encoding considerations: Binary 3733 Security considerations: Carries a request to update community 3734 membership information. 3736 Interoperability considerations: None 3738 Published specification: TBD 3740 Applications that use this media type: TAMP clients responding to 3741 requests to update community membership. 3743 Additional information: 3745 Magic number(s): None 3747 File extension(s): .TCU 3749 Macintosh File Type Code(s): none 3751 Person & email address to contact for further information: 3753 Sam Ashmore - srashmo@radium.ncsc.mil 3755 Intended usage: COMMON 3757 Restrictions on usage: None 3759 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3761 Change controller: IESG 3763 B.8. application/tamp-community-update-confirm 3765 To: ietf-types@iana.org 3767 Subject: Registration of MIME media type application/ 3768 tamp-community-update-confirm 3770 MIME media type name: application 3772 MIME subtype name: tamp-community-update-confirm 3774 Required parameters: None 3776 Optional parameters: None 3778 Encoding considerations: Binary 3780 Security considerations: Carries a response to a community update 3781 request. 3783 Interoperability considerations: None 3785 Published specification: TBD 3787 Applications that use this media type: TAMP clients responding to 3788 requests to update community membership. 3790 Additional information: 3792 Magic number(s): None 3794 File extension(s): .CUC 3796 Macintosh File Type Code(s): none 3798 Person & email address to contact for further information: 3800 Sam Ashmore - srashmo@radium.ncsc.mil 3802 Intended usage: COMMON 3804 Restrictions on usage: None 3806 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3808 Change controller: IESG 3810 B.9. application/tamp-sequence-adjust 3812 To: ietf-types@iana.org 3814 Subject: Registration of MIME media type application/ 3815 tamp-sequence-adjust 3817 MIME media type name: application 3819 MIME subtype name: tamp-sequence-adjust 3821 Required parameters: None 3823 Optional parameters: None 3825 Encoding considerations: Binary 3827 Security considerations: Carries a request to update sequence number 3828 information. 3830 Interoperability considerations: None 3832 Published specification: TBD 3834 Applications that use this media type: TAMP clients responding to 3835 requests to update sequence number information. 3837 Additional information: 3839 Magic number(s): None 3841 File extension(s): .TSA 3843 Macintosh File Type Code(s): none 3845 Person & email address to contact for further information: 3847 Sam Ashmore - srashmo@radium.ncsc.mil 3849 Intended usage: COMMON 3851 Restrictions on usage: None 3853 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3855 Change controller: IESG 3857 B.10. application/tamp-sequence-adjust-confirm 3859 To: ietf-types@iana.org 3861 Subject: Registration of MIME media type application/ 3862 tamp-sequence-adjust-confirm 3864 MIME media type name: application 3866 MIME subtype name: tamp-sequence-adjust-confirm 3868 Required parameters: None 3870 Optional parameters: None 3872 Encoding considerations: Binary 3874 Security considerations: Carries a request for status information. 3876 Interoperability considerations: None 3878 Published specification: TBD 3880 Applications that use this media type: TAMP clients responding to 3881 requests to update sequence number information. 3883 Additional information: 3885 Magic number(s): None 3887 File extension(s): .SAC 3889 Macintosh File Type Code(s): none 3891 Person & email address to contact for further information: 3893 Sam Ashmore - srashmo@radium.ncsc.mil 3895 Intended usage: COMMON 3897 Restrictions on usage: None 3899 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3901 Change controller: IESG 3903 B.11. application/tamp-error 3905 To: ietf-types@iana.org 3907 Subject: Registration of MIME media type application/tamp-error 3909 MIME media type name: application 3911 MIME subtype name: tamp-error 3913 Required parameters: None 3915 Optional parameters: None 3917 Encoding considerations: Binary 3919 Security considerations: Carries a error information collecting 3920 during TAMP processing. 3922 Interoperability considerations: None 3924 Published specification: TBD 3926 Applications that use this media type: TAMP clients processing TAMP 3927 messages. 3929 Additional information: 3931 Magic number(s): None 3933 File extension(s): .TER 3935 Macintosh File Type Code(s): none 3937 Person & email address to contact for further information: 3939 Sam Ashmore - srashmo@radium.ncsc.mil 3941 Intended usage: COMMON 3943 Restrictions on usage: None 3945 Author: Sam Ashmore - srashmo@radium.ncsc.mil 3947 Change controller: IESG 3949 Appendix C. TAMP Over HTTP 3951 This appendix describes the formatting and transportation conventions 3952 for the TAMP messages when carried by HTTP [RFC2616]. In order for 3953 TAMP clients and servers using HTTP to interoperate, the following 3954 rules apply. 3956 o Clients MUST use the POST method to submit their requests. 3958 o Servers MUST use the 200 response code for successful responses. 3960 o Clients MAY attempt to send HTTPS requests using TLS 1.0 or later, 3961 although servers are not required to support TLS. 3963 o Servers MUST NOT assume client support for any type of HTTP 3964 authentication such as cookies, Basic authentication, or Digest 3965 authentication. 3967 o Clients and servers are expected to follow the other rules and 3968 restrictions in [RFC2616]. Note that some of those rules are for 3969 HTTP methods other than POST; clearly, only the rules that apply 3970 to POST are relevant for this specification. 3972 C.1. TAMP Status Query Message 3974 A TAMP Status Query Message using the POST method is constructed as 3975 follows: The Content-Type header MUST have the value "application/ 3976 tamp-status-query". 3978 The body of the message is the binary value of the DER encoding of 3979 the TAMPStatusQuery, wrapped in a CMS body as described in Section 2. 3981 C.2. TAMP Status Response Message 3983 An HTTP-based TAMP Status Response message is composed of the 3984 appropriate HTTP headers, followed by the binary value of the DER 3985 encoding of the TAMPStatusResponse, wrapped in a CMS body as 3986 described in Section 2. 3988 The Content-Type header MUST have the value "application/ 3989 tamp-status-response." 3991 C.3. Trust Anchor Update Message 3993 A Trust Anchor Update Message using the POST method is constructed as 3994 follows: The Content-Type header MUST have the value "application/ 3995 tamp-update". 3997 The body of the message is the binary value of the DER encoding of 3998 the TAMPUpdate, wrapped in a CMS body as described in Section 2. 4000 C.4. Trust Anchor Update Confirm Message 4002 An HTTP-based Trust Anchor Update Confirm message is composed of the 4003 appropriate HTTP headers, followed by the binary value of the DER 4004 encoding of the TAMPUpdateConfirm, wrapped in a CMS body as described 4005 in Section 2. 4007 The Content-Type header MUST have the value "application/ 4008 tamp-update-confirm". 4010 C.5. Apex Trust Anchor Update Message 4012 An Apex Trust Anchor Update Message using the POST method is 4013 constructed as follows: The Content-Type header MUST have the value 4014 "application/tamp-apex-update". 4016 The body of the message is the binary value of the DER encoding of 4017 the TAMPApexUpdate, wrapped in a CMS body as described in Section 2. 4019 C.6. Apex Trust Anchor Update Confirm Message 4021 An HTTP-based Apex Trust Anchor Update Confirm message is composed of 4022 the appropriate HTTP headers, followed by the binary value of the DER 4023 encoding of the TAMPApexUpdateConfirm, wrapped in a CMS body as 4024 described in Section 2. 4026 The Content-Type header MUST have the value "application/ 4027 tamp-apex-update-confirm". 4029 C.7. Community Update Message 4031 A Community Update Message using the POST method is constructed as 4032 follows: The Content-Type header MUST have the value "application/ 4033 tamp-community-update". 4035 The body of the message is the binary value of the DER encoding of 4036 the TAMPCommunityUpdate, wrapped in a CMS body as described in 4037 Section 2. 4039 C.8. Community Update Confirm Message 4041 An HTTP-based Community Update Confirm message is composed of the 4042 appropriate HTTP headers, followed by the binary value of the DER 4043 encoding of the TAMPCommunityUpdateConfirm, wrapped in a CMS body as 4044 described in Section 2. 4046 The Content-Type header MUST have the value "application/ 4047 tamp-community-update-confirm". 4049 C.9. Sequence Number Adjust Message 4051 A Sequence Number Adjust Message using the POST method is constructed 4052 as follows: The Content-Type header MUST have the value "application/ 4053 tamp-sequence-adjust". 4055 The body of the message is the binary value of the DER encoding of 4056 the SequenceNumberAdjust, wrapped in a CMS body as described in 4057 Section 2. 4059 C.10. Sequence Number Adjust Confirm Message 4061 An HTTP-based Sequence Number Adjust Confirm message is composed of 4062 the appropriate HTTP headers, followed by the binary value of the DER 4063 encoding of the SequenceNumberAdjustConfirm, wrapped in a CMS body as 4064 described in Section 2. 4066 The Content-Type header MUST have the value "application/ 4067 tamp-sequence-adjust-confirm". 4069 C.11. TAMP Error Message 4071 An HTTP-based TAMP Error message is composed of the appropriate HTTP 4072 headers, followed by the binary value of the DER encoding of the 4073 TAMPError, wrapped in a CMS body as described in Section 2. 4075 Authors' Addresses 4077 Russ Housley 4078 Vigil Security, LLC 4079 918 Spring Knoll Drive 4080 Herndon, VA 20170 4082 Email: housley@vigilsec.com 4084 Sam Ashmore 4085 National Security Agency 4086 Suite 6751 4087 9800 Savage Road 4088 Fort Meade, MD 20755 4090 Email: srashmo@radium.ncsc.mil 4092 Carl Wallace 4093 Cygnacom Solutions 4094 Suite 5200 4095 7925 Jones Branch Drive 4096 McLean, VA 22102 4098 Email: cwallace@cygnacom.com