Network Working Group                                         R. Housley
Internet-Draft                                       Vigil Security, LLC
Intended status: Standards Track                              S. Ashmore
Expires: April 9, 2009                          National Security Agency
                                                              C. Wallace
                                                      Cygnacom Solutions
                                                         October 6, 2008


                Trust Anchor Management Protocol (TAMP)
                        draft-ietf-pkix-tamp-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 9, 2009.















Housley, et al.           Expires April 9, 2009                 [Page 1]


Internet-Draft                    TAMP                      October 2008


Abstract

   This document describes a transport independent protocol for the
   management of trust anchors 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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Trust Anchors  . . . . . . . . . . . . . . . . . . . . . .  4
       1.2.1.  Apex Trust Anchors . . . . . . . . . . . . . . . . . .  5
       1.2.2.  Management Trust Anchors . . . . . . . . . . . . . . .  6
       1.2.3.  Identity Trust Anchors . . . . . . . . . . . . . . . .  7
     1.3.  Architectural Elements . . . . . . . . . . . . . . . . . .  7
       1.3.1.  Cryptographic Module . . . . . . . . . . . . . . . . .  7
       1.3.2.  Trust Anchor Store . . . . . . . . . . . . . . . . . .  8
       1.3.3.  TAMP Processing Dependencies . . . . . . . . . . . . .  8
       1.3.4.  Application-Specific Protocol Processing . . . . . . .  9
     1.4.  ASN.1 Encoding . . . . . . . . . . . . . . . . . . . . . . 10
   2.  Cryptographic Message Syntax Profile . . . . . . . . . . . . . 12
     2.1.  Content Info . . . . . . . . . . . . . . . . . . . . . . . 13
     2.2.  SignedData Info  . . . . . . . . . . . . . . . . . . . . . 13
       2.2.1.  SignerInfo . . . . . . . . . . . . . . . . . . . . . . 14
       2.2.2.  EncapsulatedContentInfo  . . . . . . . . . . . . . . . 16
       2.2.3.  Signed Attributes  . . . . . . . . . . . . . . . . . . 16
       2.2.4.  Unsigned Attributes  . . . . . . . . . . . . . . . . . 18
   3.  Trust Anchor Formats . . . . . . . . . . . . . . . . . . . . . 20
   4.  Trust Anchor Management Protocol Messages  . . . . . . . . . . 21
     4.1.  TAMP Status Query  . . . . . . . . . . . . . . . . . . . . 22
     4.2.  TAMP Status Query Response . . . . . . . . . . . . . . . . 26
     4.3.  Trust Anchor Update  . . . . . . . . . . . . . . . . . . . 28
     4.4.  Trust Anchor Update Confirm  . . . . . . . . . . . . . . . 34
     4.5.  Apex Trust Anchor Update . . . . . . . . . . . . . . . . . 36
     4.6.  Apex Trust Anchor Update Confirm . . . . . . . . . . . . . 39
     4.7.  Community Update . . . . . . . . . . . . . . . . . . . . . 41
     4.8.  Community Update Confirm . . . . . . . . . . . . . . . . . 43
     4.9.  Sequence Number Adjust . . . . . . . . . . . . . . . . . . 45
     4.10. Sequence Number Adjust Confirm . . . . . . . . . . . . . . 46
     4.11. TAMP Error . . . . . . . . . . . . . . . . . . . . . . . . 47
   5.  Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . 49
   6.  Sequence Number Processing . . . . . . . . . . . . . . . . . . 54



Housley, et al.           Expires April 9, 2009                 [Page 2]


Internet-Draft                    TAMP                      October 2008


   7.  Subordination Processing . . . . . . . . . . . . . . . . . . . 56
   8.  Implementation Considerations  . . . . . . . . . . . . . . . . 59
   9.  Apex trust anchor info certificate extension . . . . . . . . . 60
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 61
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 64
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 65
     12.2. Informative References . . . . . . . . . . . . . . . . . . 65
   Appendix A.  ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 67
     A.1.  ASN.1 Module Using 1993 Syntax . . . . . . . . . . . . . . 67
     A.2.  ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . 76
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84
   Intellectual Property and Copyright Statements . . . . . . . . . . 85






































Housley, et al.           Expires April 9, 2009                 [Page 3]


Internet-Draft                    TAMP                      October 2008


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)
   [RFC3852].  The CMS is a data protection encapsulation syntax that
   makes use of ASN.1 [X.680].

   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.

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 within the protocol
   itself: Certificate [RFC5280], TBSCertificate [RFC5280] and
   TrustAnchorInfo [TAF].

   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:



Housley, et al.           Expires April 9, 2009                 [Page 4]


Internet-Draft                    TAMP                      October 2008


   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 issue TAMP messages also include a
   sequence number for replay detection.

   The public key is used to name a trust anchor, and the public key
   identifier is used to identify the trust anchor as the signer.  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 can 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 signed by a trust anchor.  Support for TAMP messages
   validated using an X.509 certificate signed by 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.  In order to make processing of messages as uniform as
   possible, the apex has an implicit OID associated with it that
   represents the special id-ct-anyContentType value.  This OID will be
   used as input to processing algorithms to represent the apex trust



Housley, et al.           Expires April 9, 2009                 [Page 5]


Internet-Draft                    TAMP                      October 2008


   anchor authorization.

   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

   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 would 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 which 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.

   Authorization checking is needed for management messages, and these



Housley, et al.           Expires April 9, 2009                 [Page 6]


Internet-Draft                    TAMP                      October 2008


   checks are based on the content type of the management message.  As a
   result, management trust anchors include a list of object identifiers
   (OIDs) that name authorized content types along with OPTIONAL
   constraints.

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.

1.3.  Architectural Elements

   TAMP does not assume any particular architecture; however, for TAMP
   to be useful in an architecture, it MUST include 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.

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



Housley, et al.           Expires April 9, 2009                 [Page 7]


Internet-Draft                    TAMP                      October 2008


      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 [RFC3852], and for validation of X.509
      certification paths.

