path: root/doc/rfc/rfc5934.txt

Internet Engineering Task Force (IETF)                        R. Housley
Request for Comments: 5934                           Vigil Security, LLC
Category: Standards Track                                     S. Ashmore
ISSN: 2070-1721                                 National Security Agency
                                                              C. Wallace
                                                      Cygnacom Solutions
                                                             August 2010


                Trust Anchor Management Protocol (TAMP)

Abstract

   This document describes a transport independent protocol for the
   management of trust anchors (TAs) and community identifiers stored in
   a trust anchor store.  The protocol makes use of the Cryptographic
   Message Syntax (CMS), and a digital signature is used to provide
   integrity protection and data origin authentication.  The protocol
   can be used to manage trust anchor stores containing trust anchors
   represented as Certificate, TBSCertificate, or TrustAnchorInfo
   objects.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5934.
















Housley, et al.              Standards Track                    [Page 1]
^L
RFC 5934                          TAMP                       August 2010


Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

























Housley, et al.              Standards Track                    [Page 2]
^L
RFC 5934                          TAMP                       August 2010


Table of Contents

   1. Introduction ....................................................4
      1.1. Terminology ................................................5
      1.2. Trust Anchors ..............................................5
           1.2.1. Apex Trust Anchors ..................................6
           1.2.2. Management Trust Anchors ............................7
           1.2.3. Identity Trust Anchors ..............................7
      1.3. Architectural Elements .....................................8
           1.3.1. Cryptographic Module ................................8
           1.3.2. Trust Anchor Store ..................................9
           1.3.3. TAMP Processing Dependencies ........................9
           1.3.4. Application-Specific Protocol Processing ...........10
      1.4. ASN.1 Encoding ............................................11
   2. Cryptographic Message Syntax Profile ...........................12
      2.1. ContentInfo ...............................................13
      2.2. SignedData Info ...........................................14
           2.2.1. SignerInfo .........................................15
           2.2.2. EncapsulatedContentInfo ............................16
           2.2.3. Signed Attributes ..................................16
           2.2.4. Unsigned Attributes ................................18
   3. Trust Anchor Formats ...........................................18
   4. Trust Anchor Management Protocol Messages ......................19
      4.1. TAMP Status Query .........................................21
      4.2. TAMP Status Query Response ................................24
      4.3. Trust Anchor Update .......................................27
           4.3.1. Trust Anchor List ..................................31
      4.4. Trust Anchor Update Confirm ...............................32
      4.5. Apex Trust Anchor Update ..................................34
      4.6. Apex Trust Anchor Update Confirm ..........................36
      4.7. Community Update ..........................................38
      4.8. Community Update Confirm ..................................40
      4.9. Sequence Number Adjust ....................................42
      4.10. Sequence Number Adjust Confirm ...........................43
      4.11. TAMP Error ...............................................44
   5. Status Codes ...................................................45
   6. Sequence Number Processing .....................................50
   7. Subordination Processing .......................................51
   8. Implementation Considerations ..................................54
   9. Wrapped Apex Contingency Key Certificate Extension .............54
   10. Security Considerations .......................................55
   11. IANA Considerations ...........................................58
   12. References ....................................................58
      12.1. Normative References .....................................58
      12.2. Informative References ...................................59






Housley, et al.              Standards Track                    [Page 3]
^L
RFC 5934                          TAMP                       August 2010


   Appendix A.  ASN.1 Modules ........................................61
     A.1.  ASN.1 Module Using 1993 Syntax ............................61
     A.2.  ASN.1 Module Using 1988 Syntax ............................70
   Appendix B.  Media Type Registrations .............................77
     B.1.  application/tamp-status-query .............................77
     B.2.  application/tamp-status-response ..........................78
     B.3.  application/tamp-update ...................................79
     B.4.  application/tamp-update-confirm ...........................80
     B.5.  application/tamp-apex-update ..............................81
     B.6.  application/tamp-apex-update-confirm ......................82
     B.7.  application/tamp-community-update .........................83
     B.8.  application/tamp-community-update-confirm .................84
     B.9.  application/tamp-sequence-adjust ..........................85
     B.10. application/tamp-sequence-adjust-confirm ..................86
     B.11. application/tamp-error ....................................87
   Appendix C.  TAMP over HTTP .......................................88
     C.1.  TAMP Status Query Message .................................89
     C.2.  TAMP Status Response Message ..............................89
     C.3.  Trust Anchor Update Message ...............................89
     C.4.  Trust Anchor Update Confirm Message .......................89
     C.5.  Apex Trust Anchor Update Message ..........................89
     C.6.  Apex Trust Anchor Update Confirm Message ..................90
     C.7.  Community Update Message ..................................90
     C.8.  Community Update Confirm Message ..........................90
     C.9.  Sequence Number Adjust Message ............................90
     C.10. Sequence Number Adjust Confirm Message ....................90
     C.11. TAMP Error Message ........................................91

1.  Introduction

   This document describes the Trust Anchor Management Protocol (TAMP).
   TAMP may be used to manage the trust anchors and community
   identifiers in any device that uses digital signatures; however, this
   specification was written with the requirements of cryptographic
   modules in mind.  For example, TAMP can support signed firmware
   packages [RFC4108], where the trust anchor public key can be used to
   validate digital signatures on firmware packages or validate the
   X.509 certification path [RFC5280][X.509] of the firmware package
   signer.

   Most TAMP messages are digitally signed to provide integrity
   protection and data origin authentication.  Both signed and unsigned
   TAMP messages employ the Cryptographic Message Syntax (CMS)
   [RFC5652].  The CMS is a data protection encapsulation syntax that
   makes use of ASN.1 [X.680].






Housley, et al.              Standards Track                    [Page 4]
^L
RFC 5934                          TAMP                       August 2010


   This specification does not provide for confidentiality of TAMP
   messages.  If confidentiality is required, then the communications
   environment that is used to transfer TAMP messages must provide it.
   This specification is intended to satisfy the protocol-related
   requirements expressed in "Trust Anchor Management Requirements"
   [TA-MGMT-REQS] and uses vocabulary from that document.

   TAMP messages may be exchanged in real time over a network, such as
   via HTTP as described in Appendix A, or may be stored and transferred
   using other means.  TAMP exchanges consist of a request message that
   includes instructions for a trust anchor store and, optionally, a
   corresponding response message that reports the result of carrying
   out the instructions in the request.  Response messages need not be
   propagated in all cases.  For example, a GPS receiver may be unable
   to transmit a response and may instead use an attached display to
   indicate the results of processing a TAMP request.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2.  Trust Anchors

   TAMP manages trust anchors.  A trust anchor contains a public key
   that is used to validate digital signatures.  TAMP recognizes three
   formats for representing trust anchor information: Certificate
   [RFC5280], TBSCertificate [RFC5280], and TrustAnchorInfo [RFC5914].

   All trust anchors are distinguished by the public key, and all trust
   anchors consist of the following components:

   o  A public key signature algorithm identifier and associated public
      key, which MAY include parameters

   o  A public key identifier

   Other information may appear in a trust anchor, including
   certification path processing controls and a human readable name.

   TAMP recognizes three types of trust anchors based on functionality:
   apex trust anchors, management trust anchors, and identity trust
   anchors.

   In addition to the information described above, apex trust anchors
   and management trust anchors that sign TAMP messages have an
   associated sequence number that is used for replay detection.



Housley, et al.              Standards Track                    [Page 5]
^L
RFC 5934                          TAMP                       August 2010


   The public key is used to name a trust anchor, and the public key
   identifier is used to identify the trust anchor as a signer of a
   particular object, such as a SignedData object or a public key
   certificate.  This public key identifier can be stored with the trust
   anchor, or in most public key identifier assignment methods, it can
   be computed from the public key whenever needed.

   A trust anchor public key can be used in two different ways to
   support digital signature validation.  In the first approach, the
   trust anchor public key is used directly to validate the digital
   signature.  In the second approach, the trust anchor public key is
   used to validate an X.509 certification path, and then the subject
   public key in the final certificate in the certification path is used
   to validate the digital signature.  When the second approach is
   employed, the certified public key may be used for things other than
   digital signature validation; the other possible actions are
   constrained by the key usage certificate extension.

   TAMP implementations MUST support validation of TAMP messages that
   are directly validated using a trust anchor.  Support for TAMP
   messages validated using an X.509 certificate validated using a trust
   anchor, or using longer certification paths, is OPTIONAL.  The CMS
   provides a location to carry X.509 certificates, and this facility
   can be used to transfer certificates to aid in the construction of
   the certification path.

1.2.1.  Apex Trust Anchors

   Within the context of a single trust anchor store, one trust anchor
   is superior to all others.  This trust anchor is referred to as the
   apex trust anchor.  This trust anchor represents the ultimate
   authority over the trust anchor store.  Much of this authority can be
   delegated to other trust anchors.

   The apex trust anchor private key is expected to be controlled by an
   entity with information assurance responsibility for the trust anchor
   store.  The apex trust anchor is by definition unconstrained and
   therefore does not have explicit authorization information associated
   with it.

   Due to the special nature of the apex trust anchor, TAMP includes
   separate facilities to change it.  In particular, TAMP includes a
   facility to securely replace the apex trust anchor.  This action
   might be taken for one or more of the following reasons:

   o  The crypto period for the apex trust anchor public/private key
      pair has come to an end




Housley, et al.              Standards Track                    [Page 6]
^L
RFC 5934                          TAMP                       August 2010


   o  The apex trust anchor private key is no longer available

   o  The apex trust anchor public/private key pair needs to be revoked

   o  The authority has decided to use a different digital signature
      algorithm or the same digital signature algorithm with different
      parameters, such as a different elliptic curve

   o  The authority has decided to use a different key size

   o  The authority has decided to transfer control to another authority

   To accommodate these requirements, the apex trust anchor MAY include
   two public keys.  Whenever the apex trust anchor is updated, both
   public keys will be replaced.  The first public key, called the
   operational public key, is used in the same manner as other trust
   anchors.  Any type of TAMP message, including an Apex Trust Anchor
   Update message, can be validated with the operational public key.
   The second public key, called the contingency public key, can only be
   used to update the apex trust anchor.  The contingency private key
   SHOULD be used at only one point in time; it is used only to sign an
   Apex Trust Anchor Update message that results in its own replacement
   (as well as the replacement of the operational public key).  The
   contingency public key is distributed in encrypted form.  When the
   contingency public key is used to validate an Apex Trust Anchor
   Update message, the symmetric key needed to decrypt the contingency
   public key is provided as part of the signed Apex Trust Anchor Update
   message that is to be verified with the contingency public key.

1.2.2.  Management Trust Anchors

   Management trust anchors are used in the management of cryptographic
   modules.  For example, the TAMP messages specified in this document
   are validated to a management trust anchor.  Likewise, a signed
   firmware package as specified in [RFC4108] is validated to a
   management trust anchor.

1.2.3.  Identity Trust Anchors

   Identity trust anchors are used to validate certification paths, and
   they represent the trust anchor for a public key infrastructure.
   They are most often used in the validation of certificates associated
   with non-management applications.








Housley, et al.              Standards Track                    [Page 7]
^L
RFC 5934                          TAMP                       August 2010


1.3.  Architectural Elements

   TAMP does not assume any particular architecture.  However, TAMP
   REQUIRES the following architectural elements: a cryptographic
   module, a trust anchor store, TAMP protocol processing, and other
   application-specific protocol processing.

   A globally unique algorithm identifier MUST be assigned for each one-
   way hash function, digital signature generation/validation algorithm,
   and symmetric key unwrapping algorithm that is implemented.  To
   support CMS, an object identifier (OID) is assigned to name a one-way
   hash function, and another OID is assigned to name each combination
   of a one-way hash function when used with a digital signature
   algorithm.  Similarly, certificates associate OIDs assigned to public
   key algorithms with subject public keys, and certificates make use of
   an OID that names both the one-way hash function and the digital
   signature algorithm for the certificate issuer digital signature.
   [RFC3279], [RFC3370], [RFC5753], and [RFC5754] provide OIDs for a
   number of commonly used algorithms; however, OIDs may be defined in
   later or different specifications.

1.3.1.  Cryptographic Module

   The cryptographic module MUST include the following capabilities:

   o  The cryptographic module SHOULD support the secure storage of a
      digital signature private key to sign TAMP responses and either a
      certificate containing the associated public key or a certificate
      designator.  In the latter case, the certificate is stored
      elsewhere but is available to parties that need to validate
      cryptographic module digital signatures.  The designator is a
      public key identifier.

   o  The cryptographic module MUST support at least one one-way hash
      function, one digital signature validation algorithm, one digital
      signature generation algorithm, and, if contingency keys are
      supported, one symmetric key unwrapping algorithm.  If only one
      one-way hash function is present, it MUST be consistent with the
      digital signature validation and digital signature generation
      algorithms.  If only one digital signature validation algorithm is
      present, it MUST be consistent with the apex trust anchor
      operational public key.  If only one digital signature generation
      algorithm is present, it MUST be consistent with the cryptographic
      module digital signature private key.  These algorithms MUST be
      available for processing TAMP messages, including the content
      types defined in [RFC5652], and for validation of X.509





Housley, et al.              Standards Track                    [Page 8]
^L
RFC 5934                          TAMP                       August 2010


      certification paths.  As with similar specifications, such as
      RFC 5280, this specification does not mandate support for any
      cryptographic algorithms.  However, algorithm requirements may be
      imposed by specifications that use trust anchors managed via TAMP.

1.3.2.  Trust Anchor Store

   The trust anchor store MUST include the following capabilities:

   o  Each trust anchor store MUST have a unique name.  For example, a
      cryptographic module containing a single trust anchor store may be
      identified by a unique serial number with respect to other modules
      within the same family where the family is represented as an ASN.1
      object identifier (OID) and the unique serial number is
      represented as a string of octets.  Other means of establishing a
      unique name are also possible.

   o  Each trust anchor store SHOULD have the capability to securely
      store one or more community identifiers.  The community identifier
      is an OID, and it identifies a collection of cryptographic modules
      that can be the target of a single TAMP message or the intended
      recipients for a particular management message.

   o  The trust anchor store SHOULD support the use of an apex trust
      anchor.  If apex support is provided, the trust anchor store MUST
      support the secure storage of exactly one apex trust anchor.  The
      trust anchor store SHOULD support the secure storage of at least
      one additional trust anchor.  Each trust anchor MUST contain a
      unique public key.  A public key MUST NOT appear more than once in
      a trust anchor store.

   o  The trust anchor store MUST have the capability to securely store
      a sequence number for each trust anchor authorized to generate
      TAMP messages and be able to report the sequence number along with
      the key identifier of the trust anchor.

1.3.3.  TAMP Processing Dependencies

   TAMP processing MUST include the following capabilities:

   o  TAMP processing MUST have a means of locating an appropriate trust
      anchor.  Two mechanisms are available.  The first mechanism is
      based on the public key identifier for digital signature
      verification, and the second mechanism is based on the trust
      anchor X.500 distinguished name and other X.509 certification path
      controls for certificate path discovery and validation.  The first
      mechanism MUST be supported, but the second mechanism MAY be
      supported.



Housley, et al.              Standards Track                    [Page 9]
^L
RFC 5934                          TAMP                       August 2010


   o  TAMP processing MUST be able to invoke the digital signature
      validation algorithm using the public key held in secure storage
      for trust anchors.

   o  TAMP processing MUST have read and write access to secure storage
      for sequence numbers associated with each TAMP message signer as
      described in Section 6.

   o  TAMP processing MUST have read and write access to secure storage
      for trust anchors in order to update them.  Update operations
      include adding trust anchors, removing trust anchors, and
      modifying trust anchors.  Application-specific constraints MUST be
      securely stored with each management trust anchor as described in
      Section 1.3.4.

   o  TAMP processing MUST have read access to secure storage for the
      community membership list, if any, to determine whether a targeted
      message ought to be accepted.

   o  To implement the OPTIONAL community identifier update feature,
      TAMP processing MUST have read and write access to secure storage
      for the community membership list.

   o  To generate signed confirmation messages, TAMP processing MUST be
      able to invoke the digital signature generation algorithm using
      the cryptographic module digital signature private key, and it
      MUST have read access to the cryptographic module certificate or
      its designator.  TAMP uses X.509 certificates [RFC5280].

   o  The TAMP processing MUST have read access to the trust anchor
      store unique name.

1.3.4.  Application-Specific Protocol Processing

   The apex trust anchor and management trust anchors managed with TAMP
   can be used by the TAMP application.  Other management applications
   MAY make use of all three types of trust anchors, but non-management
   applications SHOULD only make use of identity trust anchors.
   Applications MUST ensure that usage of a trust anchor is consistent
   with any constraints associated with the trust anchor.  For example,
   if name constraints are associated with a trust anchor, certification
   paths that start with the trust anchor and contain certificates with
   names that violate the name constraints MUST be rejected.

   The application-specific protocol processing MUST be provided with
   the following services:





Housley, et al.              Standards Track                   [Page 10]
^L
RFC 5934                          TAMP                       August 2010


   o  The application-specific protocol processing MUST have a means of
      locating an appropriate trust anchor.  Two mechanisms are
      available to applications.  The first mechanism is based on the
      public key identifier for digital signature verification, and the
      second mechanism is based on the trust anchor X.500 distinguished
      name and other X.509 certification path controls for certificate
      path discovery and validation.

   o  The application-specific protocol processing MUST be able to
      invoke the digital signature validation algorithm using the public
      key held in secure storage for trust anchors.

   o  The application-specific protocol processing MUST have read access
      to data associated with trust anchors to ensure that constraints
      can be enforced appropriately.  For example, an application MUST
      have read access to any name constraints associated with a TA to
      ensure that certification paths terminated by that TA do not
      include certificates issued to entities outside the TA manager-
      designated namespace.

   o  The application-specific protocol processing MUST have read access
      to secure storage for the community membership list, if any, to
      determine whether a targeted message ought to be accepted.

   o  If the application-specific protocol requires digital signatures
      on confirmation messages or receipts, then the application-
      specific protocol processing MUST be able to invoke the digital
      signature generation algorithm with the cryptographic module
      digital signature private key and its associated certificate or
      certificate designator.  Digital signature generation MUST be
      controlled in a manner that ensures that the content type of
      signed confirmation messages or receipts is appropriate for the
      application-specific protocol processing.

   o  The application-specific protocol processing MUST have read access
      to the trust anchor store unique name.

1.4.  ASN.1 Encoding

   The CMS uses Abstract Syntax Notation One (ASN.1) [X.680].  ASN.1 is
   a formal notation used for describing data protocols, regardless of
   the programming language used by the implementation.  Encoding rules
   describe how the values defined in ASN.1 will be represented for
   transmission.  The Basic Encoding Rules (BER) [X.690] are the most
   widely employed rule set, but they offer more than one way to
   represent data structures.  For example, definite-length encoding and
   indefinite-length encoding are supported.  This flexibility is not
   desirable when digital signatures are used.  As a result, the



Housley, et al.              Standards Track                   [Page 11]
^L
RFC 5934                          TAMP                       August 2010


   Distinguished Encoding Rules (DER) [X.690] were invented.  DER is a
   subset of BER that ensures a single way to represent a given value.
   For example, DER always employs definite-length encoding.

   Digitally signed structures MUST be encoded with DER.  In other
   specifications, structures that are not digitally signed do not
   require DER, but in this specification, DER is REQUIRED for all
   structures.  By always using DER, the TAMP processor will have fewer
   options to implement.

   ASN.1 is used throughout the text of this document for illustrative
   purposes.  The authoritative source of ASN.1 for the structures
   defined in this document is Appendix A.

