tech-invite   World Map     

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

RFC 5934

 
 
 

Trust Anchor Management Protocol (TAMP)

Part 3 of 4, p. 45 to 60
Prev RFC Part       Next RFC Part

 


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

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

   The various values of StatusCode are used as follows:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.  Sequence Number Processing

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

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

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

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

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

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

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

7.  Subordination Processing

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

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

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

   o  Calculation of the trust anchor information to be stored.

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

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

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

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

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

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

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

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

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

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

8.  Implementation Considerations

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

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

   TAMP assumes a reliable underlying transport protocol.

9.  Wrapped Apex Contingency Key Certificate Extension

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

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

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

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

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

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

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

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

10.  Security Considerations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11.  IANA Considerations

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

12.  References

12.1.  Normative References

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

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

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

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

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

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

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


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

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

12.2.  Informative References

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

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

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

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

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

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

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

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

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

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

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


Next RFC Part