1.3.2.  Trust Anchor Store

   The trust anchor store MUST include the following capabilities:

   o  Each trust anchor store within a family of cryptographic modules
      (which are generally produced by the same manufacturer) MUST have
      a unique serial number (with respect to other modules within the
      same family).  The family is represented as an ASN.1 object
      identifier (OID), and the unique serial number is represented as a
      string of octets.

   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 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.

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 can also be
      used.

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





Housley, et al.           Expires April 9, 2009                 [Page 8]


Internet-Draft                    TAMP                      October 2008


   o  TAMP processing MUST have read and write access to secure storage
      for sequence numbers associated with each TAMP message source 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 access controls
      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 family identifier
      and serial number.

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 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 the
   following services:

   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



Housley, et al.           Expires April 9, 2009                 [Page 9]


Internet-Draft                    TAMP                      October 2008


      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 the content types and any associated constraints held in
      storage with management trust anchors to make authorization
      decisions for that application.  The authorization decisions apply
      to the management trust anchor as well as any public key that is
      validated to the management trust anchor via an X.509
      certification path.

   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 family identifier, serial number, and community membership
      list.

   It is expected that application-specific protocol processing will
   also include constraints processing.  In some applications,
   management trust anchors could be authorized for a subset of the
   functionality associated with a particular content type.

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
   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.



Housley, et al.           Expires April 9, 2009                [Page 10]


Internet-Draft                    TAMP                      October 2008


   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 the document for illustrative
   purposes.  The authoritative source of ASN.1 for the structures
   defined in this document is Appendix A.










































Housley, et al.           Expires April 9, 2009                [Page 11]


Internet-Draft                    TAMP                      October 2008


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, and it MUST encapsulate the CMS
   SignedData content type.  The CMS SignedData content type MUST
   encapsulate the TAMP message.  A unique content type identifier
   identifies the particular 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
    }

    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
    }





Housley, et al.           Expires April 9, 2009                [Page 12]


Internet-Draft                    TAMP                      October 2008


   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.  Content Info

   CMS requires the outer-most encapsulation to be ContentInfo
   [RFC3852].  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.

   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 [RFC3852] 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.





Housley, et al.           Expires April 9, 2009                [Page 13]


Internet-Draft                    TAMP                      October 2008


   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 cryptographic module 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 cryptographic
      module, this field SHOULD include only the cryptographic module
      certificate or 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) [RFC3281] 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].

   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:






Housley, et al.           Expires April 9, 2009                [Page 14]


Internet-Draft                    TAMP                      October 2008


   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 an apex trust anchor
      operational public key or a management trust anchor public key is
      used directly, this identifier is the keyId from the associated
      TrustAnchorInfo.  When the public key is included in an X.509
      certificate, 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 the cryptographic module MUST
      ignore any unrecognized signed attributes.

   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.

   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.







Housley, et al.           Expires April 9, 2009                [Page 15]


Internet-Draft                    TAMP                      October 2008


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 [PKIXASN1]

   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 or content-hints signed attributes.

   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.




Housley, et al.           Expires April 9, 2009                [Page 16]


Internet-Draft                    TAMP                      October 2008


   o  content-hints MAY be supported.  Only present when more than one
      layer of encapsulation is employed.

   o  binary-signing-time MAY be supported.  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 [RFC3852] 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 [RFC3852]
   defines the message-digest attribute.

2.2.3.3.  Content-Hints Attribute

   Many applications find it useful to have information that describes
   the innermost content when multiple layers of encapsulation have been
   applied.  Since this version of TAMP only has one layer of
   encapsulation, the encapContentInfo provides the content type of the
   innermost content.  To accommodate future versions of TAMP that might
   include additional layers of encapsulation, the content-hints
   attribute MUST be included in every instance of SignedData that does
   not directly encapsulate a TAMP message.  Section 2.9 of [RFC2634]
   defines the content-hints attribute.

   The content-hints attribute contains two fields: contentDescription
   and contentType.  The contentType field MUST be present, and the
   contentDescription field MAY be present.  The fields of the content-
   hints attribute are used as follows:

   o  contentDescription is OPTIONAL.  The TAMP message signer MAY
      provide a brief description of the purpose of the TAMP message.
      The text is intended for human consumption, not machine
      processing.  The text is encoded in UTF-8 [RFC3629], which



Housley, et al.           Expires April 9, 2009                [Page 17]


Internet-Draft                    TAMP                      October 2008


      accommodates most of the world's writing systems.  The
      implementation MUST provide the capability to constrain the
      character set.

   o  contentType is mandatory.  This field indicates the content type
      that will be discovered when CMS protection content types are
      removed.

2.2.3.4.  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.

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 the cryptographic module MUST ignore unrecognized
   unsigned attributes.

   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



Housley, et al.           Expires April 9, 2009                [Page 18]


Internet-Draft                    TAMP                      October 2008


   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







































Housley, et al.           Expires April 9, 2009                [Page 19]


Internet-Draft                    TAMP                      October 2008


3.  Trust Anchor Formats

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


    TrustAnchorChoice ::= CHOICE {
     certificate  [0] EXPLICIT 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.
























Housley, et al.           Expires April 9, 2009                [Page 20]


Internet-Draft                    TAMP                      October 2008


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 }.

   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 }.

   Support for TrustAnchorUpdate messages is REQUIRED.  Support for all
   other message formats is RECOMMENDED.



Housley, et al.           Expires April 9, 2009                [Page 21]


Internet-Draft                    TAMP                      October 2008


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


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

               Figure 4-1: Typical TAMP Message Flow


   Each TAMP query and update message include an indication of the type
   of response that is desired.  The response can either be terse or
   verbose.  All trust anchor stores SHOULD support both the 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 cryptographic
   module supports the Community Update message, then the cryptographic
   module SHOULD also support generation of the Community Update Confirm
   message.

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 cryptographic
   module, and for the list of communities to which the cryptographic



Housley, et al.           Expires April 9, 2009                [Page 22]


Internet-Draft                    TAMP                      October 2008


   module belongs.  The TAMP Status Query message MUST be signed.  For
   the query message to be valid, the cryptographic module 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 operational public key, a management trust
   anchor authorized for the id-ct-TAMP-statusQuery content type, 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 for
   the id-ct-TAMP-statusQuery content type, and the cryptographic module
   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:
