2.  Cryptographic Message Syntax Profile

   TAMP makes use of signed and unsigned messages.  The Cryptographic
   Message Syntax (CMS) is used in both cases.  A digital signature is
   used to protect the message from undetected modification and provide
   data origin authentication.  TAMP makes no general provision for
   encryption of content.

   CMS is used to construct a signed TAMP message.  The CMS ContentInfo
   content type MUST always be present.  For signed messages,
   ContentInfo MUST encapsulate the CMS SignedData content type; for
   unsigned messages, ContentInfo MUST encapsulate the TAMP message
   directly.  The CMS SignedData content type MUST encapsulate the TAMP
   message.  A unique content type identifier identifies the particular
   type of TAMP message.  The CMS encapsulation of a signed TAMP message
   is summarized by:

    ContentInfo {
      contentType id-signedData, -- (1.2.840.113549.1.7.2)
      content     SignedData
    }

    SignedData {
      version           CMSVersion, -- Always set to 3
      digestAlgorithms  DigestAlgorithmIdentifiers, -- Only one
      encapContentInfo  EncapsulatedContentInfo,
      certificates      CertificateSet, -- OPTIONAL signer certificates
      crls              CertificateRevocationLists, -- OPTIONAL
      signerInfos       SET OF SignerInfo -- Only one
    }







Housley, et al.              Standards Track                   [Page 12]
^L
RFC 5934                          TAMP                       August 2010


    SignerInfo {
      version             CMSVersion, -- Always set to 3
      sid                 SignerIdentifier,
      digestAlgorithm     DigestAlgorithmIdentifier,
      signedAttrs         SignedAttributes,
                                          -- REQUIRED in TAMP messages
      signatureAlgorithm  SignatureAlgorithmIdentifier,
      signature           SignatureValue,
      unsignedAttrs       UnsignedAttributes -- OPTIONAL; may only be
    }                                        -- present in Apex Trust
                                             -- Anchor Update messages

    EncapsulatedContentInfo {
      eContentType  OBJECT IDENTIFIER, -- Names TAMP message type
      eContent      OCTET STRING       -- Contains TAMP message
    }

   When a TAMP message is used to update the apex trust anchor, this
   same structure is used; however, the digital signature will be
   validated with either the apex trust anchor operational public key or
   the contingency public key.  When the contingency public key is used,
   the symmetric key needed to decrypt the previously stored contingency
   public key is provided as a contingency-public-key-decrypt-key
   unsigned attribute.  Section 4.5 of this document describes the Apex
   Trust Anchor Update message.

   CMS is also used to construct an unsigned TAMP message.  The CMS
   ContentInfo structure MUST always be present, and it MUST be the
   outermost layer of encapsulation.  A unique content type identifier
   identifies the particular TAMP message.  The CMS encapsulation of an
   unsigned TAMP message is summarized by:

    ContentInfo {
      contentType  OBJECT IDENTIFIER, -- Names TAMP message type
      content      OCTET STRING       -- Contains TAMP message
    }

2.1.  ContentInfo

   CMS requires the outermost encapsulation to be ContentInfo [RFC5652].
   The fields of ContentInfo are used as follows:

   o  contentType indicates the type of the associated content, and for
      TAMP, the encapsulated type is either SignedData or the content
      type identifier associated with an unsigned TAMP message.  When
      the id-signedData (1.2.840.113549.1.7.2) object identifier is
      present in this field, then a signed TAMP message is in the
      content.  Otherwise, an unsigned TAMP message is in the content.



Housley, et al.              Standards Track                   [Page 13]
^L
RFC 5934                          TAMP                       August 2010


   o  content holds the content, and for TAMP, the content is either a
      SignedData content or an unsigned TAMP message.

2.2.  SignedData Info

   The SignedData content type [RFC5652] contains the signed TAMP
   message and a digital signature value; the SignedData content type
   MAY also contain the certificates needed to validate the digital
   signature.  The fields of SignedData are used as follows:

   o  version is the syntax version number, and for TAMP, the version
      number MUST be set to 3.

   o  digestAlgorithms is a collection of one-way hash function
      identifiers, and for TAMP, it contains a single one-way hash
      function identifier.  The one-way hash function employed by the
      TAMP message originator in generating the digital signature MUST
      be present.

   o  encapContentInfo is the signed content, consisting of a content
      type identifier and the content itself.  The use of the
      EncapsulatedContentInfo type is discussed further in
      Section 2.2.2.

   o  certificates is an OPTIONAL collection of certificates.  It MAY be
      omitted, or it MAY include the X.509 certificates needed to
      construct the certification path of the TAMP message originator.
      For TAMP messages sent to a trust anchor store where an apex trust
      anchor or management trust anchor is used directly to validate the
      TAMP message digital signature, this field SHOULD be omitted.
      When an apex trust anchor or management trust anchor is used to
      validate an X.509 certification path [RFC5280], and the subject
      public key from the final certificate in the certification path is
      used to validate the TAMP message digital signature, the
      certificate of the TAMP message originator SHOULD be included, and
      additional certificates to support certification path construction
      MAY be included.  For TAMP messages sent by a trust anchor store,
      this field SHOULD include only the signer's certificate or should
      be omitted.  A TAMP message recipient MUST NOT reject a valid TAMP
      message that contains certificates that are not needed to validate
      the digital signature.  PKCS#6 extended certificates [PKCS#6] and
      attribute certificates (either version 1 or version 2) [RFC5755]
      MUST NOT be included in the set of certificates; these certificate
      formats are not used in TAMP.  Certification authority (CA)
      certificates and end entity certificates MUST conform to the
      profiles defined in [RFC5280].





Housley, et al.              Standards Track                   [Page 14]
^L
RFC 5934                          TAMP                       August 2010


   o  crls is an OPTIONAL collection of certificate revocation lists
      (CRLs).

   o  signerInfos is a collection of per-signer information, and for
      TAMP, the collection MUST contain exactly one SignerInfo.  The use
      of the SignerInfo type is discussed further in Section 2.2.1.

2.2.1.  SignerInfo

   The TAMP message originator is represented in the SignerInfo type.
   The fields of SignerInfo are used as follows:

   o  version is the syntax version number.  With TAMP, the version MUST
      be set to 3.

   o  sid identifies the TAMP message originator's public key.  The
      subjectKeyIdentifier alternative is always used with TAMP, which
      identifies the public key directly.  When the public key is
      included in a TrustAnchorInfo object, this identifier is included
      in the keyId field.  When the public key is included in a
      Certificate or TBSCertificate, this identifier is included in the
      subjectKeyIdentifier certificate extension.

   o  digestAlgorithm identifies the one-way hash function, and any
      associated parameters, used by the TAMP message originator.  It
      MUST contain the one-way hash functions employed by the
      originator.  This message digest algorithm identifier MUST match
      the one carried in the digestAlgorithms field in SignedData.  The
      message digest algorithm identifier is carried in two places to
      facilitate stream processing by the receiver.

   o  signedAttrs is an OPTIONAL set of attributes that are signed along
      with the content.  The signedAttrs are OPTIONAL in the CMS, but
      signedAttrs is REQUIRED for all signed TAMP messages.  The SET OF
      Attribute MUST be encoded with the Distinguished Encoding Rules
      (DER) [X.690].  Section 2.2.3 of this document lists the signed
      attributes that MUST be included in the collection.  Other signed
      attributes MAY be included, but any unrecognized signed attributes
      MUST be ignored.

   o  signatureAlgorithm identifies the digital signature algorithm, and
      any associated parameters, used by the TAMP message originator to
      generate the digital signature.

   o  signature is the digital signature value generated by the TAMP
      message originator.





Housley, et al.              Standards Track                   [Page 15]
^L
RFC 5934                          TAMP                       August 2010


   o  unsignedAttrs is an OPTIONAL set of attributes that are not
      signed.  For TAMP, this field is usually omitted.  It is present
      only in Apex Trust Anchor Update messages that are to be validated
      using the apex trust anchor contingency public key.  In this case,
      the SET OF Attribute MUST include the symmetric key needed to
      decrypt the contingency public key in the contingency-public-key-
      decrypt-key unsigned attribute.  Section 2.2.4 of this document
      describes this unsigned attribute.

2.2.2.  EncapsulatedContentInfo

   The EncapsulatedContentInfo structure contains the TAMP message.  The
   fields of EncapsulatedContentInfo are used as follows:

   o  eContentType is an object identifier that uniquely specifies the
      content type, and for TAMP, the value identifies the TAMP message.
      The list of TAMP message content types is provided in Section 4.

   o  eContent is the TAMP message, encoded as an octet string.  In
      general, the CMS does not require the eContent to be DER-encoded
      before constructing the octet string.  However, TAMP messages MUST
      be DER-encoded.

2.2.3.  Signed Attributes

   The TAMP message originator MUST digitally sign a collection of
   attributes along with the TAMP message.  Each attribute in the
   collection MUST be DER-encoded.  The syntax for attributes is defined
   in [RFC5912].

   Each of the attributes used with this CMS profile has a single
   attribute value.  Even though the syntax is defined as a SET OF
   AttributeValue, there MUST be exactly one instance of AttributeValue
   present.

   The SignedAttributes syntax within SignerInfo is defined as a SET OF
   Attribute.  The SignedAttributes MUST include only one instance of
   any particular attribute.  TAMP messages that violate this rule MUST
   be rejected as malformed.

   The TAMP message originator MUST include the content-type and
   message-digest attributes.  The TAMP message originator MAY also
   include the binary-signing-time attribute.








Housley, et al.              Standards Track                   [Page 16]
^L
RFC 5934                          TAMP                       August 2010


   The TAMP message originator MAY include any other attribute that it
   deems appropriate.  The intent is to allow additional signed
   attributes to be included if a future need is identified.  This does
   not cause an interoperability concern because unrecognized signed
   attributes MUST be ignored.

   The following summarizes the signed attribute requirements for TAMP
   messages:

   o  content-type MUST be supported.

   o  message-digest MUST be supported.

   o  binary-signing-time MAY be supported.  When present, it is
      generally ignored by the recipient.

   o  other attributes MAY be supported.  Unrecognized attributes MUST
      be ignored by the recipient.

2.2.3.1.  Content-Type Attribute

   The TAMP message originator MUST include a content-type attribute; it
   is an object identifier that uniquely specifies the content type.
   Section 11.1 of [RFC5652] defines the content-type attribute.  For
   TAMP, the value identifies the TAMP message.  The list of TAMP
   message content types and their identifiers is provided in Section 4.

   A content-type attribute MUST contain the same object identifier as
   the content type contained in the EncapsulatedContentInfo.

2.2.3.2.  Message-Digest Attribute

   The TAMP message originator MUST include a message-digest attribute,
   having as its value the output of a one-way hash function computed on
   the TAMP message that is being signed.  Section 11.2 of [RFC5652]
   defines the message-digest attribute.

2.2.3.3.  Binary-Signing-Time Attribute

   The TAMP message originator MAY include a binary-signing-time
   attribute, specifying the time at which the digital signature was
   applied to the TAMP message.  The binary-signing-time attribute is
   defined in [RFC4049].

   No processing of the binary-signing-time attribute is REQUIRED of a
   TAMP message recipient; however, the binary-signing-time attribute
   MAY be included by the TAMP message originator as a form of message
   identifier.



Housley, et al.              Standards Track                   [Page 17]
^L
RFC 5934                          TAMP                       August 2010


2.2.4.  Unsigned Attributes

   For TAMP, unsigned attributes are usually omitted.  An unsigned
   attribute is present only in Apex Trust Anchor Update messages that
   are to be validated by the apex trust anchor contingency public key.
   In this case, the symmetric key to decrypt the previous contingency
   public key is provided in the contingency-public-key-decrypt-key
   unsigned attribute.  This attribute MUST be supported, and it is
   described in Section 2.2.4.1.

   The TAMP message originator SHOULD NOT include other unsigned
   attributes, and any unrecognized unsigned attributes MUST be ignored.

   The UnsignedAttributes syntax within SignerInfo is defined as a SET
   OF Attribute.  The UnsignedAttributes MUST include only one instance
   of any particular attribute.  TAMP messages that violate this rule
   MUST be rejected as malformed.

2.2.4.1.  Contingency-Public-Key-Decrypt-Key Attribute

   The contingency-public-key-decrypt-key attribute provides the
   plaintext symmetric key needed to decrypt the previously distributed
   apex trust anchor contingency public key.  The symmetric key MUST be
   useable with the symmetric algorithm used to previously encrypt the
   contingency public key.

   The contingency-public-key-decrypt-key attribute has the following
   syntax:

    contingency-public-key-decrypt-key ATTRIBUTE ::= {
      WITH SYNTAX PlaintextSymmetricKey
      SINGLE VALUE TRUE
      ID id-aa-TAMP-contingencyPublicKeyDecryptKey }

    id-aa-TAMP-contingencyPublicKeyDecryptKey
      OBJECT IDENTIFIER ::= { id-attributes 63 }

    PlaintextSymmetricKey ::= OCTET STRING

3.  Trust Anchor Formats

   TAMP recognizes three formats for representing trust anchor
   information within the protocol itself: Certificate [RFC5280],
   TBSCertificate [RFC5280], and TrustAnchorInfo [RFC5914].  The
   TrustAnchorChoice structure, defined in [RFC5914], is used to select
   one of these options.





Housley, et al.              Standards Track                   [Page 18]
^L
RFC 5934                          TAMP                       August 2010


    TrustAnchorChoice ::= CHOICE {
     certificate  Certificate,
     tbsCert      [1] EXPLICIT TBSCertificate,
     taInfo       [2] EXPLICIT TrustAnchorInfo }

   The Certificate structure is commonly used to represent trust
   anchors.  Certificates include a signature, which removes the ability
   for relying parties to customize the information within the structure
   itself.  TBSCertificate contains all of the information of the
   Certificate structure except for the signature, enabling tailoring of
   the information.  TrustAnchorInfo is intended to serve as a
   minimalist representation of trust anchor information for scenarios
   where storage or bandwidth is highly constrained.

   Implementations are not required to support all three options.  The
   unsupportedTrustAnchorFormat error code should be indicated when
   generating a TAMPError due to receipt of an unsupported trust anchor
   format.

4.  Trust Anchor Management Protocol Messages

   TAMP makes use of signed and unsigned messages.  The CMS is used in
   both cases.  An object identifier is assigned to each TAMP message
   type, and this object identifier is used as a content type in the
   CMS.

   TAMP specifies eleven message types.  The following provides the
   content type identifier for each TAMP message type, and it indicates
   whether a digital signature is required.  If the following indicates
   that the TAMP message MUST be signed, then implementations MUST
   reject a message of that type that is not signed.

   o  The TAMP Status Query message MUST be signed.  It uses the
      following object identifier: { id-tamp 1 }.

   o  The TAMP Status Response message SHOULD be signed.  It uses the
      following object identifier: { id-tamp 2 }.

   o  The Trust Anchor Update message MUST be signed.  It uses the
      following object identifier: { id-tamp 3 }.

   o  The Trust Anchor Update Confirm message SHOULD be signed.  It uses
      the following object identifier: { id-tamp 4 }.

   o  The Apex Trust Anchor Update message MUST be signed.  It uses the
      following object identifier: { id-tamp 5 }.





Housley, et al.              Standards Track                   [Page 19]
^L
RFC 5934                          TAMP                       August 2010


   o  The Apex Trust Anchor Update Confirm message SHOULD be signed.  It
      uses the following object identifier: { id-tamp 6 }.

   o  The Community Update message MUST be signed.  It uses the
      following object identifier: { id-tamp 7 }.

   o  The Community Update Confirm message SHOULD be signed.  It uses
      the following object identifier: { id-tamp 8 }.

   o  The Sequence Number Adjust MUST be signed.  It uses the following
      object identifier: { id-tamp 10 }.

   o  The Sequence Number Adjust Confirm message SHOULD be signed.  It
      uses the following object identifier: { id-tamp 11 }.

   o  The TAMP Error message SHOULD be signed.  It uses the following
      object identifier: { id-tamp 9 }.

   Trust anchor managers generate TAMP Status Query, Trust Anchor
   Update, Apex Trust Anchor Update, Community Update, and Sequence
   Number Adjust messages.  Trust anchor stores generate TAMP Status
   Response, Trust Anchor Update Confirm, Apex Trust Anchor Update
   Confirm, Community Update Confirm, Sequence Number Adjust Confirm,
   and TAMP Error messages.

   Support for Trust Anchor Update messages is REQUIRED.  Support for
   all other message formats is RECOMMENDED.  Implementations that
   support the HTTP binding described in Appendix C MUST additionally
   support Trust Anchor Update Confirm and TAMP Error messages and MAY
   support 0 or more of the following pairs of messages: TAMP Status
   Query and TAMP Status Query Response; Apex Trust Anchor Update and
   Apex Trust Anchor Update Confirm; Community Update and Community
   Update Confirm; Sequence Number Adjust and Sequence Number Adjust
   Confirm.  Implementations that operate in a disconnected manner MUST
   NOT assume a response will be received from each consumer of a TAMP
   message.

   A typical interaction between a trust anchor manager and a trust
   anchor store will follow the message flow shown in Figure 1.  Figure
   1 does not illustrate a flow where an error occurs.











Housley, et al.              Standards Track                   [Page 20]
^L
RFC 5934                          TAMP                       August 2010


      +---------+                                +----------+
      |         |  Trust Anchor Status Query     |          |
      |         |------------------------------->|          |
      |         |                                |          |
      |         |  Trust Anchor Status Response  |          |
      | Trust   |<-------------------------------| Trust    |
      | Anchor  |                                | Anchor   |
      | Manager |  Trust Anchor Update           | Store    |
      |         |------------------------------->|          |
      |         |                                |          |
      |         |  Trust Anchor Update Confirm   |          |
      |         |<-------------------------------|          |
      |         |                                |          |
      +---------+                                +----------+

                   Figure 1.  Typical TAMP Message Flow

   Each TAMP query and update message includes an indication of the type
   of response that is desired.  The response can either be terse or
   verbose.  All trust anchor stores MUST support both the terse and
   verbose responses and SHOULD generate a response of the type
   indicated in the corresponding request.  TAMP response processors
   MUST support processing of both terse and verbose responses.

   Trust anchor stores SHOULD be able to process and properly act upon
   the valid payload of the TAMP Status Query message, the Trust Anchor
   Update message, the Apex Trust Anchor Update message, and the
   Sequence Number Adjust message.  TAMP implementations MAY also
   process and act upon the valid payload of the Community Update
   message.

   TAMP implementations SHOULD support generation of the TAMP Status
   Response message, the Trust Anchor Update Confirm message, the Apex
   Trust Anchor Update Confirm message, the Sequence Number Adjust
   Confirm message, and the TAMP Error message.  If a TAMP
   implementation supports the Community Update message, then generation
   of Community Update Confirm messages SHOULD also be supported.

4.1.  TAMP Status Query

   The TAMP Status Query message is used to request information about
   the trust anchors that are currently installed in a trust anchor
   store, and for the list of communities to which the store belongs.
   The TAMP Status Query message MUST be signed.  For the query message
   to be valid, the trust anchor store MUST be an intended recipient of
   the query; the sequence number checking described in Section 6 MUST
   be successful when the TAMP message signer is a trust anchor; and the
   digital signature MUST be validated by the apex trust anchor



Housley, et al.              Standards Track                   [Page 21]
^L
RFC 5934                          TAMP                       August 2010


   operational public key, an authorized management trust anchor, or via
   an authorized X.509 certification path originating with such a trust
   anchor.

   If the digital signature on the TAMP Status Query message is valid,
   sequence number checking is successful, the signer is authorized, and
   the trust anchor store is an intended recipient of the TAMP message,
   then a TAMP Status Response message SHOULD be returned.  If a TAMP
   Status Response message is not returned, then a TAMP Error message
   SHOULD be returned.

   The TAMP Status Query content type has the following syntax:

    CONTENT-TYPE  ::= TYPE-IDENTIFIER

    tamp-status-query CONTENT-TYPE  ::=
       { TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery }

    id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 }

    TAMPStatusQuery ::= SEQUENCE {
      Version  [0] TAMPVersion DEFAULT v2,
      terse    [1] TerseOrVerbose DEFAULT verbose,
      query    TAMPMsgRef }

    TAMPVersion ::= INTEGER { v1(1), v2(2) }

    TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) }

    TAMPMsgRef ::= SEQUENCE {
      target  TargetIdentifier,
      seqNum  SeqNumber }

    SeqNumber ::= INTEGER (0..9223372036854775807)

    TargetIdentifier ::= CHOICE {
      hwModules    [1] HardwareModuleIdentifierList,
      communities  [2] CommunityIdentifierList,
      allModules   [3] NULL,
      uri          [4] IA5String,
      otherName    [5] AnotherName }

    HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF
                                     HardwareModules

    HardwareModules ::= SEQUENCE {
      hwType           OBJECT IDENTIFIER,
      hwSerialEntries  SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry }



