idnits 2.17.1 draft-housley-tamp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3791. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3802. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3815. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 4, 2007) is 6048 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: '0' on line 3696 -- Looks like a reference, but probably isn't: '1' on line 3665 -- Looks like a reference, but probably isn't: '2' on line 3651 -- Looks like a reference, but probably isn't: '3' on line 3578 -- Looks like a reference, but probably isn't: '4' on line 3486 -- Possible downref: Non-RFC (?) normative reference: ref. 'CCC' -- Possible downref: Non-RFC (?) normative reference: ref. 'ClearConstr' ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4049 (Obsoleted by RFC 6019) -- Obsolete informational reference (is this intentional?): RFC 3281 (Obsoleted by RFC 5755) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 15 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 R. Reddy 5 Expires: April 6, 2008 National Security Agency 6 C. Wallace 7 Cygnacom Solutions 8 October 4, 2007 10 Trust Anchor Management Protocol (TAMP) 11 draft-housley-tamp-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 6, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes a transport independent, request-response 45 protocol for the management of trust anchors and community 46 identifiers stored in a device. The protocol makes use of the 47 Cryptographic Message Syntax (CMS), and a digital signature is used 48 to provide integrity protection and data origin authentication. Each 49 trust anchor is associated with a list of functions within devices 50 that make use of digital signature mechanisms. Digital signatures 51 can be validated directly with the public key associated with the 52 trust anchor, or they can be validated with a certified public key 53 whose X.509 certification path terminates with the trust anchor 54 public key. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2.1. Apex Trust Anchors . . . . . . . . . . . . . . . . . . 5 62 1.2.2. Management Trust Anchors . . . . . . . . . . . . . . . 6 63 1.2.3. Identity Trust Anchors . . . . . . . . . . . . . . . . 7 64 1.3. Architectural Elements . . . . . . . . . . . . . . . . . . 7 65 1.3.1. Cryptographic Module . . . . . . . . . . . . . . . . . 7 66 1.3.2. TAMP Protocol Processing Dependencies . . . . . . . . 8 67 1.3.3. Application-Specific Protocol Processing . . . . . . . 9 68 1.4. ASN.1 Encoding . . . . . . . . . . . . . . . . . . . . . . 10 69 2. Cryptographic Message Syntax Profile . . . . . . . . . . . . . 12 70 2.1. Content Info . . . . . . . . . . . . . . . . . . . . . . . 13 71 2.2. SignedData Info . . . . . . . . . . . . . . . . . . . . . 13 72 2.2.1. SignerInfo . . . . . . . . . . . . . . . . . . . . . . 14 73 2.2.2. EncapsulatedContentInfo . . . . . . . . . . . . . . . 16 74 2.2.3. Signed Attributes . . . . . . . . . . . . . . . . . . 16 75 2.2.4. Unsigned Attributes . . . . . . . . . . . . . . . . . 19 76 3. Trust Anchor Information Syntax . . . . . . . . . . . . . . . 21 77 4. Trust Anchor Management Protocol Messages . . . . . . . . . . 30 78 4.1. TAMP Status Query . . . . . . . . . . . . . . . . . . . . 31 79 4.2. TAMP Status Query Response . . . . . . . . . . . . . . . . 35 80 4.3. Trust Anchor Update . . . . . . . . . . . . . . . . . . . 37 81 4.4. Trust Anchor Update Confirm . . . . . . . . . . . . . . . 41 82 4.5. Apex Trust Anchor Update . . . . . . . . . . . . . . . . . 43 83 4.6. Apex Trust Anchor Update Confirm . . . . . . . . . . . . . 46 84 4.7. Community Update . . . . . . . . . . . . . . . . . . . . . 47 85 4.8. Community Update Confirm . . . . . . . . . . . . . . . . . 49 86 4.9. Sequence Number Adjust . . . . . . . . . . . . . . . . . . 51 87 4.10. Sequence Number Adjust Confirm . . . . . . . . . . . . . . 52 88 4.11. TAMP Error . . . . . . . . . . . . . . . . . . . . . . . . 53 89 5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . 55 90 6. Sequence Number Processing . . . . . . . . . . . . . . . . . . 60 91 7. Subordination Processing . . . . . . . . . . . . . . . . . . . 62 92 8. Implementation Considerations . . . . . . . . . . . . . . . . 65 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 66 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 96 11.1. Normative References . . . . . . . . . . . . . . . . . . . 70 97 11.2. Informative References . . . . . . . . . . . . . . . . . . 70 98 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 72 99 A.1. ASN.1 Module Using 1993 Syntax . . . . . . . . . . . . . . 72 100 A.2. ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . 81 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90 102 Intellectual Property and Copyright Statements . . . . . . . . . . 91 104 1. Introduction 106 This document describes the Trust Anchor Management Protocol (TAMP). 107 TAMP may be used to manage the trust anchors and community 108 identifiers in any device that uses digital signatures; however, this 109 specification was written with the requirements of cryptographic 110 modules in mind. For example, TAMP can support signed firmware 111 packages, where the trust anchor public key can be used to validate 112 digital signatures on firmware packages or validate the X.509 113 certification path [RFC3280][X.509] of the firmware package signer 114 [RFC4108]. 116 Most TAMP messages are digitally signed to provide integrity 117 protection and data origin authentication. Both signed and unsigned 118 TAMP messages employ the Cryptographic Message Syntax (CMS) 119 [RFC3852]. The CMS is a data protection encapsulation syntax that 120 makes use of ASN.1 [X.680]. 122 This specification does not provide for confidentiality of TAMP 123 messages. If confidentiality is required, then the communications 124 environment that is used to transfer TAMP messages must provide it. 126 1.1. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 1.2. Trust Anchors 134 TAMP manages trust anchors, but TAMP does not dictate a particular 135 structure for the storage of trust anchor information in 136 cryptographic modules. A trust anchor contains a public key that is 137 used to validate digital signatures. 139 There are three types of trust anchors: apex trust anchors, 140 management trust anchors, and identity trust anchors. 142 All trust anchors, regardless of their type, are named by the public 143 key, and all trust anchors consist of the following components: 145 o A public key signature algorithm identifier and associated public 146 key, which MAY include parameters 148 o A public key identifier 150 o An OPTIONAL human readable trust anchor title 151 o OPTIONAL X.509 certification path controls 153 The apex trust anchor and management trust anchors that issue TAMP 154 messages also include a sequence number for replay detection. 156 The public key is used to name a trust anchor, and the public key 157 identifier is used to identify the trust anchor as the signer. This 158 public key identifier can be stored with the trust anchor, or in most 159 public key identifier assignment methods, it can be computed from the 160 public key whenever needed. The trust anchor X.500 distinguished 161 name within the OPTIONAL X.509 certification path controls is used 162 when the trust anchor public key is used to validate an X.509 163 certification path. In this case, the certificate subject is the 164 signer. Use of an X.509 certification path represents delegation, 165 and delegation is possible only when the trust anchor configuration 166 includes an X.500 distinguished name. 168 A trust anchor public key can be used in two different ways to 169 support digital signature validation. In the first approach, the 170 trust anchor public key is used directly to validate the digital 171 signature. In the second approach, the trust anchor public key is 172 used to validate an X.509 certification path, and then the subject 173 public key in the final certificate in the certification path is used 174 to validate the digital signature. When the second approach is 175 employed, the certified public key can be used for things other than 176 digital signature validation; the other possible actions are 177 constrained by the key usage certificate extension. Cryptographic 178 modules MUST support validation of X.509 certificates that are 179 directly signed by a trust anchor; however, support for longer 180 certification paths is RECOMMENDED. The CMS provides a location to 181 carry X.509 certificates, and this facility can be used to transfer 182 certificates to aid in the construction of the certification path. 184 1.2.1. Apex Trust Anchors 186 Within the context of a single cryptographic module, one trust anchor 187 is superior to all others. This trust anchor is referred to as the 188 apex trust anchor. This trust anchor represents the ultimate 189 authority over the cryptographic module. The ultimate authority 190 could be the legal owner of the device in a commercial setting. Much 191 of this authority can be delegated to other trust anchors. 193 The apex trust anchor private key is expected to be controlled by an 194 entity with information assurance responsibility for the 195 cryptographic module. The apex trust anchor is by definition 196 unconstrained and therefore does not have explicit authorization 197 information associated with it. In order to make processing of 198 messages as uniform as possible, the apex has an implicit OID 199 associated with it that represents the special anyContentType value. 200 This OID will be used as input to processing algorithms to represent 201 the apex trust anchor authorization. 203 Due to the special nature of the apex trust anchor, TAMP includes 204 separate facilities to change it. In particular, TAMP includes a 205 facility to securely replace the apex trust anchor. This action 206 might be taken for one or more of the following reasons: 208 o The crypto period for the apex trust anchor public/private key 209 pair has come to an end 211 o The apex trust anchor private key is no longer available 213 o The apex trust anchor public/private key pair needs to be revoked 215 o The authority has decided to use a different digital signature 216 algorithm or the same digital signature algorithm with different 217 parameters, such as a different elliptic curve 219 o The authority has decided to use a different key size 221 o The authority has decided to transfer control to another authority 223 To accommodate these requirements, the apex trust anchor has a 224 different structure than other trust anchors; it includes two public 225 keys. Whenever the apex trust anchor is updated, both public keys 226 are replaced. The first public key, called the operational public 227 key, is used in the same manner as other trust anchors. Any type of 228 TAMP message, including an Apex Trust Anchor Update message, can be 229 validated with the operational public key. The second public key, 230 called the contingency public key, can only be used to update the 231 apex trust anchor. The contingency private key SHOULD be used at 232 only one point in time; it is used only to sign an Apex Trust Anchor 233 Update message which results in its own replacement (as well as the 234 replacement of the operational public key). The contingency public 235 key is distributed in encrypted form. When the contingency public 236 key is used to validate an Apex Trust Anchor Update message, the 237 symmetric key needed to decrypt the contingency public key is 238 provided as part of the signed Apex Trust Anchor Update message that 239 is to be verified with the contingency public key. 241 1.2.2. Management Trust Anchors 243 Management trust anchors are used in the management of cryptographic 244 modules. For example, the TAMP messages specified in this document 245 are validated to a management trust anchor. Likewise, a signed 246 firmware package as specified in [RFC4108] is validated to a 247 management trust anchor. 249 Authorization checking is needed for management messages, and these 250 checks are based on the content type of the management message. As a 251 result, management trust anchors include a list of object identifiers 252 (OIDs) that name authorized content types along with OPTIONAL 253 constraints. 255 1.2.3. Identity Trust Anchors 257 Identity trust anchors are used to validate certification paths, and 258 they represent the trust anchor for a public key infrastructure. 259 They are most often used in the validation of certificates associated 260 with non-management applications. 262 1.3. Architectural Elements 264 TAMP does not assume any particular architecture; however, for TAMP 265 to be useful in an architecture, it MUST include a cryptographic 266 module, TAMP protocol processing, and other application-specific 267 protocol processing. 269 A globally unique algorithm identifier MUST be assigned for each one- 270 way hash function, digital signature generation/validation algorithm, 271 and symmetric key unwrapping algorithm that is implemented. To 272 support CMS, an object identifier (OID) is assigned to name a one-way 273 hash function, and another OID is assigned to name each combination 274 of a one-way hash function when used with a digital signature 275 algorithm. Similarly, certificates associate OIDs assigned to public 276 key algorithms with subject public keys, and certificates make use of 277 an OID that names both the one-way hash function and the digital 278 signature algorithm for the certificate issuer digital signature. 280 1.3.1. Cryptographic Module 282 The cryptographic module MUST include the following capabilities: 284 o Each cryptographic module within a family of cryptographic modules 285 (which are generally produced by the same manufacturer) MUST have 286 a unique serial number (with respect to other modules within the 287 same family). The cryptographic module family is represented as 288 an ASN.1 object identifier (OID), and the unique serial number is 289 represented as a string of octets. 291 o Each cryptographic module MUST have the capability to securely 292 store one or more community identifiers. The community identifier 293 is an OID, and it identifies a collection of cryptographic modules 294 that can be the target of a single TAMP message or the intended 295 recipients for a particular firmware package. 297 o The cryptographic module MUST support the secure storage of 298 exactly one apex trust anchor. The cryptographic module SHOULD 299 support the secure storage of at least one additional trust 300 anchor. 302 o The cryptographic module MUST support the secure storage of a 303 digital signature private key to sign TAMP responses and either a 304 certificate containing the associated public key or a certificate 305 designator. In the latter case, the certificate is stored 306 elsewhere but is available to parties that need to validate 307 cryptographic module digital signatures. The designator is a 308 public key identifier. 310 o The cryptographic module MUST support at least one one-way hash 311 function, one digital signature validation algorithm, one digital 312 signature generation algorithm, and one symmetric key unwrapping 313 algorithm. If only one one-way hash function is present, it MUST 314 be consistent with the digital signature validation and digital 315 signature generation algorithms. If only one digital signature 316 validation algorithm is present, it must be consistent with the 317 apex trust anchor operational public key. If only one digital 318 signature generation algorithm is present, it must be consistent 319 with the cryptographic module digital signature private key. 320 These algorithms MUST be available for processing TAMP messages, 321 including the content types defined in [RFC3852], and for 322 validation of X.509 certification paths. 324 1.3.2. TAMP Protocol Processing Dependencies 326 TAMP processing MUST include the following capabilities: 328 o TAMP processing MUST have a means of locating an appropriate trust 329 anchor. Two mechanisms are available. The first mechanism is 330 based on the public key identifier for digital signature 331 verification, and the second mechanism is based on the trust 332 anchor X.500 distinguished name and other X.509 certification path 333 controls for certificate path discovery and validation. The first 334 mechanism MUST be supported, but the second mechanism can also be 335 used. 337 o TAMP processing MUST be able to invoke the digital signature 338 validation algorithm using the public key held in secure storage 339 for trust anchors. 341 o TAMP processing MUST have read and write access to secure storage 342 for sequence numbers associated with each TAMP message source as 343 described in Section 6. 345 o TAMP processing MUST have read and write access to secure storage 346 for trust anchors in order to update them. Update operations 347 include adding trust anchors, removing trust anchors, and 348 modifying trust anchors. Application-specific access controls 349 MUST be securely stored with each management trust anchor as 350 described in Section 1.3.3. 352 o TAMP processing MUST have read access to secure storage for the 353 community membership list to determine whether a targeted message 354 ought to be accepted. 356 o To implement the OPTIONAL community identifier update feature, 357 TAMP processing MUST have read and write access to secure storage 358 for the community membership list. 360 o To generate signed confirmation messages, TAMP processing MUST be 361 able to invoke the digital signature generation algorithm using 362 the cryptographic module digital signature private key, and it 363 MUST have read access to the cryptographic module certificate or 364 its designator. TAMP uses X.509 certificates [RFC3280]. 366 o The TAMP processing MUST have read access to the cryptographic 367 module family identifier, serial number, and community membership 368 list. 370 1.3.3. Application-Specific Protocol Processing 372 The apex trust anchor and management trust anchors managed with TAMP 373 can be used by the TAMP application. Other management applications 374 MAY make use of all three types of trust anchors, but non-management 375 applications SHOULD only make use of identity trust anchors. 377 The application-specific protocol processing MUST be provided the 378 following services: 380 o The application-specific protocol processing MUST have a means of 381 locating an appropriate trust anchor. Two mechanisms are 382 available to applications. The first mechanism is based on the 383 public key identifier for digital signature verification, and the 384 second mechanism is based on the trust anchor X.500 distinguished 385 name and other X.509 certification path controls for certificate 386 path discovery and validation. 388 o The application-specific protocol processing MUST be able to 389 invoke the digital signature validation algorithm using the public 390 key held in secure storage for trust anchors. 392 o The application-specific protocol processing MUST have read access 393 to the content types and any associated constraints held in 394 storage with management trust anchors to make authorization 395 decisions for that application. The authorization decisions apply 396 to the management trust anchor as well as any public key that is 397 validated to the management trust anchor via an X.509 398 certification path. 400 o If the application-specific protocol requires digital signatures 401 on confirmation messages or receipts, then the application- 402 specific protocol processing MUST be able to invoke the digital 403 signature generation algorithm with the cryptographic module 404 digital signature private key and its associated certificate or 405 certificate designator. Digital signature generation MUST be 406 controlled in a manner that ensures that the content type of 407 signed confirmation messages or receipts is appropriate for the 408 application-specific protocol processing. 410 o The application-specific protocol processing MUST have read access 411 to the cryptographic module family identifier, serial number, and 412 community membership list. 414 It is expected that application-specific protocol processing will 415 also include constraints processing. In some applications, 416 management trust anchors could be authorized for a subset of the 417 functionality associated with a particular content type. 419 1.4. ASN.1 Encoding 421 The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is 422 a formal notation used for describing data protocols, regardless of 423 the programming language used by the implementation. Encoding rules 424 describe how the values defined in ASN.1 will be represented for 425 transmission. The Basic Encoding Rules (BER) [X.690] are the most 426 widely employed rule set, but they offer more than one way to 427 represent data structures. For example, definite length encoding and 428 indefinite length encoding are supported. This flexibility is not 429 desirable when digital signatures are used. As a result, the 430 Distinguished Encoding Rules (DER) [X.690] were invented. DER is a 431 subset of BER that ensures a single way to represent a given value. 432 For example, DER always employs definite length encoding. 434 Digitally signed structures MUST be encoded with DER. In other 435 specifications, structures that are not digitally signed do not 436 require DER, but in this specification, DER is REQUIRED for all 437 structures. By always using DER, the TAMP processor will have fewer 438 options to implement. 440 ASN.1 is used throughout the text of the document for illustrative 441 purposes. The authoritative source of ASN.1 for the structures 442 defined in this document is Appendix A. 444 2. Cryptographic Message Syntax Profile 446 TAMP makes use of signed and unsigned messages. The Cryptographic 447 Message Syntax (CMS) is used in both cases. A digital signature is 448 used to protect the message from undetected modification and provide 449 data origin authentication. TAMP makes no general provision for 450 encryption of content. 452 CMS is used to construct a signed TAMP message. The CMS ContentInfo 453 content type MUST always be present, and it MUST encapsulate the CMS 454 SignedData content type. The CMS SignedData content type MUST 455 encapsulate the TAMP message. A unique content type identifier 456 identifies the particular TAMP message. The CMS encapsulation of a 457 signed TAMP message is summarized by: 459 ContentInfo { 460 contentType id-signedData, -- (1.2.840.113549.1.7.2) 461 content SignedData 462 } 464 SignedData { 465 version CMSVersion, -- Always set to 3 466 digestAlgorithms DigestAlgorithmIdentifiers, -- Only one 467 encapContentInfo EncapsulatedContentInfo, 468 certificates CertificateSet, -- OPTIONAL signer certificates 469 crls CertificateRevocationLists, -- OPTIONAL 470 signerInfos SET OF SignerInfo -- Only one 471 } 473 SignerInfo { 474 version CMSVersion, -- Always set to 3 475 sid SignerIdentifier, 476 digestAlgorithm DigestAlgorithmIdentifier, 477 signedAttrs SignedAttributes, 478 -- REQUIRED in TAMP messages 479 signatureAlgorithm SignatureAlgorithmIdentifier, 480 signature SignatureValue, 481 unsignedAttrs UnsignedAttributes -- OPTIONAL; may only be 482 } -- present in Apex Trust 483 -- Anchor Update messages 485 EncapsulatedContentInfo { 486 eContentType OBJECT IDENTIFIER, -- Names TAMP message type 487 eContent OCTET STRING -- Contains TAMP message 488 } 490 When a TAMP message is used to update the apex trust anchor, this 491 same structure is used; however, the digital signature will be 492 validated with either the apex trust anchor operational public key or 493 the contingency public key. When the contingency public key is used, 494 the symmetric key needed to decrypt the previously stored contingency 495 public key is provided as a contingency-public-key-decrypt-key 496 unsigned attribute. Section 4.5 of this document describes the Apex 497 Trust Anchor Update message. 499 CMS is also used to construct an unsigned TAMP message. The CMS 500 ContentInfo structure MUST always be present, and it MUST be the 501 outermost layer of encapsulation. A unique content type identifier 502 identifies the particular TAMP message. The CMS encapsulation of an 503 unsigned TAMP message is summarized by: 505 ContentInfo { 506 contentType OBJECT IDENTIFIER, -- Names TAMP message type 507 content OCTET STRING -- Contains TAMP message 508 } 510 2.1. Content Info 512 CMS requires the outer-most encapsulation to be ContentInfo 513 [RFC3852]. The fields of ContentInfo are used as follows: 515 o contentType indicates the type of the associated content, and for 516 TAMP, the encapsulated type is either SignedData or the content 517 type identifier associated with an unsigned TAMP message. When 518 the id-signedData (1.2.840.113549.1.7.2) object identifier is 519 present in this field, then a signed TAMP message is in the 520 content. Otherwise, an unsigned TAMP message is in the content. 522 o content holds the content, and for TAMP, the content is either a 523 SignedData content or an unsigned TAMP message. 525 2.2. SignedData Info 527 The SignedData content type [RFC3852] contains the signed TAMP 528 message and a digital signature value; the SignedData content type 529 MAY also contain the certificates needed to validate the digital 530 signature. The fields of SignedData are used as follows: 532 o version is the syntax version number, and for TAMP, the version 533 number MUST be set to 3. 535 o digestAlgorithms is a collection of one-way hash function 536 identifiers, and for TAMP, it contains a single one-way hash 537 function identifier. The one-way hash function employed by the 538 TAMP message originator in generating the digital signature MUST 539 be present. 541 o encapContentInfo is the signed content, consisting of a content 542 type identifier and the content itself. The use of the 543 EncapsulatedContentInfo type is discussed further in Section 544 2.2.2. 546 o certificates is an OPTIONAL collection of certificates. It MAY be 547 omitted, or it MAY include the X.509 certificates needed to 548 construct the certification path of the TAMP message originator. 549 For TAMP messages sent to a cryptographic module where an apex 550 trust anchor or management trust anchor is used directly to 551 validate the TAMP message digital signature, this field SHOULD be 552 omitted. When an apex trust anchor or management trust anchor is 553 used to validate an X.509 certification path [RFC3280], and the 554 subject public key from the final certificate in the certification 555 path is used to validate the TAMP message digital signature, the 556 certificate of the TAMP message originator SHOULD be included, and 557 additional certificates to support certification path construction 558 MAY be included. For TAMP messages sent by a cryptographic 559 module, this field SHOULD include only the cryptographic module 560 certificate or be omitted. A TAMP message recipient MUST NOT 561 reject a valid TAMP message that contains certificates that are 562 not needed to validate the digital signature. PKCS#6 extended 563 certificates [PKCS#6] and attribute certificates (either version 1 564 or version 2) [RFC3281] MUST NOT be included in the set of 565 certificates; these certificate formats are not used in TAMP. 566 Certification Authority (CA) certificates and end entity 567 certificates MUST conform to the profiles defined in [RFC3280]. 569 o crls is an OPTIONAL collection of certificate revocation lists 570 (CRLs). 572 o signerInfos is a collection of per-signer information, and for 573 TAMP, the collection MUST contain exactly one SignerInfo. The use 574 of the SignerInfo type is discussed further in Section 2.2.1. 576 2.2.1. SignerInfo 578 The TAMP message originator is represented in the SignerInfo type. 579 The fields of SignerInfo are used as follows: 581 o version is the syntax version number. With TAMP, the version MUST 582 be set to 3. 584 o sid identifies the TAMP message originator's public key. The 585 subjectKeyIdentifier alternative is always used with TAMP, which 586 identifies the public key directly. When an apex trust anchor 587 operational public key or a management trust anchor public key is 588 used directly, this identifier is the keyId from the associated 589 TrustAnchorInfo. When the public key is included in an X.509 590 certificate, this identifier is included in the 591 subjectKeyIdentifier certificate extension. 593 o digestAlgorithm identifies the one-way hash function, and any 594 associated parameters, used by the TAMP message originator. It 595 MUST contain the one-way hash functions employed by the 596 originator. This message digest algorithm identifier MUST match 597 the one carried in the digestAlgorithms field in SignedData. The 598 message digest algorithm identifier is carried in two places to 599 facilitate stream processing by the receiver. 601 o signedAttrs is an OPTIONAL set of attributes that are signed along 602 with the content. The signedAttrs are OPTIONAL in the CMS, but 603 signedAttrs is REQUIRED for all signed TAMP messages. The SET OF 604 Attribute MUST be encoded with the distinguished encoding rules 605 (DER) [X.690]. Section 2.2.3 of this document lists the signed 606 attributes that MUST be included in the collection. Other signed 607 attributes MAY be included, but the cryptographic module MUST 608 ignore any unrecognized signed attributes. 610 o signatureAlgorithm identifies the digital signature algorithm, and 611 any associated parameters, used by the TAMP message originator to 612 generate the digital signature. 614 o signature is the digital signature value generated by the TAMP 615 message originator. 617 o unsignedAttrs is an OPTIONAL set of attributes that are not 618 signed. For TAMP, this field is usually omitted. It is present 619 only in Apex Trust Anchor Update messages that are to be validated 620 using the apex trust anchor contingency public key. In this case, 621 the SET OF Attribute MUST include the symmetric key needed to 622 decrypt the contingency public key in the contingency-public-key- 623 decrypt-key unsigned attribute. Section 2.2.4 of this document 624 describes this unsigned attribute. 626 2.2.2. EncapsulatedContentInfo 628 The EncapsulatedContentInfo structure contains the TAMP message. The 629 fields of EncapsulatedContentInfo are used as follows: 631 o eContentType is an object identifier that uniquely specifies the 632 content type, and for TAMP, the value identifies the TAMP message. 633 The list of TAMP message content types is provided in Section 4. 635 o eContent is the TAMP message, encoded as an octet string. In 636 general, the CMS does not require the eContent to be DER-encoded 637 before constructing the octet string. However, TAMP messages MUST 638 be DER encoded. 640 2.2.3. Signed Attributes 642 The TAMP message originator MUST digitally sign a collection of 643 attributes along with the TAMP message. Each attribute in the 644 collection MUST be DER-encoded. The syntax for attributes is defined 645 in [X.501]. X.500 Directory provides a rich attribute syntax. A 646 very simple subset of this syntax is used extensively in [RFC3852], 647 where ATTRIBUTE.&Type and ATTRIBUTE.&id are the only parts of the 648 ATTRIBUTE class that are employed. 650 The attribute syntax is repeated here for convenience: 652 Attribute ::= SEQUENCE { 653 type ATTRIBUTE.&id ({SupportedAttributes}), 654 values SET SIZE (1..MAX) OF ATTRIBUTE.&Type 655 ({SupportedAttributes}{@type}) } 657 SupportedAttributes ATTRIBUTE ::= { ... } 659 ATTRIBUTE ::= CLASS { 660 &derivation ATTRIBUTE OPTIONAL, 661 &Type OPTIONAL, 662 -- either &Type or &derivation REQUIRED 663 &equality-match MATCHING-RULE OPTIONAL, 664 &ordering-match MATCHING-RULE OPTIONAL, 665 &substrings-match MATCHING-RULE OPTIONAL, 666 &single-valued BOOLEAN DEFAULT FALSE, 667 &collective BOOLEAN DEFAULT FALSE, 668 -- operational extensions 669 &no-user-modification BOOLEAN DEFAULT FALSE, 670 &usage AttributeUsage DEFAULT 671 userApplications, 672 &id OBJECT IDENTIFIER UNIQUE } 674 WITH SYNTAX { 675 [ SUBTYPE OF &derivation ] 676 [ WITH SYNTAX &Type ] 677 [ EQUALITY MATCHING RULE &equality-match ] 678 [ ORDERING MATCHING RULE &ordering-match ] 679 [ SUBSTRINGS MATCHING RULE &substrings-match ] 680 [ SINGLE VALUE &single-valued ] 681 [ COLLECTIVE &collective ] 682 [ NO USER MODIFICATION &no-user-modification ] 683 [ USAGE &usage ] 684 ID &id } 686 MATCHING-RULE ::= CLASS { 687 &AssertionType OPTIONAL, 688 &id OBJECT IDENTIFIER UNIQUE } 689 WITH SYNTAX { 690 [ SYNTAX &AssertionType ] 691 ID &id } 693 AttributeType ::= ATTRIBUTE.&id 695 AttributeValue ::= ATTRIBUTE.&Type 697 AttributeUsage ::= ENUMERATED { 698 userApplications (0), 699 directoryOperation (1), 700 distributedOperation (2), 701 dSAOperation (3) } 703 Each of the attributes used with this CMS profile has a single 704 attribute value. Even though the syntax is defined as a SET OF 705 AttributeValue, there MUST be exactly one instance of AttributeValue 706 present. 708 The SignedAttributes syntax within signerInfo is defined as a SET OF 709 Attribute. The SignedAttributes MUST include only one instance of 710 any particular attribute. TAMP messages that violate this rule MUST 711 be rejected as malformed. 713 The TAMP message originator MUST include the content-type and 714 message-digest attributes. The TAMP message originator MAY also 715 include the binary-signing-time signed attribute. 717 The TAMP message originator MAY include any other attribute that it 718 deems appropriate. The intent is to allow additional signed 719 attributes to be included if a future need is identified. This does 720 not cause an interoperability concern because unrecognized signed 721 attributes MUST be ignored. 723 The following summarizes the signed attribute requirements for TAMP 724 messages: 726 o content-type MUST be supported. 728 o message-digest MUST be supported. 730 o content-hints MAY be supported. Only present when more than one 731 layer of encapsulation is employed. 733 o binary-signing-time MAY be supported. Generally ignored by the 734 recipient. 736 o other attributes MAY be supported. Unrecognized attributes MUST 737 be ignored by the recipient. 739 2.2.3.1. Content-Type Attribute 741 The TAMP message originator MUST include a content-type attribute; it 742 is an object identifier that uniquely specifies the content type. 743 Section 11.1 of [RFC3852] defines the content-type attribute. For 744 TAMP, the value identifies the TAMP message. The list of TAMP 745 message content types and their identifiers is provided in Section 4. 747 A content-type attribute MUST contain the same object identifier as 748 the content type contained in the EncapsulatedContentInfo. 750 2.2.3.2. Message-Digest Attribute 752 The TAMP message originator MUST include a message-digest attribute, 753 having as its value the output of a one-way hash function computed on 754 the TAMP message that is being signed. Section 11.2 of [RFC3852] 755 defines the message-digest attribute. 757 2.2.3.3. Content-Hints Attribute 759 Many applications find it useful to have information that describes 760 the innermost content when multiple layers of encapsulation have been 761 applied. Since this version of TAMP only has one layer of 762 encapsulation, the encapContentInfo provides the content type of the 763 innermost content. To accommodate future versions of TAMP that might 764 include additional layers of encapsulation, the content-hints 765 attribute MUST be included in every instance of SignedData that does 766 not directly encapsulate a TAMP message. Section 2.9 of [RFC2634] 767 defines the content-hints attribute. 769 The content-hints attribute contains two fields: contentDescription 770 and contentType. The contentType field MUST be present, and the 771 contentDescription field MAY be present. The fields of the content- 772 hints attribute are used as follows: 774 o contentDescription is OPTIONAL. The TAMP message signer MAY 775 provide a brief description of the purpose of the TAMP message. 776 The text is intended for human consumption, not machine 777 processing. The text is encoded in UTF-8 [RFC3629], which 778 accommodates most of the world's writing systems. The 779 implementation MUST provide the capability to constrain the 780 character set. 782 o contentType is mandatory. This field indicates the content type 783 that will be discovered when CMS protection content types are 784 removed. 786 2.2.3.4. Binary-Signing-Time Attribute 788 The TAMP message originator MAY include a binary-signing-time 789 attribute, specifying the time at which the digital signature was 790 applied to the TAMP message. The binary-signing-time attribute is 791 defined in [RFC4049]. 793 No processing of the binary-signing-time attribute is REQUIRED of a 794 TAMP message recipient; however, the binary-signing-time attribute 795 MAY be included by the TAMP message originator as a form of message 796 identifier. 798 2.2.4. Unsigned Attributes 800 For TAMP, unsigned attributes are usually omitted. An unsigned 801 attribute is present only in Apex Trust Anchor Update messages that 802 are to be validated by the apex trust anchor contingency public key. 803 In this case, the symmetric key to decrypt the previous contingency 804 public key is provided in the contingency-public-key-decrypt-key 805 unsigned attribute. This attribute MUST be supported, and it is 806 described in Section 2.2.4.1. 808 The TAMP message originator SHOULD NOT include other unsigned 809 attributes, and the cryptographic module MUST ignore unrecognized 810 unsigned attributes. 812 The UnsignedAttributes syntax within signerInfo is defined as a SET 813 OF Attribute. The UnsignedAttributes MUST include only one instance 814 of any particular attribute. TAMP messages that violate this rule 815 MUST be rejected as malformed. 817 2.2.4.1. Contingency Public Key Decrypt Key Attribute 819 The contingency-public-key-decrypt-key attribute provides the 820 plaintext symmetric key needed to decrypt the previously distributed 821 apex trust anchor contingency public key. The symmetric key MUST be 822 useable with the symmetric algorithm used to previously encrypt the 823 contingency public key. 825 The contingency-public-key-decrypt-key attribute has the following 826 syntax: 828 contingency-public-key-decrypt-key ATTRIBUTE ::= { 829 WITH SYNTAX PlaintextSymmetricKey 830 SINGLE VALUE TRUE 831 ID id-aa-TAMP-contingencyPublicKeyDecryptKey } 833 id-aa-TAMP-contingencyPublicKeyDecryptKey 834 OBJECT IDENTIFIER ::= { id-attributes 63 } 836 PlaintextSymmetricKey ::= OCTET STRING 838 3. Trust Anchor Information Syntax 840 An implementation MAY store trust anchor information in any format; 841 however, a common syntax is used throughout the TAMP specification 842 for trust anchor information. This section describes the 843 TrustAnchorInfo ASN.1 type. 845 TrustAnchorInfo ::= SEQUENCE { 846 version [0] TAMPVersion DEFAULT v2, 847 pubKey PublicKeyInfo, 848 keyId KeyIdentifier, 849 taType TrustAnchorType, 850 taTitle TrustAnchorTitle OPTIONAL, 851 certPath CertPathControls OPTIONAL } 853 TAMPVersion ::= INTEGER { v1(1), v2(2) } 855 PublicKeyInfo ::= SEQUENCE { 856 algorithm AlgorithmIdentifier, 857 publicKey BIT STRING } 859 KeyIdentifier ::= OCTET STRING 861 TrustAnchorType ::= CHOICE { 862 apex [0] ApexTrustAnchorInfo, 863 mgmt [1] MgmtTrustAnchorInfo, 864 ident [2] NULL } 866 ApexTrustAnchorInfo ::= SEQUENCE { 867 continPubKey ApexContingencyKey, 868 seqNum SeqNumber OPTIONAL } 870 ApexContingencyKey ::= SEQUENCE { 871 wrapAlgorithm AlgorithmIdentifier, 872 wrappedContinPubKey OCTET STRING } 874 SeqNumber ::= INTEGER (0..9223372036854775807) 876 MgmtTrustAnchorInfo ::= SEQUENCE { 877 taUsage TrustAnchorUsage, 878 seqNum SeqNumber OPTIONAL } 880 TrustAnchorUsage ::= CMSContentConstraints 882 CMSContentConstraints ::= ContentTypeConstraintList 884 ContentTypeConstraintList ::= SEQUENCE SIZE (1..MAX) OF 885 ContentTypeConstraint 887 ContentTypeConstraint ::= SEQUENCE { 888 contentType ContentType, 889 canSource BOOLEAN DEFAULT TRUE, 890 attrConstraints AttrConstraintList OPTIONAL } 892 ContentType ::= OBJECT IDENTIFIER 894 AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint 896 AttrConstraint ::= SEQUENCE { 897 attrType AttributeType, 898 attrValues SET SIZE (1..MAX) OF AttributeValue } 900 TrustAnchorTitle ::= UTF8String (SIZE (1..64)) 902 CertPathControls ::= SEQUENCE { 903 taName Name, 904 selfSigned [0] Certificate OPTIONAL, 905 policySet [1] CertificatePolicies OPTIONAL, 906 policyFlags [2] CertPolicyFlags OPTIONAL, 907 clearanceConstr [3] CAClearanceConstraints OPTIONAL, 908 nameConstr [4] NameConstraints OPTIONAL } 910 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 912 PolicyInformation ::= SEQUENCE { 913 policyIdentifier CertPolicyId, 914 policyQualifiers SEQUENCE SIZE (1..MAX) OF 915 PolicyQualifierInfo OPTIONAL } 917 CertPolicyId ::= OBJECT IDENTIFIER 919 CertPolicyFlags ::= BIT STRING { 920 inhibitPolicyMapping (0), 921 requireExplicitPolicy (1), 922 inhibitAnyPolicy (2) } 924 CAClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance 926 Clearance ::= SEQUENCE { 927 policyId [0] OBJECT IDENTIFIER, 928 classList [1] ClassList DEFAULT {unclassified}, 929 securityCategories [2] SET OF SecurityCategory OPTIONAL } 931 ClassList ::= BIT STRING { 932 unmarked (0), 933 unclassified (1), 934 restricted (2), 935 confidential (3), 936 secret (4), 937 topSecret (5) } 939 SecurityCategory ::= SEQUENCE { 940 type [0] SECURITY-CATEGORY.&id({SecurityCategoriesTable}), 941 value [1] EXPLICIT SECURITY-CATEGORY.&Type 942 ({SecurityCategoriesTable}{@type}) } 944 SECURITY-CATEGORY ::= TYPE-IDENTIFIER 946 SecurityCategoriesTable SECURITY-CATEGORY ::= {...} 948 NameConstraints ::= SEQUENCE { 949 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 950 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 952 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 954 GeneralSubtree ::= SEQUENCE { 955 base GeneralName, 956 minimum [0] BaseDistance DEFAULT 0, 957 maximum [1] BaseDistance OPTIONAL } 959 BaseDistance ::= INTEGER (0..MAX) 961 The fields of TrustAnchorInfo are used as follows: 963 o version identifies version of TAMP. For this version of the 964 specification, the default value, v2, MUST be used. 966 o pubKey identifies the public key and algorithm associated with the 967 trust anchor using the PublicKeyInfo structure. The PublicKeyInfo 968 structure contains the algorithm identifier followed by the public 969 key itself. The algorithm identifier is an AlgorithmIdentifier, 970 which contains an object identifier and OPTIONAL parameters. The 971 object identifier names the digital signature algorithm, and it 972 indicates the syntax of the parameters, if present, as well as the 973 format of the public key. The public key is encoded as a BIT 974 STRING. For the apex trust anchor, this field contains the 975 operational public key. 977 o keyId contains the public key identifier of the trust anchor 978 public key. For the apex trust anchor, this field contains the 979 public key identifier of the operational public key. 981 o taType indicates the type of trust anchor, and it carries 982 information specific to the type of trust anchor that is being 983 represented. If an apex trust anchor is represented, then apex 984 trust anchor information is carried using the ApexTrustAnchorInfo 985 structure. If a management trust anchor is represented, then 986 management trust anchor information is carried using the 987 MgmtTrustAnchorInfo. If an identity trust anchor is represented, 988 no additional information is carried, which is represented by 989 NULL. 991 o taTitle is OPTIONAL. When it is present, it provides a human 992 readable name for the trust anchor. The text is encoded in UTF-8 993 [RFC3629], which accommodates most of the world's writing systems. 994 The implementation MUST provide the capability to constrain the 995 character set. 997 o certPath is OPTIONAL. When it is present, it provides the 998 controls needed to initialize an X.509 certification path 999 validation algorithm implementation (see Section 6 in [RFC3280]). 1000 When absent, the trust anchor cannot be used to validate the 1001 signature on an X.509 certificate. For the apex trust anchor, 1002 this field contains the certification path controls associated 1003 with the operational public key. 1005 The fields of ApexTrustAnchorInfo are used as follows: 1007 o continPubKey contains the encrypted apex trust anchor contingency 1008 public key using the ApexContingencyKey structure. 1010 o seqNum is OPTIONAL. When it is present, it contains the current 1011 sequence number value stored by the cryptographic module for the 1012 apex trust anchor operational public key. When seqNum is absent, 1013 the cryptographic module is prepared to accept any sequence number 1014 value for the apex trust anchor operational public key. Section 6 1015 provides sequence number processing details. 1017 The fields of ApexContingencyKey are used as follows: 1019 o wrapAlgorithm identifies the symmetric algorithm used to encrypt 1020 the apex trust anchor contingency public key. If this public key 1021 is ever needed, the symmetric key needed to decrypt it will be 1022 provided in the TAMP message that is to be validated using it. 1023 The algorithm identifier is an AlgorithmIdentifier, which contains 1024 an object identifier and OPTIONAL parameters. The object 1025 identifier indicates the syntax of the parameters, if present. 1027 o wrappedContinPubKey is the encrypted apex trust anchor contingency 1028 public key. Once decrypted, it yields the PublicKeyInfo 1029 structure, which consists of the algorithm identifier followed by 1030 the public key itself. The algorithm identifier is an 1031 AlgorithmIdentifier that contains an object identifier and 1032 OPTIONAL parameters. The object identifier indicates the format 1033 of the public key and the syntax of the parameters, if present. 1034 The public key is encoded as a BIT STRING. 1036 The fields of MgmtTrustAnchorInfo are used as follows: 1038 o taUsage represents the authorized uses of the management trust 1039 anchor using the TrustAnchorUsage structure. 1041 o seqNum is OPTIONAL. When it is present, it contains the current 1042 sequence number value stored by the cryptographic module for this 1043 management trust anchor. When seqNum is absent, the cryptographic 1044 module is prepared to accept any sequence number value for this 1045 management trust anchor. Section 6 provides sequence number 1046 processing details. 1048 The TrustAnchorUsage is defined using the CMSContentConstraints type 1049 defined in [CCC]. The CMSContentConstraints is a list of permitted 1050 content types and associated constraints. The management trust 1051 anchor can be used to validate digital signatures on the permitted 1052 content types, including TAMP message content types. 1054 The anyContentType object identifier can be used to indicate that the 1055 trust anchor is unconstrained. The apex trust anchor has an implicit 1056 CMSContentConstraints field with a single permitted content type of 1057 anyContentType. 1059 The fields of ContentTypeConstraint are used as follows: 1061 o contentType indicates the encapsulated content type identifier 1062 that can be validated using the management trust anchor. For 1063 example, it contains id-ct-firmwarePackage when the management 1064 trust anchor can be used to validate digital signatures on 1065 firmware packages [RFC4108]. A particular content type MUST NOT 1066 appear more than once in the list. The CMS-related content types 1067 need not be included in the list of permitted content types. 1068 These content types are always authorized to facilitate the use of 1069 CMS in the protection of content, and they MUST NOT appear in the 1070 permitted list. The always authorized content types are: 1072 * id-signedData, 1073 * id-envelopedData, 1075 * id-digestedData, 1077 * id-encryptedData, 1079 * id-ct-authEnvData, 1081 * id-ct-authData, 1083 * id-ct-compressedData, 1085 * id-ct-contentCollection 1087 * id-ct-contentWithAttrs. 1089 o canSource is a Boolean flag, and it applies to direct signatures 1090 or direct authentication for the specified content type. If the 1091 canSource flag is FALSE, then the management trust anchor cannot 1092 be used to directly sign or authenticate the specified content 1093 type. Regardless of the flag value, a management trust anchor can 1094 be used to sign or authenticate outer layers when multiple layers 1095 of CMS protected content type are present. 1097 o attrConstraints is an OPTIONAL field that contains a sequence of 1098 content type specific constraints. If the attrConstraints field 1099 is absent, then the management trust anchor can be used to verify 1100 the specified content type without any further checking. If the 1101 attrConstraints field is present, then the management trust anchor 1102 can only be used to verify the specified content type if all of 1103 the constraints for that content type are satisfied. Content type 1104 constraints are checked by matching the attribute values in the 1105 AttrConstraintList against the attribute value in the content. 1106 The constraints checking fails if the attribute is present and the 1107 attribute value is not one of the values provided in 1108 AttrConstraintList. 1110 The AttrConstraintList contains a sequence of attributes, which is 1111 defined in [CCC] and repeated above. The fields of AttrConstraint 1112 are used as follows: 1114 o attrType is the object identifier of the signed attribute carried 1115 in the SignerInfo of the content. For a signed content to satisfy 1116 the constraint, if the SignerInfo includes a signed attribute of 1117 the same type, then the signed attribute MUST contain one of the 1118 values supplied in the attrValues field. 1120 o attrValues provides one or more acceptable signed attribute 1121 values. It is a set of AttributeValue. For a signed content to 1122 satisfy the constraint, if the SignerInfo includes a signed 1123 attribute of the type identified in the attrType field, then the 1124 signed attribute MUST contain one of the values in the set. 1126 The fields of CertPathControls are used as follows: 1128 o taName provides the X.500 distinguished name associated with the 1129 trust anchor, and this distinguished name is used to construct and 1130 validate an X.509 certification path. The name MUST NOT be an 1131 empty sequence. An identity trust anchor is of little use without 1132 a distinguished name. 1134 o selfSigned provides an OPTIONAL self-signed X.509 certificate, 1135 which can be used in some environments to represent the trust 1136 anchor in certification path development and validation. If the 1137 self-signed certificate is present, the subject name in the 1138 certificate MUST exactly match the X.500 distinguished name 1139 provided in the taName field. The complete description of the 1140 syntax and semantics of the Certificate are provided in [RFC3280]. 1142 o policySet is OPTIONAL. When present, it contains sequence of 1143 certificate policy identifiers to be provided as inputs to the 1144 certification path validation algorithm. When absent, the special 1145 value any-policy is provided as the input to the certification 1146 path validation algorithm. The complete description of the syntax 1147 and semantics of the CertificatePolicies are provided in 1148 [RFC3280], including the syntax for PolicyInformation. In this 1149 context, the OPTIONAL policyQualifiers structure MUST NOT be 1150 included. 1152 o policyFlags is OPTIONAL. When present, three Boolean values for 1153 input to the certification path validation algorithm are provided 1154 in a BIT STRING. When absent, the input to the certification path 1155 validation algorithm is { FALSE, FALSE, FALSE }, which represents 1156 the most liberal setting for these flags. The three bits are used 1157 as follows: 1159 * inhibitPolicyMapping indicates if policy mapping is allowed in 1160 the certification path. When set to TRUE, policy mapping is 1161 not permitted. This value represents the initial-policy- 1162 mapping-inhibit input value to the certification path 1163 validation algorithm described in section 6.1.1 of [RFC3280]. 1165 * requireExplicitPolicy indicates if the certification path MUST 1166 be valid for at least one of the certificate policies in the 1167 policySet. When set to TRUE, all certificates in the 1168 certification path MUST contain an acceptable policy identifier 1169 in the certificate policies extension. This value represents 1170 the initial-explicit-policy input value to the certification 1171 path validation algorithm described in section 6.1.1 of 1172 [RFC3280]. An acceptable policy identifier is a member of the 1173 policySet or the identifier of a policy that is declared to be 1174 equivalent through policy mapping. This bit MUST be set to 1175 FALSE if policySet is absent. 1177 * inhibitAnyPolicy indicates whether the special anyPolicy policy 1178 identifier, with the value { 2 5 29 32 0 }, is considered an 1179 explicit match for other certificate policies. When set to 1180 TRUE, the special anyPolicy policy identifier is only 1181 considered a match for itself. This value represents the 1182 initial-any-policy-inhibit input value to the certification 1183 path validation algorithm described in section 6.1.1 of 1184 [RFC3280]. 1186 o clearanceConstr is OPTIONAL. It has the same syntax and semantics 1187 as the CA Clearance Constraints certificate extension as specified 1188 in [ClearConstr]. When it is present, constraints are provided on 1189 the CA Clearance Constraints certificate extension and Clearance 1190 certificate extension that might appear in subordinate X.509 1191 certificates. For a subordinate certificate to be valid, it MUST 1192 conform to these constraints. When it is absent, no constraints 1193 are imposed on the CA Clearance Constraints certificate extension 1194 and Clearance certificate extension that might appear in 1195 subordinate X.509 certificates. 1197 o nameConstr is OPTIONAL. It has the same syntax and semantics as 1198 the Name Constraints certificate extension [RFC3280], which 1199 includes a list of permitted names and a list of excluded names. 1200 The definition of GeneralName can be found in [RFC3280]. When it 1201 is present, constraints are provided on names (including 1202 alternative names) that might appear in subordinate X.509 1203 certificates. When applied to CA certificates, the CA can apply 1204 further constraints by including the Name Constraints certificate 1205 extension in subordinate certificates. For a subordinate 1206 certificate to be valid, it MUST conform to these constraints. 1207 When it is absent, no constraints are imposed on names that appear 1208 in subordinate X.509 certificates. 1210 When the trust anchor is used to validate a certification path, 1211 CertPathControls provides limitations on certification paths that 1212 will successfully validate. An application that is validating a 1213 certification path MUST NOT ignore these limitations, but the 1214 application can impose additional limitations to ensure that the 1215 validated certification path is appropriate for the intended 1216 application context. As input to the certification path validation 1217 algorithm, an application MAY: 1219 o Provide a subset of the certification policies provided in the 1220 policySet; 1222 o Provide a TRUE value for any of the flags in the policyFlags; 1224 o Provide a subset of clearance values provided in the 1225 clearanceConstr; 1227 o Provide a subset of the permitted names provided in the 1228 nameConstr; 1230 o Provide additional excluded names to the ones that are provided in 1231 the nameConstr 1233 4. Trust Anchor Management Protocol Messages 1235 TAMP makes use of signed and unsigned messages. The CMS is used in 1236 both cases. An object identifier is assigned to each TAMP message 1237 type, and this object identifier is used as a content type in the 1238 CMS. 1240 TAMP specifies eleven message types. The following provides the 1241 content type identifier for each TAMP message type, and it indicates 1242 whether a digital signature is REQUIRED. If the following indicates 1243 that the TAMP message MUST be signed, then implementations MUST 1244 reject a message of that type that is not signed. 1246 o The TAMP Status Query message MUST be signed. It uses the 1247 following object identifier: { id-tamp 1 }. 1249 o The TAMP Status Response message SHOULD be signed. It uses the 1250 following object identifier: { id-tamp 2 }. 1252 o The Trust Anchor Update message MUST be signed. It uses the 1253 following object identifier: { id-tamp 3 }. 1255 o The Trust Anchor Update Confirm message SHOULD be signed. It uses 1256 the following object identifier: { id-tamp 4 }. 1258 o The Apex Trust Anchor Update message MUST be signed. It uses the 1259 following object identifier: { id-tamp 5 }. 1261 o The Apex Trust Anchor Update Confirm SHOULD be signed. It uses 1262 the following object identifier: { id-tamp 6 }. 1264 o The Community Update message MUST be signed. It uses the 1265 following object identifier: { id-tamp 7 }. 1267 o The Community Update Confirm message SHOULD be signed. It uses 1268 the following object identifier: { id-tamp 8 }. 1270 o The Sequence Number Adjust MUST be signed. It uses the following 1271 object identifier: { id-tamp 10 }. 1273 o The Sequence Number Adjust Confirm message SHOULD be signed. It 1274 uses the following object identifier: { id-tamp 11 }. 1276 o The TAMP Error message SHOULD be signed. It uses the following 1277 object identifier: { id-tamp 9 }. 1279 A typical interaction between a trust anchor manager and a 1280 cryptographic module will follow the message flow shown in Figure 1281 4-1. Figure 4-1 does not illustrate a flow where an error occurs. 1283 +---------+ +----------+ 1284 | | Trust Anchor Status Query | | 1285 | |------------------------------->| | 1286 | | | | 1287 | | Trust Anchor Status Response | | 1288 | Trust |<-------------------------------| Crypto | 1289 | Anchor | | Module | 1290 | Manager | Trust Anchor Update | | 1291 | |------------------------------->| | 1292 | | | | 1293 | | Trust Anchor Update Confirm | | 1294 | |<-------------------------------| | 1295 | | | | 1296 +---------+ +----------+ 1298 Figure 4-1: Typical TAMP Message Flow 1300 Each TAMP query and update message include an indication of the type 1301 of response that is desired. The response can either be terse or 1302 verbose. All cryptographic modules MUST support both the terse and 1303 verbose responses. 1305 Cryptographic modules MUST be able to process and properly act upon 1306 the valid payload of the TAMP Status Query message, the Trust Anchor 1307 Update message, the Apex Trust Anchor Update message, and the 1308 Sequence Number Adjust message. Cryptographic modules MAY also 1309 process and act upon the valid payload of the Community Update 1310 message. 1312 Cryptographic modules MUST support generation of the TAMP Status 1313 Response message, the Trust Anchor Update Confirm message, the Apex 1314 Trust Anchor Update Confirm message, the Sequence Number Adjust 1315 Confirm message, and the TAMP Error message. If a cryptographic 1316 module supports the Community Update message, then the cryptographic 1317 module MUST also support generation of the Community Update Confirm 1318 message. 1320 4.1. TAMP Status Query 1322 The TAMP Status Query message is used to request information about 1323 the trust anchors that are currently installed in a cryptographic 1324 module, and for the list of communities to which the cryptographic 1325 module belongs. The TAMP Status Query message MUST be signed. For 1326 the query message to be valid, the cryptographic module MUST be an 1327 intended recipient of the query, the sequence number checking 1328 described in Section 6 MUST be successful when the TAMP message 1329 source is a trust anchor, and the digital signature MUST be validated 1330 by the apex trust anchor operational public key, a management trust 1331 anchor authorized for the id-ct-TAMP-statusQuery content type, or via 1332 a valid X.509 certification path originating with such a trust 1333 anchor. 1335 If the digital signature on the TAMP Status Query message is valid, 1336 sequence number checking is successful, the signer is authorized for 1337 the id-ct-TAMP-statusQuery content type, and the cryptographic module 1338 is an intended recipient of the TAMP message, then a TAMP Status 1339 Response message MUST be returned. If a TAMP Status Response message 1340 is not returned, then a TAMP Error message MUST be returned. 1342 The TAMP Status Query content type has the following syntax: 1344 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 1346 tamp-status-query PKCS7-CONTENT-TYPE ::= 1347 { TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery } 1349 id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 } 1351 TAMPStatusQuery ::= SEQUENCE { 1352 Version [0] TAMPVersion DEFAULT v2, 1353 terse [1] TerseOrVerbose DEFAULT verbose, 1354 query TAMPMsgRef } 1356 TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) } 1358 TAMPMsgRef ::= SEQUENCE { 1359 target TargetIdentifier, 1360 seqNum SeqNumber } 1362 TargetIdentifier ::= CHOICE { 1363 hwModules [1] HardwareModuleIdentifierList, 1364 communities [2] CommunityIdentifierList, 1365 allModules [3] NULL } 1367 HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF 1368 HardwareModules 1370 HardwareModules ::= SEQUENCE { 1371 hwType OBJECT IDENTIFIER, 1372 hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry } 1374 HardwareSerialEntry ::= CHOICE { 1375 all NULL, 1376 single OCTET STRING, 1377 block SEQUENCE { 1378 low OCTET STRING, 1379 high OCTET STRING } } 1381 CommunityIdentifierList ::= SEQUENCE SIZE (1..MAX) OF Community 1383 Community ::= OBJECT IDENTIFIER 1385 The fields of TAMPStatusQuery are used as follows: 1387 o version identifies version of TAMP. For this version of the 1388 specification, the default value, v2, MUST be used. 1390 o terse indicates the type of response that is desired. A terse 1391 response is indicated by a value of 1, and a verbose response is 1392 indicated by a value of 2, which is omitted during encoding since 1393 it is the default value. 1395 o query contains two items: the target and the seqNum. target 1396 identifies the cryptographic module or collection of cryptographic 1397 modules that are the target of the query message. seqNum is a 1398 single use value that will be used to match the TAMP Status Query 1399 message with the TAMP Status Response message. The sequence 1400 number is also used to detect TAMP message replay. The sequence 1401 number processing described in Section 6 MUST successfully 1402 complete before a response is returned. 1404 The fields of TAMPMsgRef are used as follows: 1406 o target identifies the cryptographic modules or community of 1407 cryptographic modules that are the target of the query. To 1408 identify a cryptographic module, a combination of a cryptographic 1409 type and serial number are used. The cryptographic type is 1410 represented as an ASN.1 object identifier, and the unique serial 1411 number is represented as a string of octets. To facilitate 1412 compact representation of serial numbers, a contiguous block can 1413 be specified by the lowest included serial number and the highest 1414 included serial number. When present, the high and low octet 1415 strings MUST have the same length. The HardwareModuleIdentifiers 1416 sequence MUST NOT contain duplicate hwType values, so that each 1417 member of the sequence names all of the cryptographic modules of 1418 this type. Object identifiers are also used to identify 1419 communities of cryptographic modules. A sequence of these object 1420 identifiers is used if more than one community is the target of 1421 the message. A cryptographic module is considered a target if it 1422 is a member of any of the listed communities. An explicit NULL 1423 value is used to identify all modules that consider the signer of 1424 the TAMP message to be an authorized source for that message type. 1426 o seqNum contains a single use value that will be used to match the 1427 TAMP Status Query message with the successful TAMP Status Response 1428 message. The sequence number processing described in Section 6 1429 MUST successfully complete before a response is returned. 1431 To determine whether a particular cryptographic module serial number 1432 is considered part of a specified block, all of the following 1433 conditions MUST be met. First, the cryptographic module serial 1434 number MUST be the same length as both the high and low octet 1435 strings. Second, the cryptographic module serial number MUST be 1436 greater than or equal to the low octet string. Third, the 1437 cryptographic module serial number MUST be less than or equal to the 1438 high octet string. 1440 One octet string is equal to another if they are of the same length 1441 and are the same at each octet position. An octet string, S1, is 1442 greater than another, S2, where S1 and S2 have the same length, if 1443 and only if S1 and S2 have different octets in one or more positions, 1444 and in the first such position, the octet in S1 is greater than that 1445 in S2, considering the octets as unsigned binary numbers. Note that 1446 these octet string comparison definitions are consistent with those 1447 in clause 6 of [X.690]. 1449 4.2. TAMP Status Query Response 1451 The TAMP Status Response message is a reply by a cryptographic module 1452 to a valid TAMP Status Query message. The TAMP Status Response 1453 message provides information about the trust anchors that are 1454 currently installed in the cryptographic module and the list of 1455 communities to which the cryptographic module belongs, if any. The 1456 TAMP Status Response message MAY be signed or unsigned. A TAMP 1457 Status Response message MUST be signed if the cryptographic module is 1458 capable of signing it. 1460 The TAMP Status Response content type has the following syntax: 1462 tamp-status-response PKCS7-CONTENT-TYPE ::= 1463 { TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse } 1465 id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 } 1467 TAMPStatusResponse ::= SEQUENCE { 1468 version [0] TAMPVersion DEFAULT v2, 1469 query TAMPMsgRef, 1470 response StatusResponse } 1472 StatusResponse ::= CHOICE { 1473 terseResponse [0] TerseStatusResponse, 1474 verboseResponse [1] VerboseStatusResponse } 1476 TerseStatusResponse ::= SEQUENCE { 1477 taKeyIds KeyIdentifiers, 1478 communities CommunityIdentifierList OPTIONAL } 1480 KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier 1482 VerboseStatusResponse ::= SEQUENCE { 1483 taInfo TrustAnchorInfoList, 1484 continPubKeyDecryptAlg AlgorithmIdentifier, 1485 communities CommunityIdentifierList OPTIONAL } 1487 TrustAnchorInfoList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorInfo 1489 The fields of TAMPStatusResponse are used as follows: 1491 o version identifies version of TAMP. For this version of the 1492 specification, the default value, v2, MUST be used. 1494 o query identifies the TAMPStatusQuery to which the cryptographic 1495 module is responding. The query structure repeats the TAMPMsgRef 1496 from the TAMP Status Query message (see Section 4.1). The 1497 sequence number processing described in Section 6 MUST 1498 successfully complete before any response is returned. 1500 o response contains either a terse response or a verbose response. 1501 The terse response is represented by TerseStatusResponse, and the 1502 verbose response is represented by VerboseStatusResponse. 1504 The fields of TerseStatusResponse are used as follows: 1506 o taKeyIds contains a sequence of key identifiers. Each trust 1507 anchor contained in the cryptographic module is represented by one 1508 key identifier. The apex trust anchor is represented by the first 1509 key identifier in the sequence, which contains the key identifier 1510 of the operational public key. 1512 o communities is OPTIONAL. When present, it contains a sequence of 1513 object identifiers. Each object identifier names one community to 1514 which this cryptographic module belongs. When the module belongs 1515 to no communities, this field is omitted. 1517 The fields of VerboseStatusResponse are used as follows: 1519 o taInfo contains a sequence of TrustAnchorInfo structures. One 1520 entry in the sequence is provided for each trust anchor contained 1521 in the cryptographic module. The apex trust anchor is the first 1522 trust anchor in the sequence. 1524 o continPubKeyDecryptAlg indicates the decryption algorithm needed 1525 to decrypt the currently installed apex trust anchor contingency 1526 public key. 1528 o communities is OPTIONAL. When present, it contains a sequence of 1529 object identifiers. Each object identifier names one community to 1530 which this cryptographic module belongs. When the module belongs 1531 to no communities, this field is omitted. 1533 The fields of TrustAnchorInfo are described in Section 3. 1535 4.3. Trust Anchor Update 1537 The Trust Anchor Update message is used to add, remove, and change 1538 management and identity trust anchors. The Trust Anchor Update 1539 message cannot be used to update the apex trust anchor. The Trust 1540 Anchor Update message MUST be signed. For a Trust Anchor Update 1541 message to be valid, the cryptographic module MUST be an intended 1542 receipient of the update, the sequence number checking described in 1543 Section 6 MUST be successful when the TAMP message source is a trust 1544 anchor, and the digital signature MUST be validated using the apex 1545 trust anchor operational public key, a management trust anchor 1546 authorized for the id-ct-TAMP-update content type, or via an 1547 authorized X.509 certification path originating with such a trust 1548 anchor. 1550 If the digital signature on the Trust Anchor Update message is valid, 1551 sequence number checking is successful, the signer is authorized for 1552 the id-ct-TAMP-update content type, and the cryptographic module is 1553 an intended recipient of the TAMP message, then the cryptographic 1554 module MUST perform the specified updates and return a Trust Anchor 1555 Update Confirm message. If a Trust Anchor Update Confirm message is 1556 not returned, then a TAMP Error message MUST be returned. 1558 The Trust Anchor Update content type has the following syntax: 1560 tamp-update PKCS7-CONTENT-TYPE ::= 1561 { TAMPUpdate IDENTIFIED BY id-ct-TAMP-update } 1563 id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 } 1565 TAMPUpdate ::= SEQUENCE { 1566 version [0] TAMPVersion DEFAULT v2, 1567 terse [1] TerseOrVerbose DEFAULT verbose, 1568 msgRef TAMPMsgRef, 1569 updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate } 1571 TrustAnchorUpdate ::= CHOICE { 1572 add [1] EXPLICIT TrustAnchorInfo, 1573 remove [2] PublicKeyInfo, 1574 change [3] TrustAnchorChangeInfo } 1576 TrustAnchorChangeInfo ::= SEQUENCE { 1577 pubKey PublicKeyInfo, 1578 keyId KeyIdentifier OPTIONAL, 1579 mgmtTAType [0] MgmtTrustAnchorInfo OPTIONAL, 1580 taTitle [1] TrustAnchorTitle OPTIONAL, 1581 certPath [2] CertPathControls OPTIONAL } 1583 The fields of TAMPUpdate are used as follows: 1585 o version identifies version of TAMP. For this version of the 1586 specification, the default value, v2, MUST be used. 1588 o terse indicates the type of response that is desired. A terse 1589 response is indicated by a value of 1, and a verbose response is 1590 indicated by a value of 2, which is omitted during encoding since 1591 it is the default value. 1593 o msgRef contains two items: the target and the seqNum. target 1594 identifies the cryptographic module or collection of cryptographic 1595 modules that are the target of the update message. The 1596 TargetIdentifier syntax is described in Section 4.1. seqNum is a 1597 single use value that will be used to match the Trust Anchor 1598 Update message with the Trust Anchor Update Confirm message. The 1599 sequence number is also used to detect TAMP message replay. The 1600 sequence number processing described in Section 6 MUST 1601 successfully complete before any of the updates are processed. 1603 o updates contains a sequence of updates, which are used to add, 1604 remove, and change management or identity trust anchors. Each 1605 entry in the sequence represents one of these actions, and is 1606 indicated by an instance of TrustAnchorUpdate. The actions are a 1607 batch of updates that MUST be processed in the order that they 1608 appear, but each of the updates is processed independently. Each 1609 of the updates MUST satisfy the subordination checks described in 1610 Section 7. Even if one or more of the updates fail, then the 1611 remaining updates MUST be processed. These updates MUST NOT make 1612 any changes to the apex trust anchor. 1614 The TrustAnchorUpdate is a choice of three structures, and each 1615 alternative represents one of the three possible actions: add, 1616 remove, and change. A description of the syntax associated with each 1617 of these actions follows: 1619 o add is used to insert a new management or identity trust anchor 1620 into the cryptographic module. The TrustAnchorInfo structure is 1621 used to provide the trusted public key and all of the information 1622 associated with it. However, the action MUST fail if the 1623 subordination checks described in Section 7 are not satisfied. 1624 See Section 3 for a discussion of the TrustAnchorInfo structure. 1625 The apex trust anchor cannot be introduced into a cryptographic 1626 module using this action; therefore taType MUST NOT use 1627 ApexTrustAnchorInfo. The privileges of the existing trust anchors 1628 are unchanged by this action. An attempt to add a management or 1629 identity trust anchor that is already in place with the same 1630 values for every field in the TrustAnchorInfo structure, except 1631 the seqNum field, MUST be treated as a successful addition. When 1632 the seqNum field does not match the most recently stored sequence 1633 number, the larger value MUST be stored by the cryptographic 1634 module. An attempt to add a management or identity trust anchor 1635 that is already present with the same keyId and pubKey values, but 1636 with different values for any of the fields in the TrustAnchorInfo 1637 structure other than the seqNum field, MUST result in an error. 1639 o remove is used to delete an existing management or identity trust 1640 anchor from the cryptographic module, including the deletion of 1641 the management trust anchor associated with the TAMP message 1642 signer. However, the action MUST fail if the subordination checks 1643 described in Section 7 are not satisfied. The public key 1644 contained in PublicKeyInfo names the management or identity trust 1645 anchor to be deleted. An attempt to delete a trust anchor that is 1646 not present MUST be treated as a successful deletion. The 1647 privileges of the deleted trust anchor are not distributed to 1648 other trust anchors in any manner. The apex trust anchor cannot 1649 be removed using this action, which ensures that this action 1650 cannot place the cryptographic module in an unrecoverable 1651 configuration. 1653 o change is used to update the information associated with an 1654 existing management or identity trust anchor in the cryptographic 1655 module. The public key contained in the PublicKeyInfo field of 1656 TrustAnchorChangeInfo names the to-be-updated trust anchor. 1657 However, the action MUST fail if the subordination checks 1658 described in Section 7 are not satisfied. An attempt to change a 1659 trust anchor that is not present MUST result in a failure with the 1660 trustAnchorNotFound status code. The TrustAnchorChangeInfo 1661 structure is used to provide the revised configuration of the 1662 management or identity trust anchor. If the update fails for any 1663 reason, then the original trust anchor configuration MUST be 1664 preserved. The apex trust anchor information cannot be changed 1665 using this action. 1667 The fields of TrustAnchorChangeInfo are used as follows: 1669 o pubKey contains the algorithm identifier and the public key of the 1670 management or identity trust anchor. It is used to locate the to- 1671 be-updated trust anchor in the cryptographic module storage. 1673 o keyId is OPTIONAL, and when present, it contains the public key 1674 identifier of the trust anchor public key. If this field is not 1675 present, then the public key identifier remains unchanged. If 1676 this field is present, the provided public key identifier replaces 1677 the previous one. 1679 o mgmtTAType is OPTIONAL, and when present, it carries information 1680 specific to the management trust anchor using the 1681 MgmtTrustAnchorInfo structure. This structure can be used to 1682 convert an identity trust anchor to a management trust anchor. 1683 There is not a way to use a single Trust Anchor Update message to 1684 convert a management trust anchor to an identity trust anchor. If 1685 this structure is not present, then the previous taType is 1686 preserved. The syntax and semantics of MgmtTrustAnchorInfo is 1687 discussed in Section 3. Each of the updates MUST satisfy the 1688 subordination checks described in Section 7. Normally, the 1689 sequence number for the management trust anchor is updated by 1690 receiving a signed TAMP message, including the Sequence Number 1691 Adjust message. The seqNum field is an alternative mechanism for 1692 advancing the sequence number values stored in a cryptographic 1693 module. When this integer value is present, the provided value is 1694 stored if it is greater than the currently stored value. When 1695 this integer value is not present, the previous value is 1696 preserved. 1698 o taTitle is OPTIONAL, and when present, it provides a human 1699 readable name for the management or identity trust anchor. When 1700 absent in a change trust anchor update, any title that was 1701 previously associated with the trust anchor is removed. 1702 Similarly, when present in a change trust anchor update, the title 1703 in the message is associated with the trust anchor. If a previous 1704 title was associated with the trust anchor, then the title is 1705 replaced. If a title was not previously associated with the trust 1706 anchor, then the title from the update message is added. 1708 o certPath is OPTIONAL, and when present, it provides the controls 1709 needed to construct and validate an X.509 certification path. 1710 When absent in a change trust anchor update, any controls that 1711 were previously associated with the management or identity trust 1712 anchor are removed, which means that delegation is no longer 1713 permitted. Similarly, when present in a change trust anchor 1714 update, the controls in the message are associated with the 1715 management or identity trust anchor. If previous controls, 1716 including the trust anchor distinguished name, were associated 1717 with the trust anchor, then the controls are replaced, which means 1718 that delegation continues to be supported, but that different 1719 certification paths will be valid. If controls were not 1720 previously associated with the management or identity trust 1721 anchor, then the controls from the update message are added, which 1722 enables delegation. The syntax and semantics of CertPathControls 1723 is discussed in Section 3. 1725 4.4. Trust Anchor Update Confirm 1727 The Trust Anchor Update Confirm message is a reply by a cryptographic 1728 module to a valid Trust Anchor Update message. The Trust Anchor 1729 Update Confirm message provides success and failure information for 1730 each of the requested updates. The Trust Anchor Update Confirm 1731 message MAY be signed or unsigned. A Trust Anchor Update Confirm 1732 message MUST be signed if the cryptographic module is capable of 1733 signing it. 1735 The Trust Anchor Update Confirm content type has the following 1736 syntax: 1738 tamp-update-confirm PKCS7-CONTENT-TYPE ::= 1739 { TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm } 1741 id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 } 1743 TAMPUpdateConfirm ::= SEQUENCE { 1744 version [0] TAMPVersion DEFAULT v2, 1745 update TAMPMsgRef, 1746 confirm UpdateConfirm } 1748 UpdateConfirm ::= CHOICE 1749 terseConfirm [0] TerseUpdateConfirm, 1750 verboseConfirm [1] VerboseUpdateConfirm } 1752 TerseUpdateConfirm ::= StatusCodeList 1754 StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode 1756 VerboseUpdateConfirm ::= SEQUENCE { 1757 status StatusCodeList, 1758 taInfo TrustAnchorInfoList } 1760 The fields of TAMPUpdateConfirm are used as follows: 1762 o version identifies version of TAMP. For this version of the 1763 specification, the default value, v2, MUST be used. 1765 o update identifies the TAMPUpdate message to which the 1766 cryptographic module is responding. The update structure repeats 1767 the TAMPMsgRef from the Trust Anchor Update message (see Section 1768 4.3). The sequence number processing described in Section 6 MUST 1769 successfully complete before any of the updates are processed. 1771 o confirm contains either a terse update confirmation or a verbose 1772 update confirmation. The terse update confirmation is represented 1773 by TerseUpdateConfirm, and the verbose response is represented by 1774 VerboseUpdateConfirm. 1776 The TerseUpdateConfirm contains a sequence of status codes, one for 1777 each TrustAnchorUpdate structure in the Trust Anchor Update message. 1778 The status codes appear in the same order as the TrustAnchorUpdate 1779 structures to which they apply, and the number of elements in the 1780 status code list MUST be the same as the number of elements in the 1781 trust anchor update list. Each of the status codes is discussed in 1782 Section 5. 1784 The fields of VerboseUpdateConfirm are used as follows: 1786 o status contains a sequence of status codes, one for each 1787 TrustAnchorUpdate structure in the Trust Anchor Update message. 1788 The status codes appear in the same order as the TrustAnchorUpdate 1789 structures to which they apply, and the number of elements in the 1790 status code list MUST be the same as the number of elements in the 1791 trust anchor update list. Each of the status codes is discussed 1792 in Section 5. 1794 o taInfo contains a sequence of TrustAnchorInfo structures. One 1795 entry in the sequence is provided for each trust anchor contained 1796 in the cryptographic module. These represent the state of the 1797 trust anchors after the updates have been processed. See Section 1798 3 for a discussion of the TrustAnchorInfo structure. The apex 1799 trust anchor is the first trust anchor in the sequence. 1801 4.5. Apex Trust Anchor Update 1803 The Apex Trust Anchor Update message replaces both the operational 1804 and the contingency public keys associated with the apex trust 1805 anchor. Each cryptographic module has exactly one apex trust anchor. 1806 Since the apex trust anchor represents the ultimate authority over 1807 the cryptographic module, no constraints are associated with the apex 1808 trust anchor. The public key identifier of the operational public 1809 key is used to identify the apex trust anchor in subsequent TAMP 1810 messages. The digital signature on the Apex Trust Anchor Update 1811 message is validated with either the current operational public key 1812 or the current contingency public key. For the Apex Trust Anchor 1813 Update message that is validated with the operational public key to 1814 be valid, the cryptographic module MUST be a target of the update, 1815 the sequence number MUST be larger than the most recently stored 1816 sequence number for the operational public key, and the digital 1817 signature MUST be validated directly with the operational public key. 1818 That is, no delegation via a certification path is permitted. For 1819 the Apex Trust Anchor Update message that is validated with the 1820 contingency public key to be valid, the cryptographic module MUST be 1821 a target of the update, the provided decryption key MUST properly 1822 decrypt the contingency public key, and the digital signature MUST be 1823 validated directly with the decrypted contingency public key. Again, 1824 no delegation via a certification path is permitted. 1826 If the Apex Trust Anchor Update message is validated using the 1827 operational public key, then sequence number processing is handled 1828 normally, as described in Section 6. If the Apex Trust Anchor Update 1829 message is validated using the contingency public key, then the 1830 TAMPMsgRef sequence number MUST contain a zero value. A sequence 1831 number for subsequent messages that will be validated with the new 1832 operational public key can optionally be provided. If no value is 1833 provided, then the cryptographic module MUST be prepared to accept 1834 any sequence number in the next TAMP message validated with the 1835 newly-installed apex trust anchor operational public key. If the 1836 Apex Trust Anchor Update message is valid and the clearTrustAnchors 1837 flag is set to TRUE, then all of the management and identity trust 1838 anchors stored in the cryptographic module MUST be deleted. That is, 1839 the new apex trust anchor MUST be the only trust anchor remaining in 1840 the cryptographic module. If the Apex Trust Anchor Update message is 1841 valid and the clearCommunities flag is set to TRUE, then all 1842 community identifiers stored in the cryptographic module MUST be 1843 deleted. 1845 The SignedData structure includes a sid value, and it identifies the 1846 apex trust anchor public key that will be used to validate the 1847 digital signature on this TAMP message. The public key identifier 1848 for the operational public key is known in advance, and it is stored 1849 as part of the apex trust anchor. The public key identifier for the 1850 contingency public key is not known in advance; however, the presence 1851 of the unsigned attribute containing the symmetric key needed to 1852 decrypt the contingency public key unambiguously indicates that the 1853 TAMP message signer used the contingency private key to sign the Apex 1854 Trust Anchor Update message. 1856 If the digital signature on the Apex Trust Anchor Update message is 1857 valid using either the apex trust anchor operational public key or 1858 the apex trust anchor contingency public key, sequence number 1859 checking is successful, and the cryptographic module is an intended 1860 recipient of the TAMP message, then the cryptographic module MUST 1861 update the apex trust anchor and return an Apex Trust Anchor Update 1862 Confirm message. If an Apex Trust Anchor Update Confirm message is 1863 not returned, then a TAMP Error message MUST be returned. Note that 1864 the sequence number MUST be zero if the Apex Trust Anchor Update 1865 message is validated with the apex trust anchor contingency public 1866 key. 1868 The Apex Trust Anchor Update content type has the following syntax: 1870 tamp-apex-update PKCS7-CONTENT-TYPE ::= 1871 { TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate } 1873 id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 } 1875 TAMPApexUpdate ::= SEQUENCE { 1876 version [0] TAMPVersion DEFAULT v2, 1877 terse [1] TerseOrVerbose DEFAULT verbose, 1878 msgRef TAMPMsgRef, 1879 clearTrustAnchors BOOLEAN, 1880 clearCommunities BOOLEAN, 1881 apexTA TrustAnchorInfo } 1883 The fields of TAMPApexUpdate are used as follows: 1885 o version identifies version of TAMP. For this version of the 1886 specification, the default value, v2, MUST be used. 1888 o terse indicates the type of response that is desired. A terse 1889 response is indicated by a value of 1, and a verbose response is 1890 indicated by a value of 2, which is omitted during encoding since 1891 it is the default value. 1893 o msgRef contains two items: the target and the seqNum. target 1894 identifies the cryptographic module or collection of cryptographic 1895 modules that are the target of the Apex Trust Anchor Update 1896 message. The TargetIdentifier syntax as described in Section 4.1 1897 is used. seqNum is a single use value that will be used to match 1898 the Apex Trust Anchor Update message with the Apex Trust Anchor 1899 Update Confirm message. The sequence number is also used to 1900 detect TAMP message replay if the message is validated with the 1901 apex trust anchor operational public key. The sequence number 1902 processing described in Section 6 MUST successfully complete 1903 before any action is taken. However, seqNum MUST contain a zero 1904 value if the message is validated with the apex trust anchor 1905 contingency public key. 1907 o clearTrustAnchors is a Boolean. If the value is set to TRUE, then 1908 all of the management and identity trust anchors stored in the 1909 cryptographic module MUST be deleted, leaving the newly installed 1910 apex trust anchor as the only trust anchor in the cryptographic 1911 module. If the value is set to FALSE, the other trust anchors 1912 MUST NOT be changed. 1914 o clearCommunities is a Boolean. If the value is set to TRUE, then 1915 all of the community identifiers stored in the cryptographic 1916 module MUST be deleted, leaving none. If the value is set to 1917 FALSE, the list of community identifiers MUST NOT be changed. 1919 o apexTA provides the information for the replacement apex trust 1920 anchor. The TrustAnchorInfo structure is used to provide the 1921 trusted public key and all of the information associated with it. 1922 See Section 3 for a discussion of the TrustAnchorInfo structure; 1923 the taType MUST use the apex choice. The pubKey, keyId, taTitle, 1924 and certPath fields apply to the operational public key of the 1925 apex trust anchor. 1927 4.6. Apex Trust Anchor Update Confirm 1929 The Apex Trust Anchor Update Confirm message is a reply by a 1930 cryptographic module to a valid Apex Trust Anchor Update message. 1931 The Apex Trust Anchor Update Confirm message provides success or 1932 failure information for the apex trust anchor update. The Apex Trust 1933 Anchor Update Confirm message MAY be signed or unsigned. An Apex 1934 Trust Anchor Update Confirm message MUST be signed if the 1935 cryptographic module is capable of signing it. 1937 The Apex Trust Anchor Update Confirm content type has the following 1938 syntax: 1940 tamp-apex-update-confirm PKCS7-CONTENT-TYPE ::= 1941 { TAMPApexUpdateConfirm IDENTIFIED BY 1942 id-ct-TAMP-apexUpdateConfirm } 1944 id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 } 1946 TAMPApexUpdateConfirm ::= SEQUENCE { 1947 version [0] TAMPVersion DEFAULT v2, 1948 apexReplace TAMPMsgRef, 1949 apexConfirm ApexUpdateConfirm } 1951 ApexUpdateConfirm ::= CHOICE { 1952 terseApexConfirm [0] TerseApexUpdateConfirm, 1953 verboseApexConfirm [1] VerboseApexUpdateConfirm } 1955 TerseApexUpdateConfirm ::= StatusCode 1957 VerboseApexUpdateConfirm ::= SEQUENCE { 1958 status StatusCode, 1959 taInfo TrustAnchorInfoList, 1960 communities CommunityIdentifierList OPTIONAL } 1962 The fields of TAMPApexUpdateConfirm are used as follows: 1964 o version identifies version of TAMP. For this version of the 1965 specification, the default value, v2, MUST be used. 1967 o apexReplace identifies the Apex Trust Anchor Update message to 1968 which the cryptographic module is responding. The apexReplace 1969 structure repeats the TAMPMsgRef from the beginning of the Apex 1970 Trust Anchor Update message (see Section 4.5). When the Apex 1971 Trust Anchor Update message is validated with the operational 1972 public key, the sequence number processing described in Section 6 1973 MUST successfully complete before an Apex Trust Anchor Update 1974 Confirm message is generated. When the Apex Trust Anchor Update 1975 message is validated with the contingency public key, normal 1976 sequence number processing is ignored, but the seqNum MUST be 1977 zero. 1979 o apexConfirm contains either a terse update confirmation or a 1980 verbose update confirmation. The terse update confirmation is 1981 represented by TerseApexUpdateConfirm, and the verbose response is 1982 represented by VerboseApexUpdateConfirm. 1984 The TerseApexUpdateConfirm contains a single status code, indicating 1985 the success or failure of the apex trust anchor update. If the apex 1986 trust anchor update failed, then the status code provides the reason 1987 for the failure. Each of the status codes is discussed in Section 5. 1989 The fields of VerboseApexUpdateConfirm are used as follows: 1991 o status contains a single status code, indicating the success or 1992 failure of the apex trust anchor update. If the apex trust anchor 1993 update failed, then the status code provides the reason for the 1994 failure. Each of the status codes is discussed in Section 5. 1996 o taInfo contains a sequence of TrustAnchorInfo structures. One 1997 entry in the sequence is provided for each trust anchor contained 1998 in the cryptographic module. These represent the state of the 1999 trust anchors after the apex trust anchor update has been 2000 processed. See Section 3 for a description of the TrustAnchorInfo 2001 structure. The apex trust anchor is the first trust anchor in the 2002 sequence. 2004 o communities is OPTIONAL. When present, it contains a sequence of 2005 object identifiers. Each object identifier names one community to 2006 which this cryptographic module belongs. When the module belongs 2007 to no communities, this field is omitted. 2009 4.7. Community Update 2011 The cryptographic module maintains a list of identifiers for the 2012 communities of which it is a member. The Community Update message 2013 can be used to remove or add community identifiers from this list. 2014 The Community Update message MUST be signed. For the Community 2015 Update message to be valid, the cryptographic module MUST be a target 2016 of the update, the sequence number checking described in Section 6 2017 MUST be successful when the TAMP message source is a trust anchor, 2018 and the digital signature MUST be validated by the apex trust anchor 2019 operational public key, a management trust anchor authorized for the 2020 id-ct-TAMP-communityUpdate content type, or via an X.509 2021 certification path originating with such a trust anchor. 2023 If the cryptographic module supports the Community Update message, 2024 the digital signature on the Community Update message is valid, 2025 sequence number checking is successful, the signer is authorized for 2026 the id-ct-TAMP-communityUpdate content type, and the cryptographic 2027 module is an intended recipient of the TAMP message, then the 2028 cryptographic module MUST make the specified updates and return a 2029 Community Update Confirm message. If a Community Update Confirm 2030 message is not returned, then, a TAMP Error message MUST be returned. 2032 The Community Update message contains a batch of updates, and all of 2033 the updates MUST be accepted for the cryptographic module to return a 2034 successful Community Update Confirm message. The remove updates, if 2035 present, MUST be processed before the add updates. This approach 2036 prevents community identifiers that are intended to be mutually 2037 exclusive from being installed by a successful addition and a failed 2038 removal. 2040 The Community Update content type has the following syntax: 2042 tamp-community-update PKCS7-CONTENT-TYPE ::= 2043 { TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate } 2045 id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 } 2047 TAMPCommunityUpdate ::= SEQUENCE { 2048 version [0] TAMPVersion DEFAULT v2, 2049 terse [1] TerseOrVerbose DEFAULT verbose, 2050 msgRef TAMPMsgRef, 2051 updates CommunityUpdates } 2053 CommunityUpdates ::= SEQUENCE { 2054 add [1] CommunityIdentifierList OPTIONAL, 2055 remove [2] CommunityIdentifierList OPTIONAL } 2056 -- At least one MUST be present 2058 The fields of TAMPCommunityUpdate are used as follows: 2060 o version identifies version of TAMP. For this version of the 2061 specification, the default value, v2, MUST be used. 2063 o terse indicates the type of response that is desired. A terse 2064 response is indicated by a value of 1, and a verbose response is 2065 indicated by a value of 2, which is omitted during encoding since 2066 it is the default value. 2068 o msgRef contains two items: the target and the seqNum. target 2069 identifies the cryptographic module or collection of 2070 cryptographicmodules that are the target of the update message. 2071 The TargetIdentifier syntax as described in Section 4.1 is used. 2072 seqNum is a single use value that will be used to match the 2073 Community Update message with the Community Update Confirm 2074 message. The sequence number is also used to detect TAMP message 2075 replay. The sequence number processing described in Section 6 2076 MUST successfully complete before any of the updates are 2077 processed. 2079 o updates contains a sequence of community identifiers to be removed 2080 and a sequence of community identifiers to be added. These are 2081 represented by the CommunityUpdates structure. 2083 The CommunityUpdates is a sequence of two OPTIONAL sequences, but at 2084 least one of these sequences MUST be present. The first sequence 2085 contains community identifiers to be removed, and if there are none, 2086 it is absent. The second sequence contains community identifiers to 2087 be added, and if there are none, it is absent. The remove updates, 2088 if present, MUST be processed before the add updates. An error is 2089 generated if any of the requested removals or additions cannot be 2090 accomplished. However, requests to remove community identifiers that 2091 are not present are treated as successful removals. Likewise, 2092 requests to add community identifiers that are already present are 2093 treated as successful additions. If an error is generated, the 2094 cryptographic module community list MUST NOT be changed. 2096 A description of the syntax associated with each of these actions 2097 follows: 2099 o remove is used to remove one or more community identifiers from 2100 the cryptographic module. 2102 o add is used to insert one or more new community identifiers into 2103 the cryptographic module. 2105 4.8. Community Update Confirm 2107 The Community Update Confirm message is a reply by a cryptographic 2108 module to a valid Community Update message. The Community Update 2109 Confirm message provides success or failure information for the 2110 requested updates. Success is returned only if the whole batch of 2111 updates is successfully processed. If any of the requested updates 2112 cannot be performed, then a failure is indicated, and the set of 2113 community identifiers stored in the cryptographic module is 2114 unchanged. The Community Update Confirm message MAY be signed or 2115 unsigned. A Community Update Confirm message MUST be signed if the 2116 cryptographic module is capable of signing it. 2118 The Community Update Confirm content type has the following syntax: 2120 tamp-community-update-confirm PKCS7-CONTENT-TYPE ::= 2121 { TAMPCommunityUpdateConfirm IDENTIFIED BY 2122 id-ct-TAMP-communityUpdateConfirm } 2124 id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= 2125 { id-tamp 8 } 2127 TAMPCommunityUpdateConfirm ::= SEQUENCE { 2128 version [0] TAMPVersion DEFAULT v2, 2129 update TAMPMsgRef, 2130 commConfirm CommunityConfirm } 2132 CommunityConfirm ::= CHOICE { 2133 terseCommConfirm [0] TerseCommunityConfirm, 2134 verboseCommConfirm [1] VerboseCommunityConfirm } 2136 TerseCommunityConfirm ::= StatusCode 2138 VerboseCommunityConfirm ::= SEQUENCE { 2139 status StatusCode, 2140 communities CommunityIdentifierList OPTIONAL } 2142 The fields of TAMPCommunityUpdateConfirm are used as follows: 2144 o version identifies version of TAMP. For this version of the 2145 specification, the default value, v2, MUST be used. 2147 o update identifies the Community Update message to which the 2148 cryptographic module is responding. The update structure repeats 2149 the TAMPMsgRef from the Community Update message (see Section 2150 4.7). The sequence number processing described in Section 6 MUST 2151 successfully complete before any of the updates are processed. 2153 o commConfirm contains either a terse community update confirmation 2154 or a verbose community update confirmation. The terse response is 2155 represented by TerseCommunityConfirm, and the verbose response is 2156 represented by VerboseCommunityConfirm. 2158 The TerseCommunityConfirm contains a single status code, indicating 2159 the success or failure of the Community Update message has been 2160 processed. If the community update failed, then the status code 2161 indicates the reason for the failure. Each of the status codes is 2162 discussed in Section 5. 2164 The fields of VerboseCommunityConfirm are used as follows: 2166 o status contains a single status code, indicating the success or 2167 failure of the Community Update message has been processed. If 2168 the community update failed, then the status code indicates the 2169 reason for the failure. Each of the status codes is discussed in 2170 Section 5. 2172 o communities contains the sequence of community identifiers present 2173 in the cryptographic module after the update is processed. When 2174 the module belongs to no communities, this field is omitted. 2176 4.9. Sequence Number Adjust 2178 The cryptographic module maintains the current sequence number for 2179 the apex trust anchor and each management trust anchor. Sequence 2180 number processing is discussed in Section 6. The Sequence Number 2181 Adjust message can be used provide the most recently used sequence 2182 number to one or more cryptographic modules, thereby reducing the 2183 possibility of replay. The Sequence Number Adjust message MUST be 2184 signed. For the Sequence Number Adjust message to be valid, the 2185 cryptographic module MUST be an intended recipient of the Sequence 2186 Number Adjust message, the sequence number MUST be equal to or larger 2187 than the most recently stored sequence number for the originating 2188 trust anchor, and the digital signature MUST be validated by the apex 2189 trust anchor operational public key or a management trust anchor that 2190 is authorized for the id-ct-TAMP-seqNumAdjust content type. 2192 If the digital signature on the Sequence Number Adjust message is 2193 valid, the sequence number is equal to or larger than the most 2194 recently stored sequence number for the originating trust anchor, the 2195 signer is authorized for the id-ct-TAMP-seqNumAdjust content type, 2196 and the cryptographic module is an intended recipient of the TAMP 2197 message, then the cryptographic module MUST update the sequence 2198 number associated with the originating trust anchor and return a 2199 Sequence Number Adjust Confirm message. If a Sequence Number Adjust 2200 Confirm message is not returned, then a TAMP Error message MUST be 2201 returned. 2203 The Sequence Number Adjust message contains an adjustment for the 2204 sequence number of the TAMP message signer. 2206 The Sequence Number Adjust content type has the following syntax: 2208 tamp-sequence-number-adjust PKCS7-CONTENT-TYPE ::= 2209 { SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust } 2211 id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 } 2213 SequenceNumberAdjust ::= SEQUENCE { 2214 Version [0] TAMPVersion DEFAULT v2, 2215 msgRef TAMPMsgRef } 2217 The fields of SequenceNumberAdjust are used as follows: 2219 o version identifies version of TAMP. For this version of the 2220 specification, the default value, v2, MUST be used. 2222 o msgRef contains two items: the target and the seqNum. target 2223 identifies the cryptographic module or collection of cryptographic 2224 modules that are the target of the sequence number adjust message. 2225 The TargetIdentifier syntax as described in Section 4.1 is used. 2226 The allModules target is expected to be used for Sequence Number 2227 Adjust messages. seqNum MUST be equal to or larger than the most 2228 recently stored sequence number for this TAMP message source, and 2229 the value will be used to match the Sequence Number Adjust message 2230 with the Sequence Number Adjust Confirm message. The sequence 2231 number processing described in Section 6 applies, except that the 2232 sequence number in a Sequence Number Adjust message is acceptable 2233 if it matches the most recently stored sequence number for this 2234 TAMP message source. If sequence number checking completes 2235 successfully, then the sequence number is adjusted, otherwise it 2236 remains unchanged. 2238 4.10. Sequence Number Adjust Confirm 2240 The Sequence Number Adjust Confirm message is a reply by a 2241 cryptographic module to a valid Sequence Number Adjust message. The 2242 Sequence Number Adjust Confirm message provides success or failure 2243 information. Success is returned only if the sequence number for the 2244 trust anchor that signed the Sequence Number Adjust message 2245 originator is adjusted. If the sequence number cannot be adjusted, 2246 then a failure is indicated, and the sequence number stored in the 2247 cryptographic module is unchanged. The Sequence Number Adjust 2248 Confirm message MAY be signed or unsigned. A Sequence Number Adjust 2249 Confirm message MUST be signed if the cryptographic module is capable 2250 of signing it. 2252 The Sequence Number Adjust Confirm content type has the following 2253 syntax: 2255 tamp-sequence-number-adjust-confirm PKCS7-CONTENT-TYPE ::= 2256 { SequenceNumberAdjustConfirm IDENTIFIED BY 2257 id-ct-TAMP-seqNumAdjustConfirm } 2259 id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= 2260 { id-tamp 11 } 2262 SequenceNumberAdjustConfirm ::= SEQUENCE { 2263 version [0] TAMPVersion DEFAULT v2, 2264 adjust TAMPMsgRef, 2265 status StatusCode } 2267 The fields of SequenceNumberAdjustConfirm are used as follows: 2269 o version identifies version of TAMP. For this version of the 2270 specification, the default value, v2, MUST be used. 2272 o adjust identifies the Sequence Number Adjust message to which the 2273 cryptographic module is responding. The adjust structure repeats 2274 the TAMPMsgRef from the Sequence Number Adjust message (see 2275 Section 4.9). The sequence number processing described in Section 2276 6 MUST successfully complete to adjust the sequence number 2277 associated with the Sequence Number Adjust message originator. 2279 o status contains a single status code, indicating the success or 2280 failure of the Sequence Number Adjust message processing. If the 2281 adjustment failed, then the status code indicates the reason for 2282 the failure. Each of the status codes is discussed in Section 5. 2284 4.11. TAMP Error 2286 The TAMP Error message is a reply by a cryptographic module to any 2287 invalid TAMP message. The TAMP Error message provides an indication 2288 of the reason for the error. The TAMP Error message MAY be signed or 2289 unsigned. A TAMP Error message MUST be signed if the cryptographic 2290 module is capable of signing it. 2292 The object identifier names the TAMP Error message content: 2294 tamp-error PKCS7-CONTENT-TYPE ::= 2295 { TAMPError IDENTIFIED BY id-ct-TAMP-error } 2297 id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 } 2299 TAMPError ::= SEQUENCE { 2300 version [0] TAMPVersion DEFAULT v2, 2301 msgType OBJECT IDENTIFIER, 2302 status StatusCode, 2303 msgRef TAMPMsgRef OPTIONAL } 2305 The fields of TAMPError are used as follows: 2307 o version identifies version of TAMP. For this version of the 2308 specification, the default value, v2, MUST be used. 2310 o msgType indicates the content type of the TAMP message that caused 2311 the error. 2313 o status contains a status code that indicates the reason for the 2314 error. Each of the status codes is discussed in Section 5. 2316 o msgRef is OPTIONAL, but whenever possible it SHOULD be present. 2317 It identifies the TAMP message that caused the error. It repeats 2318 the target and seqNum from the TAMP message that caused the error 2319 (see Sections 4.1, 4.3, 4.5, 4.7 and 4.9). 2321 5. Status Codes 2323 The Trust Anchor Update Confirm, the Apex Trust Anchor Update 2324 Confirm, the Community Update Confirm, the Sequence Number Adjust 2325 Confirm, and the TAMP Error messages include status codes. The 2326 syntax for the status codes is: 2328 StatusCode ::= ENUMERATED { 2329 success (0), 2330 decodeFailure (1), 2331 badContentInfo (2), 2332 badSignedData (3), 2333 badEncapContent (4), 2334 badCertificate (5), 2335 badSignerInfo (6), 2336 badSignedAttrs (7), 2337 badUnsignedAttrs (8), 2338 missingContent (9), 2339 noTrustAnchor (10), 2340 notAuthorized (11), 2341 badDigestAlgorithm (12), 2342 badSignatureAlgorithm (13), 2343 unsupportedKeySize (14), 2344 unsupportedParameters (15), 2345 signatureFailure (16), 2346 insufficientMemory (17), 2347 unsupportedTAMPMsgType (18), 2348 apexTAMPAnchor (19), 2349 improperTAAddition (20), 2350 seqNumFailure (21), 2351 contingencyPublicKeyDecrypt (22), 2352 incorrectTarget (23), 2353 communityUpdateFailed (24), 2354 trustAnchorNotFound (25), 2355 unsupportedTAAlgorithm (26), 2356 unsupportedTAKeySize (27), 2357 unsupportedContinPubKeyDecryptAlg (28), 2358 missingSignature (29), 2359 resourcesBusy (30), 2360 versionNumberMismatch (31), 2361 missingPolicySet (32), 2362 revokedCertificate (33), 2363 other (127) } 2365 The various values of StatusCode are used as follows: 2367 o success is used to indicate that an update, portion of an update, 2368 or adjust was processed successfully. 2370 o decodeFailure is used to indicate that the cryptographic module 2371 was unable to successfully decode the provided message. The 2372 specified content type and the provided content do not match. 2374 o badContentInfo is used to indicate that the ContentInfo syntax is 2375 invalid or that the contentType carried within the ContentInfo is 2376 unknown or unsupported. 2378 o badSignedData is used to indicate that the SignedData syntax is 2379 invalid, the version is unknown or unsupported, or more than one 2380 entry is present in digestAlgorithms. 2382 o badEncapContent is used to indicate that the 2383 EncapsulatedContentInfo syntax is invalid. This error can be 2384 generated due to problems located in SignedData. 2386 o badCertificate is used to indicate that the syntax for one or more 2387 certificates in CertificateSet is invalid. 2389 o badSignerInfo is used to indicate that the SignerInfo syntax is 2390 invalid, or the version is unknown or unsupported. 2392 o badSignedAttrs is used to indicate that the signedAttrs syntax 2393 within SignerInfo is invalid. 2395 o badUnsignedAttrs is used to indicate that the unsignedAttrs within 2396 SignerInfo contains an attribute other than the contingency- 2397 public-key-decrypt-key unsigned attribute, which is the only 2398 unsigned attribute supported by this specification. 2400 o missingContent is used to indicate that the OPTIONAL eContent is 2401 missing in EncapsulatedContentInfo, which is REQUIRED in this 2402 specification. This error can be generated due to problems 2403 located in SignedData. 2405 o noTrustAnchor is used to indicate one of two possible error 2406 situations. In one case, the subjectKeyIdentifier does not 2407 identify the public key of a trust anchor or a certification path 2408 that terminates with an installed trust anchor. In the other 2409 case, the issuerAndSerialNumber is used to identify the TAMP 2410 message signer, which is prohibited by this specification. 2412 o notAuthorized is used to indicate one of two possible error 2413 situations. In one case the sid within SignerInfo leads to an 2414 installed trust anchor, but that trust anchor is not an authorized 2415 signer for the received TAMP message content type. Identity trust 2416 anchors are not authorized signers for any of the TAMP message 2417 content types. In the other case, the signer of a Trust Anchor 2418 Update message is not authorized to manage the to-be-updated trust 2419 anchor as determined by a failure of the subordination processing 2420 in Sec. 7. 2422 o badDigestAlgorithm is used to indicate that the digestAlgorithm in 2423 either SignerInfo or SignedData is unknown or unsupported. 2425 o badSignatureAlgorithm is used to indicate that the 2426 signatureAlgorithm in SignerInfo is unknown or unsupported. 2428 o unsupportedKeySize is used to indicate that the signatureAlgorithm 2429 in SignerInfo is known and supported, but the TAMP message digital 2430 signature could not be validated because an unsupported key size 2431 was employed by the signer. 2433 o unsupportedParameters is used to indicate that the 2434 signatureAlgorithm in SignerInfo is known, but the TAMP message 2435 digital signature could not be validated because unsupported 2436 parameters were employed by the signer. 2438 o signatureFailure is used to indicate that the signatureAlgorithm 2439 in SignerInfo is known and supported, but the digital signature in 2440 the signature field within SignerInfo could not be validated. 2442 o insufficientMemory indicates that the update could not be 2443 processed because the cryptographic module did not have sufficient 2444 memory to store the resulting trust anchor configuration or 2445 community identifier. 2447 o unsupportedTAMPMsgType indicates that the TAMP message could not 2448 be processed because the cryptographic module does not support the 2449 provided TAMP message type. This code will be used if the id-ct- 2450 TAMP-communityUpdate content type is provided and the 2451 cryptographic module does not support the Community Update 2452 message. This status code will also be used if the contentType 2453 value within eContentType is not one that is defined in this 2454 specification. 2456 o apexTAMPAnchor indicates that the update could not be processed 2457 because the Trust Anchor Update message tried to remove the apex 2458 trust anchor. 2460 o improperTAAddition indicates that a trust anchor update is trying 2461 to add a new trust anchor that may already exist, but some 2462 attributes of the to-be-added trust anchor are being modified in 2463 an improper manner. The desired trust anchor configuration may be 2464 attainable with a change operation instead of an add operation. 2466 o seqNumFailure indicates that the TAMP message could not be 2467 processed because the processing of the sequence number, which is 2468 described in Section 6, resulted in an error. 2470 o contingencyPublicKeyDecrypt indicates that the update could not be 2471 processed because an error occurred while decrypting the 2472 contingency public key. 2474 o incorrectTarget indicates that the query, update, or adjust 2475 message could not be processed because the cryptographic module is 2476 not the intended recipient. The target cryptographic module is 2477 identified in one of two ways. HardwareModule identifies the 2478 cryptographic module by the module type and serial number; in 2479 which case, either one or both of these values does not match the 2480 responding cryptographic module. Alternatively, community 2481 identifies a group of cryptographic modules; in which case, the 2482 responding cryptographic module does not belong to the identified 2483 group. 2485 o communityUpdateFailed indicates that the community update 2486 requested the addition of a community identifier or the removal of 2487 a community identifier, but the request could not be honored. 2489 o trustAnchorNotFound indicates that a change to a trust anchor was 2490 requested, but the referenced trust anchor is not represented in 2491 the cryptographic module. 2493 o unsupportedTAAlgorithm indicates that an update message would 2494 result in the trust anchor with a public key associated with a 2495 digital signature validation algorithm that is not implemented in 2496 the cryptographic module. In addition, this status code is used 2497 if the algorithm is supported, but the parameters associated with 2498 the algorithm are not supported. 2500 o unsupportedTAKeySize indicates that the trust anchor would include 2501 a public key of a size that is not supported. 2503 o unsupportedContinPubKeyDecryptAlg indicates that the decryption 2504 algorithm for the apex trust anchor contingency public key is not 2505 supported. 2507 o missingSignature indicates that an unsigned TAMP message was 2508 received, but the received TAMP message type MUST be signed. 2510 o resourcesBusy indicates that the resources necessary to process 2511 the TAMP message are not available at the present time, but the 2512 resources might be available at some point in the future. 2514 o versionNumberMismatch indicates that the version number in a 2515 received TAMP message is not acceptable. 2517 o missingPolicySet indicates that the policyFlags associated with a 2518 trust anchor are set in a fashion that requires the policySet to 2519 be present, but the policySet is missing. 2521 o revokedCertificate indicates that one or more of the certificates 2522 needed to properly process the TAMP message has been revoked. 2524 o other indicates that the update could not be processed, but the 2525 reason is not covered by any of the assigned status codes. Use of 2526 this status code SHOULD be avoided. 2528 6. Sequence Number Processing 2530 The sequence number processing facilities in TAMP represent a balance 2531 between replay protection, operational considerations, and 2532 cryptographic module memory management. The goal is to provide 2533 replay protection without making TAMP difficult to use, creating an 2534 environment where surprising error conditions occur on a regular 2535 basis, or imposing onerous memory management requirements on 2536 implementations. This balance is achieved by performing sequence 2537 number checking on TAMP messages that are signed directly by a trust 2538 anchor, and skipping these checks whenever the TAMP message 2539 originator is represented by a certificate. 2541 The TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update, 2542 Community Update, and Sequence Number Adjust messages include a 2543 sequence number. This single-use identifier is used to match a TAMP 2544 message with the response to that TAMP message. When the TAMP 2545 message is signed directly by a trust anchor, the sequence number is 2546 also used to detect TAMP message replay. 2548 To provide replay protection, each TAMP message originator MUST treat 2549 the sequence number as a monotonically increasing non-negative 2550 integer. The sequence number counter is associated with the signing 2551 operation performed by the private key. The cryptographic module 2552 MUST ensure that a newly received TAMP message that is validated 2553 directly by a trust anchor public key contains a sequence number that 2554 is greater than the most recent successfully processed TAMP message 2555 from that originator. Note that the Sequence Number Adjust message 2556 is considered valid if the sequence number is greater than or equal 2557 to the most recent successfully processed TAMP message from that 2558 originator. If the sequence number in a received TAMP message does 2559 not meet these conditions, then the cryptographic module MUST reject 2560 the TAMP message, returning a sequence number failure (seqNumFailure) 2561 error. 2563 Whenever a trust anchor is authorized for TAMP messages, either as a 2564 newly installed trust anchor or as a modification to an existing 2565 trust anchor, if a sequence number value is not provided in the Trust 2566 Anchor Update message, memory MUST be allocated for the sequence 2567 number and set to zero. The first TAMP message signed by that trust 2568 anchor is not rejected based on sequence number checks, and the 2569 sequence number from that first TAMP message is stored. The sequence 2570 number for that trust anchor could also be updated by the OPTIONAL 2571 sequence number field of a Trust Anchor Update message that is 2572 received after the trust anchor is installed. The TAMP message 2573 recipient MUST maintain a database of the most recent sequence number 2574 from a successfully processed TAMP message from each trust anchor. 2575 The index for this database is the trust anchor public key. This 2576 could be the apex trust anchor operational public key or a management 2577 trust anchor public key. In the first case, the apex trust anchor 2578 operational public key is used directly to validate the TAMP message 2579 digital signature. In the second case, a management trust anchor 2580 public key is used directly to validate the TAMP message digital 2581 signature. 2583 Sequence number values MUST be 64-bit non-negative integers. Since 2584 ASN.1 encoding of an INTEGER always includes a sign bit, a TAMP 2585 message signer can generate 9,223,372,036,854,775,807 TAMP messages 2586 before exhausting the 64-bit sequence number space, before which the 2587 TAMP message signer MUST transition to a different public/private key 2588 pair. The ability to reset a sequence number provided by the Trust 2589 Anchor Update and Sequence Number Adjust messages is not intended to 2590 avoid the transition to a different key pair; rather, it is intended 2591 to aid recovery from operational errors. A relatively small non- 2592 volatile storage requirement is imposed on the cryptographic module 2593 for the apex trust anchor and each management trust anchor. 2595 When the apex trust anchor or a management trust anchor is replaced 2596 or removed from the cryptographic module, the associated sequence 2597 number storage SHOULD be reclaimed. 2599 7. Subordination Processing 2601 The apex trust anchor is unconstrained, which means that 2602 subordination checking is not performed on Trust Anchor Update 2603 messages signed with the apex trust anchor operational public key. 2604 Subordination checking is performed as part of the validation process 2605 of all other Trust Anchor Update messages. 2607 For a Trust Anchor Update message that is not signed with the apex 2608 trust anchor operational public key to be valid, the digital 2609 signature MUST be validated using a management trust anchor 2610 associated with the id-ct-TAMP-update content type, either directly 2611 or via an X.509 certification path originating with the apex trust 2612 anchor operational public key or such a management trust anchor. The 2613 following subordination checks MUST also be performed as part of 2614 validation. 2616 Each Trust Anchor Update message contains one or more individual 2617 updates, each of which is used to add, modify or remove a trust 2618 anchor. For each individual update the privileges of the TAMP 2619 message signer MUST be greater than or equal to the privileges of the 2620 trust anchor in the update. The privileges of the TAMP message 2621 signer and the to-be-updated trust anchor are determined based on the 2622 applicable CMS Content Constraints. Specifically, the privileges of 2623 the TAMP message signer are determined as described in section 3 of 2624 [CCC] passing the special value anyContentType and an empty set of 2625 attributes as input; the privileges of the to-be-updated trust anchor 2626 are determined as described below. If the privileges of a trust 2627 anchor in an update exceed the privileges of the signer, that update 2628 MUST be rejected. Each update is considered and accepted or rejected 2629 individually without regard to other updates in the TAMP message. 2630 The privileges of the to-be-updated trust anchors are determined as 2631 follows: 2633 o If the to-be-updated trust anchor is the subject of an add 2634 operation, the privileges are read from the taType.mgmt.taUsage 2635 field of the corresponding TrustAnchorInfo in the update. 2637 o If the to-be-updated trust anchor is the subject of a remove 2638 operation, the trust anchor is located in the message recipient's 2639 trust anchor store using the public key included in the update. 2640 The privileges are read from the taType.mgmt.taUsage (or 2641 equivalent) field in the to-be-updated trust anchor. 2643 o If the to-be-updated trust anchor is the subject of a change 2644 operation, the trust anchor has two distinct sets of privileges 2645 that MUST be checked. The trust anchor's pre-change privileges 2646 are determined by locating the trust anchor in the message 2647 recipient's trust anchor store using the public key included in 2648 the update and reading the privileges from the taType.mgmt.taUsage 2649 (or equivalent) field in the trust anchor. The trust anchor's 2650 post-change privileges are read from the taType.mgmt.taUsage field 2651 of the corresponding TrustAnchorChangeInfo in the update. If the 2652 taType.mgmt.taUsage field is not present, then the trust anchor's 2653 post-change privileges are equivalent to the trust anchor's pre- 2654 change privileges. 2656 The following steps can be used to determine if a Trust Anchor Update 2657 message signer is authorized to manage each to-be-updated trust 2658 anchor contained in a Trust Anchor Update message. 2660 o The TAMP message signer's CMS Content Constraints privileges are 2661 determined as described in section 3 of [CCC] passing the special 2662 value anyContentType and an empty set of attributes as input. 2663 Note that it is possible for the TAMP message signer to have more 2664 than one possible certification path that will authorize it to 2665 sign Trust Anchor Update messages, with each certification path 2666 resulting in different CMS Content Constraints privileges. The 2667 update is authorized if the processing below succeeds for any one 2668 certification path of the TAMP message signer. The resulting 2669 cms_permitted_content_types variable is used to check each to-be- 2670 updated trust anchor contained in the update message. The message 2671 signer MUST be authorized for the Trust Anchor Update message. 2672 This can be confirmed using the steps described in section 4 of 2673 [CCC]. 2675 o The privileges of each to-be-updated trust anchor in the TAMP 2676 message MUST be checked against the message signer's privileges 2677 (represented in the message signer's cms_permitted_content_types 2678 computed above) using the following steps. For change operations, 2679 the following steps MUST be performed for the trust anchor's pre- 2680 change privileges and the trust anchor's post-change privileges. 2682 * Operations on identity trust anchors are permitted provided the 2683 message signer is authorized for the Trust Anchor Update 2684 message. 2686 * If the to-be-updated trust anchor is unconstrained, the message 2687 signer MUST also be unconstrained, i.e., the message signer's 2688 cms_permitted_content_types MUST be set to the special value 2689 anyContentType. If the to-be-updated trust anchor is 2690 unconstrained and the message signer is not, then the message 2691 signer is not authorized to manage the trust anchor and the 2692 update MUST be rejected. 2694 * The message signer's authorization for each permitted content 2695 type MUST be checked using the state variables and procedures 2696 similar to those described in sections 3.2 and 3.3 of [CCC]. 2697 For each permitted content type in the to-be-updated trust 2698 anchor's privileges, 2700 + Set cms_effective_attributes equal to the value of the 2701 attrConstraints field from the permitted content type. 2703 + If the content type does not match an entry in the message 2704 signer's cms_permitted_content_types, the message signer is 2705 not authorized to manage the trust anchor and the update 2706 MUST be rejected. Note, the special value anyContentType 2707 produces a match for all content types with the resulting 2708 matching entry containing the content type, canSource set to 2709 TRUE and attrConstraints absent. 2711 + If the content type matches an entry in the message signer's 2712 cms_permitted_content_types, the canSource field of the 2713 entry is FALSE and the canSource field in the to-be-updated 2714 trust anchor's privilege is TRUE, the message signer is not 2715 authorized to manage the trust anchor and the update MUST be 2716 rejected. 2718 + If the content type matches an entry in the message signer's 2719 cms_permitted_content_types and the entry's attrConstraints 2720 field is present, then constraints MUST be checked. For 2721 each attrType in the entry's attrConstraints, a 2722 corresponding attribute MUST be present in 2723 cms_effective_attributes containing values from the entry's 2724 attrConstraints. If values appear in the corresponding 2725 attribute that are not in the entry's attrConstraints or if 2726 there is no corresponding attribute, the message signer is 2727 not authorized to manage the trust anchor and the update 2728 MUST be rejected. 2730 Once these steps are completed, if the update has not been rejected, 2731 then the message signer is authorized to manage the to-be-updated 2732 trust anchor. 2734 Note that a management trust anchor that has only the id-ct-TAMP- 2735 update permitted content type is useful only for managing identity 2736 trust anchors. It can sign a Trust Anchor Update message, but it 2737 cannot impact a management trust anchor that is associated with any 2738 other content type. 2740 8. Implementation Considerations 2742 A public key identifier is used to identify a TAMP message signer. 2743 Since there is no guarantee that the same public key identifier is 2744 not associated with more than one public key, implementations MUST be 2745 prepared for one or more trust anchor to have the same public key 2746 identifier. In practical terms, this means that when a digital 2747 signature validation fails, the implementation MUST see if there is 2748 another trust anchor with the same public key identifier that can be 2749 used to validate the digital signature. While duplicate public key 2750 identifiers are expected to be rare, implementations MUST NOT fail to 2751 find the correct trust anchor when they do occur. 2753 An X.500 distinguished name is used to identify certificate issuers 2754 and certificate subjects. The same X.500 distinguished name can be 2755 associated with more than one trust anchor. However, the trust 2756 anchor public key will be different. The probability that two trust 2757 anchors will have the same X.500 distinguished name and the same 2758 public key identifier but a different public key is diminishingly 2759 small. Therefore, the authority key identifier certificate extension 2760 can be used to resolve X.500 distinguished name collisions. 2762 9. Security Considerations 2764 The majority of this specification is devoted to the syntax and 2765 semantics of TAMP messages. It relies on other specifications, 2766 especially [RFC3852] and [RFC3280], for the syntax and semantics of 2767 CMS protecting content types and X.509 certificates, respectively. 2768 Since TAMP messages that change the trust anchor state of a 2769 cryptographic module are always signed by a Trust Anchor Manager, no 2770 further data integrity or data origin authentication mechanisms are 2771 needed; however, no confidentiality for these messages is provided. 2772 Similarly, certificates are digitally signed, and no additional data 2773 integrity or data origin authentication mechanisms are needed. Trust 2774 anchor configurations, Trust Anchor Manager certificates, and 2775 cryptographic module certificates are not intended to be sensitive. 2776 As a result, this specification does not provide for confidentiality 2777 of TAMP messages. 2779 Security factors outside the scope of this specification greatly 2780 affect the assurance provided. The procedures used by certification 2781 authorities (CAs) to validate the binding of the subject identity to 2782 their public key greatly affect the assurance associated with the 2783 resulting certificate. This is particularly important when issuing 2784 certificates to other CAs. In the context of TAMP, the issuance of 2785 an end entity certificate under a management trust anchor is an act 2786 of delegation. However, such end entities cannot further delegate. 2787 On the other hand, issuance of a CA certificate under a management 2788 trust anchor is an act of delegation where the CA can perform further 2789 delegation. The scope of the delegation can be constrained by 2790 including a CMS content constraints certificate extension [CCC] in a 2791 CA certificate. 2793 X.509 certification path construction involves comparison of X.500 2794 distinguished names. Inconsistent application of name comparison 2795 rules can result in acceptance of invalid X.509 certification paths 2796 or rejection of valid ones. Name comparison can be extremely 2797 complex. To avoid imposing this complexity on cryptographic modules, 2798 any certificate profile used with TAMP SHOULD employ simple name 2799 structures and impose rigorous restrictions on acceptable 2800 distinguished names, including the way that they are encoded. The 2801 goal of that certificate profile should be to enable simple binary 2802 comparison. That is, case conversion, character set conversion, 2803 white space compression, and leading and trailing white space 2804 trimming SHOULD be avoided. 2806 Some digital signature algorithms require the generation of random 2807 one-time values. For example, when generating a DSA digital 2808 signature, the signer MUST generate a random k value [DSS]. Also, 2809 the generation of public/private key pairs relies on random numbers. 2811 The use of an inadequate random number generator (RNG) or an 2812 inadequate pseudo-random number generator (PRNG) to generate such 2813 cryptographic values can result in little or no security. An 2814 attacker may find it much easier to reproduce the random number 2815 generation environment, searching the resulting small set of 2816 possibilities, rather than brute force searching the whole space. 2818 Compromise of an identity trust anchor private key permits 2819 unauthorized parties to issue certificates that will be acceptable to 2820 all cryptographic modules configured with the corresponding identity 2821 trust anchor. The unauthorized private key holder will be limited by 2822 the certification path controls associated with the identity trust 2823 anchor. For example, clearance constraints in the identity trust 2824 anchor will determine the clearances that will be accepted in 2825 certificates that are issued by the unauthorized private key holder. 2827 Compromise of a management trust anchor private key permits 2828 unauthorized parties to generate signed messages that will be 2829 acceptable to all cryptographic modules configured with the 2830 corresponding management trust anchor. All devices that include the 2831 compromised management trust anchor can be configured as desired by 2832 the unauthorized private key holder within the limits of the 2833 subordination checks described in Section 7. If the management trust 2834 anchor is associated with content types other than TAMP, then the 2835 unauthorized private key holder can generate signed messages of that 2836 type. For example, if the management trust anchor is associated with 2837 firmware packages, then the unauthorized private key holder can 2838 install different firmware into the cryptographic module. 2840 Compromise of the Apex Trust Anchor operational private key permits 2841 unauthorized parties to generate signed messages that will be 2842 acceptable to all cryptographic modules configured with the 2843 corresponding apex trust anchor. All devices that include that apex 2844 trust anchor can be configured as desired by the unauthorized private 2845 key holder, and the unauthorized private key holder can generate 2846 signed messages of any content type. The contingency private key 2847 offers a potential way to recover from such a compromise. 2849 The compromise of a CA's private key leads to the same type of 2850 problems as the compromise of an identity or a management trust 2851 anchor private key. The unauthorized private key holder will be 2852 limited by the certification path controls associated with the trust 2853 anchor. If the CA is subordinate to a management trust anchor, the 2854 scope of potential damage caused by a private key compromise is also 2855 limited by the CMS content constraints certificate extension [CCC] in 2856 the CA certificate, the CMS content constraints on any superior CA 2857 certificates, and the CMS content constraints on the parent 2858 management trust anchor. 2860 The compromise of an end entity private key leads to the same type of 2861 problems as the compromise of an identity or a management trust 2862 anchor private key, except that the end entity is unable to issue any 2863 certificates. The unauthorized private key holder will be limited by 2864 the certification path controls associated with the trust anchor. If 2865 the certified public key is subordinate to a management trust anchor, 2866 the scope of potential damage caused by a private key compromise is 2867 also limited by the CMS content constraints certificate extension 2868 [CCC] in the end entity certificate, the CMS content constraints on 2869 any superior CA certificates, and the CMS content constraints on the 2870 parent management trust anchor. 2872 Compromise of a cryptographic module's digital signature private key 2873 permits unauthorized parties to generate signed TAMP response 2874 messages, masquerading as the cryptographic module. 2876 Premature disclosure of the key-encryption key used to encrypt the 2877 apex trust anchor contingency public key may result in early exposure 2878 of the apex trust anchor contingency public key. 2880 To implement TAMP, a cryptographic module needs to be able to parse 2881 messages and certificates. Care must be taken to ensure that there 2882 are no implementation defects in the TAMP message parser or the 2883 processing that acts on the message content. A validation suite is 2884 one way to increase confidence in the parsing of TAMP messages, CMS 2885 content types, signed attributes, and certificates. 2887 10. IANA Considerations 2889 There are no IANA considerations. Please delete this section prior 2890 to RFC publication. 2892 11. References 2894 11.1. Normative References 2896 [CCC] Housley, R. and C. Wallace, "Cryptographic Message Syntax 2897 (CMS) Content Signature Constraints X.509 Certificate 2898 Extension", in progress. 2900 [ClearConstr] 2901 Turner, S., "Clearance and CA Clearance Constraints 2902 Certificate Extensions", in progress. 2904 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2905 Requirement Levels", BCP 14, RFC 2119, March 1997. 2907 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", 2908 RFC 2634, June 1999. 2910 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 2911 X.509 Public Key Infrastructure Certificate and 2912 Certificate Revocation List (CRL) Profile", RFC 3280, 2913 April 2002. 2915 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2916 10646", STD 63, RFC 3629, November 2003. 2918 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 2919 RFC 3852, July 2004. 2921 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 2922 Representing Date and Time in ASN.1", RFC 4049, 2923 April 2005. 2925 [X.680] "ITU-T Recommendation X.680: Information Technology - 2926 Abstract Syntax Notation One", 1997. 2928 [X.690] "ITU-T Recommendation X.690 Information Technology - ASN.1 2929 encoding rules: Specification of Basic Encoding Rules 2930 (BER), Canonical Encoding Rules (CER) and Distinguished 2931 Encoding Rules (DER)", 1997. 2933 11.2. Informative References 2935 [DSS] "FIPS Pub 186: Digital Signature Standard", May 1994. 2937 [PKCS#6] "PKCS #6: Extended-Certificate Syntax Standard, Version 2938 1.5", November 1993. 2940 [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute 2941 Certificate Profile for Authorization", RFC 3281, 2942 April 2002. 2944 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 2945 Protect Firmware Packages", RFC 4108, August 2005. 2947 [X.208] "ITU-T Recommendation X.208 - Specification of Abstract 2948 Syntax Notation One (ASN.1)", 1988. 2950 [X.501] "ITU-T Recommendation X.501 - The Directory - Models", 2951 1993. 2953 [X.509] "ITU-T Recommendation X.509 - The Directory - 2954 Authentication Framework", 2000. 2956 Appendix A. ASN.1 Modules 2958 Appendix A.1 provides the normative ASN.1 definitions for the 2959 structures described in this specification using ASN.1 as defined in 2960 [X.680]. Appendix A.2 provides a module using ASN.1 as defined in 2961 [X.208]. The module in A.2 removes usage of newer ASN.1 features 2962 that provide support for limiting the types of elements that may 2963 appear in certain SEQUENCE and SET constructions. Otherwise, the 2964 modules are compatible in terms of encoded representation, i.e., the 2965 modules are bits-on-the-wire compatible aside from the limitations on 2966 SEQUENCE and SET constituents. A.2 is included as a courtesy to 2967 developers using ASN.1 compilers that do not support current ASN.1. 2969 A.1. ASN.1 Module Using 1993 Syntax 2971 TrustAnchorManagementProtocolVersion2 2972 { joint-iso-ccitt(2) country(16) us(840) organization(1) 2973 gov(101) dod(2) infosec(1) modules(0) TBD } 2975 DEFINITIONS IMPLICIT TAGS ::= 2976 BEGIN 2978 IMPORTS 2979 ATTRIBUTE, Attribute 2980 FROM InformationFramework -- from [X.501] 2981 { joint-iso-itu-t(2) ds(5) module(1) 2982 informationFramework(1) 4 } 2983 ContentType 2984 FROM CryptographicMessageSyntax2004 -- [RFC3852] 2985 { iso(1) member-body(2) us(840) rsadsi(113549) 2986 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } 2987 AlgorithmIdentifier, Certificate, Name 2988 FROM PKIX1Explicit88 -- from [RFC3280] 2989 { iso(1) identified-organization(3) dod(6) internet(1) 2990 security(5) mechanisms(5) pkix(7) id-mod(0) 2991 id-pkix1-explicit(18) } 2992 CertificatePolicies, KeyIdentifier, NameConstraints 2993 FROM PKIX1Implicit88 -- from 2994 { iso(1) identified-organization(3) dod(6) internet(1) 2995 security(5) mechanisms(5) pkix(7) id-mod(0) 2996 id-pkix1-implicit(19) } 2997 CMSContentConstraints 2998 FROM CMSContentConstraintsCertExtn-93 -- [CCC] 2999 { iso(1) identified-organization(3) dod(6) internet(1) 3000 security(5) mechanisms(5) pkix(7) id-mod(0) 3001 cmsContentConstraints-93(42) } 3002 CAClearanceConstraints 3003 FROM Clearance-CAClearanceConstraints93 -- from [ClearConstr] 3004 { joint-iso-ccitt(2) country(16) us(840) organization(1) 3005 gov(101) dod(2) infosec(1) modules(0) 9997 } ; 3006 -- Placeholder for TBD 3008 -- Trust Anchor Information 3010 TrustAnchorInfo ::= SEQUENCE { 3011 version [0] TAMPVersion DEFAULT v2, 3012 pubKey PublicKeyInfo, 3013 keyId KeyIdentifier, 3014 taType TrustAnchorType, 3015 taTitle TrustAnchorTitle OPTIONAL, 3016 certPath CertPathControls OPTIONAL } 3018 PublicKeyInfo ::= SEQUENCE { 3019 algorithm AlgorithmIdentifier, 3020 publicKey BIT STRING } 3022 KeyIdentifier ::= OCTET STRING 3024 TrustAnchorType ::= CHOICE { 3025 apex [0] ApexTrustAnchorInfo, 3026 mgmt [1] MgmtTrustAnchorInfo, 3027 ident [2] NULL } 3029 ApexTrustAnchorInfo ::= SEQUENCE { 3030 continPubKey ApexContingencyKey, 3031 seqNum SeqNumber OPTIONAL } 3033 ApexContingencyKey ::= SEQUENCE { 3034 wrapAlgorithm AlgorithmIdentifier, 3035 wrappedContinPubKey OCTET STRING } 3037 SeqNumber ::= INTEGER (0..9223372036854775807) 3039 MgmtTrustAnchorInfo ::= SEQUENCE { 3040 taUsage TrustAnchorUsage, 3041 seqNum SeqNumber OPTIONAL } 3043 TrustAnchorUsage ::= CMSContentConstraints 3045 CMSContentConstraints ::= ContentTypeConstraintList 3047 ContentTypeConstraintList ::= SEQUENCE SIZE (1..MAX) OF 3048 ContentTypeConstraint 3050 ContentTypeConstraint ::= SEQUENCE { 3051 contentType ContentType, 3052 canSource BOOLEAN DEFAULT TRUE, 3053 attrConstraints AttrConstraintList OPTIONAL } 3055 AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint 3057 AttrConstraint ::= SEQUENCE { 3058 attrType AttributeType, 3059 attrValues SET SIZE (1..MAX) OF AttributeValue } 3061 ContentType ::= OBJECT IDENTIFIER 3063 TrustAnchorTitle ::= UTF8String (SIZE (1..64)) 3065 CertPathControls ::= SEQUENCE { 3066 taName Name, 3067 selfSigned [0] Certificate OPTIONAL, 3068 policySet [1] CertificatePolicies OPTIONAL, 3069 policyFlags [2] CertPolicyFlags OPTIONAL, 3070 clearanceConstr [3] CAClearanceConstraints OPTIONAL, 3071 nameConstr [4] NameConstraints OPTIONAL } 3073 CertPolicyFlags ::= BIT STRING { 3074 inhibitPolicyMapping (0), 3075 requireExplicitPolicy (1), 3076 inhibitAnyPolicy (2) } 3078 -- Object Identifier Arc for TAMP Message Content Types 3080 id-tamp OBJECT IDENTIFIER ::= { 3081 joint-iso-ccitt(2) country(16) us(840) organization(1) 3082 gov(101) dod(2) infosec(1) formats(2) 77 } 3084 -- CMS Content Types 3086 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 3088 TAMPContentTypes PKCS7-CONTENT-TYPE ::= { 3089 tamp-status-query | 3090 tamp-status-response | 3091 tamp-update | 3092 tamp-update-confirm | 3093 tamp-apex-update | 3094 tamp-apex-update-confirm | 3095 tamp-community-update | 3096 tamp-community-update-confirm | 3097 tamp-sequence-number-adjust | 3098 tamp-sequence-number-adjust-confirm | 3099 tamp-error, 3100 ... -- Expect additional content types -- 3101 } 3103 -- TAMP Status Query Message 3104 tamp-status-query PKCS7-CONTENT-TYPE ::= 3105 { TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery } 3107 id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 } 3109 TAMPStatusQuery ::= SEQUENCE { 3110 version [0] TAMPVersion DEFAULT v2, 3111 terse [1] TerseOrVerbose DEFAULT verbose, 3112 query TAMPMsgRef } 3114 TAMPVersion ::= INTEGER { v1(1), v2(2) } 3116 TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) } 3118 TAMPMsgRef ::= SEQUENCE { 3119 target TargetIdentifier, 3120 seqNum SeqNumber } 3122 TargetIdentifier ::= CHOICE { 3123 hwModules [1] HardwareModuleIdentifierList, 3124 communities [2] CommunityIdentifierList, 3125 allModules [3] NULL } 3127 HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF 3128 HardwareModules 3130 HardwareModules ::= SEQUENCE { 3131 hwType OBJECT IDENTIFIER, 3132 hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry } 3134 HardwareSerialEntry ::= CHOICE { 3135 all NULL, 3136 single OCTET STRING, 3137 block SEQUENCE { 3138 low OCTET STRING, 3139 high OCTET STRING } } 3141 CommunityIdentifierList ::= SEQUENCE SIZE (1..MAX) OF Community 3143 Community ::= OBJECT IDENTIFIER 3144 -- TAMP Status Response Message 3146 tamp-status-response PKCS7-CONTENT-TYPE ::= 3147 { TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse } 3149 id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 } 3151 TAMPStatusResponse ::= SEQUENCE { 3152 version [0] TAMPVersion DEFAULT v2, 3153 query TAMPMsgRef, 3154 response StatusResponse } 3156 StatusResponse ::= CHOICE { 3157 terseResponse [0] TerseStatusResponse, 3158 verboseResponse [1] VerboseStatusResponse } 3160 TerseStatusResponse ::= SEQUENCE { 3161 taKeyIds KeyIdentifiers, 3162 communities CommunityIdentifierList OPTIONAL } 3164 KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier 3166 VerboseStatusResponse ::= SEQUENCE { 3167 taInfo TrustAnchorInfoList, 3168 continPubKeyDecryptAlg AlgorithmIdentifier, 3169 communities CommunityIdentifierList OPTIONAL } 3171 TrustAnchorInfoList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorInfo 3173 -- Trust Anchor Update Message 3175 tamp-update PKCS7-CONTENT-TYPE ::= 3176 { TAMPUpdate IDENTIFIED BY id-ct-TAMP-update } 3178 id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 } 3180 TAMPUpdate ::= SEQUENCE { 3181 version [0] TAMPVersion DEFAULT v2, 3182 terse [1] TerseOrVerbose DEFAULT verbose, 3183 msgRef TAMPMsgRef, 3184 updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate } 3186 TrustAnchorUpdate ::= CHOICE { 3187 add [1] EXPLICIT TrustAnchorInfo, 3188 remove [2] PublicKeyInfo, 3189 change [3] TrustAnchorChangeInfo } 3191 TrustAnchorChangeInfo ::= SEQUENCE { 3192 pubKey PublicKeyInfo, 3193 keyId KeyIdentifier OPTIONAL, 3194 taType [0] TrustAnchorChangeType OPTIONAL, 3195 taTitle [1] TrustAnchorTitle OPTIONAL, 3196 certPath [2] CertPathControls OPTIONAL } 3198 TrustAnchorChangeType ::= CHOICE { 3199 mgmt [1] MgmtTrustAnchorInfo, 3200 ident [2] NULL } 3202 -- Trust Anchor Update Confirm Message 3204 tamp-update-confirm PKCS7-CONTENT-TYPE ::= 3205 { TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm } 3207 id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 } 3209 TAMPUpdateConfirm ::= SEQUENCE { 3210 version [0] TAMPVersion DEFAULT v2, 3211 update TAMPMsgRef, 3212 confirm UpdateConfirm } 3214 UpdateConfirm ::= CHOICE { 3215 terseConfirm [0] TerseUpdateConfirm, 3216 verboseConfirm [1] VerboseUpdateConfirm } 3218 TerseUpdateConfirm ::= StatusCodeList 3220 StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode 3222 VerboseUpdateConfirm ::= SEQUENCE { 3223 status StatusCodeList, 3224 taInfo TrustAnchorInfoList } 3226 -- Apex Trust Anchor Update Message 3228 tamp-apex-update PKCS7-CONTENT-TYPE ::= 3229 { TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate } 3231 id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 } 3233 TAMPApexUpdate ::= SEQUENCE { 3234 version [0] TAMPVersion DEFAULT v2, 3235 terse [1] TerseOrVerbose DEFAULT verbose, 3236 msgRef TAMPMsgRef, 3237 clearTrustAnchors BOOLEAN, 3238 clearCommunities BOOLEAN, 3239 apexTA TrustAnchorInfo } 3241 -- Apex Trust Anchor Update Confirm Message 3243 tamp-apex-update-confirm PKCS7-CONTENT-TYPE ::= 3244 { TAMPApexUpdateConfirm IDENTIFIED BY 3245 id-ct-TAMP-apexUpdateConfirm } 3247 id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 } 3249 TAMPApexUpdateConfirm ::= SEQUENCE { 3250 version [0] TAMPVersion DEFAULT v2, 3251 apexReplace TAMPMsgRef, 3252 apexConfirm ApexUpdateConfirm } 3254 ApexUpdateConfirm ::= CHOICE { 3255 terseApexConfirm [0] TerseApexUpdateConfirm, 3256 verboseApexConfirm [1] VerboseApexUpdateConfirm } 3258 TerseApexUpdateConfirm ::= StatusCode 3260 VerboseApexUpdateConfirm ::= SEQUENCE { 3261 status StatusCode, 3262 taInfo TrustAnchorInfoList, 3263 communities CommunityIdentifierList OPTIONAL } 3265 -- Community Update Message 3267 tamp-community-update PKCS7-CONTENT-TYPE ::= 3268 { TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate } 3270 id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 } 3272 TAMPCommunityUpdate ::= SEQUENCE { 3273 version [0] TAMPVersion DEFAULT v2, 3274 terse [1] TerseOrVerbose DEFAULT verbose, 3275 msgRef TAMPMsgRef, 3276 updates CommunityUpdates } 3278 CommunityUpdates ::= SEQUENCE { 3279 add [1] CommunityIdentifierList OPTIONAL, 3280 remove [2] CommunityIdentifierList OPTIONAL } 3281 -- At least one must be present 3283 -- Community Update Confirm Message 3285 tamp-community-update-confirm PKCS7-CONTENT-TYPE ::= 3286 { TAMPCommunityUpdateConfirm IDENTIFIED BY 3287 id-ct-TAMP-communityUpdateConfirm } 3289 id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= 3290 { id-tamp 8 } 3292 TAMPCommunityUpdateConfirm ::= SEQUENCE { 3293 version [0] TAMPVersion DEFAULT v2, 3294 update TAMPMsgRef, 3295 commConfirm CommunityConfirm } 3297 CommunityConfirm ::= CHOICE { 3298 terseCommConfirm [0] TerseCommunityConfirm, 3299 verboseCommConfirm [1] VerboseCommunityConfirm } 3301 TerseCommunityConfirm ::= StatusCode 3303 VerboseCommunityConfirm ::= SEQUENCE { 3304 status StatusCode, 3305 communities CommunityIdentifierList OPTIONAL } 3307 -- Sequence Number Adjust Message 3309 tamp-sequence-number-adjust PKCS7-CONTENT-TYPE ::= 3310 { SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust } 3312 id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 } 3314 SequenceNumberAdjust ::= SEQUENCE { 3315 version [0] TAMPVersion DEFAULT v2, 3316 msgRef TAMPMsgRef } 3318 -- Sequence Number Adjust Message 3320 tamp-sequence-number-adjust-confirm PKCS7-CONTENT-TYPE ::= 3321 { SequenceNumberAdjustConfirm IDENTIFIED BY 3322 id-ct-TAMP-seqNumAdjustConfirm } 3324 id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= { id-tamp 11 } 3326 SequenceNumberAdjustConfirm ::= SEQUENCE { 3327 version [0] TAMPVersion DEFAULT v2, 3328 adjust TAMPMsgRef, 3329 status StatusCode } 3331 -- TAMP Error Message 3333 tamp-error PKCS7-CONTENT-TYPE ::= 3334 { TAMPError IDENTIFIED BY id-ct-TAMP-error } 3336 id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 } 3338 TAMPError ::= SEQUENCE { 3339 version [0] TAMPVersion DEFAULT v2, 3340 msgType OBJECT IDENTIFIER, 3341 status StatusCode, 3342 msgRef TAMPMsgRef OPTIONAL } 3344 -- Status Codes 3346 StatusCode ::= ENUMERATED { 3347 success (0), 3348 decodeFailure (1), 3349 badContentInfo (2), 3350 badSignedData (3), 3351 badEncapContent (4), 3352 badCertificate (5), 3353 badSignerInfo (6), 3354 badSignedAttrs (7), 3355 badUnsignedAttrs (8), 3356 missingContent (9), 3357 noTrustAnchor (10), 3358 notAuthorized (11), 3359 badDigestAlgorithm (12), 3360 badSignatureAlgorithm (13), 3361 unsupportedKeySize (14), 3362 unsupportedParameters (15), 3363 signatureFailure (16), 3364 insufficientMemory (17), 3365 unsupportedTAMPMsgType (18), 3366 apexTAMPAnchor (19), 3367 improperTAAddition (20), 3368 seqNumFailure (21), 3369 contingencyPublicKeyDecrypt (22), 3370 incorrectTarget (23), 3371 communityUpdateFailed (24), 3372 trustAnchorNotFound (25), 3373 unsupportedTAAlgorithm (26), 3374 unsupportedTAKeySize (27), 3375 unsupportedContinPubKeyDecryptAlg (28), 3376 missingSignature (29), 3377 resourcesBusy (30), 3378 versionNumberMismatch (31), 3379 missingPolicySet (32), 3380 other (127) } 3382 -- Object Identifier Arc for Attributes 3384 id-attributes OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) 3385 us(840) organization(1) gov(101) dod(2) infosec(1) 5 } 3387 -- TAMP Unsigned Attributes 3389 TAMPUnsignedAttributes ATTRIBUTE ::= { 3390 contingency-public-key-decrypt-key, 3391 ... -- Expect additional attributes -- 3392 } 3394 -- contingency-public-key-decrypt-key unsigned attribute 3396 contingency-public-key-decrypt-key ATTRIBUTE ::= { 3397 WITH SYNTAX PlaintextSymmetricKey 3398 SINGLE VALUE TRUE 3399 ID id-aa-TAMP-contingencyPublicKeyDecryptKey } 3401 id-aa-TAMP-contingencyPublicKeyDecryptKey OBJECT IDENTIFIER ::= { 3402 id-attributes 63 } 3404 PlaintextSymmetricKey ::= OCTET STRING 3406 END 3408 A.2. ASN.1 Module Using 1988 Syntax 3410 TrustAnchorManagementProtocolVersion2_88 3411 { joint-iso-ccitt(2) country(16) us(840) organization(1) 3412 gov(101) dod(2) infosec(1) modules(0) 997 } 3413 -- Placeholder for TBD 3415 DEFINITIONS IMPLICIT TAGS ::= 3416 BEGIN 3417 IMPORTS 3418 ContentType 3419 FROM CryptographicMessageSyntax2004 -- [RFC3852] 3420 { iso(1) member-body(2) us(840) rsadsi(113549) 3421 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } 3422 AlgorithmIdentifier, Certificate, Name, Attribute 3423 FROM PKIX1Explicit88 -- [RFC3280] 3424 { iso(1) identified-organization(3) dod(6) internet(1) 3425 security(5) mechanisms(5) pkix(7) id-mod(0) 3426 id-pkix1-explicit(18) } 3427 CertificatePolicies, KeyIdentifier, NameConstraints 3428 FROM PKIX1Implicit88 -- [RFC3280] 3429 { iso(1) identified-organization(3) dod(6) internet(1) 3430 security(5) mechanisms(5) pkix(7) id-mod(0) 3431 id-pkix1-implicit(19) } 3432 CMSContentConstraints 3433 FROM CMSContentConstraintsCertExtn-88 -- [CCC] 3434 { iso(1) identified-organization(3) dod(6) internet(1) 3435 security(5) mechanisms(5) pkix(7) id-mod(0) 3436 cmsContentConstr-88(41) } 3437 CAClearanceConstraints 3438 FROM Clearance-CAClearanceConstraints88 -- [ClearConstr] 3439 { joint-iso-ccitt(2) country(16) us(840) organization(1) 3440 gov(101) dod(2) infosec(1) modules(0) 9998 } ; 3441 -- Placeholder for TBD 3443 -- Trust Anchor Information 3445 TrustAnchorInfo ::= SEQUENCE { 3446 version [0] TAMPVersion DEFAULT v2, 3447 pubKey PublicKeyInfo, 3448 keyId KeyIdentifier, 3449 taType TrustAnchorType, 3450 taTitle TrustAnchorTitle OPTIONAL, 3451 certPath CertPathControls OPTIONAL } 3453 PublicKeyInfo ::= SEQUENCE { 3454 algorithm AlgorithmIdentifier, 3455 publicKey BIT STRING } 3457 TrustAnchorType ::= CHOICE { 3458 apex [0] ApexTrustAnchorInfo, 3459 mgmt [1] MgmtTrustAnchorInfo, 3460 ident [2] NULL } 3462 ApexTrustAnchorInfo ::= SEQUENCE { 3463 continPubKey ApexContingencyKey, 3464 seqNum SeqNumber OPTIONAL } 3466 ApexContingencyKey ::= SEQUENCE { 3467 wrapAlgorithm AlgorithmIdentifier, 3468 wrappedContinPubKey OCTET STRING } 3470 SeqNumber ::= INTEGER (0.. 9223372036854775807) 3472 MgmtTrustAnchorInfo ::= SEQUENCE { 3473 taUsage TrustAnchorUsage, 3474 seqNum SeqNumber OPTIONAL } 3476 TrustAnchorUsage ::= CMSContentConstraints 3478 TrustAnchorTitle ::= UTF8String (SIZE (1..64)) 3480 CertPathControls ::= SEQUENCE { 3481 taName Name, 3482 selfSigned [0] Certificate OPTIONAL, 3483 policySet [1] CertificatePolicies OPTIONAL, 3484 policyFlags [2] CertPolicyFlags OPTIONAL, 3485 clearanceConstr [3] CAClearanceConstraints OPTIONAL, 3486 nameConstr [4] NameConstraints OPTIONAL } 3488 CertPolicyFlags ::= BIT STRING { 3489 inhibitPolicyMapping (0), 3490 requireExplicitPolicy (1), 3491 inhibitAnyPolicy (2) } 3493 -- Object Identifier Arc for TAMP Message Content Types 3495 id-tamp OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) us(840) 3496 organization(1) gov(101) dod(2) infosec(1) formats(2) 77 } 3498 -- CMS Content Types 3500 -- TAMP Status Query Message 3502 id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 } 3504 TAMPStatusQuery ::= SEQUENCE { 3505 version [0] TAMPVersion DEFAULT v2, 3506 terse [1] TerseOrVerbose DEFAULT verbose, 3507 query TAMPMsgRef } 3509 TAMPVersion ::= INTEGER { v1(1), v2(2) } 3511 TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) } 3512 TAMPMsgRef ::= SEQUENCE { 3513 target TargetIdentifier, 3514 seqNum SeqNumber } 3516 TargetIdentifier ::= CHOICE { 3517 hwModules [1] HardwareModuleIdentifierList, 3518 communities [2] CommunityIdentifierList, 3519 allModules [3] NULL } 3521 HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF 3522 HardwareModules 3524 HardwareModules ::= SEQUENCE { 3525 hwType OBJECT IDENTIFIER, 3526 hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry } 3528 HardwareSerialEntry ::= CHOICE { 3529 all NULL, 3530 single OCTET STRING, 3531 block SEQUENCE { 3532 low OCTET STRING, 3533 high OCTET STRING } } 3535 CommunityIdentifierList ::= SEQUENCE SIZE (1..MAX) OF Community 3537 Community ::= OBJECT IDENTIFIER 3539 -- TAMP Status Response Message 3541 id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 } 3543 TAMPStatusResponse ::= SEQUENCE { 3544 version [0] TAMPVersion DEFAULT v2, 3545 query TAMPMsgRef, 3546 response StatusResponse } 3548 StatusResponse ::= CHOICE { 3549 terseResponse [0] TerseStatusResponse, 3550 verboseResponse [1] VerboseStatusResponse } 3552 TerseStatusResponse ::= SEQUENCE { 3553 taKeyIds KeyIdentifiers, 3554 communities CommunityIdentifierList OPTIONAL } 3556 KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier 3558 VerboseStatusResponse ::= SEQUENCE { 3559 taInfo TrustAnchorInfoList, 3560 continPubKeyDecryptAlg AlgorithmIdentifier, 3561 communities CommunityIdentifierList OPTIONAL } 3563 TrustAnchorInfoList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorInfo 3565 -- Trust Anchor Update Message 3567 id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 } 3569 TAMPUpdate ::= SEQUENCE { 3570 version [0] TAMPVersion DEFAULT v2, 3571 terse [1] TerseOrVerbose DEFAULT verbose, 3572 msgRef TAMPMsgRef, 3573 updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate } 3575 TrustAnchorUpdate ::= CHOICE { 3576 add [1] EXPLICIT TrustAnchorInfo, 3577 remove [2] PublicKeyInfo, 3578 change [3] TrustAnchorChangeInfo } 3580 TrustAnchorChangeInfo ::= SEQUENCE { 3581 pubKey PublicKeyInfo, 3582 keyId KeyIdentifier OPTIONAL, 3583 mgmtTAType [0] MgmtTrustAnchorInfo OPTIONAL, 3584 taTitle [1] TrustAnchorTitle OPTIONAL, 3585 certPath [2] CertPathControls OPTIONAL } 3587 -- Trust Anchor Update Confirm Message 3589 id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 } 3591 TAMPUpdateConfirm ::= SEQUENCE { 3592 version [0] TAMPVersion DEFAULT v2, 3593 update TAMPMsgRef, 3594 confirm UpdateConfirm } 3596 UpdateConfirm ::= CHOICE { 3597 terseConfirm [0] TerseUpdateConfirm, 3598 verboseConfirm [1] VerboseUpdateConfirm } 3600 TerseUpdateConfirm ::= StatusCodeList 3602 StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode 3604 VerboseUpdateConfirm ::= SEQUENCE { 3605 status StatusCodeList, 3606 taInfo TrustAnchorInfoList } 3608 -- Apex Trust Anchor Update Message 3610 id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 } 3612 TAMPApexUpdate ::= SEQUENCE { 3613 version [0] TAMPVersion DEFAULT v2, 3614 terse [1] TerseOrVerbose DEFAULT verbose, 3615 msgRef TAMPMsgRef, 3616 clearTrustAnchors BOOLEAN, 3617 apexTA TrustAnchorInfo } 3619 -- Apex Trust Anchor Update Confirm Message 3621 id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 } 3623 TAMPApexUpdateConfirm ::= SEQUENCE { 3624 version [0] TAMPVersion DEFAULT v2, 3625 apexReplace TAMPMsgRef, 3626 apexConfirm ApexUpdateConfirm } 3628 ApexUpdateConfirm ::= CHOICE { 3629 terseApexConfirm [0] TerseApexUpdateConfirm, 3630 verboseApexConfirm [1] VerboseApexUpdateConfirm } 3632 TerseApexUpdateConfirm ::= StatusCode 3634 VerboseApexUpdateConfirm ::= SEQUENCE { 3635 status StatusCode, 3636 taInfo TrustAnchorInfoList, 3637 communities CommunityIdentifierList OPTIONAL } 3639 -- Community Update Message 3641 id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 } 3643 TAMPCommunityUpdate ::= SEQUENCE { 3644 version [0] TAMPVersion DEFAULT v2, 3645 terse [1] TerseOrVerbose DEFAULT verbose, 3646 msgRef TAMPMsgRef, 3647 updates CommunityUpdates } 3649 CommunityUpdates ::= SEQUENCE { 3650 remove [1] CommunityIdentifierList OPTIONAL, 3651 add [2] CommunityIdentifierList OPTIONAL } 3652 -- At least one must be present 3654 -- Community Update Confirm Message 3656 id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 8 } 3658 TAMPCommunityUpdateConfirm ::= SEQUENCE { 3659 version [0] TAMPVersion DEFAULT v2, 3660 update TAMPMsgRef, 3661 commConfirm CommunityConfirm } 3663 CommunityConfirm ::= CHOICE { 3664 terseCommConfirm [0] TerseCommunityConfirm, 3665 verboseCommConfirm [1] VerboseCommunityConfirm } 3667 TerseCommunityConfirm ::= StatusCode 3669 VerboseCommunityConfirm ::= SEQUENCE { 3670 status StatusCode, 3671 communities CommunityIdentifierList OPTIONAL } 3673 -- Sequence Number Adjust Message 3675 id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 } 3676 -- Placeholder for TBD 3678 SequenceNumberAdjust ::= SEQUENCE { 3679 version [0] TAMPVersion DEFAULT v2, 3680 msgRef TAMPMsgRef } 3682 -- Sequence Number Adjust Message 3684 id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= { id-tamp 11 } 3685 -- Placeholder for TBD 3687 SequenceNumberAdjustConfirm ::= SEQUENCE { 3688 version [0] TAMPVersion DEFAULT v2, 3689 adjust TAMPMsgRef, 3690 status StatusCode } 3692 -- TAMP Error Message 3694 id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 } 3695 TAMPError ::= SEQUENCE { 3696 version [0] TAMPVersion DEFAULT v2, 3697 msgType OBJECT IDENTIFIER, 3698 status StatusCode, 3699 msgRef TAMPMsgRef OPTIONAL } 3701 -- Status Codes 3703 StatusCode ::= ENUMERATED { 3704 success (0), 3705 decodeFailure (1), 3706 badContentInfo (2), 3707 badSignedData (3), 3708 badEncapContent (4), 3709 badCertificate (5), 3710 badSignerInfo (6), 3711 badSignedAttrs (7), 3712 badUnsignedAttrs (8), 3713 missingContent (9), 3714 noTrustAnchor (10), 3715 notAuthorized (11), 3716 badDigestAlgorithm (12), 3717 badSignatureAlgorithm (13), 3718 unsupportedKeySize (14), 3719 unsupportedParameters (15), 3720 signatureFailure (16), 3721 insufficientMemory (17), 3722 unsupportedTAMPMsgType (18), 3723 apexTAMPAnchor (19), 3724 improperTAAddition (20), 3725 seqNumFailure (21), 3726 contingencyPublicKeyDecrypt (22), 3727 incorrectTarget (23), 3728 communityUpdateFailed (24), 3729 trustAnchorNotFound (25), 3730 unsupportedTAAlgorithm (26), 3731 unsupportedTAKeySize (27), 3732 unsupportedContinPubKeyDecryptAlg (28), 3733 missingSignature (29), 3734 resourcesBusy (30), 3735 versionNumberMismatch (31), 3736 missingPolicySet (32), 3737 other (127) } 3739 -- Object Identifier Arc for Attributes 3740 id-attributes OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) 3741 us(840) organization(1) gov(101) dod(2) infosec(1) 5 } 3743 -- id-aa-TAMP-contingencyPublicKeyDecryptKey uses 3744 -- PlaintextSymmetricKey syntax 3745 id-aa-TAMP-contingencyPublicKeyDecryptKey OBJECT IDENTIFIER ::= { 3746 id-attributes 63 } 3748 PlaintextSymmetricKey ::= OCTET STRING 3750 END 3752 Authors' Addresses 3754 Russ Housley 3755 Vigil Security, LLC 3756 918 Spring Knoll Drive 3757 Herndon, VA 20170 3759 Email: housley@vigilsec.com 3761 Raksha Reddy 3762 National Security Agency 3763 Suite 6751 3764 9800 Savage Road 3765 Fort Meade, MD 20755 3767 Email: r.reddy@radium.ncsc.mil 3769 Carl Wallace 3770 Cygnacom Solutions 3771 Suite 5200 3772 7925 Jones Branch Drive 3773 McLean, VA 22102 3775 Email: cwallace@cygnacom.com 3777 Full Copyright Statement 3779 Copyright (C) The IETF Trust (2007). 3781 This document is subject to the rights, licenses and restrictions 3782 contained in BCP 78, and except as set forth therein, the authors 3783 retain all their rights. 3785 This document and the information contained herein are provided on an 3786 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3787 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3788 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3789 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3790 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3791 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3793 Intellectual Property 3795 The IETF takes no position regarding the validity or scope of any 3796 Intellectual Property Rights or other rights that might be claimed to 3797 pertain to the implementation or use of the technology described in 3798 this document or the extent to which any license under such rights 3799 might or might not be available; nor does it represent that it has 3800 made any independent effort to identify any such rights. Information 3801 on the procedures with respect to rights in RFC documents can be 3802 found in BCP 78 and BCP 79. 3804 Copies of IPR disclosures made to the IETF Secretariat and any 3805 assurances of licenses to be made available, or the result of an 3806 attempt made to obtain a general license or permission for the use of 3807 such proprietary rights by implementers or users of this 3808 specification can be obtained from the IETF on-line IPR repository at 3809 http://www.ietf.org/ipr. 3811 The IETF invites any interested party to bring to its attention any 3812 copyrights, patents or patent applications, or other proprietary 3813 rights that may cover technology that may be required to implement 3814 this standard. Please address the information to the IETF at 3815 ietf-ipr@ietf.org. 3817 Acknowledgment 3819 Funding for the RFC Editor function is provided by the IETF 3820 Administrative Support Activity (IASA).