Housley, et al.           Expires April 9, 2009                [Page 23]


Internet-Draft                    TAMP                      October 2008


    PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER

    tamp-status-query PKCS7-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 }

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

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

    TargetIdentifier ::= CHOICE {
      hwModules    [1] HardwareModuleIdentifierList,
      communities  [2] CommunityIdentifierList,
      allModules   [3] NULL }

    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


   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.





Housley, et al.           Expires April 9, 2009                [Page 24]


Internet-Draft                    TAMP                      October 2008


   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 cryptographic module or collection of cryptographic
      modules that are the target 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 cryptographic modules or community of
      cryptographic modules that are the target of the query.  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 cryptographic modules.  A
      sequence of these object identifiers is used if more than one
      community is the target of the message.  A cryptographic module is
      considered a target if it is a member of any of the listed
      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.

   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



Housley, et al.           Expires April 9, 2009                [Page 25]


Internet-Draft                    TAMP                      October 2008


   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 cryptographic module 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.

   The TAMP Status Response content type has the following syntax:



























Housley, et al.           Expires April 9, 2009                [Page 26]


Internet-Draft                    TAMP                      October 2008


    tamp-status-response PKCS7-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 }

    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 AlgorithmIdentifier OPTIONAL,
      communities            CommunityIdentifierList OPTIONAL }

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

    TrustAnchorChoiceWithSeqNumber ::= SEQUENCE {
       ta TrustAnchorChoice,
       seqNumber SeqNumber OPTIONAL
       -- seqNumber only present when TA is authorized for TAMP
    }



   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 cryptographic
      module 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.           Expires April 9, 2009                [Page 27]


Internet-Draft                    TAMP                      October 2008


   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.

   The fields of TerseStatusResponse are used as follows:

   o  taKeyIds contains a sequence of key identifiers.  Each trust
      anchor contained in the cryptographic module is represented by one
      key identifier.  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 cryptographic module belongs.  When the module belongs
      to no communities, this field is omitted.

   The fields of VerboseStatusResponse are used as follows:

   o  taInfo contains a sequence of TrustAnchorChoiceWithSeqNumber
      structures.  One entry in the sequence is provided for each trust
      anchor contained in the cryptographic module.  The apex trust
      anchor is the first trust anchor in the sequence.  The
      TrustAnchorChoiceWithSeqNumber is used to associate a sequence
      number with trust anchors authorized to generate TAMP messages.

   o  continPubKeyDecryptAlg 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.

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

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 cryptographic module MUST be an intended
   recipient of the update, the sequence number checking described in
   Section 6 MUST be successful when the TAMP message source is a trust
   anchor, and the digital signature MUST be validated using the apex
   trust anchor operational public key, a management trust anchor
   authorized for the id-ct-TAMP-update content type, or via an



Housley, et al.           Expires April 9, 2009                [Page 28]


Internet-Draft                    TAMP                      October 2008


   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 for
   the id-ct-TAMP-update content type, and the cryptographic module is
   an intended recipient of the TAMP message, then the cryptographic
   module 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:







































Housley, et al.           Expires April 9, 2009                [Page 29]


Internet-Draft                    TAMP                      October 2008


    tamp-update PKCS7-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 }

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

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

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

   TrustAnchorChangeInfo ::= SEQUENCE {
     pubKey          PublicKeyInfo,
     keyId           KeyIdentifier OPTIONAL,
     taType          [0] TrustAnchorChangeType OPTIONAL,
     taTitle         [1] TrustAnchorTitle OPTIONAL,
     certPath        [2] CertPathControls OPTIONAL,
     exts            [3] Extensions OPTIONAL}

   TrustAnchorChangeType ::= CHOICE {
     mgmt            [1] MgmtTrustAnchorInfo,
     ident           [2] NULL }




   The fields of TAMPUpdate are used as follows:






Housley, et al.           Expires April 9, 2009                [Page 30]


Internet-Draft                    TAMP                      October 2008


   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 cryptographic module or collection of cryptographic
      modules that are the target 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.

   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 cryptographic module.  The TrustAnchorChoiceWithSeqNumber
      structure is used to provide the trusted public key and all of the
      information associated with it along with an optional sequence
      number.  However, the action MUST fail 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 cryptographic module using this
      action; therefore taType MUST NOT use ApexTrustAnchorInfo.  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, except the seqNum field, MUST be
      treated as a successful addition.  When the seqNum field does not



Housley, et al.           Expires April 9, 2009                [Page 31]


Internet-Draft                    TAMP                      October 2008


      match the most recently stored sequence number, the larger value
      MUST be stored by the cryptographic module.  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 other than the seqNum
      field, MUST result in an error.  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 cryptographic module, including the deletion of
      the management trust anchor associated with the TAMP message
      signer.  However, the action MUST fail if the subordination checks
      described in Section 7 are not satisfied.  The public key
      contained in PublicKeyInfo names the management or identity trust
      anchor to be deleted.  An attempt to 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 cryptographic module in an unrecoverable
      configuration.

   o  change is used to update the information associated with an
      existing management or identity trust anchor in the cryptographic
      module.  The public key contained in the PublicKeyInfo field of
      TrustAnchorChangeInfo or in the subjectPublicKeyInfo field of a
      TBSCertificateChangeInfo names the to-be-updated trust anchor.
      However, the action MUST fail 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 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
      Certificate MUST fail.  Attempts to change a trust anchor added as
      a TBSCertificate using a TrustAnchorChangeInfo MUST fail.
      Attempts to change a trust anchor added as a TrustAnchorInfo using
      a TBSCertificateChangeInfo MUST fail.  Attempts to add an exts
      field to v2 TrustAnchorInfo MUST fail.

   The fields of TrustAnchorChangeInfo are used as follows:






Housley, et al.           Expires April 9, 2009                [Page 32]