Housley, et al.              Standards Track                   [Page 22]
^L
RFC 5934                          TAMP                       August 2010


    HardwareSerialEntry ::= CHOICE {
      all     NULL,
      single  OCTET STRING,
      block   SEQUENCE {
        low     OCTET STRING,
        high    OCTET STRING } }

    CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community

    Community ::= OBJECT IDENTIFIER

   The fields of TAMPStatusQuery are used as follows:

   o  version identifies version of TAMP.  For this version of the
      specification, the default value, v2, MUST be used.

   o  terse indicates the type of response that is desired.  A terse
      response is indicated by a value of 1, and a verbose response is
      indicated by a value of 2, which is omitted during encoding since
      it is the default value.

   o  query contains two items: the target and the seqNum.  target
      identifies the target(s) of the query message.  seqNum is a
      single-use value that will be used to match the TAMP Status Query
      message with the TAMP Status Response message.  The sequence
      number is also used to detect TAMP message replay.  The sequence
      number processing described in Section 6 MUST successfully
      complete before a response is returned.

   The fields of TAMPMsgRef are used as follows:

   o  target identifies the target(s) of the query.  Several
      alternatives for naming a target are provided.  To identify a
      cryptographic module, a combination of a cryptographic type and
      serial number are used.  The cryptographic type is represented as
      an ASN.1 object identifier, and the unique serial number is
      represented as a string of octets.  To facilitate compact
      representation of serial numbers, a contiguous block can be
      specified by the lowest included serial number and the highest
      included serial number.  When present, the high and low octet
      strings MUST have the same length.  The
      HardwareModuleIdentifierList sequence MUST NOT contain duplicate
      hwType values, so that each member of the sequence names all of
      the cryptographic modules of this type.  Object identifiers are
      also used to identify communities of trust anchor stores.  A
      sequence of these object identifiers is used if more than one
      community is the target of the message.  A trust anchor store is
      considered a target if it is a member of any of the listed



Housley, et al.              Standards Track                   [Page 23]
^L
RFC 5934                          TAMP                       August 2010


      communities.  An explicit NULL value is used to identify all
      modules that consider the signer of the TAMP message to be an
      authorized source for that message type.  The uri field can be
      used to identify a target, i.e., a trust anchor store, using a
      Uniform Resource Identifier [RFC3986].  Additional name types are
      supported via the otherName field, which is of type AnotherName.
      AnotherName is defined in [RFC5280].  The format and semantics of
      the name are indicated through the OBJECT IDENTIFIER in the type-
      id field.  The name itself is conveyed as a value field in
      otherName.  Implementations MUST support the allModules option and
      SHOULD support all TargetIdentifier options.

   o  seqNum contains a single-use value that will be used to match the
      TAMP Status Query message with the successful TAMP Status Response
      message.  The sequence number processing described in Section 6
      MUST successfully complete before a response is returned.

   To determine whether a particular cryptographic module serial number
   is considered part of a specified block, all of the following
   conditions MUST be met.  First, the cryptographic module serial
   number MUST be the same length as both the high and low octet
   strings.  Second, the cryptographic module serial number MUST be
   greater than or equal to the low octet string.  Third, the
   cryptographic module serial number MUST be less than or equal to the
   high octet string.

   One octet string is equal to another if they are of the same length
   and are the same at each octet position.  An octet string, S1, is
   greater than another, S2, where S1 and S2 have the same length, if
   and only if S1 and S2 have different octets in one or more positions,
   and in the first such position, the octet in S1 is greater than that
   in S2, considering the octets as unsigned binary numbers.  Note that
   these octet string comparison definitions are consistent with those
   in clause 6 of [X.690].

4.2.  TAMP Status Query Response

   The TAMP Status Response message is a reply by a trust anchor store
   to a valid TAMP Status Query message.  The TAMP Status Response
   message provides information about the trust anchors that are
   currently installed in the trust anchor store and the list of
   communities to which the trust anchor store belongs, if any.  The
   TAMP Status Response message MAY be signed or unsigned.  A TAMP
   Status Response message MUST be signed if the implementation is
   capable of signing it.






Housley, et al.              Standards Track                   [Page 24]
^L
RFC 5934                          TAMP                       August 2010


   The TAMP Status Response content type has the following syntax:

    tamp-status-response CONTENT-TYPE  ::=
       { TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse }

    id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 }

    TAMPStatusResponse ::= SEQUENCE {
      version   [0] TAMPVersion DEFAULT v2,
      query     TAMPMsgRef,
      response  StatusResponse,
      usesApex  BOOLEAN DEFAULT TRUE }

    StatusResponse ::= CHOICE {
      terseResponse          [0] TerseStatusResponse,
      verboseResponse        [1] VerboseStatusResponse }

    TerseStatusResponse ::= SEQUENCE {
      taKeyIds               KeyIdentifiers,
      communities            CommunityIdentifierList OPTIONAL }

    KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier

    VerboseStatusResponse ::= SEQUENCE {
      taInfo                 TrustAnchorChoiceList,
      continPubKeyDecryptAlg [0] AlgorithmIdentifier OPTIONAL,
      communities            [1] CommunityIdentifierList OPTIONAL,
      tampSeqNumbers         [2] TAMPSequenceNumbers OPTIONAL }

    TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF
        TrustAnchorChoice

    TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF TAMPSequenceNumber

    TAMPSequenceNumber ::= SEQUENCE {
      keyId       KeyIdentifier,
      seqNumber   SeqNumber }

   The fields of TAMPStatusResponse are used as follows:

   o  version identifies version of TAMP.  For this version of the
      specification, the default value, v2, MUST be used.

   o  query identifies the TAMPStatusQuery to which the trust anchor
      store is responding.  The query structure repeats the TAMPMsgRef
      from the TAMP Status Query message (see Section 4.1).  The
      sequence number processing described in Section 6 MUST
      successfully complete before any response is returned.



Housley, et al.              Standards Track                   [Page 25]
^L
RFC 5934                          TAMP                       August 2010


   o  response contains either a terse response or a verbose response.
      The terse response is represented by TerseStatusResponse, and the
      verbose response is represented by VerboseStatusResponse.

   o  usesApex is a Boolean value that indicates whether the first item
      in the TerseStatusResponse.taKeyIds or
      VerboseStatusResponse.taInfo field identifies the apex TA.

   The fields of TerseStatusResponse are used as follows:

   o  taKeyIds contains a sequence of key identifiers.  Each trust
      anchor contained in the trust anchor store is represented by one
      key identifier.  When TAMPStatusResponse.usesApex is TRUE, the
      apex trust anchor is represented by the first key identifier in
      the sequence, which contains the key identifier of the operational
      public key.

   o  communities is OPTIONAL.  When present, it contains a sequence of
      object identifiers.  Each object identifier names one community to
      which this trust anchor store belongs.  When the trust anchor
      store belongs to no communities, this field is omitted.

   The fields of VerboseStatusResponse are used as follows:

   o  taInfo contains a sequence of TrustAnchorChoice structures.  One
      entry in the sequence is provided for each trust anchor contained
      in the trust anchor store.  When TAMPStatusResponse.usesApex is
      TRUE, the apex trust anchor is the first trust anchor in the
      sequence.

   o  continPubKeyDecryptAlg is OPTIONAL.  When present, it indicates
      the decryption algorithm needed to decrypt the currently installed
      apex trust anchor contingency public key, if a contingency key is
      associated with the apex trust anchor.  When present,
      TAMPStatusResponse.usesApex MUST be TRUE.

   o  communities is OPTIONAL.  When present, it contains a sequence of
      object identifiers.  Each object identifier names one community to
      which this trust anchor store belongs.  When the trust anchor
      store belongs to no communities, this field is omitted.

   o  tampSeqNumbers is OPTIONAL.  When present, it is used to indicate
      the currently held sequence number for each trust anchor
      authorized to sign TAMP messages.  The keyId field identifies the
      trust anchor, and the seqNumber field provides the current
      sequence number associated with the trust anchor.





Housley, et al.              Standards Track                   [Page 26]
^L
RFC 5934                          TAMP                       August 2010


4.3.  Trust Anchor Update

   The Trust Anchor Update message is used to add, remove, and change
   management and identity trust anchors.  The Trust Anchor Update
   message cannot be used to update the apex trust anchor.  The Trust
   Anchor Update message MUST be signed.  For a Trust Anchor Update
   message to be valid, the trust anchor store MUST be an intended
   recipient of the update; the sequence number checking described in
   Section 6 MUST be successful when the TAMP message signer is a trust
   anchor; and the digital signature MUST be validated using the apex
   trust anchor operational public key, an authorized management trust
   anchor, or via an authorized X.509 certification path originating
   with such a trust anchor.

   If the digital signature on the Trust Anchor Update message is valid,
   sequence number checking is successful, the signer is authorized, and
   the trust anchor store is an intended recipient of the TAMP message,
   then the trust anchor store MUST perform the specified updates and
   return a Trust Anchor Update Confirm message.  If a Trust Anchor
   Update Confirm message is not returned, then a TAMP Error message
   SHOULD be returned.

   The Trust Anchor Update content type has the following syntax:

    tamp-update CONTENT-TYPE  ::=
       { TAMPUpdate IDENTIFIED BY id-ct-TAMP-update }

    id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 }

    TAMPUpdate ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      terse    [1] TerseOrVerbose DEFAULT verbose,
      msgRef   TAMPMsgRef,
      updates  SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate,
      tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL }

    TrustAnchorUpdate ::= CHOICE {
      add     [1] TrustAnchorChoice,
      remove  [2] SubjectPublicKeyInfo,
      change  [3] EXPLICIT TrustAnchorChangeInfoChoice }

    TrustAnchorChangeInfoChoice ::= CHOICE {
      tbsCertChange  [0] TBSCertificateChangeInfo,
      taChange       [1] TrustAnchorChangeInfo }







Housley, et al.              Standards Track                   [Page 27]
^L
RFC 5934                          TAMP                       August 2010


    TBSCertificateChangeInfo  ::=  SEQUENCE  {
      serialNumber         CertificateSerialNumber OPTIONAL,
      signature            [0] AlgorithmIdentifier OPTIONAL,
      issuer               [1] Name OPTIONAL,
      validity             [2] Validity OPTIONAL,
      subject              [3] Name OPTIONAL,
      subjectPublicKeyInfo [4] SubjectPublicKeyInfo,
      exts                 [5] EXPLICIT Extensions OPTIONAL }

    TrustAnchorChangeInfo ::= SEQUENCE {
      pubKey          SubjectPublicKeyInfo,
      keyId           KeyIdentifier OPTIONAL,
      taTitle         TrustAnchorTitle OPTIONAL,
      certPath        CertPathControls OPTIONAL,
      exts            [1] Extensions OPTIONAL }

   The fields of TAMPUpdate are used as follows:

   o  version identifies version of TAMP.  For this version of the
      specification, the default value, v2, MUST be used.

   o  terse indicates the type of response that is desired.  A terse
      response is indicated by a value of 1, and a verbose response is
      indicated by a value of 2, which is omitted during encoding since
      it is the default value.

   o  msgRef contains two items: the target and the seqNum.  target
      identifies the target(s) of the update message.  The
      TargetIdentifier syntax is described in Section 4.1.  seqNum is a
      single-use value that will be used to match the Trust Anchor
      Update message with the Trust Anchor Update Confirm message.  The
      sequence number is also used to detect TAMP message replay.  The
      sequence number processing described in Section 6 MUST
      successfully complete before any of the updates are processed.

   o  updates contains a sequence of updates, which are used to add,
      remove, and change management or identity trust anchors.  Each
      entry in the sequence represents one of these actions, and is
      indicated by an instance of TrustAnchorUpdate.  The actions are a
      batch of updates that MUST be processed in the order that they
      appear, but each of the updates is processed independently.  Each
      of the updates MUST satisfy the subordination checks described in
      Section 7.  Even if one or more of the updates fail, then the
      remaining updates MUST be processed.  These updates MUST NOT make
      any changes to the apex trust anchor.






Housley, et al.              Standards Track                   [Page 28]
^L
RFC 5934                          TAMP                       August 2010


   o  tampSeqNumbers MAY be included to provide the initial or new
      sequence numbers for trust anchors added or changed by the updates
      field.  Elements included in the tampSeqNumbers field that do not
      correspond to an element in the updates field are ignored.
      Elements included in the tampSeqNumbers field that do correspond
      to an element in the updates field and contain a sequence number
      less than or equal to the most recently stored sequence number for
      the trust anchor are ignored.  Elements included in the
      tampSeqNumbers field that do correspond to an element in the
      updates field and contain a sequence number greater than the most
      recently stored sequence number for the indicated trust anchor are
      processed by setting the stored sequence number for the trust
      anchor equal to the new value.

   The TrustAnchorUpdate is a choice of three structures, and each
   alternative represents one of the three possible actions: add,
   remove, and change.  A description of the syntax associated with each
   of these actions follows:

   o  add is used to insert a new management or identity trust anchor
      into the trust anchor store.  The TrustAnchorChoice structure is
      used to provide the trusted public key and all of the information
      associated with it.  However, the action MUST fail with the error
      code notAuthorized if the subordination checks described in
      Section 7 are not satisfied.  See Section 3 for a discussion of
      the TrustAnchorChoice structure.  The apex trust anchor cannot be
      introduced into a trust anchor store using this action; therefore,
      the id-pe-wrappedApexContinKey MUST NOT be present in the
      extensions field.  The constraints of the existing trust anchors
      are unchanged by this action.  An attempt to add a management or
      identity trust anchor that is already in place with the same
      values for every field in the TrustAnchorChoice structure MUST be
      treated as a successful addition.  An attempt to add a management
      or identity trust anchor that is already present with the same
      pubKey values, but with different values for any of the fields in
      the TrustAnchorChoice structure, MUST fail with the error code
      improperTAAddition.  This means a trust anchor may not be added
      twice using different TrustAnchorChoice options.  If a different
      format is desired, the existing trust anchor must be removed and
      the new format added.

   o  remove is used to delete an existing management or identity trust
      anchor from the trust anchor store, including the deletion of the
      management trust anchor associated with the TAMP message signer.
      However, the action MUST fail with the error code notAuthorized if
      the subordination checks described in Section 7 are not satisfied.
      The public key contained in SubjectPublicKeyInfo names the
      management or identity trust anchor to be deleted.  An attempt to



Housley, et al.              Standards Track                   [Page 29]
^L
RFC 5934                          TAMP                       August 2010


      delete a trust anchor that is not present MUST be treated as a
      successful deletion.  The constraints of the deleted trust anchor
      are not distributed to other trust anchors in any manner.  The
      apex trust anchor cannot be removed using this action, which
      ensures that this action cannot place the trust anchor store in an
      unrecoverable configuration.

   o  change is used to update the information associated with an
      existing management or identity trust anchor in the trust anchor
      store.  Attempts to change a trust anchor added as a Certificate
      MUST fail with the error code improperTAChange.  The public key
      contained in the SubjectPublicKeyInfo field of
      TrustAnchorChangeInfo or in the subjectPublicKeyInfo field of a
      TBSCertificateChangeInfo names the to-be-updated trust anchor.
      However, the action MUST fail with the error code notAuthorized if
      the subordination checks described in Section 7 are not satisfied.
      An attempt to change a trust anchor that is not present MUST
      result in a failure with the trustAnchorNotFound status code.  The
      TrustAnchorChangeInfo structure or the TBSCertificateChangeInfo
      structure is used to provide the revised configuration of the
      management or identity trust anchor.  If the update fails for any
      reason, then the original trust anchor configuration MUST be
      preserved.  The apex trust anchor information cannot be changed
      using this action.  Attempts to change a trust anchor added as a
      TBSCertificate using a TrustAnchorChangeInfo MUST fail with an
      improperTAChange error.  Attempts to change a trust anchor added
      as a TrustAnchorInfo using a TBSCertificateChangeInfo MUST fail
      with an improperTAChange error.

   The fields of TrustAnchorChangeInfo are used as follows:

   o  pubKey contains the algorithm identifier and the public key of the
      management or identity trust anchor.  It is used to locate the
      to-be-updated trust anchor in the trust anchor store.

   o  keyId is OPTIONAL, and when present, it contains the public key
      identifier of the trust anchor public key, which is contained in
      the pubKey field.  If this field is not present, then the public
      key identifier remains unchanged.  If this field is present, the
      provided public key identifier replaces the previous one.

   o  taTitle is OPTIONAL, and when present, it provides a human
      readable name for the management or identity trust anchor.  When
      absent in a change trust anchor update, any title that was
      previously associated with the trust anchor is removed.
      Similarly, when present in a change trust anchor update, the title





Housley, et al.              Standards Track                   [Page 30]
^L
RFC 5934                          TAMP                       August 2010


      in the message is associated with the trust anchor.  If a previous
      title was associated with the trust anchor, then the title is
      replaced.  If a title was not previously associated with the trust
      anchor, then the title from the update message is added.

   o  certPath is OPTIONAL, and when present, it provides the controls
      needed to construct and validate an X.509 certification path.
      When absent in a change trust anchor update, any controls that
      were previously associated with the management or identity trust
      anchor are removed, which means that delegation is no longer
      permitted.  Similarly, when present in a change trust anchor
      update, the controls in the message are associated with the
      management or identity trust anchor.  If previous controls,
      including the trust anchor distinguished name, were associated
      with the trust anchor, then the controls are replaced, which means
      that delegation continues to be supported, but that different
      certification paths will be valid.  If controls were not
      previously associated with the management or identity trust
      anchor, then the controls from the update message are added, which
      enables delegation.  The syntax and semantics of CertPathControls
      are discussed in [RFC5914].

   o  exts is OPTIONAL, and when present, it provides the extensions
      values that are associated with the trust anchor.  When absent in
      a change trust anchor update, any extensions that were previously
      associated with the trust anchor are removed.  Similarly, when
      present in a change trust anchor update, the extensions in the
      message are associated with the trust anchor.  Any extensions
      previously associated with the trust anchor are replaced or
      removed.

   The fields of TBSCertificateChangeInfo are used to alter the fields
   within a TBSCertificate structure.  TBSCertificate is described in
   [RFC5280].  For all fields except exts, if the field is absent in a
   change trust anchor update, then any previous value associated with a
   trust anchor is unchanged.  For the exts field, if the field is
   absent in a change trust anchor update, then any previous value
   associated with a trust anchor is removed.  For all fields, if the
   field is present in a change trust anchor update, then any previous
   value associated with a trust anchor is replaced with the value from
   the update message.

4.3.1.  Trust Anchor List

   [RFC5914] defines the TrustAnchorList structure to convey a list of
   trust anchors.  TAMP implementations MAY process TrustAnchorList
   objects (with eContentType (or contentType) using the id-ct-
   trustAnchorList OID defined in [RFC5914]) as equivalent to TAMPUpdate



Housley, et al.              Standards Track                   [Page 31]
^L
RFC 5934                          TAMP                       August 2010


   objects with terse set to terse, msgRef set to allModules (with a
   suitable sequence number), and all elements within the list contained
   within the add field.  This alternative to TrustAnchorUpdate is
   provided for implementations that perform integrity and authorization
   checks out-of-band as a simple means of transferring trust anchors
   from one trust anchor store to another.  It does not provide a means
   of removing or changing trust anchors and has no HTTP binding.

