tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5934

 
 
 

Trust Anchor Management Protocol (TAMP)

Part 2 of 4, p. 19 to 45
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 19 
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 }.

Top      Up      ToC       Page 20 
   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.

Top      Up      ToC       Page 21 
      +---------+                                +----------+
      |         |  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

Top      Up      ToC       Page 22 
   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 }

Top      Up      ToC       Page 23 
    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

Top      Up      ToC       Page 24 
      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.

Top      Up      ToC       Page 25 
   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.

Top      Up      ToC       Page 26 
   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.

Top      Up      ToC       Page 27 
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 }

Top      Up      ToC       Page 28 
    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.

Top      Up      ToC       Page 29 
   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

Top      Up      ToC       Page 30 
      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

Top      Up      ToC       Page 31 
      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

Top      Up      ToC       Page 32 
   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 }

Top      Up      ToC       Page 33 
   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.

Top      Up      ToC       Page 34 
   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

Top      Up      ToC       Page 35 
   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.

Top      Up      ToC       Page 36 
      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.

Top      Up      ToC       Page 37 
   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.

Top      Up      ToC       Page 38 
   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

Top      Up      ToC       Page 39 
   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

Top      Up      ToC       Page 40 
      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.

Top      Up      ToC       Page 41 
   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.

Top      Up      ToC       Page 42 
   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.

Top      Up      ToC       Page 43 
   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.

Top      Up      ToC       Page 44 
   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.

Top      Up      ToC       Page 45 
   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).



(page 45 continued on part 3)

Next RFC Part