Internet-Draft                    TAMP                      October 2008


   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 cryptographic module storage.

   o  keyId is OPTIONAL, and when present, it contains the public key
      identifier of the trust anchor public key.  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  taType is OPTIONAL, and when present, it carries information
      specific to the management trust anchor using the
      MgmtTrustAnchorInfo structure or indicates the trust anchor is an
      identity trust anchor.  This structure can be used to convert an
      identity trust anchor to a management trust anchor or vice versa.
      If this structure is not present, then the previous taType is
      preserved.  The syntax and semantics of MgmtTrustAnchorInfo is
      discussed in [TAF].  Each of the updates MUST satisfy the
      subordination checks described in Section 7.  The tampSeqNum field
      has been deprecated and is ignored if present.

   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
      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
      is discussed in [TAF].




Housley, et al.           Expires April 9, 2009                [Page 33]


Internet-Draft                    TAMP                      October 2008


   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.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:



















Housley, et al.           Expires April 9, 2009                [Page 34]


Internet-Draft                    TAMP                      October 2008


    tamp-update-confirm PKCS7-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 }


   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
      cryptographic module 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 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:



Housley, et al.           Expires April 9, 2009                [Page 35]


Internet-Draft                    TAMP                      October 2008


   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 TrustAnchorChoiceWithSeqNumber
      structures.  One entry in the sequence is provided for each trust
      anchor contained in the cryptographic module.  These represent the
      state of the trust anchors after the updates have been processed.
      The apex trust anchor is the first trust anchor in the sequence.
      The TrustAnchorChoiceWithSeqNumber is used to associate a sequence
      number with trust anchors authorized to generate TAMP messages.

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 cryptographic module has exactly one apex
   trust anchor.  Since the apex trust anchor represents the ultimate
   authority over the cryptographic module, 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 cryptographic module 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
   cryptographic module 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



Housley, et al.           Expires April 9, 2009                [Page 36]


Internet-Draft                    TAMP                      October 2008


   operational public key can optionally be provided.  If no value is
   provided, then the cryptographic module 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 cryptographic module MUST be deleted.  That is,
   the new apex trust anchor MUST be the only trust anchor remaining in
   the cryptographic module.  If the Apex Trust Anchor Update message is
   valid and the clearCommunities flag is set to TRUE, then all
   community identifiers stored in the cryptographic module MUST be
   deleted.

   The SignedData structure includes a 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 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 cryptographic module is an intended
   recipient of the TAMP message, then the cryptographic module 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:














Housley, et al.           Expires April 9, 2009                [Page 37]


Internet-Draft                    TAMP                      October 2008


    tamp-apex-update PKCS7-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,
      apexTA             TrustAnchorChoiceWithSeqNumber }


   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 cryptographic module or collection of cryptographic
      modules that are the target of the Apex Trust Anchor 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 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
      cryptographic module MUST be deleted, leaving the newly installed
      apex trust anchor as the only trust anchor in the cryptographic
      module.  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 cryptographic
      module MUST be deleted, leaving none.  If the value is set to



Housley, et al.           Expires April 9, 2009                [Page 38]


Internet-Draft                    TAMP                      October 2008


      FALSE, the list of community identifiers MUST NOT be changed.

   o  apexTA provides the information for the replacement apex trust
      anchor.  The TrustAnchorChoiceWithSeqNumber structure is used to
      provide the trusted public key and all of the information
      associated with it, including an optional sequence number that may
      be used to detect TAMP message replay.  Where TrustAnchorInfo is
      used, the taType MUST use the apex choice.  See [TAF] for a
      discussion of the TrustAnchorInfo structure.  The pubKey, keyId,
      taTitle, certPath and exts fields apply to the operational public
      key of the apex trust anchor.  Where Certificate or TBSCertificate
      is used, the ApexTrustAnchorInfo certificate extension MUST appear
      as an extension and the CMSContentConstraints certificate
      extension MUST NOT appear, the special content type id-ct-
      anyContentType is associated with the apex trust anchor
      implicitly.  Section 9 describes the ApexTrustAnchorInfo
      certificate extension.

4.6.  Apex Trust Anchor Update Confirm

   The Apex Trust Anchor Update Confirm message is a reply by a
   cryptographic module 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
   cryptographic module is capable of signing it.

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





















Housley, et al.           Expires April 9, 2009                [Page 39]


Internet-Draft                    TAMP                      October 2008


    tamp-apex-update-confirm PKCS7-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             CommunityIdentifierList 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 cryptographic module 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.

   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



Housley, et al.           Expires April 9, 2009                [Page 40]


Internet-Draft                    TAMP                      October 2008


   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 TrustAnchorChoiceWithSeqNumber
      structures.  One entry in the sequence is provided for each trust
      anchor contained in the cryptographic module.  These represent the
      state of the trust anchors after the apex trust anchor update has
      been processed.  See [TAF] for a description of the
      TrustAnchorInfo structure.  The apex trust anchor is the first
      trust anchor in the sequence.  The TrustAnchorChoiceWithSeqNumber
      is used to associate a sequence number with trust anchors
      authorized to generate TAMP messages.

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

4.7.  Community Update

   The cryptographic module 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 cryptographic module MUST be a target
   of the update, the sequence number checking described in Section 6
   MUST be successful when the TAMP message source is a trust anchor,
   and the digital signature MUST be validated by the apex trust anchor
   operational public key, a management trust anchor authorized for the
   id-ct-TAMP-communityUpdate content type, or via an X.509
   certification path originating with such a trust anchor.

   If the cryptographic module supports the Community Update message,
   the digital signature on the Community Update message is valid,
   sequence number checking is successful, the signer is authorized for
   the id-ct-TAMP-communityUpdate content type, and the cryptographic
   module is an intended recipient of the TAMP message, then the
   cryptographic module 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.




Housley, et al.           Expires April 9, 2009                [Page 41]


Internet-Draft                    TAMP                      October 2008


   The Community Update message contains a batch of updates, and all of
   the updates MUST be accepted for the cryptographic module 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 PKCS7-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 cryptographic module or collection of cryptographic
      modules that are the target 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
      message.  The sequence number is also used to detect TAMP message
      replay.  The sequence number processing described in Section 6



Housley, et al.           Expires April 9, 2009                [Page 42]


Internet-Draft                    TAMP                      October 2008


      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.  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
   cryptographic module 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 cryptographic module.

   o  add is used to insert one or more new community identifiers into
      the cryptographic module.