4.4.  Trust Anchor Update Confirm

   The Trust Anchor Update Confirm message is a reply by a trust anchor
   store to a valid Trust Anchor Update message.  The Trust Anchor
   Update Confirm message provides success and failure information for
   each of the requested updates.  The Trust Anchor Update Confirm
   message MAY be signed or unsigned.  A Trust Anchor Update Confirm
   message MUST be signed if the implementation is capable of
   signing it.

   The Trust Anchor Update Confirm content type has the following
   syntax:

    tamp-update-confirm CONTENT-TYPE  ::=
       { TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm }

    id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 }

    TAMPUpdateConfirm ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      update   TAMPMsgRef,
      confirm  UpdateConfirm }

    UpdateConfirm ::= CHOICE {
      terseConfirm    [0] TerseUpdateConfirm,
      verboseConfirm  [1] VerboseUpdateConfirm }

    TerseUpdateConfirm ::= StatusCodeList

    StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode

    VerboseUpdateConfirm ::= SEQUENCE {
      status          StatusCodeList,
      taInfo          TrustAnchorChoiceList,
      tampSeqNumbers  TAMPSequenceNumbers OPTIONAL,
      usesApex        BOOLEAN DEFAULT TRUE }







Housley, et al.              Standards Track                   [Page 32]
^L
RFC 5934                          TAMP                       August 2010


   The fields of TAMPUpdateConfirm are used as follows:

   o  version identifies version of TAMP.  For this version of the
      specification, the default value, v2, MUST be used.

   o  update identifies the TAMPUpdate message to which the trust anchor
      store is responding.  The update structure repeats the TAMPMsgRef
      from the Trust Anchor Update message (see Section 4.3).  The
      sequence number processing described in Section 6 MUST
      successfully complete before any of the updates are processed.

   o  confirm contains either a terse update confirmation or a verbose
      update confirmation.  The terse update confirmation is represented
      by TerseUpdateConfirm, and the verbose response is represented by
      VerboseUpdateConfirm.

   The TerseUpdateConfirm contains a sequence of status codes, one for
   each TrustAnchorUpdate structure in the Trust Anchor Update message.
   The status codes MUST appear in the same order as the
   TrustAnchorUpdate structures to which they apply, and the number of
   elements in the status code list MUST be the same as the number of
   elements in the trust anchor update list.  Each of the status codes
   is discussed in Section 5.

   The fields of VerboseUpdateConfirm are used as follows:

   o  status contains a sequence of status codes, one for each
      TrustAnchorUpdate structure in the Trust Anchor Update message.
      The status codes appear in the same order as the TrustAnchorUpdate
      structures to which they apply, and the number of elements in the
      status code list MUST be the same as the number of elements in the
      trust anchor update list.  Each of the status codes is discussed
      in Section 5.

   o  taInfo contains a sequence of TrustAnchorChoice structures.  One
      entry in the sequence is provided for each trust anchor contained
      in the trust anchor store.  These represent the state of the trust
      anchors after the updates have been processed.  When usesApex is
      true, the apex trust anchor is the first trust anchor in the
      sequence.

   o  tampSeqNumbers is used to indicate the currently held sequence
      number for each trust anchor authorized to sign TAMP messages.
      The keyId field identifies the trust anchor, and the seqNumber
      field provides the current sequence number associated with the
      trust anchor.





Housley, et al.              Standards Track                   [Page 33]
^L
RFC 5934                          TAMP                       August 2010


   o  usesApex is a Boolean value that indicates whether the first item
      in the taInfo field identifies the apex TA.

4.5.  Apex Trust Anchor Update

   The Apex Trust Anchor Update message replaces the operational public
   key and, optionally, the contingency public key associated with the
   apex trust anchor.  Each trust anchor store has exactly one apex
   trust anchor.  No constraints are associated with the apex trust
   anchor.  The public key identifier of the operational public key is
   used to identify the apex trust anchor in subsequent TAMP messages.
   The digital signature on the Apex Trust Anchor Update message is
   validated with either the current operational public key or the
   current contingency public key.  For the Apex Trust Anchor Update
   message that is validated with the operational public key to be
   valid, the trust anchor store MUST be a target of the update, the
   sequence number MUST be larger than the most recently stored sequence
   number for the operational public key, and the digital signature MUST
   be validated directly with the operational public key.  That is, no
   delegation via a certification path is permitted.  For the Apex Trust
   Anchor Update message that is validated with the contingency public
   key to be valid, the trust anchor store MUST be a target of the
   update, the provided decryption key MUST properly decrypt the
   contingency public key, and the digital signature MUST be validated
   directly with the decrypted contingency public key.  Again, no
   delegation via a certification path is permitted.

   If the Apex Trust Anchor Update message is validated using the
   operational public key, then sequence number processing is handled
   normally, as described in Section 6.  If the Apex Trust Anchor Update
   message is validated using the contingency public key, then the
   TAMPMsgRef sequence number MUST contain a zero value.  A sequence
   number for subsequent messages that will be validated with the new
   operational public key can optionally be provided.  If no value is
   provided, then the trust anchor store MUST be prepared to accept any
   sequence number in the next TAMP message validated with the newly
   installed apex trust anchor operational public key.  If the Apex
   Trust Anchor Update message is valid and the clearTrustAnchors flag
   is set to TRUE, then all of the management and identity trust anchors
   stored in the trust anchor store MUST be deleted.  That is, the new
   apex trust anchor MUST be the only trust anchor remaining in the
   trust anchor store.  If the Apex Trust Anchor Update message is valid
   and the clearCommunities flag is set to TRUE, then all community
   identifiers stored in the trust anchor store MUST be deleted.

   The SignedData structure includes a SignerInfo.sid value, and it
   identifies the apex trust anchor public key that will be used to
   validate the digital signature on this TAMP message.  The public key



Housley, et al.              Standards Track                   [Page 34]
^L
RFC 5934                          TAMP                       August 2010


   identifier for the operational public key is known in advance, and it
   is stored as part of the apex trust anchor.  The public key
   identifier for the contingency public key is not known in advance;
   however, the presence of the unsigned attribute containing the
   symmetric key needed to decrypt the contingency public key
   unambiguously indicates that the TAMP message signer used the
   contingency private key to sign the Apex Trust Anchor Update message.

   If the digital signature on the Apex Trust Anchor Update message is
   valid using either the apex trust anchor operational public key or
   the apex trust anchor contingency public key, sequence number
   checking is successful, and the trust anchor store is an intended
   recipient of the TAMP message, then the trust anchor store MUST
   update the apex trust anchor and return an Apex Trust Anchor Update
   Confirm message.  If an Apex Trust Anchor Update Confirm message is
   not returned, then a TAMP Error message SHOULD be returned.  Note
   that the sequence number MUST be zero if the Apex Trust Anchor Update
   message is validated with the apex trust anchor contingency public
   key.

   The Apex Trust Anchor Update content type has the following syntax:

    tamp-apex-update CONTENT-TYPE  ::=
       { TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate }

    id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 }

    TAMPApexUpdate ::= SEQUENCE {
      version            [0] TAMPVersion DEFAULT v2,
      terse              [1] TerseOrVerbose DEFAULT verbose,
      msgRef             TAMPMsgRef,
      clearTrustAnchors  BOOLEAN,
      clearCommunities   BOOLEAN,
      seqNumber          SeqNumber OPTIONAL,
      apexTA             TrustAnchorChoice }

   The fields of TAMPApexUpdate are used as follows:

   o  version identifies version of TAMP.  For this version of the
      specification, the default value, v2, MUST be used.

   o  terse indicates the type of response that is desired.  A terse
      response is indicated by a value of 1, and a verbose response is
      indicated by a value of 2, which is omitted during encoding since
      it is the default value.

   o  msgRef contains two items: the target and the seqNum.  target
      identifies the target(s) of the Apex Trust Anchor Update message.



Housley, et al.              Standards Track                   [Page 35]
^L
RFC 5934                          TAMP                       August 2010


      The TargetIdentifier syntax as described in Section 4.1 is used.
      seqNum is a single-use value that will be used to match the Apex
      Trust Anchor Update message with the Apex Trust Anchor Update
      Confirm message.  The sequence number is also used to detect TAMP
      message replay if the message is validated with the apex trust
      anchor operational public key.  The sequence number processing
      described in Section 6 MUST successfully complete before any
      action is taken.  However, seqNum MUST contain a zero value if the
      message is validated with the apex trust anchor contingency
      public key.

   o  clearTrustAnchors is a Boolean.  If the value is set to TRUE, then
      all of the management and identity trust anchors stored in the
      trust anchor store MUST be deleted, leaving the newly installed
      apex trust anchor as the only trust anchor in the trust anchor
      store.  If the value is set to FALSE, the other trust anchors MUST
      NOT be changed.

   o  clearCommunities is a Boolean.  If the value is set to TRUE, then
      all of the community identifiers stored in the trust anchor store
      MUST be deleted, leaving none.  If the value is set to FALSE, the
      list of community identifiers MUST NOT be changed.

   o  seqNumber is OPTIONAL, and when present, it provides the initial
      sequence number for the apex trust anchor.  If seqNumber is
      absent, the trust anchor store is prepared to accept any sequence
      number value for the apex trust anchor operational public key.

   o  apexTA provides the information for the replacement apex trust
      anchor.  The TrustAnchorChoice structure is used to provide the
      trusted public key and all of the information associated with it.
      The pubKey, keyId, taTitle, certPath, and exts fields apply to the
      operational public key of the apex trust anchor.  The
      ApexTrustAnchorInfo certificate extension MAY appear as an
      extension.  Section 9 describes the WrappedApexContingencyKey
      certificate extension.

4.6.  Apex Trust Anchor Update Confirm

   The Apex Trust Anchor Update Confirm message is a reply by a trust
   anchor store to a valid Apex Trust Anchor Update message.  The Apex
   Trust Anchor Update Confirm message provides success or failure
   information for the apex trust anchor update.  The Apex Trust Anchor
   Update Confirm message MAY be signed or unsigned.  An Apex Trust
   Anchor Update Confirm message MUST be signed if the trust anchor
   store is capable of signing it.





Housley, et al.              Standards Track                   [Page 36]
^L
RFC 5934                          TAMP                       August 2010


   The Apex Trust Anchor Update Confirm content type has the following
   syntax:

    tamp-apex-update-confirm CONTENT-TYPE  ::=
       { TAMPApexUpdateConfirm IDENTIFIED BY
         id-ct-TAMP-apexUpdateConfirm }

    id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 }

    TAMPApexUpdateConfirm ::= SEQUENCE {
      version      [0] TAMPVersion DEFAULT v2,
      apexReplace  TAMPMsgRef,
      apexConfirm  ApexUpdateConfirm }

    ApexUpdateConfirm ::= CHOICE {
      terseApexConfirm    [0] TerseApexUpdateConfirm,
      verboseApexConfirm  [1] VerboseApexUpdateConfirm }

    TerseApexUpdateConfirm ::= StatusCode

    VerboseApexUpdateConfirm ::= SEQUENCE {
      status                 StatusCode,
      taInfo                 TrustAnchorChoiceList,
      communities            [0] CommunityIdentifierList OPTIONAL,
      tampSeqNumbers         [1] TAMPSequenceNumbers OPTIONAL }

   The fields of TAMPApexUpdateConfirm are used as follows:

   o  version identifies version of TAMP.  For this version of the
      specification, the default value, v2, MUST be used.

   o  apexReplace identifies the Apex Trust Anchor Update message to
      which the trust anchor store is responding.  The apexReplace
      structure repeats the TAMPMsgRef from the beginning of the Apex
      Trust Anchor Update message (see Section 4.5).  When the Apex
      Trust Anchor Update message is validated with the operational
      public key, the sequence number processing described in Section 6
      MUST successfully complete before an Apex Trust Anchor Update
      Confirm message is generated.  When the Apex Trust Anchor Update
      message is validated with the contingency public key, normal
      sequence number processing is ignored, but the seqNum MUST be
      zero.

   o  apexConfirm contains either a terse update confirmation or a
      verbose update confirmation.  The terse update confirmation is
      represented by TerseApexUpdateConfirm, and the verbose response is
      represented by VerboseApexUpdateConfirm.




Housley, et al.              Standards Track                   [Page 37]
^L
RFC 5934                          TAMP                       August 2010


   The TerseApexUpdateConfirm contains a single status code, indicating
   the success or failure of the apex trust anchor update.  If the apex
   trust anchor update failed, then the status code provides the reason
   for the failure.  Each of the status codes is discussed in Section 5.

   The fields of VerboseApexUpdateConfirm are used as follows:

   o  status contains a single status code, indicating the success or
      failure of the apex trust anchor update.  If the apex trust anchor
      update failed, then the status code provides the reason for the
      failure.  Each of the status codes is discussed in Section 5.

   o  taInfo contains a sequence of TrustAnchorChoice structures.  One
      entry in the sequence is provided for each trust anchor contained
      in the trust anchor store.  These represent the state of the trust
      anchors after the apex trust anchor update has been processed.
      See [RFC5914] for a description of the TrustAnchorInfo structure.
      The apex trust anchor is the first trust anchor in the sequence.

   o  communities is OPTIONAL.  When present, it contains a sequence of
      object identifiers.  Each object identifier names one community to
      which this trust anchor store belongs.  When the trust anchor
      store belongs to no communities, this field is omitted.

   o  tampSeqNumbers is used to indicate the currently held sequence
      number for each trust anchor authorized to sign TAMP messages.
      The keyId field identifies the trust anchor, and the seqNumber
      field provides the current sequence number associated with the
      trust anchor.

4.7.  Community Update

   The trust anchor store maintains a list of identifiers for the
   communities of which it is a member.  The Community Update message
   can be used to remove or add community identifiers from this list.
   The Community Update message MUST be signed.  For the Community
   Update message to be valid, the trust anchor store MUST be a target
   of the update; the sequence number checking described in Section 6
   MUST be successful when the TAMP message signer is a trust anchor;
   and the digital signature MUST be validated by the apex trust anchor
   operational public key, an authorized management trust anchor, or via
   an authorized X.509 certification path originating with such a trust
   anchor.

   If the trust anchor store supports the Community Update message, the
   digital signature on the Community Update message is valid, sequence
   number checking is successful, the signer is authorized, and the
   trust anchor store is an intended recipient of the TAMP message, then



Housley, et al.              Standards Track                   [Page 38]
^L
RFC 5934                          TAMP                       August 2010


   the trust anchor store MUST make the specified updates and return a
   Community Update Confirm message.  If a Community Update Confirm
   message is not returned, then a TAMP Error message SHOULD be
   returned.

   The Community Update message contains a batch of updates, and all of
   the updates MUST be accepted for the trust anchor store to return a
   successful Community Update Confirm message.  The remove updates, if
   present, MUST be processed before the add updates.  Where remove is
   present with an empty list, all community identifiers MUST be
   removed.  This approach prevents community identifiers that are
   intended to be mutually exclusive from being installed by a
   successful addition and a failed removal.  Where add is present, at
   least one community identifier MUST appear in the list.

   The Community Update content type has the following syntax:

    tamp-community-update CONTENT-TYPE  ::=
       { TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate }

    id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 }

    TAMPCommunityUpdate ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      terse    [1] TerseOrVerbose DEFAULT verbose,
      msgRef   TAMPMsgRef,
      updates  CommunityUpdates }

    CommunityUpdates ::= SEQUENCE {
      remove     [1] CommunityIdentifierList OPTIONAL,
      add        [2] CommunityIdentifierList OPTIONAL }
       -- At least one MUST be present

   The fields of TAMPCommunityUpdate are used as follows:

   o  version identifies version of TAMP.  For this version of the
      specification, the default value, v2, MUST be used.

   o  terse indicates the type of response that is desired.  A terse
      response is indicated by a value of 1, and a verbose response is
      indicated by a value of 2, which is omitted during encoding since
      it is the default value.

   o  msgRef contains two items: the target and the seqNum.  target
      identifies the target(s) of the update message.  The
      TargetIdentifier syntax as described in Section 4.1 is used.
      seqNum is a single-use value that will be used to match the
      Community Update message with the Community Update Confirm



Housley, et al.              Standards Track                   [Page 39]
^L
RFC 5934                          TAMP                       August 2010


      message.  The sequence number is also used to detect TAMP message
      replay.  The sequence number processing described in Section 6
      MUST successfully complete before any of the updates are
      processed.

   o  updates contains a sequence of community identifiers to be removed
      and a sequence of community identifiers to be added.  These are
      represented by the CommunityUpdates structure.

   The CommunityUpdates is a sequence of two OPTIONAL sequences, but at
   least one of these sequences MUST be present.  The first sequence
   contains community identifiers to be removed, and if there are none,
   it is absent.  Where remove is present with an empty list, all
   community identifiers MUST be removed.  The second sequence contains
   community identifiers to be added, and if there are none, it is
   absent.  The remove updates, if present, MUST be processed before the
   add updates.  An error is generated if any of the requested removals
   or additions cannot be accomplished.  However, requests to remove
   community identifiers that are not present are treated as successful
   removals.  Likewise, requests to add community identifiers that are
   already present are treated as successful additions.  If an error is
   generated, the trust anchor store community list MUST NOT be changed.

   A description of the syntax associated with each of these actions
   follows:

   o  remove is used to remove one, multiple, or all community
      identifiers from the trust anchor store.

   o  add is used to insert one or more new community identifiers into
      the trust anchor store.

4.8.  Community Update Confirm

   The Community Update Confirm message is a reply by a trust anchor
   store to a valid Community Update message.  The Community Update
   Confirm message provides success or failure information for the
   requested updates.  Success is returned only if the whole batch of
   updates is successfully processed.  If any of the requested updates
   cannot be performed, then a failure is indicated, and the set of
   community identifiers stored in the trust anchor store is unchanged.
   The Community Update Confirm message MAY be signed or unsigned.  A
   Community Update Confirm message MUST be signed if the trust anchor
   store is capable of signing it.







Housley, et al.              Standards Track                   [Page 40]
^L
RFC 5934                          TAMP                       August 2010


   The Community Update Confirm content type has the following syntax:

    tamp-community-update-confirm CONTENT-TYPE  ::=
       { TAMPCommunityUpdateConfirm IDENTIFIED BY
         id-ct-TAMP-communityUpdateConfirm }

    id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::=
       { id-tamp 8 }

    TAMPCommunityUpdateConfirm ::= SEQUENCE {
      version      [0] TAMPVersion DEFAULT v2,
      update       TAMPMsgRef,
      commConfirm  CommunityConfirm }

    CommunityConfirm ::= CHOICE {
      terseCommConfirm     [0] TerseCommunityConfirm,
      verboseCommConfirm   [1] VerboseCommunityConfirm }

    TerseCommunityConfirm ::= StatusCode

    VerboseCommunityConfirm ::= SEQUENCE {
      status       StatusCode,
      communities  CommunityIdentifierList OPTIONAL }

   The fields of TAMPCommunityUpdateConfirm are used as follows:

   o  version identifies version of TAMP.  For this version of the
      specification, the default value, v2, MUST be used.

   o  update identifies the Community Update message to which the trust
      anchor store is responding.  The update structure repeats the
      TAMPMsgRef from the Community Update message (see Section 4.7).
      The sequence number processing described in Section 6 MUST
      successfully complete before any of the updates are processed.

   o  commConfirm contains either a terse community update confirmation
      or a verbose community update confirmation.  The terse response is
      represented by TerseCommunityConfirm, and the verbose response is
      represented by VerboseCommunityConfirm.

   The TerseCommunityConfirm contains a single status code, indicating
   the success or failure of the Community Update message processing.
   If the community update failed, then the status code indicates the
   reason for the failure.  Each of the status codes is discussed in
   Section 5.






