tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5934

 Errata 
Proposed STD
Pages: 91
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: PKIX

Trust Anchor Management Protocol (TAMP)

Part 1 of 4, p. 1 to 19
None       Next RFC Part

 


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


                Trust Anchor Management Protocol (TAMP)

Abstract

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

Status of This Memo

   This is an Internet Standards Track document.

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

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

Page 2 
Copyright Notice

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

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

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

Top       Page 3 
Table of Contents

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

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

1.  Introduction

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

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

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

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

1.1.  Terminology

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

1.2.  Trust Anchors

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

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

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

   o  A public key identifier

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

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

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

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

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

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

1.2.1.  Apex Trust Anchors

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

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

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

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

Top      ToC       Page 7 
   o  The apex trust anchor private key is no longer available

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

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

   o  The authority has decided to use a different key size

   o  The authority has decided to transfer control to another authority

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

1.2.2.  Management Trust Anchors

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

1.2.3.  Identity Trust Anchors

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

Top      ToC       Page 8 
1.3.  Architectural Elements

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

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

1.3.1.  Cryptographic Module

   The cryptographic module MUST include the following capabilities:

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

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

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

1.3.2.  Trust Anchor Store

   The trust anchor store MUST include the following capabilities:

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

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

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

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

1.3.3.  TAMP Processing Dependencies

   TAMP processing MUST include the following capabilities:

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

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

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

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

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

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

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

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

1.3.4.  Application-Specific Protocol Processing

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

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

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

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

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

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

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

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

1.4.  ASN.1 Encoding

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

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

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

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

2.  Cryptographic Message Syntax Profile

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

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

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

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

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

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

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

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

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

2.1.  ContentInfo

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

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

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

2.2.  SignedData Info

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

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

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

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

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

Top      ToC       Page 15 
   o  crls is an OPTIONAL collection of certificate revocation lists
      (CRLs).

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

2.2.1.  SignerInfo

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

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

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

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

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

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

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

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

2.2.2.  EncapsulatedContentInfo

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

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

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

2.2.3.  Signed Attributes

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

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

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

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

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

   The following summarizes the signed attribute requirements for TAMP
   messages:

   o  content-type MUST be supported.

   o  message-digest MUST be supported.

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

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

2.2.3.1.  Content-Type Attribute

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

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

2.2.3.2.  Message-Digest Attribute

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

2.2.3.3.  Binary-Signing-Time Attribute

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

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

Top      ToC       Page 18 
2.2.4.  Unsigned Attributes

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

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

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

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

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

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

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

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

    PlaintextSymmetricKey ::= OCTET STRING

3.  Trust Anchor Formats

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

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

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

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



(page 19 continued on part 2)

Next RFC Part