4.8.  Community Update Confirm

   The Community Update Confirm message is a reply by a cryptographic
   module 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 cryptographic module is
   unchanged.  The Community Update Confirm message MAY be signed or
   unsigned.  A Community Update Confirm message MUST be signed if the
   cryptographic module is capable of signing it.

   The Community Update Confirm content type has the following syntax:








Housley, et al.           Expires April 9, 2009                [Page 43]


Internet-Draft                    TAMP                      October 2008


    tamp-community-update-confirm PKCS7-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
      cryptographic module 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 has been
   processed.  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.

   The fields of VerboseCommunityConfirm are used as follows:





Housley, et al.           Expires April 9, 2009                [Page 44]


Internet-Draft                    TAMP                      October 2008


   o  status contains a single status code, indicating the success or
      failure of the Community Update message has been processed.  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 cryptographic module after
      the update is processed.  When the module belongs to no
      communities, this field is omitted.

4.9.  Sequence Number Adjust

   The cryptographic module maintains the current sequence number for
   the apex trust anchor and each management trust anchor.  Sequence
   number processing is discussed in Section 6.  The Sequence Number
   Adjust message can be used provide the most recently used sequence
   number to one or more cryptographic modules, thereby reducing the
   possibility of replay.  The Sequence Number Adjust message MUST be
   signed.  For the Sequence Number Adjust message to be valid, the
   cryptographic module 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 a management trust anchor that
   is authorized for the id-ct-TAMP-seqNumAdjust content type.

   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 for the id-ct-TAMP-seqNumAdjust content type,
   and the cryptographic module is an intended recipient of the TAMP
   message, then the cryptographic module 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.

   The Sequence Number Adjust content type has the following syntax:









Housley, et al.           Expires April 9, 2009                [Page 45]


Internet-Draft                    TAMP                      October 2008


    tamp-sequence-number-adjust PKCS7-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 cryptographic module or collection of cryptographic
      modules that are the target 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 source, 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 source.  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
   cryptographic module 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
   cryptographic module is unchanged.  The Sequence Number Adjust
   Confirm message MAY be signed or unsigned.  A Sequence Number Adjust
   Confirm message MUST be signed if the cryptographic module is capable
   of signing it.

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




Housley, et al.           Expires April 9, 2009                [Page 46]


Internet-Draft                    TAMP                      October 2008


    tamp-sequence-number-adjust-confirm PKCS7-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
      cryptographic module 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 cryptographic module 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 cryptographic
   module is capable of signing it.

   The object identifier names the TAMP Error message content:












Housley, et al.           Expires April 9, 2009                [Page 47]


Internet-Draft                    TAMP                      October 2008


    tamp-error PKCS7-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).
























Housley, et al.           Expires April 9, 2009                [Page 48]


Internet-Draft                    TAMP                      October 2008


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),
      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),
      other                            (127) }






Housley, et al.           Expires April 9, 2009                [Page 49]


Internet-Draft                    TAMP                      October 2008


   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 cryptographic module
      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.

   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 within
      SignerInfo contains an attribute other than the contingency-
      public-key-decrypt-key unsigned attribute, which is the only
      unsigned attribute supported by this specification.

   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.





Housley, et al.           Expires April 9, 2009                [Page 50]


Internet-Draft                    TAMP                      October 2008


   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 Sec. 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.

   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 cryptographic module 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 cryptographic module 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
      cryptographic module 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.




Housley, et al.           Expires April 9, 2009                [Page 51]


Internet-Draft                    TAMP                      October 2008


   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 cryptographic module is
      not the intended recipient.  The target cryptographic module is
      identified in one of two ways.  HardwareModules identifies the
      cryptographic module by the module type and serial number; in
      which case, either one or both of these values does not match the
      responding cryptographic module.  Alternatively, community
      identifies a group of cryptographic modules; in which case, the
      responding cryptographic module does not belong to the identified
      group.

   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.

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

   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
      the cryptographic module.  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.





Housley, et al.           Expires April 9, 2009                [Page 52]


Internet-Draft                    TAMP                      October 2008


   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 has been revoked.

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

   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.



























Housley, et al.           Expires April 9, 2009                [Page 53]


Internet-Draft                    TAMP                      October 2008


6.  Sequence Number Processing

   The sequence number processing facilities in TAMP represent a balance
   between replay protection, operational considerations, and
   cryptographic module 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 signed directly by a trust
   anchor, and skipping these checks whenever the TAMP message
   originator is represented by a certificate.

   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 signed directly by 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 cryptographic module
   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
   originator.  If the sequence number in a received TAMP message does
   not meet these conditions, then the cryptographic module 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
   signed by 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 each 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



Housley, et al.           Expires April 9, 2009                [Page 54]


Internet-Draft                    TAMP                      October 2008


   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 cryptographic module
   for the apex trust anchor and each management trust anchor.

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
































Housley, et al.           Expires April 9, 2009                [Page 55]


Internet-Draft                    TAMP                      October 2008


7.  Subordination Processing

   The apex trust anchor is unconstrained, which means that
   subordination checking is not performed on Trust Anchor Update
   messages signed with the apex trust anchor operational public key.
   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 a management trust anchor
   associated with the id-ct-TAMP-update content type, either directly
   or via an X.509 certification path originating with the apex trust
   anchor operational public key or such a management trust anchor.  The
   following subordination checks MUST also be performed as part of
   validation.

   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.  The constraints of the TAMP message
   signer and the to-be-updated trust anchor are determined based on the
   applicable CMS Content Constraints.  Specifically, the constraints of
   the TAMP message signer are determined as described in section 3 of
   [CCC] passing the special value id-ct-anyContentType and an empty set
   of attributes as input; the constraints of the to-be-updated trust
   anchor are determined as described below.  If the constraints of a
   trust anchor in an update exceed the constraints of the signer, that
   update MUST be rejected.  Each update is considered and accepted or
   rejected individually without regard to other updates in the TAMP
   message.  The constraints of the to-be-updated trust anchors are
   determined as follows:

   o  If the to-be-updated trust anchor is the subject of an add
      operation, the constraints are read from the taType.mgmt.taUsage
      field of the corresponding TrustAnchorInfo or
      CMSContentConstraints of the corresponding Certificate or
      TBSCertificate in the update.

   o  If the to-be-updated trust anchor is the subject of a remove
      operation, the trust anchor is located in the message recipient's
      trust anchor store using the public key included in the update.
      The constraints are read from the taType.mgmt.taUsage (or
      equivalent) field in the to-be-updated trust anchor.

   o  If the to-be-updated trust anchor is the subject of a change
      operation, the trust anchor has two distinct sets of constraints