Housley, et al.              Standards Track                   [Page 41]
^L
RFC 5934                          TAMP                       August 2010


   The fields of VerboseCommunityConfirm are used as follows:

   o  status contains a single status code, indicating the success or
      failure of the Community Update message processing.  If the
      community update failed, then the status code indicates the reason
      for the failure.  Each of the status codes is discussed in
      Section 5.

   o  communities is OPTIONAL.  When present, it contains the sequence
      of community identifiers present in the trust anchor store after
      the update is processed.  When the trust anchor store belongs to
      no communities, this field is omitted.

4.9.  Sequence Number Adjust

   The trust anchor store maintains the current sequence number for the
   apex trust anchor and each management trust anchor authorized for
   TAMP messages.  Sequence number processing is discussed in Section 6.
   The Sequence Number Adjust message can be used to provide the most
   recently used sequence number to one or more targets, thereby
   reducing the possibility of replay.  The Sequence Number Adjust
   message MUST be signed.  For the Sequence Number Adjust message to be
   valid, the trust anchor store MUST be an intended recipient of the
   Sequence Number Adjust message, the sequence number MUST be equal to
   or larger than the most recently stored sequence number for the
   originating trust anchor, and the digital signature MUST be validated
   by the apex trust anchor operational public key or an authorized
   management trust anchor.

   If the digital signature on the Sequence Number Adjust message is
   valid, the sequence number is equal to or larger than the most
   recently stored sequence number for the originating trust anchor, the
   signer is authorized, and the trust anchor store is an intended
   recipient of the TAMP message, then the trust anchor store MUST
   update the sequence number associated with the originating trust
   anchor and return a Sequence Number Adjust Confirm message.  If a
   Sequence Number Adjust Confirm message is not returned, then a TAMP
   Error message SHOULD be returned.

   The Sequence Number Adjust message contains an adjustment for the
   sequence number of the TAMP message signer.










Housley, et al.              Standards Track                   [Page 42]
^L
RFC 5934                          TAMP                       August 2010


   The Sequence Number Adjust content type has the following syntax:

    tamp-sequence-number-adjust CONTENT-TYPE  ::=
       { SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust }

    id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 }

    SequenceNumberAdjust ::= SEQUENCE {
      Version  [0] TAMPVersion DEFAULT v2,
      msgRef   TAMPMsgRef }

   The fields of SequenceNumberAdjust are used as follows:

   o  version identifies version of TAMP.  For this version of the
      specification, the default value, v2, MUST be used.

   o  msgRef contains two items: the target and the seqNum.  target
      identifies the target(s) of the sequence number adjust message.
      The TargetIdentifier syntax as described in Section 4.1 is used.
      The allModules target is expected to be used for Sequence Number
      Adjust messages.  seqNum MUST be equal to or larger than the most
      recently stored sequence number for this TAMP message signer, and
      the value will be used to match the Sequence Number Adjust message
      with the Sequence Number Adjust Confirm message.  The sequence
      number processing described in Section 6 applies, except that the
      sequence number in a Sequence Number Adjust message is acceptable
      if it matches the most recently stored sequence number for this
      TAMP message signer.  If sequence number checking completes
      successfully, then the sequence number is adjusted; otherwise, it
      remains unchanged.

4.10.  Sequence Number Adjust Confirm

   The Sequence Number Adjust Confirm message is a reply by a trust
   anchor store to a valid Sequence Number Adjust message.  The Sequence
   Number Adjust Confirm message provides success or failure
   information.  Success is returned only if the sequence number for the
   trust anchor that signed the Sequence Number Adjust message
   originator is adjusted.  If the sequence number cannot be adjusted,
   then a failure is indicated, and the sequence number stored in the
   trust anchor store is unchanged.  The Sequence Number Adjust Confirm
   message MAY be signed or unsigned.  A Sequence Number Adjust Confirm
   message MUST be signed if the trust anchor store is capable of
   signing it.







Housley, et al.              Standards Track                   [Page 43]
^L
RFC 5934                          TAMP                       August 2010


   The Sequence Number Adjust Confirm content type has the following
   syntax:

    tamp-sequence-number-adjust-confirm CONTENT-TYPE  ::=
       { SequenceNumberAdjustConfirm IDENTIFIED BY
         id-ct-TAMP-seqNumAdjustConfirm }

    id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::=
       { id-tamp 11 }

    SequenceNumberAdjustConfirm ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      adjust   TAMPMsgRef,
      status   StatusCode }

   The fields of SequenceNumberAdjustConfirm are used as follows:

   o  version identifies version of TAMP.  For this version of the
      specification, the default value, v2, MUST be used.

   o  adjust identifies the Sequence Number Adjust message to which the
      trust anchor store is responding.  The adjust structure repeats
      the TAMPMsgRef from the Sequence Number Adjust message (see
      Section 4.9).  The sequence number processing described in
      Section 6 MUST successfully complete to adjust the sequence number
      associated with the Sequence Number Adjust message originator.

   o  status contains a single status code, indicating the success or
      failure of the Sequence Number Adjust message processing.  If the
      adjustment failed, then the status code indicates the reason for
      the failure.  Each of the status codes is discussed in Section 5.

4.11.  TAMP Error

   The TAMP Error message is a reply by a trust anchor store to any
   invalid TAMP message.  The TAMP Error message provides an indication
   of the reason for the error.  The TAMP Error message MAY be signed or
   unsigned.  A TAMP Error message MUST be signed if the trust anchor
   store is capable of signing it.  For the request types defined in
   this specification, TAMP Error messages MUST NOT be used to indicate
   a request message was successfully processed.  Each TAMP Error
   message identifies the type of TAMP message that caused the error.
   In cases where the TAMP message type cannot be determined, errors MAY
   be returned via other means, such as at the protocol level, via an
   attached display, etc.






Housley, et al.              Standards Track                   [Page 44]
^L
RFC 5934                          TAMP                       August 2010


   The TAMP Error message content type has the following syntax:

    tamp-error CONTENT-TYPE  ::=
       { TAMPError IDENTIFIED BY id-ct-TAMP-error }

    id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 }

    TAMPError ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      msgType  OBJECT IDENTIFIER,
      status   StatusCode,
      msgRef   TAMPMsgRef OPTIONAL }

   The fields of TAMPError are used as follows:

   o  version identifies version of TAMP.  For this version of the
      specification, the default value, v2, MUST be used.

   o  msgType indicates the content type of the TAMP message that caused
      the error.

   o  status contains a status code that indicates the reason for the
      error.  Each of the status codes is discussed in Section 5.

   o  msgRef is OPTIONAL, but whenever possible it SHOULD be present.
      It identifies the TAMP message that caused the error.  It repeats
      the target and seqNum from the TAMP message that caused the error
      (see Sections 4.1, 4.3, 4.5, 4.7, and 4.9).

5.  Status Codes

   The Trust Anchor Update Confirm, the Apex Trust Anchor Update
   Confirm, the Community Update Confirm, the Sequence Number Adjust
   Confirm, and the TAMP Error messages include status codes.  The
   syntax for the status codes is:

     StatusCode ::= ENUMERATED {
       success                            (0),
       decodeFailure                      (1),
       badContentInfo                     (2),
       badSignedData                      (3),
       badEncapContent                    (4),
       badCertificate                     (5),
       badSignerInfo                      (6),
       badSignedAttrs                     (7),
       badUnsignedAttrs                   (8),
       missingContent                     (9),
       noTrustAnchor                     (10),



Housley, et al.              Standards Track                   [Page 45]
^L
RFC 5934                          TAMP                       August 2010


       notAuthorized                     (11),
       badDigestAlgorithm                (12),
       badSignatureAlgorithm             (13),
       unsupportedKeySize                (14),
       unsupportedParameters             (15),
       signatureFailure                  (16),
       insufficientMemory                (17),
       unsupportedTAMPMsgType            (18),
       apexTAMPAnchor                    (19),
       improperTAAddition                (20),
       seqNumFailure                     (21),
       contingencyPublicKeyDecrypt       (22),
       incorrectTarget                   (23),
       communityUpdateFailed             (24),
       trustAnchorNotFound               (25),
       unsupportedTAAlgorithm            (26),
       unsupportedTAKeySize              (27),
       unsupportedContinPubKeyDecryptAlg (28),
       missingSignature                  (29),
       resourcesBusy                     (30),
       versionNumberMismatch             (31),
       missingPolicySet                  (32),
       revokedCertificate                (33),
       unsupportedTrustAnchorFormat      (34),
       improperTAChange                  (35),
       malformed                         (36),
       cmsError                          (37),
       unsupportedTargetIdentifier       (38),
       other                            (127) }

   The various values of StatusCode are used as follows:

   o  success is used to indicate that an update, portion of an update,
      or adjust was processed successfully.

   o  decodeFailure is used to indicate that the trust anchor store was
      unable to successfully decode the provided message.  The specified
      content type and the provided content do not match.

   o  badContentInfo is used to indicate that the ContentInfo syntax is
      invalid or that the contentType carried within the ContentInfo is
      unknown or unsupported.

   o  badSignedData is used to indicate that the SignedData syntax is
      invalid, the version is unknown or unsupported, or more than one
      entry is present in digestAlgorithms.





Housley, et al.              Standards Track                   [Page 46]
^L
RFC 5934                          TAMP                       August 2010


   o  badEncapContent is used to indicate that the
      EncapsulatedContentInfo syntax is invalid.  This error can be
      generated due to problems located in SignedData.

   o  badCertificate is used to indicate that the syntax for one or more
      certificates in CertificateSet is invalid.

   o  badSignerInfo is used to indicate that the SignerInfo syntax is
      invalid, or the version is unknown or unsupported.

   o  badSignedAttrs is used to indicate that the signedAttrs syntax
      within SignerInfo is invalid.

   o  badUnsignedAttrs is used to indicate that the unsignedAttrs syntax
      within SignerInfo is invalid.

   o  missingContent is used to indicate that the OPTIONAL eContent is
      missing in EncapsulatedContentInfo, which is REQUIRED in this
      specification.  This error can be generated due to problems
      located in SignedData.

   o  noTrustAnchor is used to indicate one of two possible error
      situations.  In one case, the subjectKeyIdentifier does not
      identify the public key of a trust anchor or a certification path
      that terminates with an installed trust anchor.  In the other
      case, the issuerAndSerialNumber is used to identify the TAMP
      message signer, which is prohibited by this specification.

   o  notAuthorized is used to indicate one of two possible error
      situations.  In one case, the sid within SignerInfo leads to an
      installed trust anchor, but that trust anchor is not an authorized
      signer for the received TAMP message content type.  Identity trust
      anchors are not authorized signers for any of the TAMP message
      content types.  In the other case, the signer of a Trust Anchor
      Update message is not authorized to manage the to-be-updated trust
      anchor as determined by a failure of the subordination processing
      in Section 7.

   o  badDigestAlgorithm is used to indicate that the digestAlgorithm in
      either SignerInfo or SignedData is unknown or unsupported.

   o  badSignatureAlgorithm is used to indicate that the
      signatureAlgorithm in SignerInfo is unknown or unsupported.

   o  unsupportedKeySize is used to indicate that the signatureAlgorithm
      in SignerInfo is known and supported, but the TAMP message digital
      signature could not be validated because an unsupported key size
      was employed by the signer.



Housley, et al.              Standards Track                   [Page 47]
^L
RFC 5934                          TAMP                       August 2010


   o  unsupportedParameters is used to indicate that the
      signatureAlgorithm in SignerInfo is known, but the TAMP message
      digital signature could not be validated because unsupported
      parameters were employed by the signer.

   o  signatureFailure is used to indicate that the signatureAlgorithm
      in SignerInfo is known and supported, but the digital signature in
      the signature field within SignerInfo could not be validated.

   o  insufficientMemory indicates that the update could not be
      processed because the trust anchor store did not have sufficient
      memory to store the resulting trust anchor configuration or
      community identifier.

   o  unsupportedTAMPMsgType indicates that the TAMP message could not
      be processed because the trust anchor store does not support the
      provided TAMP message type.  This code will be used if the
      id-ct-TAMP-communityUpdate content type is provided and the trust
      anchor store does not support the Community Update message.  This
      status code will also be used if the contentType value within
      eContentType is not one that is defined in this specification.

   o  apexTAMPAnchor indicates that the update could not be processed
      because the Trust Anchor Update message tried to remove the apex
      trust anchor.

   o  improperTAAddition indicates that a trust anchor update is trying
      to add a new trust anchor that may already exist, but some
      attributes of the to-be-added trust anchor are being modified in
      an improper manner.  The desired trust anchor configuration may be
      attainable with a change operation instead of an add operation.

   o  seqNumFailure indicates that the TAMP message could not be
      processed because the processing of the sequence number, which is
      described in Section 6, resulted in an error.

   o  contingencyPublicKeyDecrypt indicates that the update could not be
      processed because an error occurred while decrypting the
      contingency public key.

   o  incorrectTarget indicates that the query, update, or adjust
      message could not be processed because the trust anchor store is
      not the intended recipient.

   o  communityUpdateFailed indicates that the community update
      requested the addition of a community identifier or the removal of
      a community identifier, but the request could not be honored.




Housley, et al.              Standards Track                   [Page 48]
^L
RFC 5934                          TAMP                       August 2010


   o  trustAnchorNotFound indicates that a change to a trust anchor was
      requested, but the referenced trust anchor is not represented in
      the trust anchor store.

   o  unsupportedTAAlgorithm indicates that an update message would
      result in the trust anchor with a public key associated with a
      digital signature validation algorithm that is not implemented.
      In addition, this status code is used if the algorithm is
      supported, but the parameters associated with the algorithm are
      not supported.

   o  unsupportedTAKeySize indicates that the trust anchor would include
      a public key of a size that is not supported.

   o  unsupportedContinPubKeyDecryptAlg indicates that the decryption
      algorithm for the apex trust anchor contingency public key is not
      supported.

   o  missingSignature indicates that an unsigned TAMP message was
      received, but the received TAMP message type MUST be signed.

   o  resourcesBusy indicates that the resources necessary to process
      the TAMP message are not available at the present time, but the
      resources might be available at some point in the future.

   o  versionNumberMismatch indicates that the version number in a
      received TAMP message is not acceptable.

   o  missingPolicySet indicates that the policyFlags associated with a
      trust anchor are set in a fashion that requires the policySet to
      be present, but the policySet is missing.

   o  revokedCertificate indicates that one or more of the certificates
      needed to properly process the TAMP message have been revoked.

   o  unsupportedTrustAnchorFormat indicates that an unsupported trust
      anchor format was presented or the version is unknown or
      unsupported.

   o  improperTAChange indicates that a trust anchor update is trying to
      change a new trust anchor using a format different than the format
      of the existing trust anchor.

   o  malformed indicates an error in the composition of the CMS
      structure encapsulating a TAMP message.






Housley, et al.              Standards Track                   [Page 49]
^L
RFC 5934                          TAMP                       August 2010


   o  cmsError indicates an error processing a CMS structure that
      encapsulated a TAMP message, such as an error processing
      ContentType or MessageDigest attributes.

   o  unsupportedTargetIdentifier indicates that a msgRef with an
      unsupported TargetIdentifier option was encountered.

   o  other indicates that the update could not be processed, but the
      reason is not covered by any of the assigned status codes.  Use of
      this status code SHOULD be avoided.

6.  Sequence Number Processing

   The sequence number processing facilities in TAMP represent a balance
   between replay protection, operational considerations, and trust
   anchor store memory management.  The goal is to provide replay
   protection without making TAMP difficult to use, creating an
   environment where surprising error conditions occur on a regular
   basis, or imposing onerous memory management requirements on
   implementations.  This balance is achieved by performing sequence
   number checking on TAMP messages that are validated directly using a
   trust anchor, and allowing these checks to be skipped whenever the
   TAMP message originator is not represented by a trust anchor.
   Implementations MUST perform sequence number checking on TAMP
   messages that are validated directly using a trust anchor and MAY
   perform sequence number checking for TAMP messages validated using a
   certification path.

   The TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update,
   Community Update, and Sequence Number Adjust messages include a
   sequence number.  This single-use identifier is used to match a TAMP
   message with the response to that TAMP message.  When the TAMP
   message is validated directly using a trust anchor, the sequence
   number is also used to detect TAMP message replay.

   To provide replay protection, each TAMP message originator MUST treat
   the sequence number as a monotonically increasing non-negative
   integer.  The sequence number counter is associated with the signing
   operation performed by the private key.  The trust anchor store MUST
   ensure that a newly received TAMP message that is validated directly
   by a trust anchor public key contains a sequence number that is
   greater than the most recent successfully processed TAMP message from
   that originator.  Note that the Sequence Number Adjust message is
   considered valid if the sequence number is greater than or equal to
   the most recent successfully processed TAMP message from that






Housley, et al.              Standards Track                   [Page 50]
^L
RFC 5934                          TAMP                       August 2010


   originator.  If the sequence number in a received TAMP message does
   not meet these conditions, then the trust anchor store MUST reject
   the TAMP message, returning a sequence number failure (seqNumFailure)
   error.

   Whenever a trust anchor is authorized for TAMP messages, either as a
   newly installed trust anchor or as a modification to an existing
   trust anchor, if a sequence number value is not provided in the Trust
   Anchor Update message, memory MUST be allocated for the sequence
   number and set to zero.  The first TAMP message received that is
   validated using that trust anchor is not rejected based on sequence
   number checks, and the sequence number from that first TAMP message
   is stored.  The TAMP message recipient MUST maintain a database of
   the most recent sequence number from a successfully processed TAMP
   message from a trust anchor.  The index for this database is the
   trust anchor public key.  This could be the apex trust anchor
   operational public key or a management trust anchor public key.  In
   the first case, the apex trust anchor operational public key is used
   directly to validate the TAMP message digital signature.  In the
   second case, a management trust anchor public key is used directly to
   validate the TAMP message digital signature.

   Sequence number values MUST be 64-bit non-negative integers.  Since
   ASN.1 encoding of an INTEGER always includes a sign bit, a TAMP
   message signer can generate 9,223,372,036,854,775,807 TAMP messages
   before exhausting the 64-bit sequence number space, before which the
   TAMP message signer MUST transition to a different public/private key
   pair.  The ability to reset a sequence number provided by the Trust
   Anchor Update and Sequence Number Adjust messages is not intended to
   avoid the transition to a different key pair; rather, it is intended
   to aid recovery from operational errors.  A relatively small non-
   volatile storage requirement is imposed on the trust anchor store for
   the apex trust anchor and each management trust anchor authorized for
   TAMP messages.

   When the apex trust anchor or a management trust anchor is replaced
   or removed from the trust anchor store, the associated sequence
   number storage SHOULD be reclaimed.

7.  Subordination Processing

   When a TAMP update message is processed, several checks are
   performed:

   o  TAMP message authentication is checked including, if necessary,
      building and validating a certification path to the signer.





Housley, et al.              Standards Track                   [Page 51]
^L
RFC 5934                          TAMP                       August 2010


   o  The signer's authorization is checked, including authorization to
      manage trust anchors included in the update message.

   o  Calculation of the trust anchor information to be stored.

   This section describes how to perform the second and third steps.
   Section 1.2 discusses authentication of TAMP messages.  Where a trust
   anchor is represented as a certificate and the calculation of the
   trust anchor information to be stored is different than the
   information in the certificate, the TAMP update fails.  The TAMP
   message signer may then wrap the certificate inside a TrustAnchorInfo
   structure to assert the intended information.

   The apex trust anchor is unconstrained, which means that
   subordination checking need not be performed on Trust Anchor Update
   messages signed with the apex trust anchor operational public key and
   that trust anchor information can be stored as it appears in the
   update message.  Subordination checking is performed as part of the
   validation process of all other Trust Anchor Update messages.

   For a Trust Anchor Update message that is not signed with the apex
   trust anchor operational public key to be valid, the digital
   signature MUST be validated using an authorized trust anchor, either
   directly or via an X.509 certification path originating with the apex
   trust anchor operational public key or an authorized management trust
   anchor.  The following subordination checks MUST also be performed as
   part of validation of the update message.

   Each Trust Anchor Update message contains one or more individual
   updates, each of which is used to add, modify, or remove a trust
   anchor.  For each individual update, the constraints of the TAMP
   message signer MUST be greater than or equal to the constraints of
   the trust anchor in the update.  Specifically, constraints included
   in the CertPathControls field of a TrustAnchorInfo object (or
   equivalent extensions in Certificate or TBSCertificate objects) must
   be checked as described below.  [RFC5280] describes how the
   intersection and union operations referenced below are performed.

   o  The values of the policy flags stored with a trust anchor as the
      result of a TAMPUpdate are either true or equal to the value of
      the policy flags associated with the TAMP message signer, i.e., an
      update may set a flag to false only if the value associated with
      the TAMP message signer is false.  The policy flags associated
      with the TAMP message signer are read from the policyFlags field
      or policyConstraints and inhibitAnyPolicy extensions if the signer






Housley, et al.              Standards Track                   [Page 52]
^L
RFC 5934                          TAMP                       August 2010


      is represented as a trust anchor or from the explicit_policy,
      policy_mapping, and inhibit_anyPolicy state variables following
      path validation if the signer is not represented as a trust
      anchor.

   o  The certificate policies stored with a trust anchor as the result
      of a TAMPUpdate are equal to the intersection of the value of the
      certificate policies associated with the TAMP message signer and
      the value of the policySet field or certificatePolicies extension
      from the update.  The certificate policies associated with the
      TAMP message signer are read from the policySet field in a
      TrustAnchorInfo or certificatePolicies extension in a Certificate
      or TBSCertificate if the signer is represented as a trust anchor
      or from the valid_policy_tree returned following path validation
      if the signer is not represented by a trust anchor.  Where the
      TAMP message signer is represented as a trust anchor, no policy
      mapping is performed.  If the intersection is NULL and the
      to-be-stored requireExplicitPolicy value is true, the TAMP update
      fails.

   o  The excluded names stored with a trust anchor as the result of a
      TAMPUpdate are equal to the union of the excluded names associated
      with the TAMP message signer and the value from the nameConstr
      field or nameConstraints extension from the update.  The name
      constraints associated with the TAMP message signer are read from
      the nameConstr field in a TrustAnchorInfo or nameConstraints
      extension in a Certificate or TBSCertificate if the signer is a
      trust anchor or from the excludedSubtrees state variable following
      path validation if the signer is not a trust anchor.  The name of
      the trust anchor included in the update MUST NOT fall within the
      excluded name space of the TAMP signer.  If the name of the trust
      anchor falls within the excluded name space of the TAMP signer,
      the TAMP update fails.

   o  The permitted names stored with a trust anchor as the result of a
      TAMPUpdate are equal to the intersection of the permitted names
      associated with the TAMP message signer and the value from the
      nameConstr field or nameConstraints extension from the update.
      The name constraints associated with the TAMP message signer are
      read from the nameConstr field in a TrustAnchorInfo or
      nameConstraints extension in a Certificate or TBSCertificate if
      the signer is a trust anchor or from the permittedSubtrees state
      variable following path validation if the signer is not a trust
      anchor.  The name of the trust anchor included in the update MUST
      fall within the permitted name space of the TAMP signer.  If the
      name of the trust anchor does not fall within the permitted name
      space of the TAMP signer, the TAMP update fails.  If the
      intersection is NULL for all name forms, the TAMP update fails.



Housley, et al.              Standards Track                   [Page 53]
^L
RFC 5934                          TAMP                       August 2010


   No other extensions defined in [RFC5280] must be processed as part of
   subordination processing.  Other extensions may define subordination
   rules.

8.  Implementation Considerations

   A public key identifier is used to identify a TAMP message signer.
   Since there is no guarantee that the same public key identifier is
   not associated with more than one public key, implementations MUST be
   prepared for one or more trust anchors to have the same public key
   identifier.  In practical terms, this means that when a digital
   signature validation fails, the implementation MUST see if there is
   another trust anchor with the same public key identifier that can be
   used to validate the digital signature.  While duplicate public key
   identifiers are expected to be rare, implementations MUST NOT fail to
   find the correct trust anchor when they do occur.

   An X.500 distinguished name is used to identify certificate issuers
   and certificate subjects.  The same X.500 distinguished name can be
   associated with more than one trust anchor.  However, the trust
   anchor public key will be different.  The probability that two trust
   anchors will have the same X.500 distinguished name and the same
   public key identifier but a different public key is diminishingly
   small.  Therefore, the authority key identifier certificate extension
   can be used to resolve X.500 distinguished name collisions.

   TAMP assumes a reliable underlying transport protocol.

9.  Wrapped Apex Contingency Key Certificate Extension

   An apex trust anchor MAY contain contingency key information using
   the WrappedApexContingencyKey extension.  The extension uses the
   ApexContingencyKey structure as defined below.

    ApexContingencyKey ::= SEQUENCE {
      wrapAlgorithm        AlgorithmIdentifier OPTIONAL,
      wrappedContinPubKey  OCTET STRING  OPTIONAL }

   The fields of ApexContingencyKey are used as described below.  When
   one field is present, both MUST be present.  When one field is
   absent, both MUST be absent.  The fields are allowed to be absent to
   enable usage of this extension as a means of indicating that the
   corresponding public key is recognized as an apex trust anchor by
   some relying parties.

   o  wrapAlgorithm identifies the symmetric algorithm used to encrypt
      the apex trust anchor contingency public key.  If this public key
      is ever needed, the symmetric key needed to decrypt it will be



Housley, et al.              Standards Track                   [Page 54]
^L
RFC 5934                          TAMP                       August 2010


      provided in the message that is to be validated using it.  The
      algorithm identifier is an AlgorithmIdentifier, which contains an
      object identifier and OPTIONAL parameters.  The object identifier
      indicates the syntax of the parameters, if present.

   o  wrappedContinPubKey is the encrypted apex trust anchor contingency
      public key.  Once decrypted, it yields the PublicKeyInfo
      structure, which consists of the algorithm identifier followed by
      the public key itself.  The algorithm identifier is an
      AlgorithmIdentifier that contains an object identifier and
      OPTIONAL parameters.  The object identifier indicates the format
      of the public key and the syntax of the parameters, if present.
      The public key is encoded as a BIT STRING.

   The WrappedApexContingencyKey certificate extension MAY be critical,
   and it MUST appear at most one time in a set of extensions. The apex
   trust anchor info extension is identified by the
   id-pe-wrappedApexContinKey object identifier:

         id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::=
             { iso(1) identified-organization(3) dod(6) internet(1)
               security(5) mechanisms(5) pkix(7) pe(1) 20 }

10.  Security Considerations

   The majority of this specification is devoted to the syntax and
   semantics of TAMP messages.  It relies on other specifications,
   especially [RFC5914], [RFC3852], and [RFC5280], for the syntax and
   semantics of trust anchors, intermediate CMS content types, and X.509
   certificates, respectively.  Since TAMP messages that change the
   trust anchor state of a trust anchor store are always signed by a
   Trust Anchor Manager, no further data integrity or data origin
   authentication mechanisms are needed; however, no confidentiality for
   these messages is provided.  Similarly, certificates are digitally
   signed, and no additional data integrity or data origin
   authentication mechanisms are needed.  Trust anchor configurations,
   Trust Anchor Manager certificates, and trust anchor store
   certificates are not intended to be sensitive.  As a result, this
   specification does not provide for confidentiality of TAMP messages.

   Security factors outside the scope of this specification greatly
   affect the assurance provided.  The procedures used by certification
   authorities (CAs) to validate the binding of the subject identity to
   their public key greatly affect the assurance associated with the
   resulting certificate.  This is particularly important when issuing
   certificates to other CAs.  In the context of TAMP, the issuance of
   an end entity certificate under a management trust anchor is an act
   of delegation.  However, such end entities cannot further delegate.



Housley, et al.              Standards Track                   [Page 55]
^L
RFC 5934                          TAMP                       August 2010


   On the other hand, issuance of a CA certificate under a management
   trust anchor is an act of delegation where the CA can perform further
   delegation.  The scope of the delegation can be constrained by
   including appropriate certificate extensions in a CA certificate.

   X.509 certification path construction involves comparison of X.500
   distinguished names.  Inconsistent application of name comparison
   rules can result in acceptance of invalid X.509 certification paths
   or rejection of valid ones.  Name comparison can be extremely
   complex.  To avoid imposing this complexity on trust anchor stores,
   any certificate profile used with TAMP SHOULD employ simple name
   structures and impose rigorous restrictions on acceptable
   distinguished names, including the way that they are encoded.  The
   goal of that certificate profile should be to enable simple binary
   comparison.  That is, case conversion, character set conversion,
   white space compression, and leading and trailing white space
   trimming SHOULD be avoided.

   Some digital signature algorithms (DSAs) require the generation of
   random one-time values.  For example, when generating a DSA digital
   signature, the signer MUST generate a random k value [DSS].  Also,
   the generation of public/private key pairs relies on random numbers.

   The use of an inadequate random number generator (RNG) or an
   inadequate pseudo-random number generator (PRNG) to generate such
   cryptographic values can result in little or no security.  An
   attacker may find it much easier to reproduce the random number
   generation environment, searching the resulting small set of
   possibilities, rather than brute-force searching the whole space.

   Compromise of an identity trust anchor private key permits
   unauthorized parties to issue certificates that will be acceptable to
   all trust anchor stores configured with the corresponding identity
   trust anchor.  The unauthorized private key holder will be limited by
   the certification path controls associated with the identity trust
   anchor.  For example, clearance constraints in the identity trust
   anchor will determine the clearances that will be accepted in
   certificates that are issued by the unauthorized private key holder.

   Compromise of a management trust anchor private key permits
   unauthorized parties to generate signed messages that will be
   acceptable to all trust anchor stores configured with the
   corresponding management trust anchor.  All devices that include the
   compromised management trust anchor can be configured as desired by
   the unauthorized private key holder within the limits of the
   subordination checks described in Section 7.  If the management trust
   anchor is associated with content types other than TAMP, then the
   unauthorized private key holder can generate signed messages of that



Housley, et al.              Standards Track                   [Page 56]
^L
RFC 5934                          TAMP                       August 2010


   type.  For example, if the management trust anchor is associated with
   firmware packages, then the unauthorized private key holder can
   install different firmware.

   Compromise of the apex trust anchor operational private key permits
   unauthorized parties to generate signed messages that will be
   acceptable to all trust anchor stores configured with the
   corresponding apex trust anchor.  All devices that include that apex
   trust anchor can be configured as desired by the unauthorized private
   key holder, and the unauthorized private key holder can generate
   signed messages of any content type.  The optional contingency
   private key offers a potential way to recover from such a compromise.

   The compromise of a CA's private key leads to the same type of
   problems as the compromise of an identity or a management trust
   anchor private key.  The unauthorized private key holder will be
   limited by the certification path controls and extensions associated
   with the trust anchor.

   The compromise of an end entity private key leads to the same type of
   problems as the compromise of an identity or a management trust
   anchor private key, except that the end entity is unable to issue any
   certificates.  The unauthorized private key holder will be limited by
   the certification path controls and extensions associated with the
   trust anchor.

   Compromise of a trust anchor store's digital signature private key
   permits unauthorized parties to generate signed TAMP response
   messages, masquerading as the trust anchor store.

   Premature disclosure of the key-encryption key used to encrypt the
   apex trust anchor contingency public key may result in early exposure
   of the apex trust anchor contingency public key.

   TAMP implementations need to be able to parse messages and
   certificates.  Care must be taken to ensure that there are no
   implementation defects in the TAMP message parser or the processing
   that acts on the message content.  A validation suite is one way to
   increase confidence in the parsing of TAMP messages, CMS content
   types, attributes, certificates, and extensions.

   TrustAnchorList messages do not provide a replay detection mechanism.
   Where TrustAnchorList messages are accepted as an alternative means
   of adding trust anchors to a trust anchor store, applications may
   require additional mechanisms to address the risks associated with
   replay of old TrustAnchorList messages.





Housley, et al.              Standards Track                   [Page 57]
^L
RFC 5934                          TAMP                       August 2010


   As sequence number values are used to detect replay attempts, trust
   anchor store managers must take care to maintain their own sequence
   number state, i.e., knowledge of which sequence number to include in
   the next TAMP message generated by the trust anchor store manager.
   Loss of sequence number state can result in generation of TAMP
   messages that cannot be processed due to seqNumFailure.  In the event
   of loss, sequence number state can be restored by inspecting the most
   recently generated TAMP message, provided the messages are logged, or
   in collaboration with a trust anchor store manager who can
   successfully issue a TAMPStatusQuery message.

11.  IANA Considerations

   The details of TAMP requests and responses are communicated using
   object identifiers (OIDs).  The objects are defined in an arc
   delegated by IANA to the PKIX working group.  This document also
   includes eleven media type registrations in Appendix B.  No further
   action by IANA is necessary for this document or any anticipated
   updates.

12.  References

12.1.  Normative References

   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]       Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                   Masinter, L., Leach, P., and T. Berners-Lee,
                   "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
                   June 1999.

   [RFC3986]       Berners-Lee, T., Fielding, R., and L. Masinter,
                   "Uniform Resource Identifier (URI): Generic Syntax",
                   STD 66, RFC 3986, January 2005.

   [RFC5280]       Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                   Housley, R., and W. Polk, "Internet X.509 Public Key
                   Infrastructure Certificate and Certificate Revocation
                   List (CRL) Profile", RFC 5280, May 2008.

   [RFC5652]       Housley, R., "Cryptographic Message Syntax (CMS)",
                   RFC 5652, September 2009.

   [RFC5912]       Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
                   Public Key Infrastructure Using X.509 (PKIX)", RFC
                   5912, June 2010.




Housley, et al.              Standards Track                   [Page 58]
^L
RFC 5934                          TAMP                       August 2010


   [RFC5914]       Housley, R., Ashmore, S., and C. Wallace, "Trust
                   Anchor Format", RFC 5914, June 2010.


   [X.680]         "ITU-T Recommendation X.680 - Information Technology
                   - Abstract Syntax Notation One", 1997.

   [X.690]         "ITU-T Recommendation X.690 - Information Technology
                   - ASN.1 encoding rules: Specification of Basic
                   Encoding Rules (BER), Canonical Encoding Rules (CER)
                   and Distinguished Encoding Rules (DER)", 1997.

12.2.  Informative References

   [DSS]           "FIPS Pub 186: Digital Signature Standard", May 1994.

   [PKCS#6]        "PKCS #6: Extended-Certificate Syntax Standard,
                   Version 1.5", November 1993.

   [RFC3279]       Bassham, L., Polk, W., and R. Housley, "Algorithms
                   and Identifiers for the Internet X.509 Public Key
                   Infrastructure Certificate and Certificate Revocation
                   List (CRL) Profile", RFC 3279, April 2002.

   [RFC3370]       Housley, R., "Cryptographic Message Syntax (CMS)
                   Algorithms", RFC 3370, August 2002.

   [RFC4049]       Housley, R., "BinaryTime: An Alternate Format for
                   Representing Date and Time in ASN.1", RFC 4049, April
                   2005.

   [RFC4108]       Housley, R., "Using Cryptographic Message Syntax
                   (CMS) to Protect Firmware Packages", RFC 4108, August
                   2005.

   [RFC5753]       Turner, S. and D. Brown, "Use of Elliptic Curve
                   Cryptography (ECC) Algorithms in Cryptographic
                   Message Syntax (CMS)", RFC 5753, January 2010.

   [RFC5754]       Turner, S., "Using SHA2 Algorithms with Cryptographic
                   Message Syntax", RFC 5754, January 2010.

   [RFC5755]       Farrell, S., Housley, R., and S. Turner, "An Internet
                   Attribute Certificate Profile for Authorization", RFC
                   5755, January 2010.

   [TA-MGMT-REQS]  Reddy, R. and C. Wallace, "Trust Anchor Management
                   Requirements", Work in Progress, March 2010.



Housley, et al.              Standards Track                   [Page 59]
^L
RFC 5934                          TAMP                       August 2010


   [X.208]         "ITU-T Recommendation X.208 - Specification of
                   Abstract Syntax Notation One (ASN.1)", 1988.

   [X.509]         "ITU-T Recommendation X.509 - The Directory -
                   Authentication Framework", 2000.














































Housley, et al.              Standards Track                   [Page 60]
^L
RFC 5934                          TAMP                       August 2010


Appendix A.  ASN.1 Modules

   Appendix A.1 provides the normative ASN.1 definitions for the
   structures described in this specification using ASN.1 as defined in
   [X.680].  Appendix A.2 provides a module using ASN.1 as defined in
   [X.208].  The module in Appendix A.2 removes usage of newer ASN.1
   features that provide support for limiting the types of elements that
   may appear in certain SEQUENCE and SET constructions.  Otherwise, the
   modules are compatible in terms of encoded representation, i.e., the
   modules are bits-on-the-wire compatible aside from the limitations on
   SEQUENCE and SET constituents.  Extension markers are not used due to
   lack of support in [X.208].  Appendix A.2 is included as a courtesy
   to developers using ASN.1 compilers that do not support current
   ASN.1.  Appendix A.1 includes definitions imported from [RFC5280],
   [RFC5912], and [RFC5914].

A.1.  ASN.1 Module Using 1993 Syntax

   TAMP-Protocol-v2
   { joint-iso-ccitt(2) country(16) us(840) organization(1)
     gov(101) dod(2) infosec(1) modules(0) 30 }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   IMPORTS
   TrustAnchorChoice, TrustAnchorTitle, CertPathControls
   FROM TrustAnchorInfoModule
      { joint-iso-ccitt(2) country(16) us(840)
      organization(1) gov(101) dod(2) infosec(1)
      modules(0) 33 }
   AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, KEY-WRAP
   FROM AlgorithmInformation-2009
      {iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-algorithmInformation-02(58)}
   Certificate, Name, TBSCertificate,
   CertificateSerialNumber, Validity, SubjectPublicKeyInfo
   FROM PKIX1Explicit-2009 -- from [RFC5912]
      {iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkix1-explicit-02(51)}
   KeyIdentifier, OTHER-NAME
   FROM PKIX1Implicit-2009 -- from [RFC5912]
      {iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkix1-implicit-02(59)}
   EXTENSION, Extensions {}, ATTRIBUTE, SingleAttribute{}



Housley, et al.              Standards Track                   [Page 61]
^L
RFC 5934                          TAMP                       August 2010


   FROM PKIX-CommonTypes-2009 -- from [RFC5912]
      { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkixCommon-02(57) }         ;

   -- Object Identifier Arc for TAMP Message Content Types

   id-tamp OBJECT IDENTIFIER ::= {
   joint-iso-ccitt(2) country(16) us(840) organization(1)
   gov(101) dod(2) infosec(1) formats(2) 77 }

   SupportedSigAlgorithms SIGNATURE-ALGORITHM ::= {
      -- add any locally defined algorithms here
      ...
   }

   SupportedWrapAlgorithms KEY-WRAP ::= {
      -- add any locally defined algorithms here
      ...
   }

   -- CMS Content Types

   CONTENT-TYPE  ::= TYPE-IDENTIFIER

   TAMPContentTypes CONTENT-TYPE  ::= {
     tamp-status-query |
     tamp-status-response |
     tamp-update |
     tamp-update-confirm |
     tamp-apex-update |
     tamp-apex-update-confirm |
     tamp-community-update |
     tamp-community-update-confirm |
     tamp-sequence-number-adjust |
     tamp-sequence-number-adjust-confirm |
     tamp-error,
     ... -- Expect additional content types --
     }

   -- TAMP Status Query Message
   tamp-status-query CONTENT-TYPE  ::=
     { TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery }

   id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 }