Housley, et al.           Expires April 9, 2009                [Page 56]


Internet-Draft                    TAMP                      October 2008


      that MUST be checked.  The trust anchor's pre-change constraints
      are determined by locating the trust anchor in the message
      recipient's trust anchor store using the public key included in
      the update and reading the constraints from the
      taType.mgmt.taUsage (or equivalent) field in the trust anchor.
      The trust anchor's post-change constraints are read from the
      taType.mgmt.taUsage (or equivalent) field of the corresponding
      TrustAnchorChangeInfo in the update.  If the taType.mgmt.taUsage
      (or equivalent) field is not present, then the trust anchor's
      post-change constraints are equivalent to the trust anchor's pre-
      change constraints.

   The following steps can be used to determine if a Trust Anchor Update
   message signer is authorized to manage each to-be-updated trust
   anchor contained in a Trust Anchor Update message.

   o  The TAMP message signer's CMS Content Constraints are determined
      as described in section 3 of [CCC] passing the special value id-
      ct-anyContentType and an empty set of attributes as input.  Note,
      for implementations that support validation of TAMP messages using
      X.509 certificates, it is possible for the TAMP message signer to
      have more than one possible certification path that will authorize
      it to sign Trust Anchor Update messages, with each certification
      path resulting in different CMS Content Constraints.  The update
      is authorized if the processing below succeeds for any one
      certification path of the TAMP message signer.  The resulting
      subject_constraints variable is used to check each to-be-updated
      trust anchor contained in the update message.  The message signer
      MUST be authorized for the Trust Anchor Update message.  This can
      be confirmed using the steps described in section 4 of [CCC].

   o  The constraints of each to-be-updated trust anchor in the TAMP
      message MUST be checked against the message signer's constraints
      (represented in the message signer's subject_constraints computed
      above) using the following steps.  For change operations, the
      following steps MUST be performed for the trust anchor's pre-
      change constraints and the trust anchor's post-change constraints.

      *  Operations on identity trust anchors are permitted provided the
         message signer is authorized for the Trust Anchor Update
         message.

      *  If the to-be-updated trust anchor is unconstrained, the message
         signer MUST also be unconstrained, i.e., the message signer's
         subject_constraints MUST be set to the special value
         anyContentType.  If the to-be-updated trust anchor is
         unconstrained and the message signer is not, then the message
         signer is not authorized to manage the trust anchor and the



Housley, et al.           Expires April 9, 2009                [Page 57]


Internet-Draft                    TAMP                      October 2008


         update MUST be rejected.

      *  The message signer's authorization for each permitted content
         type MUST be checked using the state variables and procedures
         similar to those described in sections 3.2 and 3.3 of [CCC].
         For each permitted content type in the to-be-updated trust
         anchor's constraints,

         +  Set cms_effective_attributes equal to the value of the
            attrConstraints field from the permitted content type.

         +  If the content type does not match an entry in the message
            signer's subject_constraints, the message signer is not
            authorized to manage the trust anchor and the update MUST be
            rejected.  Note, the special value id-ct-anyContentType
            produces a match for all content types with the resulting
            matching entry containing the content type, canSource set to
            TRUE and attrConstraints absent.

         +  If the content type matches an entry in the message signer's
            subject_constraints, the canSource field of the entry is
            FALSE and the canSource field in the to-be-updated trust
            anchor's privilege is TRUE, the message signer is not
            authorized to manage the trust anchor and the update MUST be
            rejected.

         +  If the content type matches an entry in the message signer's
            subject_constraints and the entry's attrConstraints field is
            present, then constraints MUST be checked.  For each
            attrType in the entry's attrConstraints, a corresponding
            attribute MUST be present in cms_effective_attributes
            containing values from the entry's attrConstraints.  If
            values appear in the corresponding attribute that are not in
            the entry's attrConstraints or if there is no corresponding
            attribute, the message signer is not authorized to manage
            the trust anchor and the update MUST be rejected.

   Once these steps are completed, if the update has not been rejected,
   then the message signer is authorized to manage the to-be-updated
   trust anchor.

   Note that a management trust anchor that has only the id-ct-TAMP-
   update permitted content type is useful only for managing identity
   trust anchors.  It can sign a Trust Anchor Update message, but it
   cannot impact a management trust anchor that is associated with any
   other content type.





Housley, et al.           Expires April 9, 2009                [Page 58]


Internet-Draft                    TAMP                      October 2008


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 anchor 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.






























Housley, et al.           Expires April 9, 2009                [Page 59]


Internet-Draft                    TAMP                      October 2008


9.  Apex trust anchor info certificate extension

   Where a Certificate or TBSCertificate structure is used to represent
   an Apex trust anchor, contingency key information may be supplied
   using the WrappedApexContingencyKey extension.  The extension uses
   the ApexContingencyKey structure as defined in [TAF], and repeated
   below.  The fields are used as described in [TAF].



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



   The apex trust anchor info certificate extension MAY be critical, and
   it MUST appear at most one time in a certificate.  The apex trust
   anchor info certificate 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 }


























Housley, et al.           Expires April 9, 2009                [Page 60]


Internet-Draft                    TAMP                      October 2008


10.  Security Considerations

   The majority of this specification is devoted to the syntax and
   semantics of TAMP messages.  It relies on other specifications,
   especially [TAF], [RFC3852] and [RFC5280], for the syntax and
   semantics of CMS protecting content types and X.509 certificates,
   respectively.  Since TAMP messages that change the trust anchor state
   of a cryptographic module 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 cryptographic module 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.
   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 a CMS content constraints certificate extension [CCC] 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 cryptographic modules,
   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 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.



Housley, et al.           Expires April 9, 2009                [Page 61]


Internet-Draft                    TAMP                      October 2008


   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 cryptographic modules 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 cryptographic modules 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
   type.  For example, if the management trust anchor is associated with
   firmware packages, then the unauthorized private key holder can
   install different firmware into the cryptographic module.

   Compromise of the Apex Trust Anchor operational private key permits
   unauthorized parties to generate signed messages that will be
   acceptable to all cryptographic modules 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 associated with the trust
   anchor.  If the CA is subordinate to a management trust anchor, the
   scope of potential damage caused by a private key compromise is also
   limited by the CMS content constraints certificate extension [CCC] in
   the CA certificate, the CMS content constraints on any superior CA
   certificates, and the CMS content constraints on the parent
   management trust anchor.



Housley, et al.           Expires April 9, 2009                [Page 62]


Internet-Draft                    TAMP                      October 2008


   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 associated with the trust anchor.  If
   the certified public key is subordinate to a management trust anchor,
   the scope of potential damage caused by a private key compromise is
   also limited by the CMS content constraints certificate extension
   [CCC] in the end entity certificate, the CMS content constraints on
   any superior CA certificates, and the CMS content constraints on the
   parent management trust anchor.

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

   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.

   To implement TAMP, a cryptographic module needs 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, signed attributes, and certificates.

























Housley, et al.           Expires April 9, 2009                [Page 63]


Internet-Draft                    TAMP                      October 2008


11.  IANA Considerations

   There are no IANA considerations.  Please delete this section prior
   to RFC publication.















































Housley, et al.           Expires April 9, 2009                [Page 64]


Internet-Draft                    TAMP                      October 2008


12.  References

12.1.  Normative References

   [CCC]      Housley, R. and C. Wallace, "Cryptographic Message Syntax
              (CMS) Content Signature Constraints X.509 Certificate
              Extension", in progress.

   [PKIXASN1]
              Hoffman, P. and J. Schaad, "New ASN.1 Modules for PKIX",
              in progress.

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

   [RFC2634]  Hoffman, P., "Enhanced Security Services for S/MIME",
              RFC 2634, June 1999.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, July 2004.

   [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.

   [TAF]      Housley, R., Wallace, C., and S. Ashmore, "Trust Anchor
              Format", in progress.

   [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.

   [RFC3281]  Farrell, S. and R. Housley, "An Internet Attribute



Housley, et al.           Expires April 9, 2009                [Page 65]


Internet-Draft                    TAMP                      October 2008


              Certificate Profile for Authorization", RFC 3281,
              April 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.

   [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.           Expires April 9, 2009                [Page 66]


Internet-Draft                    TAMP                      October 2008


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 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.  A.2 is included as a courtesy to
   developers using ASN.1 compilers that do not support current ASN.1.

A.1.  ASN.1 Module Using 1993 Syntax


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

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   IMPORTS
       TrustAnchorInfo, ApexContingencyKey
       FROM TrustAnchorInfo
          { joint-iso-ccitt(2) country(16) us(840) organization(1)
            gov(101) dod(2) infosec(1) modules(0) 33 }
       ContentType
         FROM CryptographicMessageSyntax2004 -- [RFC3852]
           { iso(1) member-body(2) us(840) rsadsi(113549)
             pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
       AlgorithmIdentifier, Certificate, Name, TBSCertificate
         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
         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) }
       EXTENSION, ATTRIBUTE, Attribute
            FROM PKIX-CommonTypes -- from [PKIXASN1]
              { iso(1) identified-organization(3) dod(6) internet(1)
                security(5) mechanisms(5) pkix(7) id-mod(0)
                id-mod-pkixCommon(43) }         ;




Housley, et al.           Expires April 9, 2009                [Page 67]


Internet-Draft                    TAMP                      October 2008


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

    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 }

   -- 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

   PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER

   TAMPContentTypes PKCS7-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 PKCS7-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,



Housley, et al.           Expires April 9, 2009                [Page 68]


Internet-Draft                    TAMP                      October 2008


     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 }

   TargetIdentifier ::= CHOICE {
     hwModules       [1] HardwareModuleIdentifierList,
     communities     [2] CommunityIdentifierList,
     allModules      [3] NULL }

   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 PKCS7-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 }

   StatusResponse ::= CHOICE {



Housley, et al.           Expires April 9, 2009                [Page 69]


Internet-Draft                    TAMP                      October 2008


     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 AlgorithmIdentifier OPTIONAL,
     communities            CommunityIdentifierList OPTIONAL }

    TrustAnchorChoiceWithSeqNumber ::= SEQUENCE {
       ta TrustAnchorChoice,
       seqNumber SeqNumber OPTIONAL
       -- seqNumber only present when TA is authorized for TAMP
    }

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


   -- Trust Anchor Update Message

   tamp-update PKCS7-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 }

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

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

    TBSCertificateChangeInfo  ::=  SEQUENCE  {
      serialNumber         CertificateSerialNumber OPTIONAL,



Housley, et al.           Expires April 9, 2009                [Page 70]


Internet-Draft                    TAMP                      October 2008


      signature            AlgorithmIdentifier OPTIONAL,
      issuer               Name OPTIONAL,
      validity             Validity OPTIONAL,
      subject              Name OPTIONAL,
      subjectPublicKeyInfo SubjectPublicKeyInfo,
      exts                 [3]  EXPLICIT Extensions OPTIONAL  }

   TrustAnchorChangeInfo ::= SEQUENCE {
     pubKey          PublicKeyInfo,
     keyId           KeyIdentifier OPTIONAL,
     taType          [0] TrustAnchorChangeType OPTIONAL,
     taTitle         [1] TrustAnchorTitle OPTIONAL,
     certPath        [2] CertPathControls OPTIONAL,
     exts            [3] Extensions OPTIONAL}

   TrustAnchorChangeType ::= CHOICE {
     mgmt            [1] MgmtTrustAnchorInfo,
     ident           [2] NULL }


   -- Trust Anchor Update Confirm Message

   tamp-update-confirm PKCS7-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 }


   -- Apex Trust Anchor Update Message

   tamp-apex-update PKCS7-CONTENT-TYPE ::=