Housley, et al.              Standards Track                   [Page 62]
^L
RFC 5934                          TAMP                       August 2010


   TAMPStatusQuery ::= SEQUENCE {
     version         [0] TAMPVersion DEFAULT v2,
     terse           [1] TerseOrVerbose DEFAULT verbose,
     query           TAMPMsgRef }

   TAMPVersion ::= INTEGER { v1(1), v2(2) }

   TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) }

   SeqNumber ::= INTEGER (0..9223372036854775807)

   TAMPMsgRef ::= SEQUENCE {
     target          TargetIdentifier,
     seqNum          SeqNumber }

   TargetIdentifier ::= CHOICE {
     hwModules    [1] HardwareModuleIdentifierList,
     communities  [2] CommunityIdentifierList,
     allModules   [3] NULL,
     uri          [4] IA5String,
     otherName    [5] INSTANCE OF OTHER-NAME }

   HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF
                                     HardwareModules

   HardwareModules ::= SEQUENCE {
     hwType          OBJECT IDENTIFIER,
     hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry }

   HardwareSerialEntry ::= CHOICE {
     all             NULL,
     single          OCTET STRING,
     block           SEQUENCE {
       low             OCTET STRING,
       high            OCTET STRING } }

   CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community

   Community ::= OBJECT IDENTIFIER

   -- TAMP Status Response Message

   tamp-status-response CONTENT-TYPE  ::=
     { TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse }

   id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 }





Housley, et al.              Standards Track                   [Page 63]
^L
RFC 5934                          TAMP                       August 2010


   TAMPStatusResponse ::= SEQUENCE {
     version   [0] TAMPVersion DEFAULT v2,
     query     TAMPMsgRef,
     response  StatusResponse,
     usesApex  BOOLEAN DEFAULT TRUE }

   StatusResponse ::= CHOICE {
     terseResponse         [0] TerseStatusResponse,
     verboseResponse       [1] VerboseStatusResponse }

   TerseStatusResponse ::= SEQUENCE {
     taKeyIds              KeyIdentifiers,
     communities           CommunityIdentifierList OPTIONAL }

   KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier

   VerboseStatusResponse ::= SEQUENCE {
     taInfo                 TrustAnchorChoiceList,
     continPubKeyDecryptAlg [0] AlgorithmIdentifier
                   {KEY-WRAP, {SupportedWrapAlgorithms}} OPTIONAL,
     communities            [1] CommunityIdentifierList OPTIONAL,
     tampSeqNumbers         [2] TAMPSequenceNumbers OPTIONAL }

   TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF
        TrustAnchorChoice

   TAMPSequenceNumber ::= SEQUENCE {
     keyId       KeyIdentifier,
     seqNumber   SeqNumber }

   TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF TAMPSequenceNumber

   -- Trust Anchor Update Message

   tamp-update CONTENT-TYPE  ::=
     { TAMPUpdate IDENTIFIED BY id-ct-TAMP-update }

   id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 }

   TAMPUpdate ::= SEQUENCE {
     version  [0] TAMPVersion DEFAULT v2,
     terse    [1] TerseOrVerbose DEFAULT verbose,
     msgRef   TAMPMsgRef,
     updates  SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate,
     tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL }






Housley, et al.              Standards Track                   [Page 64]
^L
RFC 5934                          TAMP                       August 2010


   TrustAnchorUpdate ::= CHOICE {
     add             [1] TrustAnchorChoice,
     remove          [2] SubjectPublicKeyInfo,
     change          [3] EXPLICIT TrustAnchorChangeInfoChoice }

   TrustAnchorChangeInfoChoice ::= CHOICE {
     tbsCertChange  [0] TBSCertificateChangeInfo,
     taChange       [1] TrustAnchorChangeInfo }

   TBSCertificateChangeInfo  ::=  SEQUENCE  {
     serialNumber         CertificateSerialNumber OPTIONAL,
     signature            [0] AlgorithmIdentifier
             {SIGNATURE-ALGORITHM, {SupportedSigAlgorithms}} OPTIONAL,
     issuer               [1] Name OPTIONAL,
     validity             [2] Validity OPTIONAL,
     subject              [3] Name OPTIONAL,
     subjectPublicKeyInfo [4] SubjectPublicKeyInfo,
     exts                 [5] EXPLICIT Extensions{{...}} OPTIONAL }

   TrustAnchorChangeInfo ::= SEQUENCE {
     pubKey          SubjectPublicKeyInfo,
     keyId           KeyIdentifier OPTIONAL,
     taTitle         TrustAnchorTitle OPTIONAL,
     certPath        CertPathControls OPTIONAL,
     exts            [1] Extensions{{...}} OPTIONAL }

   -- Trust Anchor Update Confirm Message

   tamp-update-confirm CONTENT-TYPE  ::=
     { TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm }

   id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 }

   TAMPUpdateConfirm ::= SEQUENCE {
     version               [0] TAMPVersion DEFAULT v2,
     update                TAMPMsgRef,
     confirm               UpdateConfirm }

   UpdateConfirm ::= CHOICE {
     terseConfirm          [0] TerseUpdateConfirm,
     verboseConfirm        [1] VerboseUpdateConfirm }

   TerseUpdateConfirm ::= StatusCodeList

   StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode






Housley, et al.              Standards Track                   [Page 65]
^L
RFC 5934                          TAMP                       August 2010


   VerboseUpdateConfirm ::= SEQUENCE {
     status          StatusCodeList,
     taInfo          TrustAnchorChoiceList,
     tampSeqNumbers  TAMPSequenceNumbers OPTIONAL,
     usesApex        BOOLEAN DEFAULT TRUE }

   -- Apex Trust Anchor Update Message

   tamp-apex-update CONTENT-TYPE  ::=
       { TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate }

   id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 }

   TAMPApexUpdate ::= SEQUENCE {
     version            [0] TAMPVersion DEFAULT v2,
     terse              [1] TerseOrVerbose DEFAULT verbose,
     msgRef             TAMPMsgRef,
     clearTrustAnchors  BOOLEAN,
     clearCommunities   BOOLEAN,
     seqNumber          SeqNumber OPTIONAL,
     apexTA             TrustAnchorChoice }

   -- Apex Trust Anchor Update Confirm Message

   tamp-apex-update-confirm CONTENT-TYPE  ::=
     { TAMPApexUpdateConfirm IDENTIFIED BY
         id-ct-TAMP-apexUpdateConfirm }

   id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 }

   TAMPApexUpdateConfirm ::= SEQUENCE {
     version               [0] TAMPVersion DEFAULT v2,
     apexReplace           TAMPMsgRef,
     apexConfirm           ApexUpdateConfirm }

   ApexUpdateConfirm ::= CHOICE {
     terseApexConfirm      [0] TerseApexUpdateConfirm,
     verboseApexConfirm    [1] VerboseApexUpdateConfirm }

   TerseApexUpdateConfirm ::= StatusCode

   VerboseApexUpdateConfirm ::= SEQUENCE {
     status                  StatusCode,
     taInfo                  TrustAnchorChoiceList,
     communities            [0] CommunityIdentifierList OPTIONAL,
     tampSeqNumbers         [1] TAMPSequenceNumbers OPTIONAL }





Housley, et al.              Standards Track                   [Page 66]
^L
RFC 5934                          TAMP                       August 2010


   -- Community Update Message

   tamp-community-update CONTENT-TYPE  ::=
     { TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate }

   id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 }

   TAMPCommunityUpdate ::= SEQUENCE {
     version         [0] TAMPVersion DEFAULT v2,
     terse           [1] TerseOrVerbose DEFAULT verbose,
     msgRef          TAMPMsgRef,
     updates         CommunityUpdates }

   CommunityUpdates ::= SEQUENCE {
     remove       [1] CommunityIdentifierList OPTIONAL,
     add          [2] CommunityIdentifierList OPTIONAL }
     -- At least one must be present

   -- Community Update Confirm Message

   tamp-community-update-confirm CONTENT-TYPE  ::=
     { TAMPCommunityUpdateConfirm IDENTIFIED BY
       id-ct-TAMP-communityUpdateConfirm }

   id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::=
     { id-tamp 8 }

   TAMPCommunityUpdateConfirm ::= SEQUENCE {
     version         [0] TAMPVersion DEFAULT v2,
     update          TAMPMsgRef,
     commConfirm     CommunityConfirm }

   CommunityConfirm ::= CHOICE {
     terseCommConfirm      [0] TerseCommunityConfirm,
     verboseCommConfirm    [1] VerboseCommunityConfirm }

   TerseCommunityConfirm ::= StatusCode

   VerboseCommunityConfirm ::= SEQUENCE {
     status          StatusCode,
     communities     CommunityIdentifierList OPTIONAL }

   -- Sequence Number Adjust Message

   tamp-sequence-number-adjust CONTENT-TYPE  ::=
     { SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust }

   id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 }



Housley, et al.              Standards Track                   [Page 67]
^L
RFC 5934                          TAMP                       August 2010


   SequenceNumberAdjust ::= SEQUENCE {
     version         [0] TAMPVersion DEFAULT v2,

     msgRef          TAMPMsgRef }

   -- Sequence Number Adjust Confirm Message

   tamp-sequence-number-adjust-confirm CONTENT-TYPE  ::=
     { SequenceNumberAdjustConfirm IDENTIFIED BY
       id-ct-TAMP-seqNumAdjustConfirm }

   id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= { id-tamp 11 }

   SequenceNumberAdjustConfirm ::= SEQUENCE {
     version         [0] TAMPVersion DEFAULT v2,
     adjust          TAMPMsgRef,
     status          StatusCode }

   -- TAMP Error Message

   tamp-error CONTENT-TYPE  ::=
     { TAMPError IDENTIFIED BY id-ct-TAMP-error }

   id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 }

   TAMPError ::= SEQUENCE {
     version         [0] TAMPVersion DEFAULT v2,
     msgType         OBJECT IDENTIFIER,
     status          StatusCode,
     msgRef          TAMPMsgRef OPTIONAL }

   -- Status Codes

   StatusCode ::= ENUMERATED {
     success                            (0),
     decodeFailure                      (1),
     badContentInfo                     (2),
     badSignedData                      (3),
     badEncapContent                    (4),
     badCertificate                     (5),
     badSignerInfo                      (6),
     badSignedAttrs                     (7),
     badUnsignedAttrs                   (8),
     missingContent                     (9),
     noTrustAnchor                     (10),
     notAuthorized                     (11),
     badDigestAlgorithm                (12),
     badSignatureAlgorithm             (13),



Housley, et al.              Standards Track                   [Page 68]
^L
RFC 5934                          TAMP                       August 2010


     unsupportedKeySize                (14),
     unsupportedParameters             (15),
     signatureFailure                  (16),
     insufficientMemory                (17),
     unsupportedTAMPMsgType            (18),
     apexTAMPAnchor                    (19),
     improperTAAddition                (20),
     seqNumFailure                     (21),
     contingencyPublicKeyDecrypt       (22),
     incorrectTarget                   (23),
     communityUpdateFailed             (24),
     trustAnchorNotFound               (25),
     unsupportedTAAlgorithm            (26),
     unsupportedTAKeySize              (27),
     unsupportedContinPubKeyDecryptAlg (28),
     missingSignature                  (29),
     resourcesBusy                     (30),
     versionNumberMismatch             (31),
     missingPolicySet                  (32),
     revokedCertificate                (33),
     unsupportedTrustAnchorFormat      (34),
     improperTAChange                  (35),
     malformed                         (36),
     cmsError                          (37),
     unsupportedTargetIdentifier       (38),
     other                            (127) }

   -- Object Identifier Arc for Attributes

   id-attributes OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16)
     us(840) organization(1) gov(101) dod(2) infosec(1) 5 }

   -- TAMP Unsigned Attributes
   -- These attributes are unsigned attributes and go into the
   --    UnsignedAttributes set in [RFC5652]

   TAMPUnsignedAttributes ATTRIBUTE ::= {
     contingency-public-key-decrypt-key,
     ... -- Expect additional attributes --
     }

   -- contingency-public-key-decrypt-key unsigned attribute

   contingency-public-key-decrypt-key ATTRIBUTE ::= {
     TYPE PlaintextSymmetricKey IDENTIFIED BY
     id-aa-TAMP-contingencyPublicKeyDecryptKey }





Housley, et al.              Standards Track                   [Page 69]
^L
RFC 5934                          TAMP                       August 2010


   id-aa-TAMP-contingencyPublicKeyDecryptKey OBJECT IDENTIFIER ::= {
     id-attributes 63 }

   PlaintextSymmetricKey ::= OCTET STRING

   -- id-pe-wrappedApexContinKey extension

   wrappedApexContinKey EXTENSION ::= {
        SYNTAX         ApexContingencyKey
        IDENTIFIED BY  id-pe-wrappedApexContinKey }

   id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::=
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) pe(1) 20 }

   ApexContingencyKey ::= SEQUENCE {
     wrapAlgorithm
         AlgorithmIdentifier{KEY-WRAP, {SupportedWrapAlgorithms}},
     wrappedContinPubKey  OCTET STRING }

   END

A.2.  ASN.1 Module Using 1988 Syntax

   TAMP-Protocol-v2-88
      { joint-iso-ccitt(2) country(16) us(840) organization(1)
        gov(101) dod(2) infosec(1) modules(0) 31 }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   IMPORTS
     TrustAnchorChoice, TrustAnchorTitle, CertPathControls
     FROM TrustAnchorInfoModule-88 -- from [RFC5914]
          { joint-iso-ccitt(2) country(16) us(840) organization(1)
            gov(101) dod(2) infosec(1) modules(0) 37 }
     AlgorithmIdentifier, Certificate, Name, Attribute, TBSCertificate,
     SubjectPublicKeyInfo, CertificateSerialNumber, Validity, Extensions
       FROM PKIX1Explicit88 -- from [RFC5280]
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-pkix1-explicit(18) }
     KeyIdentifier, AnotherName
       FROM PKIX1Implicit88 -- from [RFC5280]
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-pkix1-implicit(19) } ;




Housley, et al.              Standards Track                   [Page 70]
^L
RFC 5934                          TAMP                       August 2010


   -- Object Identifier Arc for TAMP Message Content Types

   id-tamp OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16)
   us(840) organization(1) gov(101) dod(2) infosec(1) formats(2) 77 }

   -- CMS Content Types

   -- TAMP Status Query Message

   id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 }

   TAMPStatusQuery ::= SEQUENCE {
     version         [0] TAMPVersion DEFAULT v2,
     terse           [1] TerseOrVerbose DEFAULT verbose,
     query           TAMPMsgRef }

   TAMPVersion ::= INTEGER { v1(1), v2(2) }

   TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) }

   SeqNumber ::= INTEGER (0..9223372036854775807)

   TAMPMsgRef ::= SEQUENCE {
     target          TargetIdentifier,
     seqNum          SeqNumber }

   TargetIdentifier ::= CHOICE {
     hwModules    [1] HardwareModuleIdentifierList,
     communities  [2] CommunityIdentifierList,
     allModules   [3] NULL,
     uri          [4] IA5String,
     otherName    [5] AnotherName }

   HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF
                                     HardwareModules

   HardwareModules ::= SEQUENCE {
     hwType          OBJECT IDENTIFIER,
     hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry }

   HardwareSerialEntry ::= CHOICE {
     all             NULL,
     single          OCTET STRING,
     block           SEQUENCE {
       low             OCTET STRING,
       high            OCTET STRING } }





Housley, et al.              Standards Track                   [Page 71]
^L
RFC 5934                          TAMP                       August 2010


   CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community

   Community ::= OBJECT IDENTIFIER

   -- TAMP Status Response Message

   id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 }

   TAMPStatusResponse ::= SEQUENCE {
     version   [0] TAMPVersion DEFAULT v2,
     query     TAMPMsgRef,
     response  StatusResponse,
     usesApex  BOOLEAN DEFAULT TRUE }

   StatusResponse ::= CHOICE {
     terseResponse         [0] TerseStatusResponse,
     verboseResponse       [1] VerboseStatusResponse }

   TerseStatusResponse ::= SEQUENCE {
     taKeyIds              KeyIdentifiers,
     communities           CommunityIdentifierList OPTIONAL }

   KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier

   VerboseStatusResponse ::= SEQUENCE {
     taInfo                 TrustAnchorChoiceList,
     continPubKeyDecryptAlg [0] AlgorithmIdentifier OPTIONAL,
     communities            [1] CommunityIdentifierList OPTIONAL,
     tampSeqNumbers         [2] TAMPSequenceNumbers OPTIONAL }

   TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF
        TrustAnchorChoice

   TAMPSequenceNumber ::= SEQUENCE {
     keyId       KeyIdentifier,
     seqNumber   SeqNumber }

   TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF
        TAMPSequenceNumber

   -- Trust Anchor Update Message

   id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 }








Housley, et al.              Standards Track                   [Page 72]
^L
RFC 5934                          TAMP                       August 2010


   TAMPUpdate ::= SEQUENCE {
     version  [0] TAMPVersion DEFAULT v2,
     terse    [1] TerseOrVerbose DEFAULT verbose,
     msgRef   TAMPMsgRef,
     updates  SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate,
     tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL }

   TrustAnchorUpdate ::= CHOICE {
     add             [1] TrustAnchorChoice,
     remove          [2] SubjectPublicKeyInfo,
     change          [3] EXPLICIT TrustAnchorChangeInfoChoice }

   TrustAnchorChangeInfoChoice ::= CHOICE {
     tbsCertChange [0] TBSCertificateChangeInfo,
     taChange      [1] TrustAnchorChangeInfo }

   TBSCertificateChangeInfo  ::=  SEQUENCE  {
     serialNumber         CertificateSerialNumber OPTIONAL,
     signature            [0] AlgorithmIdentifier OPTIONAL,
     issuer               [1] Name OPTIONAL,
     validity             [2] Validity OPTIONAL,
     subject              [3] Name OPTIONAL,
     subjectPublicKeyInfo [4] SubjectPublicKeyInfo,
     exts                 [5] EXPLICIT Extensions OPTIONAL }

   TrustAnchorChangeInfo ::= SEQUENCE {
     pubKey          SubjectPublicKeyInfo,
     keyId           KeyIdentifier OPTIONAL,
     taTitle         TrustAnchorTitle OPTIONAL,
     certPath        CertPathControls OPTIONAL,
     exts            [1] Extensions OPTIONAL }

   -- Trust Anchor Update Confirm Message

   id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 }

   TAMPUpdateConfirm ::= SEQUENCE {
     version               [0] TAMPVersion DEFAULT v2,
     update                TAMPMsgRef,
     confirm               UpdateConfirm }

   UpdateConfirm ::= CHOICE {
     terseConfirm          [0] TerseUpdateConfirm,
     verboseConfirm        [1] VerboseUpdateConfirm }

   TerseUpdateConfirm ::= StatusCodeList

   StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode



Housley, et al.              Standards Track                   [Page 73]
^L
RFC 5934                          TAMP                       August 2010


   VerboseUpdateConfirm ::= SEQUENCE {
     status          StatusCodeList,
     taInfo          TrustAnchorChoiceList,
     tampSeqNumbers  TAMPSequenceNumbers OPTIONAL,
     usesApex        BOOLEAN DEFAULT TRUE }

   -- Apex Trust Anchor Update Message

   id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 }

   TAMPApexUpdate ::= SEQUENCE {
     version            [0] TAMPVersion DEFAULT v2,
     terse              [1] TerseOrVerbose DEFAULT verbose,
     msgRef             TAMPMsgRef,
     clearTrustAnchors  BOOLEAN,
     clearCommunities   BOOLEAN,
     seqNumber          SeqNumber OPTIONAL,
     apexTA             TrustAnchorChoice }

   -- Apex Trust Anchor Update Confirm Message

   id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 }

   TAMPApexUpdateConfirm ::= SEQUENCE {
     version               [0] TAMPVersion DEFAULT v2,
     apexReplace           TAMPMsgRef,
     apexConfirm           ApexUpdateConfirm }

   ApexUpdateConfirm ::= CHOICE {
     terseApexConfirm      [0] TerseApexUpdateConfirm,
     verboseApexConfirm    [1] VerboseApexUpdateConfirm }

   TerseApexUpdateConfirm ::= StatusCode

   VerboseApexUpdateConfirm ::= SEQUENCE {
     status                  StatusCode,
     taInfo                  TrustAnchorChoiceList,
     communities            [0] CommunityIdentifierList OPTIONAL,
     tampSeqNumbers         [1] TAMPSequenceNumbers OPTIONAL }

   -- Community Update Message

   id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 }