Housley, et al.           Expires April 9, 2009                [Page 71]


Internet-Draft                    TAMP                      October 2008


       { 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,
     apexTA              TrustAnchorChoiceWithSeqNumber }


   -- Apex Trust Anchor Update Confirm Message

   tamp-apex-update-confirm PKCS7-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            CommunityIdentifierList OPTIONAL }


   -- Community Update Message

   tamp-community-update PKCS7-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,



Housley, et al.           Expires April 9, 2009                [Page 72]


Internet-Draft                    TAMP                      October 2008


     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 PKCS7-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 PKCS7-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 }


   -- Sequence Number Adjust Message




Housley, et al.           Expires April 9, 2009                [Page 73]


Internet-Draft                    TAMP                      October 2008


   tamp-sequence-number-adjust-confirm PKCS7-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 PKCS7-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),
     unsupportedKeySize                (14),
     unsupportedParameters             (15),
     signatureFailure                  (16),
     insufficientMemory                (17),
     unsupportedTAMPMsgType            (18),



Housley, et al.           Expires April 9, 2009                [Page 74]


Internet-Draft                    TAMP                      October 2008


     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),
     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

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


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

   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


   END




Housley, et al.           Expires April 9, 2009                [Page 75]


Internet-Draft                    TAMP                      October 2008


A.2.  ASN.1 Module Using 1988 Syntax


  TrustAnchorManagementProtocolVersion2_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
    TrustAnchorInfo
    FROM TrustAnchorInfo
         { joint-iso-ccitt(2) country(16) us(840) organization(1)
           gov(101) dod(2) infosec(1) modules(0) 33 }
    ContentType
      FROM CryptographicMessageSyntax2004 -- [RFC3852]
        { iso(1) member-body(2) us(840) rsadsi(113549)
          pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
    AlgorithmIdentifier, Certificate, Name, Attribute, TBSCertificate
      FROM PKIX1Explicit88 -- [RFC5280]
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-mod(0)
          id-pkix1-explicit(18) }
    KeyIdentifier
      FROM PKIX1Implicit88 -- [RFC5280]
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-mod(0)
          id-pkix1-implicit(19) } ;


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

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


  -- 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 }





Housley, et al.           Expires April 9, 2009                [Page 76]


Internet-Draft                    TAMP                      October 2008


  -- 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) }

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

  TargetIdentifier ::= CHOICE {
    hwModules       [1] HardwareModuleIdentifierList,
    communities     [2] CommunityIdentifierList,
    allModules      [3] NULL }

  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

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

  TAMPStatusResponse ::= SEQUENCE {



Housley, et al.           Expires April 9, 2009                [Page 77]


Internet-Draft                    TAMP                      October 2008


    version               [0] TAMPVersion DEFAULT v2,
    query                 TAMPMsgRef,
    response              StatusResponse }

  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 AlgorithmIdentifier OPTIONAL,
    communities            CommunityIdentifierList OPTIONAL }

   TrustAnchorChoiceWithSeqNumber ::= SEQUENCE {
      ta TrustAnchorChoice,
      seqNumber SeqNumber OPTIONAL
      -- seqNumber only present when TA is authorized for TAMP
   }

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

  -- Trust Anchor Update Message

  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 }

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

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

  TBSCertificateChangeInfo  ::=  SEQUENCE  {



Housley, et al.           Expires April 9, 2009                [Page 78]


Internet-Draft                    TAMP                      October 2008


    serialNumber         CertificateSerialNumber OPTIONAL,
    signature            AlgorithmIdentifier OPTIONAL,
    issuer               Name OPTIONAL,
    validity             Validity OPTIONAL,
    subject              Name OPTIONAL,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    exts                 [3]  EXPLICIT Extensions OPTIONAL  }

  TrustAnchorChangeInfo ::= SEQUENCE {
    pubKey          PublicKeyInfo,
    keyId           KeyIdentifier OPTIONAL,
    taType          [0] TrustAnchorChangeType OPTIONAL,
    taTitle         [1] TrustAnchorTitle OPTIONAL,
    certPath        [2] CertPathControls OPTIONAL,
    exts            [3] Extensions OPTIONAL}

  TrustAnchorChangeType ::= CHOICE {
    mgmt            [1] MgmtTrustAnchorInfo,
    ident           [2] NULL }


  -- 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

  VerboseUpdateConfirm ::= SEQUENCE {
    status                StatusCodeList,
    taInfo                TrustAnchorChoiceList }


  -- Apex Trust Anchor Update Message

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

  TAMPApexUpdate ::= SEQUENCE {



Housley, et al.           Expires April 9, 2009                [Page 79]


Internet-Draft                    TAMP                      October 2008


    version             [0] TAMPVersion DEFAULT v2,
    terse               [1] TerseOrVerbose DEFAULT verbose,
    msgRef              TAMPMsgRef,
    clearTrustAnchors   BOOLEAN,
    clearCommunities    BOOLEAN,
    apexTA              TrustAnchorChoiceWithSeqNumber }


  -- 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            CommunityIdentifierList OPTIONAL }

  -- Community Update Message

  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

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




Housley, et al.           Expires April 9, 2009                [Page 80]


Internet-Draft                    TAMP                      October 2008


  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 Message

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

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


  -- 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




Housley, et al.           Expires April 9, 2009                [Page 81]


Internet-Draft                    TAMP                      October 2008


  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),
    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 }



Housley, et al.           Expires April 9, 2009                [Page 82]


Internet-Draft                    TAMP                      October 2008


  PlaintextSymmetricKey ::= OCTET STRING

  END
















































Housley, et al.           Expires April 9, 2009                [Page 83]


Internet-Draft                    TAMP                      October 2008


Authors' Addresses

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

   Email: housley@vigilsec.com


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

   Email: srashmo@radium.ncsc.mil


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

   Email: cwallace@cygnacom.com

























Housley, et al.           Expires April 9, 2009                [Page 84]


Internet-Draft                    TAMP                      October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Housley, et al.           Expires April 9, 2009                [Page 85]