Housley, et al.              Standards Track                   [Page 74]
^L
RFC 5934                          TAMP                       August 2010


   TAMPCommunityUpdate ::= SEQUENCE {
     version         [0] TAMPVersion DEFAULT v2,
     terse           [1] TerseOrVerbose DEFAULT verbose,
     msgRef          TAMPMsgRef,
     updates         CommunityUpdates }

   CommunityUpdates ::= SEQUENCE {
     remove          [1] CommunityIdentifierList OPTIONAL,
     add             [2] CommunityIdentifierList OPTIONAL }
     -- At least one must be present

   -- Community Update Confirm Message

   id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 8 }

   TAMPCommunityUpdateConfirm ::= SEQUENCE {
     version         [0] TAMPVersion DEFAULT v2,
     update          TAMPMsgRef,
     commConfirm     CommunityConfirm }

   CommunityConfirm ::= CHOICE {
     terseCommConfirm      [0] TerseCommunityConfirm,
     verboseCommConfirm    [1] VerboseCommunityConfirm }

   TerseCommunityConfirm ::= StatusCode

   VerboseCommunityConfirm ::= SEQUENCE {
     status          StatusCode,
     communities     CommunityIdentifierList OPTIONAL }

   -- Sequence Number Adjust Message

   id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 }

   SequenceNumberAdjust ::= SEQUENCE {
     version         [0] TAMPVersion DEFAULT v2,
     msgRef          TAMPMsgRef }

   -- Sequence Number Adjust Confirm Message

   id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= { id-tamp 11 }

   SequenceNumberAdjustConfirm ::= SEQUENCE {
     version         [0] TAMPVersion DEFAULT v2,
     adjust          TAMPMsgRef,
     status          StatusCode }





Housley, et al.              Standards Track                   [Page 75]
^L
RFC 5934                          TAMP                       August 2010


   -- TAMP Error Message

   id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 }

   TAMPError ::= SEQUENCE {
     version         [0] TAMPVersion DEFAULT v2,
     msgType         OBJECT IDENTIFIER,
     status          StatusCode,
     msgRef          TAMPMsgRef OPTIONAL }

   -- Status Codes

   StatusCode ::= ENUMERATED {
     success                            (0),
     decodeFailure                      (1),
     badContentInfo                     (2),
     badSignedData                      (3),
     badEncapContent                    (4),
     badCertificate                     (5),
     badSignerInfo                      (6),
     badSignedAttrs                     (7),
     badUnsignedAttrs                   (8),
     missingContent                     (9),
     noTrustAnchor                     (10),
     notAuthorized                     (11),
     badDigestAlgorithm                (12),
     badSignatureAlgorithm             (13),
     unsupportedKeySize                (14),
     unsupportedParameters             (15),
     signatureFailure                  (16),
     insufficientMemory                (17),
     unsupportedTAMPMsgType            (18),
     apexTAMPAnchor                    (19),
     improperTAAddition                (20),
     seqNumFailure                     (21),
     contingencyPublicKeyDecrypt       (22),
     incorrectTarget                   (23),
     communityUpdateFailed             (24),
     trustAnchorNotFound               (25),
     unsupportedTAAlgorithm            (26),
     unsupportedTAKeySize              (27),
     unsupportedContinPubKeyDecryptAlg (28),
     missingSignature                  (29),
     resourcesBusy                     (30),
     versionNumberMismatch             (31),
     missingPolicySet                  (32),
     revokedCertificate                (33),
     unsupportedTrustAnchorFormat      (34),



Housley, et al.              Standards Track                   [Page 76]
^L
RFC 5934                          TAMP                       August 2010


     improperTAChange                  (35),
     malformed                         (36),
     cmsError                          (37),
     unsupportedTargetIdentifier       (38),
     other                            (127) }

   -- Object Identifier Arc for Attributes

   id-attributes OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16)
       us(840) organization(1) gov(101) dod(2) infosec(1) 5 }

   -- id-aa-TAMP-contingencyPublicKeyDecryptKey uses
   -- PlaintextSymmetricKey syntax
   id-aa-TAMP-contingencyPublicKeyDecryptKey OBJECT IDENTIFIER ::= {
     id-attributes 63 }

   PlaintextSymmetricKey ::= OCTET STRING

   -- id-pe-wrappedApexContinKey extension

   id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::=
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) pe(1) 20 }

   ApexContingencyKey ::= SEQUENCE {
     wrapAlgorithm        AlgorithmIdentifier,
     wrappedContinPubKey  OCTET STRING }

   END

Appendix B.  Media Type Registrations

   Eleven media type registrations are provided in this appendix, one
   for each content type defined in this specification.  As noted in
   Section 2, in all cases TAMP messages are encapsulated within
   ContentInfo structures.  Signed messages are additionally
   encapsulated within a SignedData structure.

B.1.  application/tamp-status-query

   Media type name: application

   Subtype name: tamp-status-query

   Required parameters: None

   Optional parameters: None




Housley, et al.              Standards Track                   [Page 77]
^L
RFC 5934                          TAMP                       August 2010


   Encoding considerations: binary

   Security considerations: Carries a signed request for status
   information.  Integrity protection is discussed in Section 4.1.
   Replay detection is discussed in Section 6.

   Interoperability considerations: None

   Published specification: RFC 5934

   Applications that use this media type: TAMP clients responding to
   requests for status information.

   Additional information:

      Magic number(s): None

      File extension(s): .tsq

      Macintosh File Type Code(s):

   Person & email address to contact for further information:

   Sam Ashmore - srashmo@radium.ncsc.mil

   Intended usage: LIMITED USE

   Restrictions on usage: None

   Author: Sam Ashmore - srashmo@radium.ncsc.mil

   Change controller: IESG

B.2.  application/tamp-status-response

   Media type name: application

   Subtype name: tamp-status-response

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries optionally signed status
   information.  Integrity protection is discussed in Section 4.2.




Housley, et al.              Standards Track                   [Page 78]
^L
RFC 5934                          TAMP                       August 2010


   Interoperability considerations: None

   Published specification: RFC 5934

   Applications that use this media type: TAMP clients responding to
   requests for status information.

   Additional information:

      Magic number(s): None

      File extension(s): .tsr

      Macintosh File Type Code(s):

   Person & email address to contact for further information:

   Sam Ashmore - srashmo@radium.ncsc.mil

   Intended usage: LIMITED USE

   Restrictions on usage: None

   Author: Sam Ashmore - srashmo@radium.ncsc.mil

   Change controller: IESG

B.3.  application/tamp-update

   Media type name: application

   Subtype name: tamp-update

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries a signed trust anchor update
   message.  Integrity protection is discussed in Section 4.3.  Replay
   detection is discussed in Section 6.

   Interoperability considerations: None

   Published specification: RFC 5934





Housley, et al.              Standards Track                   [Page 79]
^L
RFC 5934                          TAMP                       August 2010


   Applications that use this media type: TAMP clients responding to
   requests to update trust anchor information.

   Additional information:

      Magic number(s): None

      File extension(s): .tur

      Macintosh File Type Code(s):

   Person & email address to contact for further information:

   Sam Ashmore - srashmo@radium.ncsc.mil

   Intended usage: LIMITED USE

   Restrictions on usage: None

   Author: Sam Ashmore - srashmo@radium.ncsc.mil

   Change controller: IESG

B.4.  application/tamp-update-confirm

   Media type name: application

   Subtype name: tamp-update-confirm

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries an optionally signed TAMP update
   response.  Integrity protection is discussed in Section 4.4.

   Interoperability considerations: None

   Published specification: RFC 5934

   Applications that use this media type: TAMP clients responding to
   requests to update trust anchor information.







Housley, et al.              Standards Track                   [Page 80]
^L
RFC 5934                          TAMP                       August 2010


   Additional information:

      Magic number(s): None

      File extension(s): .tuc

      Macintosh File Type Code(s):

   Person & email address to contact for further information:

   Sam Ashmore - srashmo@radium.ncsc.mil

   Intended usage: LIMITED USE

   Restrictions on usage: None

   Author: Sam Ashmore - srashmo@radium.ncsc.mil

   Change controller: IESG

B.5.  application/tamp-apex-update

   Media type name: application

   Subtype name: tamp-apex-update

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries a signed request to update an apex
   trust anchor information.  Integrity protection is discussed in
   Section 4.5.  Replay detection is discussed in Section 6.

   Interoperability considerations: None

   Published specification: RFC 5934

   Applications that use this media type: TAMP clients responding to
   requests to update an apex trust anchor.









Housley, et al.              Standards Track                   [Page 81]
^L
RFC 5934                          TAMP                       August 2010


   Additional information:

      Magic number(s): None

      File extension(s): .tau

      Macintosh File Type Code(s):

   Person & email address to contact for further information:

   Sam Ashmore - srashmo@radium.ncsc.mil

   Intended usage: LIMITED USE

   Restrictions on usage: None

   Author: Sam Ashmore - srashmo@radium.ncsc.mil

   Change controller: IESG

B.6.  application/tamp-apex-update-confirm

   Media type name: application

   Subtype name: tamp-apex-update-confirm

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries an optionally signed response to an
   apex update request.  Integrity protection is discussed in
   Section 4.6.

   Interoperability considerations: None

   Published specification: RFC 5934

   Applications that use this media type: TAMP clients responding to
   requests to update an apex trust anchor.









Housley, et al.              Standards Track                   [Page 82]
^L
RFC 5934                          TAMP                       August 2010


   Additional information:

      Magic number(s): None

      File extension(s): .auc

      Macintosh File Type Code(s):

   Person & email address to contact for further information:

   Sam Ashmore - srashmo@radium.ncsc.mil

   Intended usage: LIMITED USE

   Restrictions on usage: None

   Author: Sam Ashmore - srashmo@radium.ncsc.mil

   Change controller: IESG

B.7.  application/tamp-community-update

   Media type name: application

   Subtype name: tamp-community-update

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries a signed request to update community
   membership information.  Integrity protection is discussed in
   Section 4.7.  Replay detection is discussed in Section 6.

   Interoperability considerations: None

   Published specification: RFC 5934

   Applications that use this media type: TAMP clients responding to
   requests to update community membership.









Housley, et al.              Standards Track                   [Page 83]
^L
RFC 5934                          TAMP                       August 2010


   Additional information:

      Magic number(s): None

      File extension(s): .tcu

      Macintosh File Type Code(s):

   Person & email address to contact for further information:

   Sam Ashmore - srashmo@radium.ncsc.mil

   Intended usage: LIMITED USE

   Restrictions on usage: None

   Author: Sam Ashmore - srashmo@radium.ncsc.mil

   Change controller: IESG

B.8.  application/tamp-community-update-confirm

   Media type name: application

   Subtype name: tamp-community-update-confirm

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries an optionally signed response to a
   community update request.  Integrity protection is discussed in
   Section 4.8.

   Interoperability considerations: None

   Published specification: RFC 5934

   Applications that use this media type: TAMP clients responding to
   requests to update community membership.









Housley, et al.              Standards Track                   [Page 84]
^L
RFC 5934                          TAMP                       August 2010


   Additional information:

      Magic number(s): None

      File extension(s): .cuc

      Macintosh File Type Code(s):

   Person & email address to contact for further information:

   Sam Ashmore - srashmo@radium.ncsc.mil

   Intended usage: LIMITED USE

   Restrictions on usage: None

   Author: Sam Ashmore - srashmo@radium.ncsc.mil

   Change controller: IESG

B.9.  application/tamp-sequence-adjust

   Media type name: application

   Subtype name: tamp-sequence-adjust

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries a signed request to update sequence
   number information.  Integrity protection is discussed in
   Section 4.9.  Replay detection is discussed in Section 6.

   Interoperability considerations: None

   Published specification: RFC 5934

   Applications that use this media type: TAMP clients responding to
   requests to update sequence number information.









Housley, et al.              Standards Track                   [Page 85]
^L
RFC 5934                          TAMP                       August 2010


   Additional information:

      Magic number(s): None

      File extension(s): .tsa

      Macintosh File Type Code(s):

   Person & email address to contact for further information:

   Sam Ashmore - srashmo@radium.ncsc.mil

   Intended usage: LIMITED USE

   Restrictions on usage: None

   Author: Sam Ashmore - srashmo@radium.ncsc.mil

   Change controller: IESG

B.10.  application/tamp-sequence-adjust-confirm

   Media type name: application

   Subtype name: tamp-sequence-adjust-confirm

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries an optionally signed sequence number
   adjust confirmation message.  Integrity protection is discussed in
   Section 4.10.

   Interoperability considerations: None

   Published specification: RFC 5934

   Applications that use this media type: TAMP clients responding to
   requests to update sequence number information.









Housley, et al.              Standards Track                   [Page 86]
^L
RFC 5934                          TAMP                       August 2010


   Additional information:

      Magic number(s): None

      File extension(s): .sac

      Macintosh File Type Code(s):

   Person & email address to contact for further information:

   Sam Ashmore - srashmo@radium.ncsc.mil

   Intended usage: LIMITED USE

   Restrictions on usage: None

   Author: Sam Ashmore - srashmo@radium.ncsc.mil

   Change controller: IESG

B.11.  application/tamp-error

   Media type name: application

   Subtype name: tamp-error

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries optionally signed error information
   collecting during TAMP processing.  Integrity protection is discussed
   in Section 4.11.

   Interoperability considerations: None

   Published specification: RFC 5934

   Applications that use this media type: TAMP clients processing TAMP
   messages.









Housley, et al.              Standards Track                   [Page 87]
^L
RFC 5934                          TAMP                       August 2010


   Additional information:

      Magic number(s): None

      File extension(s): .ter

      Macintosh File Type Code(s):

   Person & email address to contact for further information:

   Sam Ashmore - srashmo@radium.ncsc.mil

   Intended usage: LIMITED USE

   Restrictions on usage: None

   Author: Sam Ashmore - srashmo@radium.ncsc.mil

   Change controller: IESG

Appendix C.  TAMP over HTTP

   This appendix describes the formatting and transportation conventions
   for the TAMP messages when carried by HTTP [RFC2616].  Each TAMP
   message type is covered by a subsection below.  Each TAMP request
   message sent via HTTP is responded to either with an HTTP response
   containing a TAMP response or error or, if failure occurs prior to
   invoking TAMP, an HTTP error.  TAMP response, confirmation, and error
   messages are not suitable for caching.  In order for TAMP clients and
   servers using HTTP to interoperate, the following rules apply.

   o  Clients MUST use the POST method to submit their requests.

   o  Servers MUST use the 200 response code for successful responses.

   o  Clients MAY attempt to send HTTPS requests using Transport Layer
      Security (TLS) 1.0 or later, although servers are not required to
      support TLS.

   o  Servers MUST NOT assume client support for any type of HTTP
      authentication such as cookies, Basic authentication, or Digest
      authentication.

   o  Clients and servers are expected to follow the other rules and
      restrictions in [RFC2616].  Note that some of those rules are for
      HTTP methods other than POST; clearly, only the rules that apply
      to POST are relevant for this specification.




Housley, et al.              Standards Track                   [Page 88]
^L
RFC 5934                          TAMP                       August 2010


C.1.  TAMP Status Query Message

   A TAMP Status Query Message using the POST method is constructed as
   follows: The Content-Type header MUST have the value "application/
   tamp-status-query".

   The body of the message is the binary value of the DER encoding of
   the TAMPStatusQuery, wrapped in a CMS body as described in Section 2.

C.2.  TAMP Status Response Message

   An HTTP-based TAMP Status Response message is composed of the
   appropriate HTTP headers, followed by the binary value of the DER
   encoding of the TAMPStatusResponse, wrapped in a CMS body as
   described in Section 2.

   The Content-Type header MUST have the value "application/
   tamp-status-response."

C.3.  Trust Anchor Update Message

   A Trust Anchor Update Message using the POST method is constructed as
   follows: The Content-Type header MUST have the value "application/
   tamp-update".

   The body of the message is the binary value of the DER encoding of
   the TAMPUpdate, wrapped in a CMS body as described in Section 2.

C.4.  Trust Anchor Update Confirm Message

   An HTTP-based Trust Anchor Update Confirm message is composed of the
   appropriate HTTP headers, followed by the binary value of the DER
   encoding of the TAMPUpdateConfirm, wrapped in a CMS body as described
   in Section 2.

   The Content-Type header MUST have the value "application/
   tamp-update-confirm".

C.5.  Apex Trust Anchor Update Message

   An Apex Trust Anchor Update Message using the POST method is
   constructed as follows: The Content-Type header MUST have the value
   "application/tamp-apex-update".

   The body of the message is the binary value of the DER encoding of
   the TAMPApexUpdate, wrapped in a CMS body as described in Section 2.





Housley, et al.              Standards Track                   [Page 89]
^L
RFC 5934                          TAMP                       August 2010


C.6.  Apex Trust Anchor Update Confirm Message

   An HTTP-based Apex Trust Anchor Update Confirm message is composed of
   the appropriate HTTP headers, followed by the binary value of the DER
   encoding of the TAMPApexUpdateConfirm, wrapped in a CMS body as
   described in Section 2.

   The Content-Type header MUST have the value "application/
   tamp-apex-update-confirm".

C.7.  Community Update Message

   A Community Update Message using the POST method is constructed as
   follows: The Content-Type header MUST have the value "application/
   tamp-community-update".

   The body of the message is the binary value of the DER encoding of
   the TAMPCommunityUpdate, wrapped in a CMS body as described in
   Section 2.

C.8.  Community Update Confirm Message

   An HTTP-based Community Update Confirm message is composed of the
   appropriate HTTP headers, followed by the binary value of the DER
   encoding of the TAMPCommunityUpdateConfirm, wrapped in a CMS body as
   described in Section 2.

   The Content-Type header MUST have the value "application/
   tamp-community-update-confirm".

C.9.  Sequence Number Adjust Message

   A Sequence Number Adjust Message using the POST method is constructed
   as follows: The Content-Type header MUST have the value "application/
   tamp-sequence-adjust".

   The body of the message is the binary value of the DER encoding of
   the SequenceNumberAdjust, wrapped in a CMS body as described in
   Section 2.

C.10.  Sequence Number Adjust Confirm Message

   An HTTP-based Sequence Number Adjust Confirm message is composed of
   the appropriate HTTP headers, followed by the binary value of the DER
   encoding of the SequenceNumberAdjustConfirm, wrapped in a CMS body as
   described in Section 2.





Housley, et al.              Standards Track                   [Page 90]
^L
RFC 5934                          TAMP                       August 2010


   The Content-Type header MUST have the value "application/
   tamp-sequence-adjust-confirm".

C.11.  TAMP Error Message

   An HTTP-based TAMP Error message is composed of the appropriate HTTP
   headers, followed by the binary value of the DER encoding of the
   TAMPError, wrapped in a CMS body as described in Section 2.

   The Content-Type header MUST have the value "application/tamp-error".

Authors' Addresses

   Russ Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA  20170
   USA

   EMail: housley@vigilsec.com


   Sam Ashmore
   National Security Agency
   Suite 6751
   9800 Savage Road
   Fort Meade, MD  20755
   USA

   EMail: srashmo@radium.ncsc.mil


   Carl Wallace
   Cygnacom Solutions
   Suite 5400
   7925 Jones Branch Drive
   McLean, VA  22102
   USA

   EMail: cwallace@cygnacom.com











Housley, et al.              Standards Track                   [Page 91]
^L