[要約] RFC 5934は、Trust Anchor Management Protocol（TAMP）に関する規格であり、信頼アンカーの管理を目的としています。TAMPは、信頼アンカーの配布、更新、撤回などの操作を効率的かつ安全に行うためのプロトコルです。
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)
信頼アンカー管理プロトコル（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.
このドキュメントでは、信頼アンカー（TA）の管理（TAS）とトラストアンカーストアに保存されているコミュニティ識別子のためのTransport Independent Protocolについて説明しています。プロトコルは暗号化メッセージ構文（CMS）を使用し、デジタル署名を使用して、整合性保護とデータ起源の認証を提供します。このプロトコルは、証明書、TBSCertificate、またはTrustanchorinfoオブジェクトとして表される信頼アンカーを含む信頼アンカーストアを管理するために使用できます。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5934で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
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
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
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.
このドキュメントでは、Trust Anchor Management Protocol（TAMP）について説明しています。TAMPを使用して、デジタル署名を使用する任意のデバイスで、信頼のアンカーとコミュニティ識別子を管理することができます。ただし、この仕様は、暗号化モジュールの要件を念頭に置いて書かれています。たとえば、TAMPは署名済みのファームウェアパッケージ[RFC4108]をサポートできます。ここでは、ファームウェアパッケージのデジタル署名を検証するためにトラストアンカー公開キーを使用したり、ファームウェアパッケージ署名者のX.509認証パス[RFC5280] [X.509]を検証したりできます。。
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].
ほとんどのTAMPメッセージは、整合性保護とデータ起源の認証を提供するためにデジタルで署名されています。署名されたTAMPメッセージと署名されていないTAMPメッセージの両方が、暗号化メッセージの構文（CMS）[RFC5652]を使用しています。CMSは、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. 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メッセージの機密性を提供しません。機密性が必要な場合、TAMPメッセージの転送に使用される通信環境はそれを提供する必要があります。この仕様は、「信頼アンカー管理要件」[TA-MGMT-REQS]で表されるプロトコル関連の要件を満たすことを目的としており、そのドキュメントの語彙を使用します。
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.
TAMPメッセージは、付録Aに記載されているようにHTTP経由など、ネットワークを介してリアルタイムで交換される場合や、他の手段を使用して保存および転送される場合があります。TAMP交換には、トラストアンカーストアの指示と、オプションでは、リクエストの指示を実行した結果を報告する対応する応答メッセージが含まれるリクエストメッセージで構成されています。応答メッセージは、すべての場合に伝播する必要はありません。たとえば、GPSレシーバーは応答を送信できず、代わりに添付のディスプレイを使用してTAMPリクエストの処理結果を示す場合があります。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
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].
TAMPは信頼のアンカーを管理します。トラストアンカーには、デジタル署名の検証に使用される公開キーが含まれています。TAMPは、信頼できるアンカー情報を表現するための3つの形式を認識します：証明書[RFC5280]、TBSCertificate [RFC5280]、および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 パラメーターを含む可能性のある公開キーの署名アルゴリズム識別子と関連する公開キー
o A public key identifier
o 公開キー識別子
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.
TAMPは、機能性に基づいて3種類の信頼アンカーを認識します。ApexTrustアンカー、管理トラストアンカー、Identity Trustアンカー。
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.
上記の情報に加えて、Apex Trust Anchors and Management Trust AnchorsはTampメッセージに署名するアンカーに、リプレイ検出に使用される関連するシーケンス番号を持っています。
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.
公開キーは信頼のアンカーに名前を付けるために使用され、公開鍵識別子は、SignedDataオブジェクトや公開鍵証明書など、特定のオブジェクトの署名者として信頼アンカーを識別するために使用されます。この公開キー識別子は、トラストアンカーで保存することができます。または、ほとんどの公開キー識別子割り当て方法では、必要なときにいつでも公開キーから計算できます。
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.
Trust Anchorの公開キーは、デジタル署名の検証をサポートするために2つの異なる方法で使用できます。最初のアプローチでは、Trust Anchorの公開キーを直接使用して、デジタル署名を検証します。2番目のアプローチでは、Trust Anchorの公開キーを使用してX.509認証パスを検証し、認定パスの最終証明書の主題公開キーを使用してデジタル署名を検証します。2番目のアプローチが採用される場合、認定された公開キーは、デジタル署名検証以外のものに使用される場合があります。他の可能なアクションは、主要な使用証明書拡張によって制約されます。
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.
TAMP実装は、Trustアンカーを使用して直接検証されるTAMPメッセージの検証をサポートする必要があります。X.509証明書を使用して検証されたTAMPメッセージのサポートトラストアンカーを使用して検証された、またはより長い認証パスを使用して検証されたことはオプションです。CMSはX.509証明書を携帯する場所を提供し、この機能を使用して証明書を転送して認証パスの建設を支援できます。
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.
単一のトラストアンカーストアのコンテキスト内では、1つのトラストアンカーは他のすべてのものよりも優れています。このトラストアンカーは、Apex Trust Anchorと呼ばれます。このトラストアンカーは、信頼のアンカーストアに対する究極の権威を表しています。この権限の多くは、他の信頼のアンカーに委任することができます。
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.
Apex Trust Anchorの秘密鍵は、Trust Anchor Storeの情報保証責任を持つエンティティによって管理されることが期待されています。Apex Trustアンカーは制約されていないため、それに関連する明示的な認証情報がありません。
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:
Apex Trustアンカーの特別な性質のため、Tampにはそれを変更するための別々の施設が含まれています。特に、TAMPには、Apex Trustアンカーを安全に交換する施設が含まれています。このアクションは、次の1つ以上の理由で取られる可能性があります。
o The crypto period for the apex trust anchor public/private key pair has come to an end
o Apex Trust Anchor Public/Private Keyペアの暗号期間が終わりました
o The apex trust anchor private key is no longer available
o Apex Trust Anchor秘密キーはもう利用できなくなりました
o The apex trust anchor public/private key pair needs to be revoked
o Apex Trust Anchor Public/Private Keyペアを取り消す必要があります
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 当局は、異なるデジタル署名アルゴリズムまたは異なる楕円曲線などの異なるパラメーターを持つ同じデジタル署名アルゴリズムを使用することを決定しました
o The authority has decided to use a different key size
o 当局は別のキーサイズを使用することを決定しました
o The authority has decided to transfer control to another authority
o 当局は、コントロールを別の当局に譲渡することを決定しました
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.
これらの要件に対応するために、Apex Trust Anchorには2つのパブリックキーが含まれる場合があります。Apex Trust Anchorが更新されると、両方のパブリックキーが交換されます。オペレーショナル公開キーと呼ばれる最初の公開キーは、他の信頼アンカーと同じ方法で使用されます。Apex Trust Anchor Updateメッセージを含むあらゆるタイプのTAMPメッセージは、運用公開キーで検証できます。The Contingencyの公開キーと呼ばれる2番目の公開キーは、Apex Trustアンカーの更新にのみ使用できます。緊急時の秘密鍵は、1つの時点でのみ使用する必要があります。これは、Apex Trust Anchor Updateメッセージに署名するためにのみ使用されます。緊急時の公開キーは、暗号化された形式で配布されます。Apex Trust Anchor Updateメッセージを検証するためにContingencyの公開キーを使用すると、Contingenceの公開キーを解読するために必要な対称キーは、署名されたApex Trust Anchor Updateメッセージの一部として提供されます。
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.
管理信託アンカーは、暗号化モジュールの管理に使用されます。たとえば、このドキュメントで指定されたTAMPメッセージは、管理トラストアンカーに検証されます。同様に、[RFC4108]で指定されている署名付きファームウェアパッケージは、管理トラストアンカーに検証されます。
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.
Identity Trustアンカーは、認証パスを検証するために使用され、公開キーインフラストラクチャの信頼アンカーを表します。これらは、非管理アプリケーションに関連する証明書の検証に最もよく使用されます。
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.
TAMPは特定のアーキテクチャを想定していません。ただし、TAMPには次のアーキテクチャ要素が必要です。暗号化モジュール、トラストアンカーストア、TAMPプロトコル処理、およびその他のアプリケーション固有のプロトコル処理です。
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.
一方向ハッシュ関数、デジタル署名生成/検証アルゴリズム、および実装された対称キーアンラッピングアルゴリズムごとに、グローバルに一意のアルゴリズム識別子を割り当てる必要があります。CMSをサポートするために、オブジェクト識別子（OID）が一元配置ハッシュ関数に名前を付けるように割り当てられ、別のOIDがデジタル署名アルゴリズムで使用すると一方向ハッシュ関数の各組み合わせに名前を付けるように割り当てられます。同様に、公開キーアルゴリズムに割り当てられたOIDをサブジェクトのパブリックキーで関連付け、証明書は、証明書発行者デジタル署名の一方向ハッシュ関数とデジタル署名アルゴリズムの両方に名前を付けるOIDを使用します。[RFC3279]、[RFC3370]、[RFC5753]、および[RFC5754]は、多くの一般的に使用されるアルゴリズムのOIDを提供します。ただし、OIDは後の仕様または異なる仕様で定義できます。
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 暗号化モジュールは、デジタル署名の秘密キーの安全なストレージをサポートして、TAMP応答と、関連する公開キーまたは証明書指定子を含む証明書のいずれかをサポートする必要があります。後者の場合、証明書は他の場所に保存されますが、暗号化モジュールのデジタル署名を検証する必要がある当事者が利用できます。設計者は公開キー識別子です。
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 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.
o 暗号化モジュールは、少なくとも1つの一方向ハッシュ関数、1つのデジタル署名検証アルゴリズム、1つのデジタル署名生成アルゴリズム、および緊急性キーがサポートされている場合は、1つの対称キーアンラッピングアルゴリズムをサポートする必要があります。1つの一方向ハッシュ関数のみが存在する場合、デジタル署名検証およびデジタル署名生成アルゴリズムと一致する必要があります。デジタル署名検証アルゴリズムが1つしか存在しない場合、Apex Trustアンカー運用公開キーと一致する必要があります。1つのデジタル署名生成アルゴリズムのみが存在する場合、暗号化モジュールデジタルシグネチャプライベートキーと一致する必要があります。これらのアルゴリズムは、[RFC5652]で定義されているコンテンツタイプを含むTAMPメッセージの処理や、X.509認証パスの検証に使用できる必要があります。RFC 5280などの同様の仕様と同様に、この仕様は暗号化アルゴリズムのサポートを義務付けていません。ただし、アルゴリズムの要件は、TAMPを介して管理された信頼アンカーを使用する仕様によって課される場合があります。
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 各トラストアンカーストアには一意の名前が必要です。たとえば、単一のトラストアンカーストアを含む暗号化モジュールは、ファミリがASN.1オブジェクト識別子（OID）として表され、一意のシリアル番号として表される同じファミリ内の他のモジュールに関して一意のシリアル番号によって識別される場合があります。オクテットの文字列として表されます。一意の名前を確立する他の手段も可能です。
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 各トラストアンカーストアには、1つ以上のコミュニティ識別子を安全に保存する機能が必要です。コミュニティ識別子はOIDであり、単一のTAMPメッセージのターゲットまたは特定の管理メッセージの意図された受信者になる可能性のある暗号化モジュールのコレクションを識別します。
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 Trust Anchor Storeは、Apex Trust Anchorの使用をサポートする必要があります。Apexサポートが提供されている場合、Trust Anchor Storeは、1つのApex Trustアンカーの安全なストレージをサポートする必要があります。Trust Anchor Storeは、少なくとも1つの追加のトラストアンカーの安全なストレージをサポートする必要があります。各トラストアンカーには、一意の公開キーが含まれている必要があります。公開鍵は、トラストアンカーストアに複数回表示してはなりません。
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.
o Trust Anchor Storeには、TAMPメッセージを生成することが許可された各トラストアンカーのシーケンス番号を安全に保存し、トラストアンカーのキー識別子とともにシーケンス番号を報告できる機能が必要です。
TAMP processing MUST include the following capabilities:
TAMP処理には、次の機能を含める必要があります。
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.
o TAMP処理には、適切な信頼アンカーを見つける手段が必要です。2つのメカニズムが利用可能です。最初のメカニズムは、デジタル署名検証の公開キー識別子に基づいており、2番目のメカニズムは、証明書パスの発見と検証のためのトラストアンカーX.500の著名な名前およびその他のX.509認証パス制御に基づいています。最初のメカニズムをサポートする必要がありますが、2番目のメカニズムがサポートされる場合があります。
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処理は、信頼アンカーの安全なストレージに保持されている公開キーを使用して、デジタル署名検証アルゴリズムを呼び出すことができなければなりません。
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処理には、セクション6で説明されているように、各TAMPメッセージ署名者に関連付けられたシーケンス番号のセキュアストレージへの読み取りおよび書き込みアクセスが必要です。
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処理には、それらを更新するために、信頼アンカーのセキュアストレージへの読み取りおよび書き込みアクセスが必要です。更新操作には、トラストアンカーの追加、信頼のアンカーの削除、信頼のアンカーの変更が含まれます。セクション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 TAMP処理には、ターゲットメッセージを受け入れるべきかどうかを判断するために、コミュニティメンバーシップリストのセキュアストレージへの読み取りアクセスが必要です。
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 オプションのコミュニティ識別子更新機能を実装するには、TAMP処理には、コミュニティメンバーシップリストのセキュアストレージに読み取りおよび書き込みアクセスが必要です。
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 署名された確認メッセージを生成するには、TAMP処理が暗号化モジュールデジタル署名秘密鍵を使用してデジタル署名生成アルゴリズムを呼び出すことができなければならず、暗号化モジュール証明書またはその設計者に読み取る必要があります。TAMPはX.509証明書[RFC5280]を使用します。
o The TAMP processing MUST have read access to the trust anchor store unique name.
o TAMP処理には、Trust Anchor Storeユニークな名前への読み取りアクセスが必要です。
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.
TAMPで管理されているApex Trust Anchor and Management Trustアンカーは、TAMPアプリケーションで使用できます。他の管理アプリケーションは、3種類のトラストアンカーすべてを使用する場合がありますが、非管理アプリケーションはIDの信頼アンカーのみを使用する必要があります。アプリケーションは、信頼アンカーの使用が信頼アンカーに関連する制約と一致するようにする必要があります。たとえば、名前の制約が信頼アンカーに関連付けられている場合、信頼アンカーから始まり、名前の制約に違反する名前の証明書を含む認証パスを拒否する必要があります。
The application-specific protocol processing MUST be provided with 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 name and other X.509 certification path controls for certificate path discovery and validation.
アプリケーション固有のプロトコル処理は、次のサービスで提供する必要があります。oアプリケーション固有のプロトコル処理には、適切な信頼アンカーを見つける手段が必要です。アプリケーションでは2つのメカニズムが利用可能です。最初のメカニズムは、デジタル署名検証の公開キー識別子に基づいており、2番目のメカニズムは、証明書パスの発見と検証のためのトラストアンカーX.500の著名な名前およびその他のX.509認証パス制御に基づいています。
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 アプリケーション固有のプロトコル処理は、信頼できるアンカーの安全なストレージに保持されている公開キーを使用して、デジタル署名検証アルゴリズムを呼び出すことができなければなりません。
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 アプリケーション固有のプロトコル処理には、信頼アンカーに関連付けられたデータへの読み取りアクセスが必要で、制約を適切に施行できるようにする必要があります。たとえば、アプリケーションには、TAに関連付けられた名前の制約へのアクセスを読み取り、TAによって終了した認証パスには、TAマネージャーが指定された名前空間の外側のエンティティに発行された証明書が含まれていないことを確認する必要があります。
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 アプリケーション固有のプロトコル処理では、ターゲットメッセージを受け入れるべきかどうかを判断するために、コミュニティメンバーシップリストのセキュアストレージへの読み取りアクセスが必要です。
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 アプリケーション固有のプロトコルが確認メッセージまたは領収書にデジタル署名を必要とする場合、アプリケーション固有のプロトコル処理は、暗号モジュールデジタル署名プライベートキーとその関連証明書または証明書指定を使用して、デジタル署名生成アルゴリズムを呼び出すことができなければなりません。デジタル署名の生成は、署名された確認メッセージまたは領収書のコンテンツタイプがアプリケーション固有のプロトコル処理に適していることを保証する方法で制御する必要があります。
o The application-specific protocol processing MUST have read access to the trust anchor store unique name.
o アプリケーション固有のプロトコル処理には、Trust Anchor Storeユニークな名前への読み取りアクセスが必要です。
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.
CMSは、抽象的な構文表記1（asn.1）[x.680]を使用します。ASN.1は、実装で使用されるプログラミング言語に関係なく、データプロトコルの説明に使用される正式な表記です。エンコーディングルールは、asn.1で定義されている値が送信のためにどのように表されるかを説明しています。基本的なエンコーディングルール（BER）[X.690]は、最も広く採用されているルールセットですが、データ構造を表現するための複数の方法を提供します。たとえば、明確な長さのエンコーディングと無期限の長さのエンコードがサポートされています。この柔軟性は、デジタル署名を使用する場合、望ましくありません。その結果、著名なエンコードルール（der）[x.690]が発明されました。Derは、特定の値を表す単一の方法を保証するBERのサブセットです。たとえば、DERは常に明確な長さのエンコードを使用します。
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.
デジタル署名された構造は、derでエンコードする必要があります。他の仕様では、デジタルで署名されていない構造はderを必要としませんが、この仕様ではすべての構造にderが必要です。常にDERを使用することにより、TAMPプロセッサには実装するオプションが少なくなります。
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.
ASN.1は、このドキュメントのテキスト全体で説明するために使用されます。このドキュメントで定義されている構造のASN.1の権威あるソースは付録Aです。
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.
TAMPは、署名されたメッセージと署名されていないメッセージを使用します。暗号化メッセージ構文（CMS）は、両方の場合に使用されます。デジタル署名は、メッセージを検出されない変更から保護し、データ起源の認証を提供するために使用されます。TAMPは、コンテンツの暗号化の一般的な規定を作成しません。
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:
CMSは、署名されたTAMPメッセージの作成に使用されます。CMS ContentINFOコンテンツタイプは常に存在する必要があります。署名されたメッセージの場合、ContentInfoはCMS SignedDataコンテンツタイプをカプセル化する必要があります。署名されていないメッセージの場合、contentInfoはTAMPメッセージを直接カプセル化する必要があります。CMS SignedDataコンテンツタイプは、TAMPメッセージをカプセル化する必要があります。一意のコンテンツタイプ識別子は、特定のタイプのTAMPメッセージを識別します。署名されたTAMPメッセージのCMSカプセル化は、次のように要約されています。
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
}
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.
Apex Trustアンカーを更新するためにTAMPメッセージを使用すると、この同じ構造が使用されます。ただし、デジタル署名は、Apex Trust Anchor Operational Public KeyまたはContingency Public Keyのいずれかで検証されます。Contingencyの公開キーが使用されると、以前に保存されていたContingency Public Keyを復号化するために必要な対称キーが、Contingency-Public-Key-Key-Decrypt-Key Unsigned属性として提供されます。このドキュメントのセクション4.5では、Apex Trust Anchor Updateメッセージについて説明します。
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:
CMSは、署名されていないTAMPメッセージの作成にも使用されます。CMS contentinfo構造は常に存在する必要があり、カプセル化の最も外側の層でなければなりません。一意のコンテンツタイプ識別子は、特定のTAMPメッセージを識別します。署名されていないTAMPメッセージのCMSカプセル化は、次のように要約されています。
ContentInfo {
contentType OBJECT IDENTIFIER, -- Names TAMP message type
content OCTET STRING -- Contains TAMP message
}
CMS requires the outermost encapsulation to be ContentInfo [RFC5652]. The fields of ContentInfo are used as follows:
CMSでは、最も外側のカプセル化がcontentinfo [RFC5652]である必要があります。contentinfoのフィールドは次のように使用されます。
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 contentType関連コンテンツのタイプを示し、TAMPの場合、カプセル化されたタイプは署名されたtampメッセージに関連付けられたsignedDataまたはコンテンツタイプ識別子のいずれかです。ID-SignedData（1.2.840.113549.1.7.2）オブジェクト識別子がこのフィールドに存在する場合、署名されたTAMPメッセージがコンテンツにあります。それ以外の場合、署名されていないTAMPメッセージがコンテンツにあります。
o content holds the content, and for TAMP, the content is either a SignedData content or an unsigned TAMP message.
o コンテンツはコンテンツを保持し、TAMPの場合、コンテンツはSignedDataコンテンツまたは署名されていないTAMPメッセージのいずれかです。
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:
SignedDataコンテンツタイプ[RFC5652]には、署名されたTAMPメッセージとデジタル署名値が含まれています。SignedDataコンテンツタイプには、デジタル署名を検証するために必要な証明書も含まれている場合があります。SignedDataのフィールドは次のように使用されます。
o version is the syntax version number, and for TAMP, the version number MUST be set to 3.
o バージョンは構文バージョン番号であり、TAMPの場合、バージョン番号は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 Digestalgorithmsは一元配置ハッシュ関数識別子のコレクションであり、TAMPの場合、単一の一方向ハッシュ関数識別子が含まれています。デジタル署名を生成する際にTAMPメッセージオリジネーターによって使用される一方向ハッシュ関数が存在する必要があります。
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 EncapContentInfoは、コンテンツ型識別子とコンテンツ自体で構成される署名されたコンテンツです。concapsulatedContentINFOタイプの使用については、セクション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].
o 証明書は、オプションの証明書のコレクションです。省略されている場合があります。または、TAMPメッセージオリジネーターの認証パスを構築するために必要なX.509証明書が含まれている場合があります。Apex Trust AnchorまたはManagement Trust AnchorがTAMPメッセージデジタル署名を検証するために直接使用されるTrust Anchor Storeに送信されるTAMPメッセージの場合、このフィールドは省略する必要があります。Apex Trust AnchorまたはManagement Trust Anchorを使用してX.509認証パス[RFC5280]を検証し、認定パスの最終証明書の主題公開キーを使用してTAMPメッセージデジタル署名を検証するために使用される場合、TAMPメッセージオリジネーターを含める必要があり、認定パスの構築をサポートするための追加の証明書を含めることができます。Trust Anchor Storeから送信されたTAMPメッセージの場合、このフィールドには署名者の証明書のみを含めるか、省略する必要があります。TAMPメッセージ受信者は、デジタル署名を検証するために必要ではない証明書を含む有効なTAMPメッセージを拒否してはなりません。PKCS＃6拡張証明書[PKCS＃6]および属性証明書（バージョン1またはバージョン2）[RFC5755]は、証明書のセットに含めてはなりません。これらの証明書形式はTAMPでは使用されません。認証機関（CA）証明書およびエンティティ証明書は、[RFC5280]で定義されているプロファイルに準拠する必要があります。
o crls is an OPTIONAL collection of certificate revocation lists (CRLs).
o CRLSは、証明書取消リスト（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.
o SignerInfosは署名者ごとの情報のコレクションであり、TAMPの場合、コレクションには正確に1つのSignerinfoが含まれている必要があります。SignerINFOタイプの使用については、セクション2.2.1でさらに説明します。
The TAMP message originator is represented in the SignerInfo type. The fields of SignerInfo are used as follows:
TAMPメッセージのオリジネーターは、Signerinfoタイプで表されます。Signerinfoのフィールドは次のように使用されます。
o version is the syntax version number. With TAMP, the version MUST be set to 3.
o バージョンは構文バージョン番号です。TAMPを使用すると、バージョンを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 SIDは、TAMPメッセージオリジネーターの公開キーを識別します。SubjectKeyIdentifierの代替手段は常にTAMPで使用され、公開キーを直接識別します。公開キーがTrustanchorinInfoオブジェクトに含まれている場合、この識別子はKeyIDフィールドに含まれています。公開キーが証明書またはTBSCertificateに含まれている場合、この識別子はsubjectKeyidentifier証明書拡張に含まれています。
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 Digestalgorithmは、TAMPメッセージオリジネーターが使用する一元配置ハッシュ関数と、関連するパラメーターを識別します。オリジネーターが使用する一方向ハッシュ関数を含める必要があります。このメッセージダイジェストアルゴリズム識別子は、signedDataの消化器gorthmsフィールドで運ばれたものと一致する必要があります。メッセージダイジェストアルゴリズム識別子は、受信機によるストリーム処理を促進するために2つの場所で運ばれます。
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 SigneDattrsは、コンテンツとともに署名されたオプションの属性セットです。SigneDattrsはCMSではオプションですが、SigneDattrsはすべての署名されたTAMPメッセージに必要です。属性のセットは、識別式エンコードルール（der）[x.690]でエンコードする必要があります。このドキュメントのセクション2.2.3には、コレクションに含める必要がある署名された属性をリストします。その他の署名属性を含めることもできますが、認識されていない署名属性は無視する必要があります。
o signatureAlgorithm identifies the digital signature algorithm, and any associated parameters, used by the TAMP message originator to generate the digital signature.
o SignAtureAlgorithmは、デジタル署名アルゴリズムと、デジタル署名を生成するためにTAMPメッセージオリジネーターが使用する関連するパラメーターを識別します。
o signature is the digital signature value generated by the TAMP message originator.
o 署名は、TAMPメッセージオリジネーターによって生成されたデジタル署名値です。
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.
o Unsignedattrsは、署名されていないオプションの属性セットです。TAMPの場合、このフィールドは通常省略されています。Apex Trust Anchor Anchor Anchor Contingency公開キーを使用して検証されるApex Trust Anchor Updateメッセージにのみ存在します。この場合、属性のセットには、偶発的パブリックキーデクリプトキーの符号なし属性の偶発事象の公開キーを解読するために必要な対称キーを含める必要があります。このドキュメントのセクション2.2.4では、この署名されていない属性について説明します。
The EncapsulatedContentInfo structure contains the TAMP message. The fields of EncapsulatedContentInfo are used as follows:
cancopturatedContentInfo構造には、TAMPメッセージが含まれています。capsulatedContentInfoのフィールドは次のように使用されます。
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 EcontentTypeは、コンテンツタイプを一意に指定するオブジェクト識別子であり、TAMPの場合、値はTAMPメッセージを識別します。TAMPメッセージコンテンツタイプのリストは、セクション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.
o econtentは、オクテット弦としてエンコードされたタンプメッセージです。一般に、CMSは、オクテット弦を構築する前に、econtentをderエンコードする必要はありません。ただし、TAMPメッセージはder-Encodedを使用する必要があります。
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].
TAMPメッセージのオリジネーターは、TAMPメッセージとともに属性のコレクションにデジタル的に署名する必要があります。コレクション内の各属性は、der-Encodedでなければなりません。属性の構文は[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.
このCMSプロファイルで使用される各属性には、単一の属性値があります。構文は属性のセットとして定義されていますが、属性の存在の1つのインスタンスが正確に1つある必要があります。
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.
SignerInfo内のSigneDattributes構文は、属性のセットとして定義されます。SigneDattributesには、特定の属性の1つのインスタンスのみを含める必要があります。この規則に違反するTAMPメッセージは、奇形として拒否されなければなりません。
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.
TAMPメッセージのオリジネーターには、コンテンツタイプとメッセージダイジスト属性を含める必要があります。TAMPメッセージのオリジネーターには、バイナリ署名時間属性も含まれる場合があります。
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.
TAMPメッセージのオリジネーターには、適切と思われる他の属性が含まれる場合があります。意図は、将来のニーズが特定された場合、追加の署名属性を含めることを許可することです。認識されていない署名された属性を無視する必要があるため、これは相互運用性の懸念を引き起こしません。
The following summarizes the signed attribute requirements for TAMP messages:
以下は、TAMPメッセージの署名された属性要件をまとめたものです。
o content-type MUST be supported.
o コンテンツタイプをサポートする必要があります。
o message-digest MUST be supported.
o メッセージダイジェストをサポートする必要があります。
o binary-signing-time MAY be supported. When present, it is generally ignored by the recipient.
o バイナリ署名時間がサポートされる場合があります。存在する場合、それは一般に受信者によって無視されます。
o other attributes MAY be supported. Unrecognized attributes MUST be ignored by the recipient.
o 他の属性がサポートされる場合があります。認識されていない属性は、受信者が無視する必要があります。
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.
TAMPメッセージオリジネーターには、コンテンツタイプの属性を含める必要があります。これは、コンテンツタイプを一意に指定するオブジェクト識別子です。[RFC5652]のセクション11.1は、コンテンツタイプの属性を定義します。TAMPの場合、値はTAMPメッセージを識別します。TAMPメッセージコンテンツタイプとその識別子のリストは、セクション4に記載されています。
A content-type attribute MUST contain the same object identifier as the content type contained in the EncapsulatedContentInfo.
コンテンツタイプの属性には、capsulatedContentInfoに含まれるコンテンツタイプと同じオブジェクト識別子を含める必要があります。
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.
TAMPメッセージのオリジネーターには、署名されているTAMPメッセージに計算された一方向ハッシュ関数の出力をその値として、メッセージダイジェスト属性を含める必要があります。[RFC5652]のセクション11.2は、メッセージダイジスト属性を定義しています。
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].
TAMPメッセージのオリジネーターには、バイナリ署名時間属性が含まれている場合があり、デジタル署名がTAMPメッセージに適用される時間を指定します。バイナリ署名時間属性は[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.
TAMPメッセージ受信者には、バイナリ署名時間属性の処理は必要ありません。ただし、TAMPメッセージのオリジネーターは、メッセージ識別子の形式として、バイナリシグメントタイム属性を含めることができます。
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.
TAMPの場合、通常、署名されていない属性は省略されます。署名されていない属性は、Apex Trust Anchor Anchor Contingency Public Keyによって検証されるApex Trust Anchor Updateメッセージにのみ存在します。この場合、以前の偶発事象の公開キーを復号化する対称キーは、Contingency-Public-Key-Key-Decrypt-Key Unsigned属性に提供されます。この属性はサポートする必要があり、セクション2.2.4.1で説明します。
The TAMP message originator SHOULD NOT include other unsigned attributes, and any unrecognized unsigned attributes MUST be ignored.
TAMPメッセージのオリジネーターには、他の署名されていない属性を含めるべきではなく、認識されていない符号なしの属性を無視する必要があります。
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.
SignerInfo内のunsignedattributes構文は、属性のセットとして定義されます。unsignedattributesには、特定の属性の1つのインスタンスのみを含める必要があります。この規則に違反するTAMPメッセージは、奇形として拒否されなければなりません。
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.
Contingency-Public-Key-Key-Decrypt-Key属性は、以前に分散したApex Trust Anchor Contingency Public Keyを解読するために必要なプレーンテキスト対称キーを提供します。対称キーは、以前に緊急時の公開キーを暗号化するために使用される対称アルゴリズムで使用できる必要があります。
The contingency-public-key-decrypt-key attribute has the following syntax:
Contingency-Public-Key-Key-Decrypt-Key属性には、次の構文があります。
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
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.
TAMPは、プロトコル自体内で信頼できるアンカー情報を表すための3つの形式を認識します：証明書[RFC5280]、TBSCertificate [RFC5280]、およびTrustanchoriNFO [RFC5914]。[RFC5914]で定義されているTrustanchorchoice構造は、これらのオプションのいずれかを選択するために使用されます。
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.
証明書構造は、一般に信頼のアンカーを表すために使用されます。証明書には署名が含まれます。これには、構造自体内の情報をカスタマイズする当事者に依存する能力が削除されます。TBSCertificateには、署名を除く証明書構造のすべての情報が含まれており、情報の調整を可能にします。Trustanchorinfoは、ストレージまたは帯域幅が非常に制約されているシナリオの信頼アンカー情報のミニマリストの表現として機能することを目的としています。
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.
3つのオプションすべてをサポートするために実装は必要ありません。サポートされていないトラストアンカー形式の受領により、タンパーラーを生成するときに、サポートされていないストラスタンチャーフォーモットエラーコードを示す必要があります。
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は、署名されたメッセージと署名されていないメッセージを使用します。CMSはどちらの場合も使用されます。オブジェクト識別子は各TAMPメッセージタイプに割り当てられ、このオブジェクト識別子は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.
TAMPは11のメッセージタイプを指定します。以下は、各TAMPメッセージタイプのコンテンツタイプ識別子を提供し、デジタル署名が必要かどうかを示します。以下がTAMPメッセージに署名する必要があることを示している場合、実装は署名されていないタイプのメッセージを拒否する必要があります。
o The TAMP Status Query message MUST be signed. It uses the following object identifier: { id-tamp 1 }.
o TAMPステータスクエリメッセージに署名する必要があります。次のオブジェクト識別子を使用します：{id-tamp 1}。
o The TAMP Status Response message SHOULD be signed. It uses the following object identifier: { id-tamp 2 }.
o TAMPステータス応答メッセージに署名する必要があります。次のオブジェクト識別子を使用します：{id-tamp 2}。
o The Trust Anchor Update message MUST be signed. It uses the following object identifier: { id-tamp 3 }.
o Trust Anchor Updateメッセージに署名する必要があります。次のオブジェクト識別子を使用します：{id-tamp 3}。
o The Trust Anchor Update Confirm message SHOULD be signed. It uses the following object identifier: { id-tamp 4 }.
o Trust Anchor Updateの確認メッセージに署名する必要があります。次のオブジェクト識別子を使用します：{id-tamp 4}。
o The Apex Trust Anchor Update message MUST be signed. It uses the following object identifier: { id-tamp 5 }.
o Apex Trustアンカー更新メッセージに署名する必要があります。次のオブジェクト識別子を使用します：{id-tamp 5}。
o The Apex Trust Anchor Update Confirm message SHOULD be signed. It uses the following object identifier: { id-tamp 6 }.
o Apex Trustアンカーアップデートにメッセージに署名する必要があります。次のオブジェクト識別子を使用します：{id-tamp 6}。
o The Community Update message MUST be signed. It uses the following object identifier: { id-tamp 7 }.
o コミュニティの更新メッセージに署名する必要があります。次のオブジェクト識別子を使用します：{id-tamp 7}。
o The Community Update Confirm message SHOULD be signed. It uses the following object identifier: { id-tamp 8 }.
o コミュニティの更新にメッセージに署名する必要があることが確認されています。次のオブジェクト識別子を使用します：{id-tamp 8}。
o The Sequence Number Adjust MUST be signed. It uses the following object identifier: { id-tamp 10 }.
o シーケンス番号調整に署名する必要があります。次のオブジェクト識別子を使用します：{id-tamp 10}。
o The Sequence Number Adjust Confirm message SHOULD be signed. It uses the following object identifier: { id-tamp 11 }.
o シーケンス番号の調整確認メッセージに署名する必要があります。次のオブジェクト識別子を使用します：{id-tamp 11}。
o The TAMP Error message SHOULD be signed. It uses the following object identifier: { id-tamp 9 }.
o TAMPエラーメッセージに署名する必要があります。次のオブジェクト識別子を使用します：{id-tamp 9}。
Trust anchor managers generate TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update, Community Update, and Sequence Number Adjust messages. Trust anchor stores generate TAMP Status Response, Trust Anchor Update Confirm, Apex Trust Anchor Update Confirm, Community Update Confirm, Sequence Number Adjust Confirm, and TAMP Error messages.
Trust Anchor Managersは、TAMPステータスクエリ、信頼アンカーの更新、Apex Trust Anchor Update、Community Update、Sequence番号調整メッセージを生成します。Trust AnchorストアはTAMPステータス応答を生成し、Apex Trustアンカーアップデート確認、コミュニティの更新確認、シーケンス番号の調整確認、およびTAMPエラーメッセージを生成します。
Support for Trust Anchor Update messages is REQUIRED. Support for all other message formats is RECOMMENDED. Implementations that support the HTTP binding described in Appendix C MUST additionally support Trust Anchor Update Confirm and TAMP Error messages and MAY support 0 or more of the following pairs of messages: TAMP Status Query and TAMP Status Query Response; Apex Trust Anchor Update and Apex Trust Anchor Update Confirm; Community Update and Community Update Confirm; Sequence Number Adjust and Sequence Number Adjust Confirm. Implementations that operate in a disconnected manner MUST NOT assume a response will be received from each consumer of a TAMP message.
トラストアンカー更新メッセージのサポートが必要です。他のすべてのメッセージ形式のサポートをお勧めします。付録Cで説明したHTTPバインディングをサポートする実装は、さらに信頼のアンカー更新確認とTAMPエラーメッセージをサポートする必要があり、次のペアのメッセージの0以上をサポートする必要があります。TAMPステータスクエリとTAMPステータスクエリ応答。Apex Trust Anchor UpdateおよびApex Trust Anchor Updateの確認。コミュニティの更新とコミュニティの更新確認。シーケンス番号調整とシーケンス番号調整確認確認。切断された方法で動作する実装は、TAMPメッセージの各消費者から応答が受信されると仮定してはなりません。
A typical interaction between a trust anchor manager and a trust anchor store will follow the message flow shown in Figure 1. Figure 1 does not illustrate a flow where an error occurs.
Trust Anchor ManagerとTrust Anchor Storeの典型的な相互作用は、図1に示すメッセージフローに従います。図1は、エラーが発生するフローを示していません。
+---------+ +----------+
| | Trust Anchor Status Query | |
| |------------------------------->| |
| | | |
| | Trust Anchor Status Response | |
| Trust |<-------------------------------| Trust |
| Anchor | | Anchor |
| Manager | Trust Anchor Update | Store |
| |------------------------------->| |
| | | |
| | Trust Anchor Update Confirm | |
| |<-------------------------------| |
| | | |
+---------+ +----------+
Figure 1. Typical TAMP Message Flow
図1.典型的なTAMPメッセージフロー
Each TAMP query and update message includes an indication of the type of response that is desired. The response can either be terse or verbose. All trust anchor stores MUST support both the terse and verbose responses and SHOULD generate a response of the type indicated in the corresponding request. TAMP response processors MUST support processing of both terse and verbose responses.
各TAMPクエリと更新メッセージには、必要な応答のタイプの表示が含まれています。応答は、簡潔または冗長である可能性があります。すべてのトラストアンカーストアは、簡潔な応答と冗長応答の両方をサポートする必要があり、対応するリクエストに示されているタイプの応答を生成する必要があります。TAMP応答プロセッサは、簡潔な応答と冗長応答の両方の処理をサポートする必要があります。
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.
Trust Anchorストアは、TAMPステータスクエリメッセージ、Trust Anchor Updateメッセージ、Apex Trust Anchor Updateメッセージ、およびシーケンス番号を調整するメッセージの有効なペイロードを処理し、適切に機能させることができます。TAMPの実装は、コミュニティ更新メッセージの有効なペイロードに合わせて処理および行動する場合があります。
TAMP implementations SHOULD support generation of the TAMP Status Response message, the Trust Anchor Update Confirm message, the Apex Trust Anchor Update Confirm message, the Sequence Number Adjust Confirm message, and the TAMP Error message. If a TAMP implementation supports the Community Update message, then generation of Community Update Confirm messages SHOULD also be supported.
TAMP実装では、TAMPステータス応答メッセージの生成、Trust Anchor Updateの確認メッセージ、Apex Trust Anchor Updateの確認メッセージ、シーケンス番号が確認メッセージ、TAMPエラーメッセージが調整されます。TAMP実装がコミュニティの更新メッセージをサポートする場合、コミュニティアップデートの生成確認メッセージもサポートする必要があります。
The TAMP Status Query message is used to request information about the trust anchors that are currently installed in a trust anchor store, and for the list of communities to which the store belongs. The TAMP Status Query message MUST be signed. For the query message to be valid, the trust anchor store MUST be an intended recipient of the query; the sequence number checking described in Section 6 MUST be successful when the TAMP message signer is a trust anchor; and the digital signature MUST be validated by the apex trust anchor operational public key, an authorized management trust anchor, or via an authorized X.509 certification path originating with such a trust anchor.
TAMPステータスクエリメッセージは、現在トラストアンカーストアにインストールされている信頼アンカーに関する情報を要求し、ストアが属するコミュニティのリストに使用されます。TAMPステータスクエリメッセージに署名する必要があります。クエリメッセージが有効であるためには、トラストアンカーストアはクエリの意図された受信者でなければなりません。セクション6で説明されているシーケンス番号チェックは、TAMPメッセージ署名者が信頼のアンカーである場合、成功する必要があります。また、デジタル署名は、Apex Trustアンカー運用公開キー、認定管理トラストアンカーによって検証されるか、そのような信頼アンカーを介した承認されたX.509認定パスを介して検証する必要があります。
If the digital signature on the TAMP Status Query message is valid, sequence number checking is successful, the signer is authorized, and the trust anchor store is an intended recipient of the TAMP message, then a TAMP Status Response message SHOULD be returned. If a TAMP Status Response message is not returned, then a TAMP Error message SHOULD be returned.
TAMPステータスクエリメッセージのデジタル署名が有効である場合、シーケンス番号チェックが成功し、署名者が承認され、Trust Anchor StoreはTAMPメッセージの受信者である場合、TAMPステータス応答メッセージを返す必要があります。TAMPステータス応答メッセージが返されない場合、TAMPエラーメッセージを返す必要があります。
The TAMP Status Query content type has the following syntax:
TAMPステータスクエリコンテンツタイプには、次の構文があります。
CONTENT-TYPE ::= TYPE-IDENTIFIER
tamp-status-query CONTENT-TYPE ::=
{ TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery }
id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 }
TAMPStatusQuery ::= SEQUENCE {
Version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
query TAMPMsgRef }
TAMPVersion ::= INTEGER { v1(1), v2(2) }
TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) }
TAMPMsgRef ::= SEQUENCE {
target TargetIdentifier,
seqNum SeqNumber }
SeqNumber ::= INTEGER (0..9223372036854775807)
TargetIdentifier ::= CHOICE {
hwModules [1] HardwareModuleIdentifierList,
communities [2] CommunityIdentifierList,
allModules [3] NULL,
uri [4] IA5String,
otherName [5] AnotherName }
HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF
HardwareModules
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry }
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:
Tampstatusqueryのフィールドは次のように使用されます。
o version identifies version of TAMP. For this version of the specification, the default value, v2, MUST be used.
o バージョンはTAMPのバージョンを識別します。このバージョンの仕様では、デフォルト値V2を使用する必要があります。
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 Terseは、必要な応答のタイプを示します。簡潔な応答は1の値で示され、冗長応答は2の値で示されます。これは、デフォルト値であるため、エンコード中に省略されます。
o query contains two items: the target and the seqNum. target identifies the target(s) of the query message. seqNum is a single-use value that will be used to match the TAMP Status Query message with the TAMP Status Response message. The sequence number is also used to detect TAMP message replay. The sequence number processing described in Section 6 MUST successfully complete before a response is returned.
o クエリには、ターゲットとSeqnumの2つの項目が含まれています。ターゲットは、クエリメッセージのターゲットを識別します。Seqnumは、TAMPステータスクエリメッセージとTAMPステータス応答メッセージを一致させるために使用される一連の使用値です。シーケンス番号は、TAMPメッセージリプレイの検出にも使用されます。セクション6で説明されているシーケンス番号処理は、応答が返される前に正常に完了する必要があります。
The fields of TAMPMsgRef are used as follows:
Tampmsgrefのフィールドは次のように使用されます。
o target identifies the target(s) of the query. Several alternatives for naming a target are provided. To identify a cryptographic module, a combination of a cryptographic type and serial number are used. The cryptographic type is represented as an ASN.1 object identifier, and the unique serial number is represented as a string of octets. To facilitate compact representation of serial numbers, a contiguous block can be specified by the lowest included serial number and the highest included serial number. When present, the high and low octet strings MUST have the same length. The HardwareModuleIdentifierList sequence MUST NOT contain duplicate hwType values, so that each member of the sequence names all of the cryptographic modules of this type. Object identifiers are also used to identify communities of trust anchor stores. A sequence of these object identifiers is used if more than one community is the target of the message. A trust anchor store is considered a target if it is a member of any of the listed communities. An explicit NULL value is used to identify all modules that consider the signer of the TAMP message to be an authorized source for that message type. The uri field can be used to identify a target, i.e., a trust anchor store, using a Uniform Resource Identifier [RFC3986]. Additional name types are supported via the otherName field, which is of type AnotherName. AnotherName is defined in [RFC5280]. The format and semantics of the name are indicated through the OBJECT IDENTIFIER in the type-id field. The name itself is conveyed as a value field in otherName. Implementations MUST support the allModules option and SHOULD support all TargetIdentifier options.
o ターゲットは、クエリのターゲットを識別します。ターゲットを命名するためのいくつかの代替案が提供されます。暗号化モジュールを識別するために、暗号化タイプとシリアル番号の組み合わせが使用されます。暗号化タイプはASN.1オブジェクト識別子として表され、一意のシリアル番号はオクテットの文字列として表されます。シリアル番号のコンパクトな表現を容易にするために、隣接するブロックを最低のシリアル番号と最高のシリアル番号で指定できます。存在する場合、高および低オクテットの弦は同じ長さでなければなりません。hardwaremoduleidentifierlistシーケンスには、このタイプのすべての暗号化モジュールのすべてのシーケンス名に名前が付けられるように、重複したhwtype値を含めてはなりません。オブジェクト識別子は、トラストアンカーストアのコミュニティを識別するためにも使用されます。複数のコミュニティがメッセージのターゲットである場合、これらのオブジェクト識別子のシーケンスが使用されます。Trust Anchor Storeは、リストされているコミュニティのメンバーである場合、ターゲットと見なされます。明示的なヌル値は、TAMPメッセージの署名者がそのメッセージタイプの承認されたソースであると考えるすべてのモジュールを識別するために使用されます。URIフィールドは、標的、つまり、均一なリソース識別子[RFC3986]を使用して、ターゲット、つまりトラストアンカーストアを識別するために使用できます。追加の名前のタイプは、別の型のフィールドを介してサポートされています。別の名前は[RFC5280]で定義されています。名前の形式とセマンティクスは、Type-IDフィールドのオブジェクト識別子を介して示されています。名前自体は、他の名前の値フィールドとして伝えられます。実装は、Allmodulesオプションをサポートする必要があり、すべてのターゲットIdentifierオプションをサポートする必要があります。
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.
o Seqnumには、TAMPステータスクエリメッセージをTAMPステータス応答メッセージの成功と一致させるために使用される単一使用値が含まれています。セクション6で説明されているシーケンス番号処理は、応答が返される前に正常に完了する必要があります。
To determine whether a particular cryptographic module serial number is considered part of a specified block, all of the following conditions MUST be met. First, the cryptographic module serial number MUST be the same length as both the high and low octet strings. Second, the cryptographic module serial number MUST be greater than or equal to the low octet string. Third, the cryptographic module serial number MUST be less than or equal to the high octet string.
特定の暗号モジュールシリアル番号が指定されたブロックの一部と見なされるかどうかを判断するには、次のすべての条件を満たす必要があります。まず、暗号化モジュールのシリアル番号は、ハイオクテット文字列と低い弦の両方と同じ長さでなければなりません。第二に、暗号化モジュールのシリアル番号は、低オクテット文字列以上でなければなりません。第三に、暗号化モジュールのシリアル番号は、高オクテット文字列以下でなければなりません。
One octet string is equal to another if they are of the same length and are the same at each octet position. An octet string, S1, is greater than another, S2, where S1 and S2 have the same length, if and only if S1 and S2 have different octets in one or more positions, and in the first such position, the octet in S1 is greater than that in S2, considering the octets as unsigned binary numbers. Note that these octet string comparison definitions are consistent with those in clause 6 of [X.690].
1つのオクテットストリングは、同じ長さであり、各オクテットの位置で同じ場合、別のオクテット弦と等しくなります。Octet String、S1は別のS2より大きく、S1とS2の長さは同じ長さです。S1とS2が1つ以上の位置で異なるオクテットを持っている場合にのみ、最初のそのような位置では、S1のオクテットはオクテットを符号なしのバイナリ番号と考えると、S2のそれよりも大きい。これらのオクテット文字列の比較定義は、[X.690]の条項6のものと一致していることに注意してください。
The TAMP Status Response message is a reply by a trust anchor store to a valid TAMP Status Query message. The TAMP Status Response message provides information about the trust anchors that are currently installed in the trust anchor store and the list of communities to which the trust anchor store belongs, if any. The TAMP Status Response message MAY be signed or unsigned. A TAMP Status Response message MUST be signed if the implementation is capable of signing it.
TAMPステータス応答メッセージは、有効なTAMPステータスクエリメッセージに対するTrustアンカーストアによる返信です。TAMPステータス応答メッセージは、現在トラストアンカーストアにインストールされている信頼アンカーと、トラストアンカーストアが属するコミュニティのリストを提供します。TAMPステータス応答メッセージに署名または署名されている場合があります。実装が署名できる場合は、TAMPステータス応答メッセージに署名する必要があります。
The TAMP Status Response content type has the following syntax:
TAMPステータス応答コンテンツタイプには、次の構文があります。
tamp-status-response CONTENT-TYPE ::=
{ TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse }
id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 }
TAMPStatusResponse ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
query TAMPMsgRef,
response StatusResponse,
usesApex BOOLEAN DEFAULT TRUE }
StatusResponse ::= CHOICE {
terseResponse [0] TerseStatusResponse,
verboseResponse [1] VerboseStatusResponse }
TerseStatusResponse ::= SEQUENCE {
taKeyIds KeyIdentifiers,
communities CommunityIdentifierList OPTIONAL }
KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier
VerboseStatusResponse ::= SEQUENCE {
taInfo TrustAnchorChoiceList,
continPubKeyDecryptAlg [0] AlgorithmIdentifier OPTIONAL,
communities [1] CommunityIdentifierList OPTIONAL,
tampSeqNumbers [2] TAMPSequenceNumbers OPTIONAL }
TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF
TrustAnchorChoice
TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF TAMPSequenceNumber
TAMPSequenceNumber ::= SEQUENCE {
keyId KeyIdentifier,
seqNumber SeqNumber }
The fields of TAMPStatusResponse are used as follows:
TampStatusResponseのフィールドは、次のように使用されます。
o version identifies version of TAMP. For this version of the specification, the default value, v2, MUST be used.
o バージョンはTAMPのバージョンを識別します。このバージョンの仕様では、デフォルト値V2を使用する必要があります。
o query identifies the TAMPStatusQuery to which the trust anchor store is responding. The query structure repeats the TAMPMsgRef from the TAMP Status Query message (see Section 4.1). The sequence number processing described in Section 6 MUST successfully complete before any response is returned.
o クエリは、Trust Anchor Storeが応答しているTampstatusqueryを特定します。クエリ構造は、TAMPステータスクエリメッセージからTampmsgrefを繰り返します（セクション4.1を参照）。セクション6で説明されているシーケンス番号処理は、応答が返される前に正常に完了する必要があります。
o response contains either a terse response or a verbose response. The terse response is represented by TerseStatusResponse, and the verbose response is represented by VerboseStatusResponse.
o 応答には、簡潔な応答または冗長応答のいずれかが含まれます。Terse応答はTersestatusResponseで表され、冗長応答はVerboseStatusResponseで表されます。
o usesApex is a Boolean value that indicates whether the first item in the TerseStatusResponse.taKeyIds or VerboseStatusResponse.taInfo field identifies the apex TA.
o useSapexは、tersestatusResponse.takeyidsまたはverbosestatusResponse.tainfoフィールドの最初の項目が頂点taを識別するかどうかを示すブール値です。
The fields of TerseStatusResponse are used as follows:
tersestatusResponseのフィールドは、次のように使用されます。
o taKeyIds contains a sequence of key identifiers. Each trust anchor contained in the trust anchor store is represented by one key identifier. When TAMPStatusResponse.usesApex is TRUE, the apex trust anchor is represented by the first key identifier in the sequence, which contains the key identifier of the operational public key.
o Takeyidsには、キー識別子のシーケンスが含まれています。トラストアンカーストアに含まれる各トラストアンカーは、1つのキー識別子で表されます。tampstatusResponse.USESAPEXが真である場合、Apex Trustアンカーは、運用公開キーのキー識別子を含むシーケンスの最初のキー識別子で表されます。
o communities is OPTIONAL. When present, it contains a sequence of object identifiers. Each object identifier names one community to which this trust anchor store belongs. When the trust anchor store belongs to no communities, this field is omitted.
o コミュニティはオプションです。存在する場合、オブジェクト識別子のシーケンスが含まれます。各オブジェクト識別子は、このトラストアンカーストアが属する1つのコミュニティに名前を付けます。Trust Anchor Storeがコミュニティのないものに属している場合、このフィールドは省略されています。
The fields of VerboseStatusResponse are used as follows:
VerboseStatusResponseのフィールドは、次のように使用されます。
o taInfo contains a sequence of TrustAnchorChoice structures. One entry in the sequence is provided for each trust anchor contained in the trust anchor store. When TAMPStatusResponse.usesApex is TRUE, the apex trust anchor is the first trust anchor in the sequence.
o Tainfoには、Trustanchorchoice構造のシーケンスが含まれています。シーケンス内の1つのエントリは、トラストアンカーストアに含まれる各トラストアンカーに提供されます。tampstatusResponse.usesapexが真である場合、Apex Trustアンカーはシーケンスの最初の信頼アンカーです。
o continPubKeyDecryptAlg is OPTIONAL. When present, it indicates the decryption algorithm needed to decrypt the currently installed apex trust anchor contingency public key, if a contingency key is associated with the apex trust anchor. When present, TAMPStatusResponse.usesApex MUST be TRUE.
o continupubkeydecryptalgはオプションです。存在する場合、Apex Trustアンカーに関連付けられている場合、現在インストールされているApex Trust Anchor Contingency Public Keyを復号化するために必要な復号化アルゴリズムを示します。存在する場合、tampstatusresponse.usesapexである必要があります。
o communities is OPTIONAL. When present, it contains a sequence of object identifiers. Each object identifier names one community to which this trust anchor store belongs. When the trust anchor store belongs to no communities, this field is omitted.
o コミュニティはオプションです。存在する場合、オブジェクト識別子のシーケンスが含まれます。各オブジェクト識別子は、このトラストアンカーストアが属する1つのコミュニティに名前を付けます。Trust Anchor Storeがコミュニティのないものに属している場合、このフィールドは省略されています。
o tampSeqNumbers is OPTIONAL. When present, it is used to indicate the currently held sequence number for each trust anchor authorized to sign TAMP messages. The keyId field identifies the trust anchor, and the seqNumber field provides the current sequence number associated with the trust anchor.
o tampseqnumbersはオプションです。存在する場合、TAMPメッセージに署名することを許可された各トラストアンカーの現在保持されているシーケンス番号を示すために使用されます。KeyIDフィールドは信頼アンカーを識別し、SeqNumberフィールドはTrust Anchorに関連付けられた現在のシーケンス番号を提供します。
The Trust Anchor Update message is used to add, remove, and change management and identity trust anchors. The Trust Anchor Update message cannot be used to update the apex trust anchor. The Trust Anchor Update message MUST be signed. For a Trust Anchor Update message to be valid, the trust anchor store MUST be an intended recipient of the update; the sequence number checking described in Section 6 MUST be successful when the TAMP message signer is a trust anchor; and the digital signature MUST be validated using the apex trust anchor operational public key, an authorized management trust anchor, or via an authorized X.509 certification path originating with such a trust anchor.
Trust Anchor Updateメッセージは、管理およびIDの信頼のアンカーを追加、削除、およびIdentityの変更に使用します。Trust Anchor Updateメッセージを使用してApex Trust Anchorを更新することはできません。Trust Anchor Updateメッセージに署名する必要があります。Trust Anchor Updateメッセージが有効であるためには、Trust Anchor Storeが更新の意図された受信者でなければなりません。セクション6で説明されているシーケンス番号チェックは、TAMPメッセージ署名者が信頼のアンカーである場合、成功する必要があります。また、デジタル署名は、Apex Trustアンカー運用公開キー、認定管理トラストアンカーを使用して、またはそのような信頼アンカーを備えた承認されたX.509認定パスを使用して検証する必要があります。
If the digital signature on the Trust Anchor Update message is valid, sequence number checking is successful, the signer is authorized, and the trust anchor store is an intended recipient of the TAMP message, then the trust anchor store MUST perform the specified updates and return a Trust Anchor Update Confirm message. If a Trust Anchor Update Confirm message is not returned, then a TAMP Error message SHOULD be returned.
トラストアンカー更新メッセージのデジタル署名が有効である場合、シーケンス番号チェックが成功し、署名者が承認され、トラストアンカーストアはTAMPメッセージの意図された受信者である場合、Trust Anchor Storeは指定された更新を実行して返送する必要があります。トラストアンカーアップデートはメッセージを確認します。Trust Anchor Updateの確認メッセージが返されない場合、TAMPエラーメッセージを返す必要があります。
The Trust Anchor Update content type has the following syntax:
Trust Anchor Updateコンテンツタイプには、次の構文があります。
tamp-update CONTENT-TYPE ::=
{ TAMPUpdate IDENTIFIED BY id-ct-TAMP-update }
id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 }
TAMPUpdate ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
msgRef TAMPMsgRef,
updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate,
tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL }
TrustAnchorUpdate ::= CHOICE {
add [1] TrustAnchorChoice,
remove [2] SubjectPublicKeyInfo,
change [3] EXPLICIT TrustAnchorChangeInfoChoice }
TrustAnchorChangeInfoChoice ::= CHOICE {
tbsCertChange [0] TBSCertificateChangeInfo,
taChange [1] TrustAnchorChangeInfo }
TBSCertificateChangeInfo ::= SEQUENCE {
serialNumber CertificateSerialNumber OPTIONAL,
signature [0] AlgorithmIdentifier OPTIONAL,
issuer [1] Name OPTIONAL,
validity [2] Validity OPTIONAL,
subject [3] Name OPTIONAL,
subjectPublicKeyInfo [4] SubjectPublicKeyInfo,
exts [5] EXPLICIT Extensions OPTIONAL }
TrustAnchorChangeInfo ::= SEQUENCE {
pubKey SubjectPublicKeyInfo,
keyId KeyIdentifier OPTIONAL,
taTitle TrustAnchorTitle OPTIONAL,
certPath CertPathControls OPTIONAL,
exts [1] Extensions OPTIONAL }
The fields of TAMPUpdate are used as follows:
Tampupdateのフィールドは次のように使用されます。
o version identifies version of TAMP. For this version of the specification, the default value, v2, MUST be used.
o バージョンはTAMPのバージョンを識別します。このバージョンの仕様では、デフォルト値V2を使用する必要があります。
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 Terseは、必要な応答のタイプを示します。簡潔な応答は1の値で示され、冗長応答は2の値で示されます。これは、デフォルト値であるため、エンコード中に省略されます。
o msgRef contains two items: the target and the seqNum. target identifies the target(s) of the update message. The TargetIdentifier syntax is described in Section 4.1. seqNum is a single-use value that will be used to match the Trust Anchor Update message with the Trust Anchor Update Confirm message. The sequence number is also used to detect TAMP message replay. The sequence number processing described in Section 6 MUST successfully complete before any of the updates are processed.
o MSGREFには、ターゲットとSeqnumの2つの項目が含まれています。ターゲットは、更新メッセージのターゲットを識別します。TargetIdentifierの構文は、セクション4.1で説明されています。Seqnumは、Trust Anchor UpdateメッセージとTrust Anchor Updateの確認メッセージを一致させるために使用される一連の使用値です。シーケンス番号は、TAMPメッセージリプレイの検出にも使用されます。セクション6で説明されているシーケンス番号処理は、更新が処理される前に正常に完了する必要があります。
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.
o 更新には、管理またはアイデンティティの信頼のアンカーを追加、削除、変更するために使用される一連の更新が含まれています。シーケンス内の各エントリは、これらのアクションの1つを表し、Trustanchorupdateのインスタンスによって示されます。アクションは、表示される順序で処理する必要がある更新のバッチですが、各更新は個別に処理されます。各更新は、セクション7で説明されている従属チェックを満たす必要があります。更新の1つ以上が失敗したとしても、残りの更新を処理する必要があります。これらの更新は、Apex Trustアンカーに変更を加えてはなりません。
o tampSeqNumbers MAY be included to provide the initial or new sequence numbers for trust anchors added or changed by the updates field. Elements included in the tampSeqNumbers field that do not correspond to an element in the updates field are ignored. Elements included in the tampSeqNumbers field that do correspond to an element in the updates field and contain a sequence number less than or equal to the most recently stored sequence number for the trust anchor are ignored. Elements included in the tampSeqNumbers field that do correspond to an element in the updates field and contain a sequence number greater than the most recently stored sequence number for the indicated trust anchor are processed by setting the stored sequence number for the trust anchor equal to the new value.
o TampSeqNumbersを含めて、更新フィールドによって追加または変更された信頼アンカーの初期または新しいシーケンス番号を提供することができます。更新フィールドの要素に対応しないTampseqNumbersフィールドに含まれる要素は無視されます。TampseqNumbersフィールドに含まれる要素は、更新フィールドの要素に対応し、トラストアンカーのごく最近保存されたシーケンス番号以下のシーケンス数を含むシーケンス番号を含むことは無視されます。更新フィールドの要素に対応し、指定された信頼アンカーの直近の保存されたシーケンス番号よりも大きいシーケンス番号を含むTampseqNumbersフィールドに含まれる要素は、新しいトラストアンカーの保存されたシーケンス番号を新しいものに等しいと設定することにより処理されます。価値。
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:
Trustanchorupdateは3つの構造の選択であり、各代替手段は3つの可能なアクションのいずれかを表します：追加、削除、および変更。これらの各アクションに関連付けられた構文の説明は次のとおりです。
o add is used to insert a new management or identity trust anchor into the trust anchor store. The TrustAnchorChoice structure is used to provide the trusted public key and all of the information associated with it. However, the action MUST fail with the error code notAuthorized if the subordination checks described in Section 7 are not satisfied. See Section 3 for a discussion of the TrustAnchorChoice structure. The apex trust anchor cannot be introduced into a trust anchor store using this action; therefore, the id-pe-wrappedApexContinKey MUST NOT be present in the extensions field. The constraints of the existing trust anchors are unchanged by this action. An attempt to add a management or identity trust anchor that is already in place with the same values for every field in the TrustAnchorChoice structure MUST be treated as a successful addition. An attempt to add a management or identity trust anchor that is already present with the same pubKey values, but with different values for any of the fields in the TrustAnchorChoice structure, MUST fail with the error code improperTAAddition. This means a trust anchor may not be added twice using different TrustAnchorChoice options. If a different format is desired, the existing trust anchor must be removed and the new format added.
o ADDは、新しい管理またはIdentity TrustアンカーをTrust Anchor Storeに挿入するために使用されます。Trustanchorchoice構造は、信頼できる公開鍵とそれに関連するすべての情報を提供するために使用されます。ただし、セクション7で説明されている従属チェックが満たされていない場合、エラーコードがnotorizedでは解決された場合、アクションは失敗する必要があります。Trustanchorchoice構造の議論については、セクション3を参照してください。Apex Trustアンカーは、このアクションを使用してトラストアンカーストアに導入することはできません。したがって、ID-PE-WRAPPEDAPEXCONTINKEYは、拡張フィールドに存在してはなりません。既存の信頼アンカーの制約は、このアクションによって変更されません。Trustanchorchoice構造のすべてのフィールドに対してすでに同じ値で既に整っている管理またはIDの信頼アンカーを追加しようとする試みは、追加の追加として扱わなければなりません。既に同じPubKey値が存在しているが、TrustanchOrchoice構造のどのフィールドでも異なる値を持つ管理またはIdentity Trustアンカーを追加しようとする試みは、エラーコードImpropertaAdditionで失敗する必要があります。これは、TrustanchOrchoiceオプションを使用してTrust Anchorを2回追加できないことを意味します。別の形式が必要な場合は、既存の信頼アンカーを削除し、新しい形式を追加する必要があります。
o remove is used to delete an existing management or identity trust anchor from the trust anchor store, including the deletion of the management trust anchor associated with the TAMP message signer. However, the action MUST fail with the error code notAuthorized if the subordination checks described in Section 7 are not satisfied. The public key contained in SubjectPublicKeyInfo names the management or identity trust anchor to be deleted. An attempt to delete a trust anchor that is not present MUST be treated as a successful deletion. The constraints of the deleted trust anchor are not distributed to other trust anchors in any manner. The apex trust anchor cannot be removed using this action, which ensures that this action cannot place the trust anchor store in an unrecoverable configuration.
o removeは、TAMPメッセージ署名者に関連付けられた管理トラストアンカーの削除を含む、Trust Anchor Storeから既存の管理またはIdentity Trustアンカーを削除するために使用されます。ただし、セクション7で説明されている従属チェックが満たされていない場合、エラーコードがnotorizedでは解決された場合、アクションは失敗する必要があります。SubjectPublicKeyInfoに含まれる公開キーは、削除される管理またはIDトラストアンカーに名前を付けます。存在しない信頼アンカーを削除しようとする試みは、成功した削除として扱わなければなりません。削除されたトラストアンカーの制約は、いかなる方法でも他の信頼アンカーに分配されません。Apex Trustアンカーは、このアクションを使用して削除することはできません。これにより、このアクションがトラストアンカーストアを回復不可能な構成に配置できないことが保証されます。
o change is used to update the information associated with an existing management or identity trust anchor in the trust anchor store. Attempts to change a trust anchor added as a Certificate MUST fail with the error code improperTAChange. The public key contained in the SubjectPublicKeyInfo field of TrustAnchorChangeInfo or in the subjectPublicKeyInfo field of a TBSCertificateChangeInfo names the to-be-updated trust anchor. However, the action MUST fail with the error code notAuthorized if the subordination checks described in Section 7 are not satisfied. An attempt to change a trust anchor that is not present MUST result in a failure with the trustAnchorNotFound status code. The TrustAnchorChangeInfo structure or the TBSCertificateChangeInfo structure is used to provide the revised configuration of the management or identity trust anchor. If the update fails for any reason, then the original trust anchor configuration MUST be preserved. The apex trust anchor information cannot be changed using this action. Attempts to change a trust anchor added as a TBSCertificate using a TrustAnchorChangeInfo MUST fail with an improperTAChange error. Attempts to change a trust anchor added as a TrustAnchorInfo using a TBSCertificateChangeInfo MUST fail with an improperTAChange error.
o 変更は、Trust Anchor Storeの既存の管理またはIdentity Trustアンカーに関連する情報を更新するために使用されます。証明書として追加された信頼アンカーを変更しようとすると、エラーコードImpropertachangeで失敗する必要があります。Trustanchorchangeinfoの件名PublicKeyInfoフィールドまたはTBSCertificAteChangeinfoの件名PublicKeyInfoフィールドに含まれる公開鍵ただし、セクション7で説明されている従属チェックが満たされていない場合、エラーコードがnotorizedでは解決された場合、アクションは失敗する必要があります。存在しない信頼アンカーを変更しようとすると、TrustanChornotFoundのステータスコードで失敗する必要があります。TrustanchorchangeInfo構造またはTBSCertificAteChangeInfo構造は、管理またはIDの信頼アンカーの改訂された構成を提供するために使用されます。何らかの理由で更新が失敗した場合、元のトラストアンカー構成を保持する必要があります。Apex Trustアンカー情報は、このアクションを使用して変更することはできません。Trustanchorchangeinfoを使用してTBSCertificateとして追加されたトラストアンカーを変更しようとする試みは、Impropertachangeエラーで失敗する必要があります。TBSCertificAteChangeInfoを使用してTrustanchOrinfoとして追加されたトラストアンカーを変更しようとする試みは、Impropertachangeエラーで失敗する必要があります。
The fields of TrustAnchorChangeInfo are used as follows:
Trustanchorchangeinfoのフィールドは次のように使用されます。
o pubKey contains the algorithm identifier and the public key of the management or identity trust anchor. It is used to locate the to-be-updated trust anchor in the trust anchor store.
o PubKeyには、アルゴリズム識別子と管理またはIDの信頼のアンカーの公開鍵が含まれています。これは、信頼のアンカーストアで、最新のトラストアンカーを見つけるために使用されます。
o keyId is OPTIONAL, and when present, it contains the public key identifier of the trust anchor public key, which is contained in the pubKey field. If this field is not present, then the public key identifier remains unchanged. If this field is present, the provided public key identifier replaces the previous one.
o KeyIDはオプションであり、存在する場合、PubKeyフィールドに含まれるTrust Anchor公開キーの公開キー識別子が含まれています。このフィールドが存在しない場合、公開キー識別子は変更されていません。このフィールドが存在する場合、提供された公開キー識別子が前のフィールドを置き換えます。
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 Tatitleはオプションであり、存在する場合、管理またはIdentity Trustアンカーの人間の読み取り可能な名前を提供します。Change Trustアンカーアップデートに欠けている場合、以前にTrust Anchorに関連付けられていたタイトルが削除されます。同様に、Change Trustアンカーアップデートに存在する場合、メッセージのタイトルはTrust Anchorに関連付けられています。以前のタイトルがTrust Anchorに関連付けられていた場合、タイトルは置き換えられます。タイトルが以前にトラストアンカーに関連付けられていなかった場合、更新メッセージのタイトルが追加されます。
o certPath is OPTIONAL, and when present, it provides the controls needed to construct and validate an X.509 certification path. When absent in a change trust anchor update, any controls that were previously associated with the management or identity trust anchor are removed, which means that delegation is no longer permitted. Similarly, when present in a change trust anchor update, the controls in the message are associated with the management or identity trust anchor. If previous controls, including the trust anchor distinguished name, were associated with the trust anchor, then the controls are replaced, which means that delegation continues to be supported, but that different certification paths will be valid. If controls were not previously associated with the management or identity trust anchor, then the controls from the update message are added, which enables delegation. The syntax and semantics of CertPathControls are discussed in [RFC5914].
o CERTPATHはオプションであり、存在する場合、X.509認証パスの構築と検証に必要なコントロールを提供します。Change Trustアンカーアップデートに欠けている場合、以前に管理またはIDトラストアンカーに関連付けられていたコントロールが削除されます。つまり、代表団はもはや許可されていません。同様に、Change Trust Anchor Updateに存在する場合、メッセージのコントロールは管理またはIDトラストアンカーに関連付けられています。Trust Anchor Distinguished Nameを含む以前のコントロールが信頼アンカーに関連付けられていた場合、コントロールは交換されます。つまり、委任は引き続きサポートされますが、異なる認証パスは有効です。コントロールが以前に管理またはIDの信頼アンカーに関連付けられていなかった場合、更新メッセージからのコントロールが追加され、委任が可能になります。CertPathControlsの構文とセマンティクスは[RFC5914]で説明されています。
o exts is OPTIONAL, and when present, it provides the extensions values that are associated with the trust anchor. When absent in a change trust anchor update, any extensions that were previously associated with the trust anchor are removed. Similarly, when present in a change trust anchor update, the extensions in the message are associated with the trust anchor. Any extensions previously associated with the trust anchor are replaced or removed.
o extsはオプションであり、存在する場合、信頼アンカーに関連付けられている拡張値を提供します。Change Trustアンカーアップデートに欠けている場合、以前に信頼アンカーに関連付けられていた拡張機能は削除されます。同様に、Change Trustアンカーアップデートに存在する場合、メッセージの拡張機能はTrust Anchorに関連付けられています。トラストアンカーに以前に関連付けられている拡張機能は、交換または削除されます。
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.
TBSCertificateChangeingInfoのフィールドは、TBSCertificate構造内のフィールドを変更するために使用されます。TBSCertificateは[RFC5280]で説明されています。extsを除くすべてのフィールドについて、Change Trustアンカーアップデートにフィールドが存在しない場合、信頼アンカーに関連付けられた以前の値は変更されません。Extsフィールドの場合、Change Trustアンカーアップデートにフィールドが存在しない場合、Trust Anchorに関連付けられた以前の値は削除されます。すべてのフィールドについて、フィールドがChange Trustアンカーアップデートに存在する場合、Trustアンカーに関連付けられた以前の値は、更新メッセージの値に置き換えられます。
[RFC5914] defines the TrustAnchorList structure to convey a list of trust anchors. TAMP implementations MAY process TrustAnchorList objects (with eContentType (or contentType) using the id-ct-trustAnchorList OID defined in [RFC5914]) as equivalent to TAMPUpdate objects with terse set to terse, msgRef set to allModules (with a suitable sequence number), and all elements within the list contained within the add field. This alternative to TrustAnchorUpdate is provided for implementations that perform integrity and authorization checks out-of-band as a simple means of transferring trust anchors from one trust anchor store to another. It does not provide a means of removing or changing trust anchors and has no HTTP binding.
[RFC5914]は、信頼できるアンカーのリストを伝えるために、Trustanchorlist構造を定義します。TAMP実装は、Trustanchorlistオブジェクト（[RFC5914]で定義されたID-CT-Trustanchorlist OIDを使用して、EcontentType（またはContentType）を使用して）を処理する場合があります。リスト内のすべての要素は、ADDフィールド内に含まれています。TrustanchorUpdateに代わるこの代替手段は、ある信頼のアンカーから別の信頼anchorストアに信頼アンカーを転送する簡単な手段として、統合と承認チェックを実行する実装のために提供されます。信頼のアンカーを削除または変更する手段を提供することはなく、HTTPバインディングはありません。
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.
Trust Anchor Updateの確認メッセージは、有効なTrust Anchor UpdateメッセージへのTrust Anchor Storeによる返信です。Trust Anchor Updateの確認メッセージは、要求された各更新の成功と失敗情報を提供します。Trust Anchor Updateの確認メッセージに署名または署名されている場合があります。実装が署名できる場合、トラストアンカーアップデートにメッセージに署名する必要があります。
The Trust Anchor Update Confirm content type has the following syntax:
Trust Anchorの更新には、コンテンツタイプには次の構文があります。
tamp-update-confirm CONTENT-TYPE ::=
{ TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm }
id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 }
TAMPUpdateConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
update TAMPMsgRef,
confirm UpdateConfirm }
UpdateConfirm ::= CHOICE {
terseConfirm [0] TerseUpdateConfirm,
verboseConfirm [1] VerboseUpdateConfirm }
TerseUpdateConfirm ::= StatusCodeList
StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode
VerboseUpdateConfirm ::= SEQUENCE {
status StatusCodeList,
taInfo TrustAnchorChoiceList,
tampSeqNumbers TAMPSequenceNumbers OPTIONAL,
usesApex BOOLEAN DEFAULT TRUE }
The fields of TAMPUpdateConfirm are used as follows:
Tampupdateconfirmのフィールドは次のように使用されます。
o version identifies version of TAMP. For this version of the specification, the default value, v2, MUST be used.
o バージョンはTAMPのバージョンを識別します。このバージョンの仕様では、デフォルト値V2を使用する必要があります。
o update identifies the TAMPUpdate message to which the trust anchor store is responding. The update structure repeats the TAMPMsgRef from the Trust Anchor Update message (see Section 4.3). The sequence number processing described in Section 6 MUST successfully complete before any of the updates are processed.
o 更新は、Trust Anchor Storeが応答しているTampupdateメッセージを識別します。更新構造は、Trust Anchor UpdateメッセージからTampmsgrefを繰り返します（セクション4.3を参照）。セクション6で説明されているシーケンス番号処理は、更新が処理される前に正常に完了する必要があります。
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.
o 確認には、簡潔な更新確認または冗長更新確認が含まれています。Terse Updateの確認は、Terseupdateconfirmによって表され、冗長応答は冗長性Dateconfirmで表されます。
The TerseUpdateConfirm contains a sequence of status codes, one for each TrustAnchorUpdate structure in the Trust Anchor Update message. The status codes MUST appear in the same order as the TrustAnchorUpdate structures to which they apply, and the number of elements in the status code list MUST be the same as the number of elements in the trust anchor update list. Each of the status codes is discussed in Section 5.
terseupdateconfirmには、トラストアンカーアップデートメッセージの各Trustanchorupdate構造に1つのステータスコードが含まれています。ステータスコードは、適用されるTrustanchorUpdate構造と同じ順序で表示され、ステータスコードリストの要素の数は、Trust Anchor Updateリストの要素の数と同じでなければなりません。各ステータスコードについては、セクション5で説明します。
The fields of VerboseUpdateConfirm are used as follows:
Verboseupdateconfirmのフィールドは次のように使用されます。
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 ステータスには、トラストアンカーアップデートメッセージの各TrustanchorUpdate構造に1つのステータスコードのシーケンスが含まれています。ステータスコードは、適用されるTrustanchorUpdate構造と同じ順序で表示され、ステータスコードリストの要素の数は、Trust Anchor Updateリストの要素の数と同じでなければなりません。各ステータスコードについては、セクション5で説明します。
o taInfo contains a sequence of TrustAnchorChoice structures. One entry in the sequence is provided for each trust anchor contained in the trust anchor store. These represent the state of the trust anchors after the updates have been processed. When usesApex is true, the apex trust anchor is the first trust anchor in the sequence.
o Tainfoには、Trustanchorchoice構造のシーケンスが含まれています。シーケンス内の1つのエントリは、トラストアンカーストアに含まれる各トラストアンカーに提供されます。これらは、更新が処理された後の信頼アンカーの状態を表します。UseSapexがTRUEの場合、Apex Trust Anchorはシーケンスの最初の信頼アンカーです。
o tampSeqNumbers is used to indicate the currently held sequence number for each trust anchor authorized to sign TAMP messages. The keyId field identifies the trust anchor, and the seqNumber field provides the current sequence number associated with the trust anchor.
o TampSeqNumbersは、TAMPメッセージに署名することを許可された各トラストアンカーの現在保持されているシーケンス番号を示すために使用されます。KeyIDフィールドは信頼アンカーを識別し、SeqNumberフィールドはTrust Anchorに関連付けられた現在のシーケンス番号を提供します。
o usesApex is a Boolean value that indicates whether the first item in the taInfo field identifies the apex TA.
o useSapexは、TAINFOフィールドの最初のアイテムがApex TAを識別するかどうかを示すブール値です。
The Apex Trust Anchor Update message replaces the operational public key and, optionally, the contingency public key associated with the apex trust anchor. Each trust anchor store has exactly one apex trust anchor. No constraints are associated with the apex trust anchor. The public key identifier of the operational public key is used to identify the apex trust anchor in subsequent TAMP messages. The digital signature on the Apex Trust Anchor Update message is validated with either the current operational public key or the current contingency public key. For the Apex Trust Anchor Update message that is validated with the operational public key to be valid, the trust anchor store MUST be a target of the update, the sequence number MUST be larger than the most recently stored sequence number for the operational public key, and the digital signature MUST be validated directly with the operational public key. That is, no delegation via a certification path is permitted. For the Apex Trust Anchor Update message that is validated with the contingency public key to be valid, the trust anchor store MUST be a target of the update, the provided decryption key MUST properly decrypt the contingency public key, and the digital signature MUST be validated directly with the decrypted contingency public key. Again, no delegation via a certification path is permitted.
Apex Trust Anchor Updateメッセージは、Apex Trust Anchorに関連付けられている運用上の公開キー、およびオプションでは偶発的な公開キーを置き換えます。各トラストアンカーストアには、ちょうど1つのApex Trustアンカーがあります。Apex Trustアンカーには制約が関連付けられていません。運用公開キーの公開鍵識別子を使用して、後続のTAMPメッセージでApex Trustアンカーを識別します。Apex Trust Anchor Updateメッセージのデジタル署名は、現在の運用公開キーまたは現在のContingency公開キーのいずれかで検証されます。Apex Trust Anchor Updateメッセージは、運用上の公開キーで有効になるように検証されている場合、信頼できるアンカーストアはアップデートのターゲットでなければなりません。また、デジタル署名は、運用上の公開キーで直接検証する必要があります。つまり、認証パスを介した代表団は許可されていません。Apex Trust Anchor Updateメッセージは、Contingency Public Keyが有効になるように検証され、信頼アンカーストアはアップデートのターゲットでなければならず、提供された復号化キーはContingenceの公開キーを適切に復号化する必要があり、デジタル署名を検証する必要があります復号化された偶発性の公開キーと直接。繰り返しますが、認証パスを介した委任は許可されていません。
If the Apex Trust Anchor Update message is validated using the operational public key, then sequence number processing is handled normally, as described in Section 6. If the Apex Trust Anchor Update message is validated using the contingency public key, then the TAMPMsgRef sequence number MUST contain a zero value. A sequence number for subsequent messages that will be validated with the new operational public key can optionally be provided. If no value is provided, then the trust anchor store MUST be prepared to accept any sequence number in the next TAMP message validated with the newly installed apex trust anchor operational public key. If the Apex Trust Anchor Update message is valid and the clearTrustAnchors flag is set to TRUE, then all of the management and identity trust anchors stored in the trust anchor store MUST be deleted. That is, the new apex trust anchor MUST be the only trust anchor remaining in the trust anchor store. If the Apex Trust Anchor Update message is valid and the clearCommunities flag is set to TRUE, then all community identifiers stored in the trust anchor store MUST be deleted.
Apex Trust Anchor Updateメッセージがオペレーショナル公開キーを使用して検証されている場合、セクション6で説明されているように、シーケンス番号処理が正常に処理された場合、Apex Trustアンカー更新メッセージがContingencyの公開キーを使用して検証されている場合、Tampmsgrefシーケンス番号は必要ですゼロ値が含まれています。新しい運用公開キーで検証される後続のメッセージのシーケンス番号をオプションで提供できます。値が提供されていない場合、Trust Anchor Storeは、新しくインストールされたApex Trustアンカー運用公開キーで検証された次のTAMPメッセージのシーケンス番号を受け入れる準備をする必要があります。Apex Trust Anchor Updateメッセージが有効で、ClearTrustanchors FlagがTrueに設定されている場合、Trust Anchor Storeに保存されている管理およびIdentity Trustアンカーはすべて削除する必要があります。つまり、新しいApex Trustアンカーは、トラストアンカーストアに残っている唯一の信頼アンカーでなければなりません。Apex Trust Anchor Updateメッセージが有効で、ClearCommunities FlagがTrueに設定されている場合、Trust Anchor Storeに保存されているすべてのコミュニティ識別子を削除する必要があります。
The SignedData structure includes a SignerInfo.sid value, and it identifies the apex trust anchor public key that will be used to validate the digital signature on this TAMP message. The public key 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.
SignedData構造にはSignerInfo.SID値が含まれており、このTAMPメッセージのデジタル署名を検証するために使用されるApex Trust Anchor公開キーを識別します。運用上の公開キーの公開キー識別子は事前に知られており、Apex Trust Anchorの一部として保存されます。Contingencyの公開キーの公開キー識別子は、事前に知られていません。ただし、コンティンジェンシー公開キーを復号化するために必要な対称キーを含む署名されていない属性の存在は、TAMPメッセージ署名者が偶発性の秘密鍵を使用してApex Trust Anchor Updateメッセージに署名することを明確に示しています。
If the digital signature on the Apex Trust Anchor Update message is valid using either the apex trust anchor operational public key or the apex trust anchor contingency public key, sequence number checking is successful, and the trust anchor store is an intended recipient of the TAMP message, then the trust anchor store MUST update the apex trust anchor and return an Apex Trust Anchor Update Confirm message. If an Apex Trust Anchor Update Confirm message is not returned, then a TAMP Error message SHOULD be returned. Note that the sequence number MUST be zero if the Apex Trust Anchor Update message is validated with the apex trust anchor contingency public key.
Apex Trustアンカー更新メッセージのデジタル署名がApex Trust Anchor Operational Public KeyまたはApex Trust Anchor Anchor Contingency Public Keyのいずれかを使用して有効である場合、シーケンス番号チェックが成功し、Trust Anchor StoreはTAMPメッセージの受信者です、その後、Trust Anchor StoreはApex Trustアンカーを更新し、Apex Trust Anchor Updateの確認メッセージを返す必要があります。Apex Trust Anchor Updateの確認メッセージが返されない場合、TAMPエラーメッセージを返す必要があります。Apex Trust Anchor UpdateメッセージがApex Trust Anchor Anchor Contingency Public Keyで検証されている場合、シーケンス番号はゼロでなければならないことに注意してください。
The Apex Trust Anchor Update content type has the following syntax:
Apex Trust Anchor Updateコンテンツタイプには、次の構文があります。
tamp-apex-update CONTENT-TYPE ::=
{ TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate }
id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 }
TAMPApexUpdate ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
msgRef TAMPMsgRef,
clearTrustAnchors BOOLEAN,
clearCommunities BOOLEAN,
seqNumber SeqNumber OPTIONAL,
apexTA TrustAnchorChoice }
The fields of TAMPApexUpdate are used as follows:
Tampapexupdateのフィールドは次のように使用されます。
o version identifies version of TAMP. For this version of the specification, the default value, v2, MUST be used.
o バージョンはTAMPのバージョンを識別します。このバージョンの仕様では、デフォルト値V2を使用する必要があります。
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 Terseは、必要な応答のタイプを示します。簡潔な応答は1の値で示され、冗長応答は2の値で示されます。これは、デフォルト値であるため、エンコード中に省略されます。
o msgRef contains two items: the target and the seqNum. target identifies the target(s) of the Apex Trust Anchor Update message.
o MSGREFには、ターゲットとSeqnumの2つの項目が含まれています。ターゲットは、Apex Trustアンカー更新メッセージのターゲットを識別します。
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.
セクション4.1で説明されているターゲットIdentifierの構文が使用されています。Seqnumは、Apex Trust Anchor UpdateメッセージとApex Trust Anchor Updateの確認メッセージを一致させるために使用される一連の使用値です。シーケンス番号は、Apex Trust Anchor Operational Public Keyでメッセージが検証されている場合、TAMPメッセージリプレイを検出するためにも使用されます。セクション6で説明されているシーケンス番号処理は、アクションが実行される前に正常に完了する必要があります。ただし、Apex Trust Anchor Contingency Public Keyでメッセージが検証されている場合、Seqnumにはゼロ値を含める必要があります。
o clearTrustAnchors is a Boolean. If the value is set to TRUE, then all of the management and identity trust anchors stored in the trust anchor store MUST be deleted, leaving the newly installed apex trust anchor as the only trust anchor in the trust anchor store. If the value is set to FALSE, the other trust anchors MUST NOT be changed.
o ClearTrustanchorsはブールです。値がTrueに設定されている場合、Trust Anchor Storeに保存されている管理およびIdentity Trustアンカーはすべて削除する必要があり、新しくインストールされたApex Trust AnchorをTrust Anchor Storeの唯一の信頼アンカーとして残します。値がfalseに設定されている場合、他の信頼アンカーを変更してはなりません。
o clearCommunities is a Boolean. If the value is set to TRUE, then all of the community identifiers stored in the trust anchor store MUST be deleted, leaving none. If the value is set to FALSE, the list of community identifiers MUST NOT be changed.
o 明確なコミュニティはブールです。値がtrueに設定されている場合、トラストアンカーストアに保存されているすべてのコミュニティ識別子は削除する必要があり、何も残しません。値がfalsに設定されている場合、コミュニティ識別子のリストを変更してはなりません。
o seqNumber is OPTIONAL, and when present, it provides the initial sequence number for the apex trust anchor. If seqNumber is absent, the trust anchor store is prepared to accept any sequence number value for the apex trust anchor operational public key.
o SeqNumberはオプションであり、存在する場合、Apex Trustアンカーの初期シーケンス番号を提供します。SeqNumberが不在の場合、Trust Anchor StoreはApex Trust Anchor Operational Public Keyのシーケンス番号値を受け入れる準備ができています。
o apexTA provides the information for the replacement apex trust anchor. The TrustAnchorChoice structure is used to provide the trusted public key and all of the information associated with it. The pubKey, keyId, taTitle, certPath, and exts fields apply to the operational public key of the apex trust anchor. The ApexTrustAnchorInfo certificate extension MAY appear as an extension. Section 9 describes the WrappedApexContingencyKey certificate extension.
o Apextaは、交換用Apex Trustアンカーの情報を提供します。Trustanchorchoice構造は、信頼できる公開鍵とそれに関連するすべての情報を提供するために使用されます。PubKey、KeyID、Tatitle、CertPath、およびExtsフィールドは、Apex Trustアンカーの運用上の公開鍵に適用されます。apextrustanchorinfo証明書拡張機能は、拡張機能として表示される場合があります。セクション9では、LappedApexContingingEncyKey証明書拡張について説明します。
The Apex Trust Anchor Update Confirm message is a reply by a trust anchor store to a valid Apex Trust Anchor Update message. The Apex Trust Anchor Update Confirm message provides success or failure information for the apex trust anchor update. The Apex Trust Anchor Update Confirm message MAY be signed or unsigned. An Apex Trust Anchor Update Confirm message MUST be signed if the trust anchor store is capable of signing it.
Apex Trust Anchor Updateはメッセージであり、有効なApex Trust Anchor UpdateメッセージへのTrust Anchor Storeによる返信です。Apex Trust Anchor Updateは、Apex Trust Anchor Updateの成功または失敗情報を提供するメッセージを確認します。Apex Trust Anchor Updateは、メッセージに署名または署名されている場合があります。Trust Anchor Storeが署名できる場合、Apex Trust Anchor Updateの確認メッセージに署名する必要があります。
The Apex Trust Anchor Update Confirm content type has the following syntax:
Apex Trustアンカー更新には、コンテンツタイプには次の構文があることが確認されています。
tamp-apex-update-confirm CONTENT-TYPE ::=
{ TAMPApexUpdateConfirm IDENTIFIED BY
id-ct-TAMP-apexUpdateConfirm }
id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 }
TAMPApexUpdateConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
apexReplace TAMPMsgRef,
apexConfirm ApexUpdateConfirm }
ApexUpdateConfirm ::= CHOICE {
terseApexConfirm [0] TerseApexUpdateConfirm,
verboseApexConfirm [1] VerboseApexUpdateConfirm }
TerseApexUpdateConfirm ::= StatusCode
VerboseApexUpdateConfirm ::= SEQUENCE {
status StatusCode,
taInfo TrustAnchorChoiceList,
communities [0] CommunityIdentifierList OPTIONAL,
tampSeqNumbers [1] TAMPSequenceNumbers OPTIONAL }
The fields of TAMPApexUpdateConfirm are used as follows:
Tampapexupdateconfirmのフィールドは次のように使用されます。
o version identifies version of TAMP. For this version of the specification, the default value, v2, MUST be used.
o バージョンはTAMPのバージョンを識別します。このバージョンの仕様では、デフォルト値V2を使用する必要があります。
o apexReplace identifies the Apex Trust Anchor Update message to which the trust anchor store is responding. The apexReplace structure repeats the TAMPMsgRef from the beginning of the Apex Trust Anchor Update message (see Section 4.5). When the Apex Trust Anchor Update message is validated with the operational public key, the sequence number processing described in Section 6 MUST successfully complete before an Apex Trust Anchor Update Confirm message is generated. When the Apex Trust Anchor Update message is validated with the contingency public key, normal sequence number processing is ignored, but the seqNum MUST be zero.
o ApexReplaceは、Trust Anchor Storeが応答しているApex Trust Anchor Updateメッセージを識別します。ApexReplace構造は、Apex Trust Anchor Updateメッセージの最初からTampmsgrefを繰り返します（セクション4.5を参照）。Apex Trust Anchor Updateメッセージがオペレーショナル公開キーで検証された場合、Apex Trust Anchor Updateの確認メッセージが生成される前に、セクション6で説明されているシーケンス番号処理が正常に完了する必要があります。Apex Trust Anchor UpdateメッセージがContingencyの公開キーで検証されている場合、通常のシーケンス番号処理は無視されますが、Seqnumはゼロでなければなりません。
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.
o ApexConfirmには、簡潔な更新確認または冗長更新確認が含まれています。Terse Updateの確認はTerseapexupdateconfirmによって表され、冗長応答は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 for the failure. Each of the status codes is discussed in Section 5.
terseapexupdateconfirmには単一のステータスコードが含まれており、Apex Trustアンカーアップデートの成功または失敗を示しています。Apex Trustアンカーの更新が失敗した場合、ステータスコードは障害の理由を提供します。各ステータスコードについては、セクション5で説明します。
The fields of VerboseApexUpdateConfirm are used as follows:
verboseapexupdateconfirmのフィールドは次のように使用されます。
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 ステータスには単一のステータスコードが含まれており、Apex Trustアンカーの更新の成功または失敗を示します。Apex Trustアンカーの更新が失敗した場合、ステータスコードは障害の理由を提供します。各ステータスコードについては、セクション5で説明します。
o taInfo contains a sequence of TrustAnchorChoice structures. One entry in the sequence is provided for each trust anchor contained in the trust anchor store. These represent the state of the trust anchors after the apex trust anchor update has been processed. See [RFC5914] for a description of the TrustAnchorInfo structure. The apex trust anchor is the first trust anchor in the sequence.
o Tainfoには、Trustanchorchoice構造のシーケンスが含まれています。シーケンス内の1つのエントリは、トラストアンカーストアに含まれる各トラストアンカーに提供されます。これらは、Apex Trustアンカーの更新が処理された後の信頼アンカーの状態を表します。Trustanchorinfo構造の説明については、[RFC5914]を参照してください。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 trust anchor store belongs. When the trust anchor store belongs to no communities, this field is omitted.
o コミュニティはオプションです。存在する場合、オブジェクト識別子のシーケンスが含まれます。各オブジェクト識別子は、このトラストアンカーストアが属する1つのコミュニティに名前を付けます。Trust Anchor Storeがコミュニティのないものに属している場合、このフィールドは省略されています。
o tampSeqNumbers is used to indicate the currently held sequence number for each trust anchor authorized to sign TAMP messages. The keyId field identifies the trust anchor, and the seqNumber field provides the current sequence number associated with the trust anchor.
o TampSeqNumbersは、TAMPメッセージに署名することを許可された各トラストアンカーの現在保持されているシーケンス番号を示すために使用されます。KeyIDフィールドは信頼アンカーを識別し、SeqNumberフィールドはTrust Anchorに関連付けられた現在のシーケンス番号を提供します。
The trust anchor store maintains a list of identifiers for the communities of which it is a member. The Community Update message can be used to remove or add community identifiers from this list. The Community Update message MUST be signed. For the Community Update message to be valid, the trust anchor store MUST be a target of the update; the sequence number checking described in Section 6 MUST be successful when the TAMP message signer is a trust anchor; and the digital signature MUST be validated by the apex trust anchor operational public key, an authorized management trust anchor, or via an authorized X.509 certification path originating with such a trust anchor.
Trust Anchor Storeは、メンバーであるコミュニティの識別子のリストを維持しています。コミュニティの更新メッセージを使用して、このリストからコミュニティ識別子を削除または追加できます。コミュニティの更新メッセージに署名する必要があります。コミュニティアップデートメッセージが有効であるためには、Trust Anchor Storeがアップデートのターゲットでなければなりません。セクション6で説明されているシーケンス番号チェックは、TAMPメッセージ署名者が信頼のアンカーである場合、成功する必要があります。また、デジタル署名は、Apex Trustアンカー運用公開キー、認定管理トラストアンカーによって検証されるか、そのような信頼アンカーを介した承認されたX.509認定パスを介して検証する必要があります。
If the trust anchor store supports the Community Update message, the digital signature on the Community Update message is valid, sequence number checking is successful, the signer is authorized, and the trust anchor store is an intended recipient of the TAMP message, then the trust anchor store MUST make the specified updates and return a Community Update Confirm message. If a Community Update Confirm message is not returned, then a TAMP Error message SHOULD be returned.
トラストアンカーストアがコミュニティの更新メッセージをサポートしている場合、コミュニティ更新メッセージのデジタル署名が有効で、シーケンス番号チェックが成功し、署名者が承認され、トラストアンカーストアはTAMPメッセージの受信者であり、Trust The Trustの受信者です。アンカーストアは、指定された更新を作成し、コミュニティアップデートを返す必要があります。コミュニティの更新がメッセージが返されないことを確認する場合、TAMPエラーメッセージを返す必要があります。
The Community Update message contains a batch of updates, and all of the updates MUST be accepted for the trust anchor store to return a successful Community Update Confirm message. The remove updates, if present, MUST be processed before the add updates. Where remove is present with an empty list, all community identifiers MUST be removed. This approach prevents community identifiers that are intended to be mutually exclusive from being installed by a successful addition and a failed removal. Where add is present, at least one community identifier MUST appear in the list.
コミュニティの更新メッセージには更新のバッチが含まれており、すべての更新は、信頼できるアンカーストアが成功したコミュニティアップデートの確認メッセージを返すために受け入れなければなりません。削除更新は、存在する場合は、追加更新の前に処理する必要があります。削除が空のリストに存在する場合、すべてのコミュニティ識別子を削除する必要があります。このアプローチは、成功した追加と削除の失敗によってインストールされることから相互に排他的であることを意図したコミュニティ識別子を防ぎます。ADDが存在する場合、少なくとも1つのコミュニティ識別子がリストに表示される必要があります。
The Community Update content type has the following syntax:
コミュニティの更新コンテンツタイプには、次の構文があります。
tamp-community-update CONTENT-TYPE ::=
{ TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate }
id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 }
TAMPCommunityUpdate ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
msgRef TAMPMsgRef,
updates CommunityUpdates }
CommunityUpdates ::= SEQUENCE {
remove [1] CommunityIdentifierList OPTIONAL,
add [2] CommunityIdentifierList OPTIONAL }
-- At least one MUST be present
The fields of TAMPCommunityUpdate are used as follows:
TampCommunityUpdateのフィールドは次のように使用されます。
o version identifies version of TAMP. For this version of the specification, the default value, v2, MUST be used.
o バージョンはTAMPのバージョンを識別します。このバージョンの仕様では、デフォルト値V2を使用する必要があります。
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 Terseは、必要な応答のタイプを示します。簡潔な応答は1の値で示され、冗長応答は2の値で示されます。これは、デフォルト値であるため、エンコード中に省略されます。
o msgRef contains two items: the target and the seqNum. target identifies the target(s) of the update message. The TargetIdentifier syntax as described in Section 4.1 is used. seqNum is a single-use value that will be used to match the Community Update message with the Community Update Confirm 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 MSGREFには、ターゲットとSeqnumの2つの項目が含まれています。ターゲットは、更新メッセージのターゲットを識別します。セクション4.1で説明されているターゲットIdentifierの構文が使用されています。Seqnumは、コミュニティの更新メッセージとコミュニティアップデートの確認メッセージを一致させるために使用される使い捨ての値です。シーケンス番号は、TAMPメッセージリプレイの検出にも使用されます。セクション6で説明されているシーケンス番号処理は、更新が処理される前に正常に完了する必要があります。
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.
o 更新には、削除するコミュニティ識別子のシーケンスと、追加するコミュニティ識別子のシーケンスが含まれています。これらは、CommunityUpdates構造によって表されます。
The CommunityUpdates is a sequence of two OPTIONAL sequences, but at least one of these sequences MUST be present. The first sequence contains community identifiers to be removed, and if there are none, it is absent. Where remove is present with an empty list, all community identifiers MUST be removed. The second sequence contains community identifiers to be added, and if there are none, it is absent. The remove updates, if present, MUST be processed before the add updates. An error is generated if any of the requested removals or additions cannot be accomplished. However, requests to remove community identifiers that are not present are treated as successful removals. Likewise, requests to add community identifiers that are already present are treated as successful additions. If an error is generated, the trust anchor store community list MUST NOT be changed.
CommunityUpdatesは2つのオプションシーケンスのシーケンスですが、これらのシーケンスの少なくとも1つが存在する必要があります。最初のシーケンスには、削除されるコミュニティ識別子が含まれています。削除が空のリストに存在する場合、すべてのコミュニティ識別子を削除する必要があります。2番目のシーケンスには、追加されるコミュニティ識別子が含まれています。削除更新は、存在する場合は、追加更新の前に処理する必要があります。要求された削除または追加のいずれかを達成できない場合、エラーが生成されます。ただし、存在しないコミュニティ識別子を削除するリクエストは、成功した撤去として扱われます。同様に、すでに存在するコミュニティ識別子を追加するリクエストは、追加の追加として扱われます。エラーが生成された場合、Trust Anchor Storeコミュニティリストを変更してはなりません。
A description of the syntax associated with each of these actions follows:
これらの各アクションに関連付けられた構文の説明は次のとおりです。
o remove is used to remove one, multiple, or all community identifiers from the trust anchor store.
o 削除は、トラストアンカーストアから1つ、複数、またはすべてのコミュニティ識別子を削除するために使用されます。
o add is used to insert one or more new community identifiers into the trust anchor store.
o ADDは、1つ以上の新しいコミュニティ識別子をトラストアンカーストアに挿入するために使用されます。
The Community Update Confirm message is a reply by a trust anchor store to a valid Community Update message. The Community Update Confirm message provides success or failure information for the requested updates. Success is returned only if the whole batch of updates is successfully processed. If any of the requested updates cannot be performed, then a failure is indicated, and the set of community identifiers stored in the trust anchor store is unchanged. The Community Update Confirm message MAY be signed or unsigned. A Community Update Confirm message MUST be signed if the trust anchor store is capable of signing it.
コミュニティの更新では、メッセージが有効なコミュニティアップデートメッセージに対するTrust Anchor Storeによる返信です。コミュニティの更新により、メッセージは要求された更新の成功または失敗情報を提供します。成功は、更新のバッチ全体が正常に処理された場合にのみ返されます。要求された更新のいずれかを実行できない場合、失敗が示され、トラストアンカーストアに保存されているコミュニティ識別子のセットは変更されていません。コミュニティの更新では、メッセージが署名されたり、署名されていないことが確認されています。トラストアンカーストアが署名できる場合は、コミュニティの更新にメッセージに署名する必要があります。
The Community Update Confirm content type has the following syntax:
コミュニティの更新には、コンテンツのタイプに次の構文があることが確認されています。
tamp-community-update-confirm CONTENT-TYPE ::=
{ TAMPCommunityUpdateConfirm IDENTIFIED BY
id-ct-TAMP-communityUpdateConfirm }
id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::=
{ id-tamp 8 }
TAMPCommunityUpdateConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
update TAMPMsgRef,
commConfirm CommunityConfirm }
CommunityConfirm ::= CHOICE {
terseCommConfirm [0] TerseCommunityConfirm,
verboseCommConfirm [1] VerboseCommunityConfirm }
TerseCommunityConfirm ::= StatusCode
VerboseCommunityConfirm ::= SEQUENCE {
status StatusCode,
communities CommunityIdentifierList OPTIONAL }
The fields of TAMPCommunityUpdateConfirm are used as follows:
TampCommunityUpDateConfirmのフィールドは次のように使用されます。
o version identifies version of TAMP. For this version of the specification, the default value, v2, MUST be used.
o バージョンはTAMPのバージョンを識別します。このバージョンの仕様では、デフォルト値V2を使用する必要があります。
o update identifies the Community Update message to which the trust anchor store is responding. The update structure repeats the TAMPMsgRef from the Community Update message (see Section 4.7). The sequence number processing described in Section 6 MUST successfully complete before any of the updates are processed.
o 更新は、Trust Anchor Storeが応答しているコミュニティ更新メッセージを識別します。更新構造は、コミュニティの更新メッセージからTampmsgrefを繰り返します（セクション4.7を参照）。セクション6で説明されているシーケンス番号処理は、更新が処理される前に正常に完了する必要があります。
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.
o CommConfirmには、簡潔なコミュニティの更新確認または冗長なコミュニティの更新確認が含まれています。Terse応答はTerseCommunityConfirmによって表され、冗長応答はVerboseCommunityConfirmによって表されます。
The TerseCommunityConfirm contains a single status code, indicating the success or failure of the Community Update message processing. If the community update failed, then the status code indicates the reason for the failure. Each of the status codes is discussed in Section 5.
TerseCommunityConfirmには単一のステータスコードが含まれており、コミュニティ更新メッセージ処理の成功または失敗を示しています。コミュニティの更新が失敗した場合、ステータスコードは失敗の理由を示します。各ステータスコードについては、セクション5で説明します。
The fields of VerboseCommunityConfirm are used as follows:
VerboseCommunityConfirmのフィールドは次のように使用されます。
o status contains a single status code, indicating the success or failure of the Community Update message processing. If the community update failed, then the status code indicates the reason for the failure. Each of the status codes is discussed in Section 5.
o ステータスには単一のステータスコードが含まれており、コミュニティ更新メッセージ処理の成功または失敗を示します。コミュニティの更新が失敗した場合、ステータスコードは失敗の理由を示します。各ステータスコードについては、セクション5で説明します。
o communities is OPTIONAL. When present, it contains the sequence of community identifiers present in the trust anchor store after the update is processed. When the trust anchor store belongs to no communities, this field is omitted.
o コミュニティはオプションです。存在する場合、更新が処理された後、トラストアンカーストアに存在するコミュニティ識別子のシーケンスが含まれます。Trust Anchor Storeがコミュニティのないものに属している場合、このフィールドは省略されています。
The trust anchor store maintains the current sequence number for the apex trust anchor and each management trust anchor authorized for TAMP messages. Sequence number processing is discussed in Section 6. The Sequence Number Adjust message can be used to provide the most recently used sequence number to one or more targets, thereby reducing the possibility of replay. The Sequence Number Adjust message MUST be signed. For the Sequence Number Adjust message to be valid, the trust anchor store MUST be an intended recipient of the Sequence Number Adjust message, the sequence number MUST be equal to or larger than the most recently stored sequence number for the originating trust anchor, and the digital signature MUST be validated by the apex trust anchor operational public key or an authorized management trust anchor.
Trust Anchor Storeは、Apex Trust AnchorとTAMPメッセージの認可された各管理トラストアンカーの現在のシーケンス番号を維持しています。シーケンス番号処理については、セクション6で説明します。シーケンス番号調整メッセージを使用して、最近使用されたシーケンス番号を1つ以上のターゲットに提供し、リプレイの可能性を減らします。シーケンス番号調整メッセージに署名する必要があります。シーケンス番号調整メッセージを有効にするには、トラストアンカーストアがシーケンス番号調整メッセージの意図された受信者である必要があります。シーケンス番号は、元の信頼アンカーの最近保存されたシーケンス番号、およびデジタル署名は、Apex Trustアンカー運用公開鍵または認定管理トラストアンカーによって検証する必要があります。
If the digital signature on the Sequence Number Adjust message is valid, the sequence number is equal to or larger than the most recently stored sequence number for the originating trust anchor, the signer is authorized, and the trust anchor store is an intended recipient of the TAMP message, then the trust anchor store MUST update the sequence number associated with the originating trust anchor and return a Sequence Number Adjust Confirm message. If a Sequence Number Adjust Confirm message is not returned, then a TAMP Error message SHOULD be returned.
シーケンス番号調整メッセージのデジタル署名が有効である場合、シーケンス番号は、元の信頼できるアンカーの直近保存されたシーケンス番号と等しく、署名者は承認され、トラストアンカーストアは意図された受信者です。TAMPメッセージ、次に、Trust Anchor Storeは、発信元のトラストアンカーに関連付けられたシーケンス番号を更新し、シーケンス番号調整確認メッセージを返す必要があります。シーケンス番号を調整して確認メッセージが返されない場合、TAMPエラーメッセージを返す必要があります。
The Sequence Number Adjust message contains an adjustment for the sequence number of the TAMP message signer.
シーケンス番号調整メッセージには、TAMPメッセージ署名者のシーケンス番号の調整が含まれています。
The Sequence Number Adjust content type has the following syntax:
シーケンス番号調整コンテンツタイプには、次の構文があります。
tamp-sequence-number-adjust CONTENT-TYPE ::=
{ SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust }
id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 }
SequenceNumberAdjust ::= SEQUENCE {
Version [0] TAMPVersion DEFAULT v2,
msgRef TAMPMsgRef }
The fields of SequenceNumberAdjust are used as follows:
シーケンスヌンバーアジュストのフィールドは、次のように使用されます。
o version identifies version of TAMP. For this version of the specification, the default value, v2, MUST be used.
o バージョンはTAMPのバージョンを識別します。このバージョンの仕様では、デフォルト値V2を使用する必要があります。
o msgRef contains two items: the target and the seqNum. target identifies the target(s) of the sequence number adjust message. The TargetIdentifier syntax as described in Section 4.1 is used. The allModules target is expected to be used for Sequence Number Adjust messages. seqNum MUST be equal to or larger than the most recently stored sequence number for this TAMP message signer, and the value will be used to match the Sequence Number Adjust message with the Sequence Number Adjust Confirm message. The sequence number processing described in Section 6 applies, except that the sequence number in a Sequence Number Adjust message is acceptable if it matches the most recently stored sequence number for this TAMP message signer. If sequence number checking completes successfully, then the sequence number is adjusted; otherwise, it remains unchanged.
o MSGREFには、ターゲットとSeqnumの2つの項目が含まれています。ターゲットは、シーケンス番号調整メッセージのターゲットを識別します。セクション4.1で説明されているターゲットIdentifierの構文が使用されています。Allmodulesターゲットは、シーケンス番号調整メッセージに使用されると予想されます。Seqnumは、このTAMPメッセージ署名者のごく最近保存されたシーケンス番号と等しいまたは大きくする必要があります。値は、シーケンス番号調整メッセージをシーケンス番号調整確認メッセージと一致させるために使用されます。セクション6で説明するシーケンス番号処理は、このTAMPメッセージ署名者の最近保存されたシーケンス番号と一致する場合、シーケンス番号調整メッセージのシーケンス番号が許容できることを除きます。シーケンス番号のチェックが正常に完了すると、シーケンス番号が調整されます。そうでなければ、それは変わらないままです。
The Sequence Number Adjust Confirm message is a reply by a trust anchor store to a valid Sequence Number Adjust message. The Sequence Number Adjust Confirm message provides success or failure information. Success is returned only if the sequence number for the trust anchor that signed the Sequence Number Adjust message originator is adjusted. If the sequence number cannot be adjusted, then a failure is indicated, and the sequence number stored in the trust anchor store is unchanged. The Sequence Number Adjust Confirm message MAY be signed or unsigned. A Sequence Number Adjust Confirm message MUST be signed if the trust anchor store is capable of signing it.
シーケンス番号の調整確認メッセージは、トラストアンカーストアによる有効なシーケンス番号調整メッセージへの返信です。シーケンス番号の調整確認メッセージは成功または失敗情報を提供します。成功は、シーケンス番号調整メッセージオリジネーターに署名した信頼アンカーのシーケンス番号が調整された場合にのみ返されます。シーケンス番号を調整できない場合、障害が示され、トラストアンカーストアに保存されているシーケンス番号は変更されていません。シーケンス番号を調整することは、メッセージに署名または署名されている場合があります。トラストアンカーストアが署名できる場合、シーケンス番号調整確認メッセージに署名する必要があります。
The Sequence Number Adjust Confirm content type has the following syntax:
シーケンス番号の調整コンテンツタイプには、次の構文があります。
tamp-sequence-number-adjust-confirm CONTENT-TYPE ::=
{ SequenceNumberAdjustConfirm IDENTIFIED BY
id-ct-TAMP-seqNumAdjustConfirm }
id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::=
{ id-tamp 11 }
SequenceNumberAdjustConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
adjust TAMPMsgRef,
status StatusCode }
The fields of SequenceNumberAdjustConfirm are used as follows:
SequencenumberAdjustConfirmのフィールドは次のように使用されます。
o version identifies version of TAMP. For this version of the specification, the default value, v2, MUST be used.
o バージョンはTAMPのバージョンを識別します。このバージョンの仕様では、デフォルト値V2を使用する必要があります。
o adjust identifies the Sequence Number Adjust message to which the trust anchor store is responding. The adjust structure repeats the TAMPMsgRef from the Sequence Number Adjust message (see Section 4.9). The sequence number processing described in Section 6 MUST successfully complete to adjust the sequence number associated with the Sequence Number Adjust message originator.
o 調整Trust Anchor Storeが応答しているシーケンス番号調整メッセージを識別します。調整構造は、シーケンス番号調整メッセージからtampmsgrefを繰り返します（セクション4.9を参照）。セクション6で説明されているシーケンス番号処理は、シーケンス番号調整メッセージオリジターターに関連付けられたシーケンス番号を調整するために正常に完了する必要があります。
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.
o ステータスには単一のステータスコードが含まれており、シーケンス番号調整メッセージ処理の成功または障害を示します。調整が失敗した場合、ステータスコードは障害の理由を示します。各ステータスコードについては、セクション5で説明します。
The TAMP Error message is a reply by a trust anchor store to any invalid TAMP message. The TAMP Error message provides an indication of the reason for the error. The TAMP Error message MAY be signed or unsigned. A TAMP Error message MUST be signed if the trust anchor store is capable of signing it. For the request types defined in this specification, TAMP Error messages MUST NOT be used to indicate a request message was successfully processed. Each TAMP Error message identifies the type of TAMP message that caused the error. In cases where the TAMP message type cannot be determined, errors MAY be returned via other means, such as at the protocol level, via an attached display, etc.
TAMPエラーメッセージは、無効なTAMPメッセージに対するTrust Anchor Storeによる返信です。TAMPエラーメッセージは、エラーの理由を示しています。TAMPエラーメッセージに署名または署名されている場合があります。Trust Anchor Storeが署名できる場合は、TAMPエラーメッセージに署名する必要があります。この仕様で定義されている要求タイプの場合、TAMPエラーメッセージを使用して、リクエストメッセージが正常に処理されたことを示す必要はありません。各TAMPエラーメッセージは、エラーを引き起こしたTAMPメッセージのタイプを識別します。TAMPメッセージタイプを決定できない場合、エラーは、プロトコルレベル、添付のディスプレイなど、他の手段を介して返される場合があります。
The TAMP Error message content type has the following syntax:
TAMPエラーメッセージコンテンツタイプには、次の構文があります。
tamp-error CONTENT-TYPE ::=
{ TAMPError IDENTIFIED BY id-ct-TAMP-error }
id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 }
TAMPError ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
msgType OBJECT IDENTIFIER,
status StatusCode,
msgRef TAMPMsgRef OPTIONAL }
The fields of TAMPError are used as follows:
Tamperrorのフィールドは次のように使用されます。
o version identifies version of TAMP. For this version of the specification, the default value, v2, MUST be used.
o バージョンはTAMPのバージョンを識別します。このバージョンの仕様では、デフォルト値V2を使用する必要があります。
o msgType indicates the content type of the TAMP message that caused the error.
o MSGTypeは、エラーを引き起こしたTAMPメッセージのコンテンツタイプを示します。
o status contains a status code that indicates the reason for the error. Each of the status codes is discussed in Section 5.
o ステータスには、エラーの理由を示すステータスコードが含まれています。各ステータスコードについては、セクション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).
o MSGREFはオプションですが、可能な場合はいつでも存在する必要があります。エラーを引き起こしたTAMPメッセージを識別します。エラーを引き起こしたTAMPメッセージからターゲットとseqnumを繰り返します（セクション4.1、4.3、4.5、4.7、および4.9を参照）。
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:
Trust Anchor Updateの確認、Apex Trust Anchor Updateの確認、コミュニティの更新確認、シーケンス番号の調整確認、TAMPエラーメッセージにはステータスコードが含まれます。ステータスコードの構文は次のとおりです。
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),
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 成功は、更新、更新の一部、または調整が正常に処理されたことを示すために使用されます。
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 DecodeFailureは、Trust Anchor Storeが提供されたメッセージを正常にデコードできないことを示すために使用されます。指定されたコンテンツタイプと提供されたコンテンツは一致しません。
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 BadContentInfoは、ContentInfoの構文が無効であること、またはContentInfo内でContentTypeが不明またはサポートされていないことを示すために使用されます。
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 BadsignedDataは、SignedData構文が無効であること、バージョンが不明またはサポートされていないことを示すために使用されます。
o badEncapContent is used to indicate that the EncapsulatedContentInfo syntax is invalid. This error can be generated due to problems located in SignedData.
o badencapcontentは、cancedulatedContentInfo構文が無効であることを示すために使用されます。このエラーは、SignedDataにある問題のために生成できます。
o badCertificate is used to indicate that the syntax for one or more certificates in CertificateSet is invalid.
o BadCertificateは、証明書の1つ以上の証明書の構文が無効であることを示すために使用されます。
o badSignerInfo is used to indicate that the SignerInfo syntax is invalid, or the version is unknown or unsupported.
o badsignerinfoは、Signerinfo構文が無効であるか、バージョンが不明またはサポートされていないことを示すために使用されます。
o badSignedAttrs is used to indicate that the signedAttrs syntax within SignerInfo is invalid.
o badsignedattrsは、Signerinfo内のSigneDattrs構文が無効であることを示すために使用されます。
o badUnsignedAttrs is used to indicate that the unsignedAttrs syntax within SignerInfo is invalid.
o badunsignedattrsは、Signerinfo内のUnsignedattrs構文が無効であることを示すために使用されます。
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 MissingContentは、この仕様で必要とされるcapsulatedContentInfoでオプションのecontentが欠落していることを示すために使用されます。このエラーは、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 NotRustanchorは、2つの可能なエラー状況のいずれかを示すために使用されます。あるケースでは、SubjectKeyIdentifierは、インストールされたトラストアンカーで終了する信頼アンカーまたは認証パスの公開鍵を識別しません。他のケースでは、発行者と登録担当者は、この仕様で禁止されているTAMPメッセージ署名者を特定するために使用されます。
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 notouthorizedは、2つの可能なエラー状況のいずれかを示すために使用されます。あるケースでは、Signerinfo内のSIDはインストールされたトラストアンカーにつながりますが、そのトラストアンカーは受信したTAMPメッセージコンテンツタイプの承認された署名者ではありません。Identity Trust Anchorsは、TAMPメッセージコンテンツタイプのいずれの署名者ではありません。他のケースでは、Trust Anchor Updateメッセージの署名者は、セクション7の従属処理の障害によって決定されるように、アップデートされた信頼アンカーを管理することを許可されていません。
o badDigestAlgorithm is used to indicate that the digestAlgorithm in either SignerInfo or SignedData is unknown or unsupported.
o badDigestalgorithmは、SignerinfoまたはSignedDataの消化器gorityが不明またはサポートされていないことを示すために使用されます。
o badSignatureAlgorithm is used to indicate that the signatureAlgorithm in SignerInfo is unknown or unsupported.
o badsignaturealgorithmは、signerinfoのsignaturealgorithmが不明またはサポートされていないことを示すために使用されます。
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 UnsportedKeysizeは、SignerinfoのSignatureAlgorithmが既知でサポートされていることを示すために使用されますが、サポートされていないキーサイズが署名者によって採用されていたため、Tampメッセージデジタル署名は検証できませんでした。
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 UnsupportedParametersは、SignerInfoのSignatureAlgorithmが知られていることを示すために使用されますが、サポートされていないパラメーターが署名者によって採用されたため、TAMPメッセージデジタル署名は検証できませんでした。
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 SignatureFailureは、SignerInfoのSignatureAlgorithmが既知でサポートされていることを示すために使用されますが、Signerinfo内の署名フィールドのデジタル署名は検証できませんでした。
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 不十分なメモリは、トラストアンカーストアには、結果の信頼アンカー構成またはコミュニティ識別子を保存するのに十分なメモリがなかったため、更新を処理できなかったことを示しています。
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 UnsupportedTampmsgTypeは、Trust Anchor Storeが提供されたTAMPメッセージタイプをサポートしていないため、TAMPメッセージを処理できなかったことを示しています。このコードは、ID-CT-TAMP-CommunityUpDateコンテンツタイプが提供され、Trust Anchor Storeがコミュニティの更新メッセージをサポートしていない場合に使用されます。このステータスコードは、econtentType内のコンテンツタイプ値がこの仕様で定義されているものではない場合にも使用されます。
o apexTAMPAnchor indicates that the update could not be processed because the Trust Anchor Update message tried to remove the apex trust anchor.
o ApextAmpanchorは、Trust Anchor Updateメッセージが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 ImpropertaAdditionは、Trust Anchor Updateがすでに存在する可能性のある新しい信頼アンカーを追加しようとしていることを示していますが、Addedの信頼アンカーのいくつかの属性は不適切な方法で変更されています。目的の信頼アンカー構成は、追加操作の代わりに変更操作で達成できる場合があります。
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 SeqnumFailureは、セクション6で説明されているシーケンス番号の処理がエラーをもたらしたため、TAMPメッセージを処理できなかったことを示しています。
o contingencyPublicKeyDecrypt indicates that the update could not be processed because an error occurred while decrypting the contingency public key.
o ContingencyPublicKeyDecryptは、緊急時の公開キーを復号化する際にエラーが発生したために更新が処理できなかったことを示しています。
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 誤ったターゲットは、トラストアンカーストアが意図した受信者ではないため、クエリ、更新、または調整メッセージを処理できないことを示しています。
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 CommunityUpdateFailedは、コミュニティの更新がコミュニティ識別子の追加またはコミュニティ識別子の削除を要求したことを示していますが、リクエストは尊重できませんでした。
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 Trustanchornotfoundは、信頼アンカーへの変更が要求されたことを示していますが、参照された信頼アンカーは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 Unsupportedtaalgorithmは、更新メッセージが実装されていないデジタル署名検証アルゴリズムに関連付けられた公開キーを使用した信頼アンカーになることを示しています。さらに、アルゴリズムがサポートされている場合、このステータスコードが使用されますが、アルゴリズムに関連付けられたパラメーターはサポートされていません。
o unsupportedTAKeySize indicates that the trust anchor would include a public key of a size that is not supported.
o UnsportedTakeysizeは、信頼アンカーにはサポートされていないサイズの公開鍵が含まれることを示しています。
o unsupportedContinPubKeyDecryptAlg indicates that the decryption algorithm for the apex trust anchor contingency public key is not supported.
o UnsupportedContinPubkeyDecryptalgは、Apex Trust Anchor Contingency公開鍵の復号化アルゴリズムがサポートされていないことを示しています。
o missingSignature indicates that an unsigned TAMP message was received, but the received TAMP message type MUST be signed.
o MissingSignatureは、署名されていないTAMPメッセージが受信されたことを示していますが、受信したTAMPメッセージタイプに署名する必要があります。
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 ResourcesBusyは、TAMPメッセージの処理に必要なリソースは現時点では利用できないことを示していますが、リソースは将来のある時点で利用可能になる可能性があることを示しています。
o versionNumberMismatch indicates that the version number in a received TAMP message is not acceptable.
o VersionNumberMismatchは、受信したTAMPメッセージのバージョン番号が受け入れられないことを示します。
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 MissingPolicySetは、信頼アンカーに関連付けられたポリシーフラグがポリシソテを存在させる必要がある方法で設定されていることを示していますが、ポリシーは欠落しています。
o revokedCertificate indicates that one or more of the certificates needed to properly process the TAMP message have been revoked.
o 取り消された証明書は、TAMPメッセージを適切に処理するために必要な1つ以上の証明書が取り消されたことを示しています。
o unsupportedTrustAnchorFormat indicates that an unsupported trust anchor format was presented or the version is unknown or unsupported.
o UnsupportEdtrustanchorformatは、サポートされていない信頼のアンカー形式が提示されたか、バージョンが不明またはサポートされていないことを示しています。
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 Impropertachangeは、Trust Anchor Updateが既存の信頼アンカーの形式とは異なる形式を使用して新しいトラストアンカーを変更しようとしていることを示しています。
o malformed indicates an error in the composition of the CMS structure encapsulating a TAMP message.
o 奇形は、TAMPメッセージをカプセル化するCMS構造の構成のエラーを示します。
o cmsError indicates an error processing a CMS structure that encapsulated a TAMP message, such as an error processing ContentType or MessageDigest attributes.
o CMSERRORは、エラー処理ContentTypeやMessagedGigest属性など、TAMPメッセージをカプセル化するCMS構造の処理エラーを示します。
o unsupportedTargetIdentifier indicates that a msgRef with an unsupported TargetIdentifier option was encountered.
o UnsportedTargetIdentidifierは、サポートされていないターゲット産物オプションを備えたMSGREFが遭遇したことを示しています。
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.
o その他は、更新を処理できないことを示していますが、理由は割り当てられたステータスコードのいずれのいずれでもカバーされていません。このステータスコードの使用は避ける必要があります。
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.
TAMPのシーケンス番号処理施設は、リプレイ保護、運用上の考慮事項、および信頼できるアンカーストアメモリ管理のバランスを表しています。目標は、TAMPの使用を困難にせずにリプレイ保護を提供したり、驚くべきエラー条件が定期的に発生したり、実装に面倒なメモリ管理要件を課す環境を作成することです。このバランスは、トラストアンカーを使用して直接検証されたTAMPメッセージのシーケンス番号チェックを実行し、TAMPメッセージのオリジネーターが信頼アンカーで表されないときはいつでもこれらのチェックをスキップできるようにすることで達成されます。実装は、信頼アンカーを使用して直接検証されたTAMPメッセージのシーケンス番号チェックを実行する必要があり、認定パスを使用して検証されたTAMPメッセージのシーケンス番号チェックを実行する場合があります。
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.
TAMPステータスクエリ、トラストアンカーアップデート、Apex Trustアンカーアップデート、コミュニティの更新、シーケンス番号調整メッセージには、シーケンス番号が含まれます。この使い捨て識別子は、TAMPメッセージをそのTAMPメッセージへの応答と一致させるために使用されます。TAMPメッセージがTrustアンカーを使用して直接検証されると、シーケンス番号も使用されてTAMPメッセージリプレイを検出します。
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 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.
リプレイ保護を提供するために、各TAMPメッセージのオリジネーターは、シーケンス数を単調に増加させる非陰性整数として扱う必要があります。シーケンス番号カウンターは、秘密鍵によって実行される署名操作に関連付けられています。Trust Anchor Storeは、Trust Anchor Public Keyによって直接検証された新しく受信したTAMPメッセージに、そのオリジネーターからの最新の成功したTAMPメッセージよりも大きいシーケンス番号が含まれていることを確認する必要があります。シーケンス番号調整メッセージは、シーケンス番号がそのオリジネーターからの最新の正常に処理されたTAMPメッセージ以上である場合、有効と見なされることに注意してください。受信したTAMPメッセージのシーケンス番号がこれらの条件を満たしていない場合、Trust Anchor StoreはTAMPメッセージを拒否し、シーケンス番号障害（SEQNUMFAILURE）エラーを返す必要があります。
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.
Trust AnchorがTAMPメッセージに対して許可されている場合はいつでも、新しくインストールされたトラストアンカーとして、または既存のトラストアンカーの変更として、トラストアンカー更新メッセージにシーケンス番号値が提供されていない場合、シーケンス番号にメモリを割り当てる必要がありますゼロに設定します。その信頼アンカーを使用して検証された最初のTAMPメッセージは、シーケンス番号チェックに基づいて拒否されず、その最初のTAMPメッセージのシーケンス番号が保存されます。TAMPメッセージ受信者は、信頼できるアンカーからの成功した処理されたTAMPメッセージから、最新のシーケンス番号のデータベースを維持する必要があります。このデータベースのインデックスは、トラストアンカー公開キーです。これは、Apex Trust Anchor Operational Public KeyまたはManagement Trust Anchor公開キーです。最初のケースでは、Apex Trust Anchor Anchor Operational Public Keyを直接使用して、TAMPメッセージデジタル署名を検証します。2番目のケースでは、Management Trust Anchor公開キーを直接使用して、TAMPメッセージデジタル署名を検証します。
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.
シーケンス番号値は、64ビットの非陰性整数でなければなりません。整数のASN.1エンコードには常にサインビットが含まれているため、TAMPメッセージ署名者は64ビットシーケンス番号スペースを使い果たす前に9,223,372,036,854,775,807のTAMPメッセージを生成できます。トラストアンカーの更新とシーケンス番号調整メッセージによって提供されるシーケンス番号をリセットする機能は、別のキーペアへの移行を回避することを意図していません。むしろ、運用上のエラーからの回復を支援することを目的としています。Apex Trust AnchorおよびTAMPメッセージの認可された各管理トラストアンカーのトラストアンカーストアには、比較的小さな不揮発性ストレージ要件が課されています。
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.
Apex Trust AnchorまたはManagement Trust AnchorがTrust Anchor Storeから交換または削除される場合、関連するシーケンス番号ストレージを再生する必要があります。
When a TAMP update message is processed, several checks are performed:
TAMP更新メッセージが処理されると、いくつかのチェックが実行されます。
o TAMP message authentication is checked including, if necessary, building and validating a certification path to the signer.
o 必要に応じて、署名者への認証パスの構築と検証を含むTAMPメッセージ認証がチェックされます。
o The signer's authorization is checked, including authorization to manage trust anchors included in the update message.
o 署名者の承認は、更新メッセージに含まれる信頼アンカーを管理する許可を含むチェックされます。
o Calculation of the trust anchor information to be stored.
o 保存されるトラストアンカー情報の計算。
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.
このセクションでは、2番目と3番目のステップを実行する方法について説明します。セクション1.2では、TAMPメッセージの認証について説明します。信頼アンカーが証明書として表され、保存されるトラストアンカー情報の計算が証明書の情報とは異なる場合、TAMPアップデートは失敗します。Tampメッセージ署名者は、Trustanchorininfo構造の内部に証明書をラップして、意図した情報を主張することができます。
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.
Apex Trust Anchorは制約されていません。つまり、Apex Trust Anchor Operational Public Keyで署名されたTrust Anchor Updateメッセージで従属チェックを実行する必要はありません。従属チェックは、他のすべてのトラストアンカー更新メッセージの検証プロセスの一部として実行されます。
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.
Apex Trust Anchorで署名されていないTrust Anchor Updateメッセージの場合、運用公開キーを有効にするために、デジタル署名は、直接またはApex Trust Anchorを介したX.509認証パスを介して認定されたトラストアンカーを使用して検証する必要があります。運用上の公開キーまたは認定管理トラストアンカー。更新メッセージの検証の一部として、次の従属チェックも実行する必要があります。
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.
各トラストアンカー更新メッセージには、1つ以上の個別の更新が含まれており、それぞれが信頼アンカーの追加、変更、または削除に使用されます。個々の更新ごとに、TAMPメッセージ署名者の制約は、アップデート内のトラストアンカーの制約以上でなければなりません。具体的には、以下に説明するように、TrustanchorinFoオブジェクト（または証明書またはTBSCertificateオブジェクトの同等の拡張機能）のCertPathControlsフィールドに含まれる制約を確認する必要があります。[RFC5280]は、以下を参照する交差点と組合の操作がどのように実行されるかを説明しています。
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 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 Tampupdateの結果として信頼アンカーで保存されたポリシーフラグの値は、TAMPメッセージ署名者に関連付けられたポリシーフラグの値に真または等しい場合、つまり、更新は値が値の場合にのみFalseにフラグを設定することができます。TAMPメッセージ署名者に関連付けられているのは偽です。TAMPメッセージ署名者に関連付けられたポリシーフラグは、署名者が信頼アンカーとして表される場合、またはLiblicit_Policy、Policy_Mapping、および抑制されたパス検証の後に署名者が表現されていない場合に署名を阻害する場合、PolicyFlagsフィールドまたはPolicy -Cyconstraintsおよびbititanypolicy拡張から読み取られます。信頼のアンカー。
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 Tampupdateの結果として信頼アンカーで保存されている証明書ポリシーは、TAMPメッセージ署名者に関連する証明書ポリシーの値の交差点と、更新からのポリシセットフィールドまたは証明書の拡張の値の交差点に等しくなります。TAMPメッセージ署名者に関連する証明書ポリシーは、署名者が信頼アンカーとして表されている場合、または署名者が代表されていない場合にパス検証後に返された場合、証明書またはTBSCertificateのTrustanchOrinfoまたはTBSCertificateのTrustanchOrinfoまたはTBSCertificateの拡張機能のPolicySetフィールドから読み取られます。信頼のアンカー。TAMPメッセージ署名者が信頼のアンカーとして表されている場合、ポリシーマッピングは実行されません。交差点が無効であり、トゥーに保存されている要件の要件値が真である場合、TAMPの更新は失敗します。
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 Tampupdateの結果として信頼のアンカーで保存された除外された名前は、TAMPメッセージ署名者に関連付けられた除外された名前と、NameConstフィールドからの値またはアップデートからのNameConstraintsの拡張機能に等しい。TAMPメッセージ署名者に関連付けられている名前の制約は、署名者が信頼アンカーである場合、または署名者が信頼アンカーでない場合にパス検証に続いて、署名者が信託アンカーである場合、またはTBSCertificateのTrustanchorinfoまたはNameConstraints拡張機能のNameConstフィールドから読み取られます。。更新に含まれるトラストアンカーの名前は、TAMP署名者の除外された名前スペースに該当してはなりません。トラストアンカーの名前がTAMP署名者の除外された名前スペース内に収まる場合、TAMPの更新は失敗します。
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.
o Tampupdateの結果として信頼のアンカーで保存された許可された名前は、TAMPメッセージ署名者に関連付けられた許可された名前の交差点と、NameConstフィールドからの値または更新からのNameConstraints拡張の交差点に等しくなります。TAMPメッセージ署名者に関連付けられている名前の制約は、署名者が信託アンカーである場合、または署名者が信頼のアンカーでない場合にパス検証に続いて許可されたサブツリーの変数から証明書またはTBSCertificateのTrustanchorinfoまたはNameConstraints拡張機能のNameConstフィールドから読み取られます。。更新に含まれるトラストアンカーの名前は、タンプ署名者の許可された名前スペースに該当する必要があります。Trust Anchorの名前がTAMP署名者の許可された名前スペースに該当しない場合、TAMPの更新は失敗します。すべての名前フォームの交差点がnullの場合、TAMPの更新は失敗します。
No other extensions defined in [RFC5280] must be processed as part of subordination processing. Other extensions may define subordination rules.
[RFC5280]で定義されている他の拡張機能は、従属処理の一部として処理する必要はありません。その他の拡張機能は、従属規則を定義する場合があります。
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.
公開キー識別子を使用して、TAMPメッセージ署名者を識別します。同じ公開キー識別子が複数の公開キーに関連付けられていないという保証はないため、同じ公開キー識別子を持つために1つ以上の信頼アンカーを実装する必要があります。実際には、これは、デジタル署名検証が失敗する場合、実装がデジタル署名の検証に使用できる同じ公開キー識別子を持つ別の信頼アンカーがあるかどうかを実装する必要があることを意味します。複製された公開キー識別子はまれであると予想されますが、実装が発生したときに正しい信頼アンカーを見つけることに失敗してはなりません。
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.
X.500の著名な名前は、証明書発行者と証明書の科目を識別するために使用されます。同じX.500の著名な名前は、複数の信頼アンカーに関連付けられています。ただし、トラストアンカー公開キーは異なります。2つのトラストアンカーが同じx.500の著名な名前と同じ公開キー識別子を持つ可能性は、異なる公開キーが減少します。したがって、Authority Key Identifier証明書拡張機能を使用して、X.500の著名な名前の衝突を解決できます。
TAMP assumes a reliable underlying transport protocol.
TAMPは、信頼できる基礎となる輸送プロトコルを想定しています。
An apex trust anchor MAY contain contingency key information using the WrappedApexContingencyKey extension. The extension uses the ApexContingencyKey structure as defined below.
Apex Trustアンカーには、rappedapexContingencyKey拡張機能を使用して、偶発性キー情報が含まれている場合があります。拡張機能は、以下に定義するようにApexContingingEncyKey構造を使用します。
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.
ApexContingencyKeyのフィールドは、以下に説明するように使用されます。1つのフィールドが存在する場合、両方が存在する必要があります。1つのフィールドがない場合、両方が欠けている必要があります。対応する公開キーが一部の依存関係者によってApex Trustアンカーとして認識されていることを示す手段として、この拡張機能の使用を有効にするために、フィールドを欠席することができます。
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 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 wrapalgorithmは、Apex Trust Anchor Contingencyの公開キーを暗号化するために使用される対称アルゴリズムを識別します。この公開キーが必要な場合、それを復号化するために必要な対称キーは、それを使用して検証されるメッセージで提供されます。アルゴリズム識別子は、オブジェクト識別子とオプションのパラメーターを含むアルゴリズムIdentidifierです。オブジェクト識別子は、存在する場合のパラメーターの構文を示します。
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.
o lappedContinPubkeyは、暗号化されたApex Trustアンカーコンティンジェンシー公開鍵です。復号化されると、アルゴリズム識別子で構成されるpublicKeyInfo構造が生成され、公開キー自体が続きます。アルゴリズム識別子は、オブジェクト識別子とオプションのパラメーターを含むアルゴリズムIdentidifierです。オブジェクト識別子は、存在する場合、公開キーの形式とパラメーターの構文を示します。公開キーは、少し文字列としてエンコードされています。
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:
LappedApexContingEncyKey証明書拡張機能は重要である可能性があり、拡張機能のセットにせいぜい1回表示する必要があります。Apex Trust Anchor Info Extensionは、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 }
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.
この仕様の大部分は、TAMPメッセージの構文とセマンティクスに専念しています。他の仕様、特に[RFC5914]、[RFC3852]、[RFC5280]、信頼アンカー、中間CMSコンテンツタイプ、X.509証明書の構文とセマンティクスについては、それぞれ依存しています。トラストアンカーの信頼アンカーストアの状態を変更するTAMPメッセージは、常にトラストアンカーマネージャーによって署名されているため、さらなるデータの整合性またはデータ起源認証メカニズムは必要ありません。ただし、これらのメッセージの機密性は提供されていません。同様に、証明書はデジタル署名されており、追加のデータの整合性またはデータ起源認証メカニズムは必要ありません。トラストアンカー構成、信頼アンカーマネージャー証明書、および信頼できるアンカーストア証明書は、敏感であることを意図していません。その結果、この仕様はTAMPメッセージの機密性を提供しません。
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.
この仕様の範囲外のセキュリティ要因は、提供される保証に大きく影響します。認定当局（CAS）が使用する手順は、主題の公開鍵への拘束力を検証するために使用されています。これは、他のCAに証明書を発行する場合に特に重要です。TAMPの文脈では、管理信託アンカーの下での最終エンティティ証明書の発行は、委任行為です。ただし、このようなエンティティはさらに委任することはできません。
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.
一方、管理信託アンカーに基づくCA証明書の発行は、CAがさらに委任できる委任の行為です。代表団の範囲は、CA証明書に適切な証明書延長を含めることにより制約することができます。
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.
X.509認証パス構築には、X.500の著名な名前の比較が含まれます。名前の比較ルールの一貫性のない適用により、無効なX.509認証パスの受け入れまたは有効なパスの拒否が生じる可能性があります。名前の比較は非常に複雑です。Trust Anchor Storeにこの複雑さを課すことを避けるために、TAMPで使用される証明書プロファイルは、単純な名前構造を使用し、エンコードの方法を含む許容可能な識別名に厳密な制限を課す必要があります。その証明書プロファイルの目標は、簡単なバイナリ比較を有効にすることです。つまり、ケース変換、キャラクターセット変換、空白圧縮、およびリーディングおよびトレーリングホワイトスペースのトリミングを避ける必要があります。
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.
一部のデジタル署名アルゴリズム（DSA）には、ランダムな1回限りの値の生成が必要です。たとえば、DSAデジタル署名を生成する場合、署名者はランダムk値[DSS]を生成する必要があります。また、パブリック/秘密鍵のペアの生成は、乱数に依存しています。
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.
不十分な乱数ジェネレーター（RNG）または不十分な擬似ランダム数ジェネレーター（PRNG）を使用して、このような暗号化値を生成すると、セキュリティがほとんどまたはまったくなくなります。攻撃者は、乱数生成環境を再現する方がはるかに簡単になる可能性があり、スペース全体を検索するのではなく、結果として生じる小さな可能性のセットを検索します。
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.
アイデンティティトラストアンカーの妥協秘密キーは、対応するIDトラストアンカーで構成されたすべての信頼できるアンカーストアに受け入れられる証明書を発行することを許可されていない当事者を許可します。許可されていない秘密キーホルダーは、IDの信頼アンカーに関連する認証パスコントロールによって制限されます。たとえば、Identity Trust Anchorのクリアランスの制約は、不正な秘密キーホルダーによって発行される証明書で受け入れられるクリアランスを決定します。
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 type. For example, if the management trust anchor is associated with firmware packages, then the unauthorized private key holder can install different firmware.
管理トラストの妥協案の秘密キーは、対応する管理トラストアンカーで構成されたすべての信頼できるアンカーストアに受け入れられる署名済みメッセージを生成することを許可されていません。侵害された管理信託アンカーを含むすべてのデバイスは、セクション7で説明されている従属チェックの制限内で不正な秘密キーホルダーが望むように構成できます。キーホルダーは、そのタイプの署名付きメッセージを生成できます。たとえば、マネジメントトラストアンカーがファームウェアパッケージに関連付けられている場合、許可されていないプライベートキーホルダーは異なるファームウェアをインストールできます。
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.
Apex Trustの妥協運用秘密鍵は、対応するApex Trustアンカーで構成されたすべてのトラストアンカーストアに受け入れられる署名済みメッセージを生成することを許可されていないパーティーを許可します。Apex Trustアンカーを含むすべてのデバイスは、不正な秘密キーホルダーが望むように構成でき、許可されていない秘密鍵ホルダーは、任意のコンテンツタイプの署名型メッセージを生成できます。オプションの偶発性の秘密鍵は、そのような妥協から回復する潜在的な方法を提供します。
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.
CAの秘密鍵の妥協は、アイデンティティや管理信託アンカーの秘密鍵と同じタイプの問題につながります。許可されていない秘密キーホルダーは、信頼アンカーに関連付けられた認証パスコントロールと拡張機能によって制限されます。
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.
End Entityの秘密鍵の妥協は、End Entityが証明書を発行できないことを除いて、IDまたは管理トラストアンカーの秘密鍵と同じタイプの問題につながります。許可されていない秘密キーホルダーは、信頼アンカーに関連付けられた認証パスコントロールと拡張機能によって制限されます。
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.
Trust Anchor Storeのデジタル署名の秘密キーの妥協により、不正なパーティーは、信頼できるアンカーストアを装った署名済みのTAMP応答メッセージを生成することを許可します。
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.
Apex Trust Anchor Contingency Public Keyを暗号化するために使用されるキー暗号化キーの早期開示は、Apex Trustアンカーコンティンジェンシー公開キーの早期露出をもたらす可能性があります。
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.
TAMPの実装は、メッセージと証明書を解析できる必要があります。TAMPメッセージパーサーまたはメッセージコンテンツに作用する処理に実装欠陥がないことを確認するために注意する必要があります。検証スイートは、TAMPメッセージ、CMSコンテンツタイプ、属性、証明書、拡張機能の解析に対する信頼性を高める1つの方法です。
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.
Trustanchorlistメッセージは、リプレイ検出メカニズムを提供しません。Trustanchorlistメッセージが信頼アンカーに信頼アンカーを追加する代替手段として受け入れられている場合、アプリケーションは、古いTrustanchorlistメッセージのリプレイに関連するリスクに対処するために追加のメカニズムを必要とする場合があります。
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.
シーケンス番号の値がリプレイの試みを検出するために使用されるため、トラストアンカーストアマネージャーは、独自のシーケンス番号状態を維持するように注意する必要があります。シーケンス番号状態の損失は、seqnumfailureのために処理できないTAMPメッセージの生成をもたらす可能性があります。損失が発生した場合、シーケンス番号状態は、最近生成されたTAMPメッセージを検査することで復元できます。
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.
TAMPリクエストと応答の詳細は、オブジェクト識別子（OID）を使用して通信されます。オブジェクトは、IANAによってPKIXワーキンググループに委任されたアークで定義されています。このドキュメントには、付録Bに11のメディアタイプ登録も含まれています。このドキュメントまたは予想される更新には、IANAによるさらなるアクションは必要ありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[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.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 5652、2009年9月。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
[RFC5912] Hoffman、P。およびJ. Schaad、「X.509（PKIX）を使用した公開キーインフラストラクチャの新しいASN.1モジュール」、RFC 5912、2010年6月。
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, June 2010.
[RFC5914] Housley、R.、Ashmore、S。、およびC. Wallace、「Trust Anchor Format」、RFC 5914、2010年6月。
[X.680] "ITU-T Recommendation X.680 - Information Technology - Abstract Syntax Notation One", 1997.
[X.680]「ITU -Tの推奨X.680-情報技術 - 抽象的構文表記1」、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.
[X.690] "ITU -T推奨X.690-情報技術-ASN.1エンコーディングルール：基本エンコーディングルール（BER）、標準エンコードルール（CER）、著名なエンコードルール（DER）の仕様"、1997。
[DSS] "FIPS Pub 186: Digital Signature Standard", May 1994.
[DSS]「Fips Pub 186：Digital Signature Standard」、1994年5月。
[PKCS#6] "PKCS #6: Extended-Certificate Syntax Standard, Version 1.5", November 1993.
[PKCS＃6] "PKCS＃6：ExtendedCertificate Syntax Standard、バージョン1.5"、1993年11月。
[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.
[RFC3279] Bassham、L.、Polk、W。、およびR. Housley、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイルのアルゴリズムと識別子」、RFC 3279、2002年4月。
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[RFC3370] Housley、R。、「暗号化メッセージ構文（CMS）アルゴリズム」、RFC 3370、2002年8月。
[RFC4049] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 4049, April 2005.
[RFC4049] Housley、R。、「BinaryTime：ASN.1で日付と時刻を表すための代替形式」、RFC 4049、2005年4月。
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
[RFC4108] Housley、R。、「暗号化メッセージ構文（CMS）を使用してファームウェアパッケージを保護する」、RFC 4108、2005年8月。
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, January 2010.
[RFC5753] Turner、S。およびD. Brown、「暗号化メッセージ構文（CMS）における楕円曲線暗号化（ECC）アルゴリズムの使用」、RFC 5753、2010年1月。
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[RFC5754] Turner、S。、「暗号化メッセージ構文を使用したSHA2アルゴリズムを使用」、RFC 5754、2010年1月。
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010.
[RFC5755] Farrell、S.、Housley、R。、およびS. Turner、「認証のためのインターネット属性証明書プロファイル」、RFC 5755、2010年1月。
[TA-MGMT-REQS] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", Work in Progress, March 2010.
[Ta-Mgmt-reqs] Reddy、R。およびC. Wallace、「信頼アンカー管理要件」、2010年3月の作業。
[X.208] "ITU-T Recommendation X.208 - Specification of Abstract Syntax Notation One (ASN.1)", 1988.
[X.208]「ITU -T推奨X.208-抽象的構文表記の仕様（ASN.1）」、1988。
[X.509] "ITU-T Recommendation X.509 - The Directory - Authentication Framework", 2000.
[X.509]「ITU -T推奨X.509-ディレクトリ - 認証フレームワーク」、2000。
Appendix A.1 provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680]. Appendix A.2 provides a module using ASN.1 as defined in [X.208]. The module in Appendix A.2 removes usage of newer ASN.1 features that provide support for limiting the types of elements that may appear in certain SEQUENCE and SET constructions. Otherwise, the modules are compatible in terms of encoded representation, i.e., the modules are bits-on-the-wire compatible aside from the limitations on SEQUENCE and SET constituents. Extension markers are not used due to lack of support in [X.208]. Appendix A.2 is included as a courtesy to developers using ASN.1 compilers that do not support current ASN.1. Appendix A.1 includes definitions imported from [RFC5280], [RFC5912], and [RFC5914].
付録A.1は、[X.680]で定義されているASN.1を使用して、この仕様で説明されている構造の規範ASN.1定義を提供します。付録A.2は、[x.208]で定義されているように、asn.1を使用したモジュールを提供します。付録A.2のモジュールは、特定のシーケンスに表示され、構造を設定する可能性のある要素の種類を制限するためのサポートを提供する新しいASN.1機能の使用を削除します。それ以外の場合、モジュールはエンコードされた表現の観点から互換性があります。つまり、モジュールは、シーケンスとセット構成要素の制限以外に、ワイヤに互換性があります。[x.208]のサポートが不足しているため、拡張マーカーは使用されません。付録A.2は、現在のASN.1をサポートしていないASN.1コンパイラを使用して開発者の礼儀として含まれています。付録A.1には、[RFC5280]、[RFC5912]、および[RFC5914]からインポートされた定義が含まれています。
TAMP-Protocol-v2
{ joint-iso-ccitt(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) modules(0) 30 }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
TrustAnchorChoice, TrustAnchorTitle, CertPathControls
FROM TrustAnchorInfoModule
{ joint-iso-ccitt(2) country(16) us(840)
organization(1) gov(101) dod(2) infosec(1)
modules(0) 33 }
AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, KEY-WRAP
FROM AlgorithmInformation-2009
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
Certificate, Name, TBSCertificate,
CertificateSerialNumber, Validity, SubjectPublicKeyInfo
FROM PKIX1Explicit-2009 -- from [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51)}
KeyIdentifier, OTHER-NAME
FROM PKIX1Implicit-2009 -- from [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-implicit-02(59)}
EXTENSION, Extensions {}, ATTRIBUTE, SingleAttribute{}
FROM PKIX-CommonTypes-2009 -- from [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ;
-- Object Identifier Arc for TAMP Message Content Types
-TAMPメッセージコンテンツタイプのオブジェクト識別子アーク
id-tamp OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) formats(2) 77 }
SupportedSigAlgorithms SIGNATURE-ALGORITHM ::= {
-- add any locally defined algorithms here
...
}
SupportedWrapAlgorithms KEY-WRAP ::= {
-- add any locally defined algorithms here
...
}
-- CMS Content Types
-CMSコンテンツタイプ
CONTENT-TYPE ::= TYPE-IDENTIFIER
TAMPContentTypes CONTENT-TYPE ::= {
tamp-status-query |
tamp-status-response |
tamp-update |
tamp-update-confirm |
tamp-apex-update |
tamp-apex-update-confirm |
tamp-community-update |
tamp-community-update-confirm |
tamp-sequence-number-adjust |
tamp-sequence-number-adjust-confirm |
tamp-error,
... -- Expect additional content types --
}
-- TAMP Status Query Message
tamp-status-query CONTENT-TYPE ::=
{ TAMPStatusQuery IDENTIFIED BY id-ct-TAMP-statusQuery }
id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 }
TAMPStatusQuery ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
query TAMPMsgRef }
TAMPVersion ::= INTEGER { v1(1), v2(2) }
TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) }
SeqNumber ::= INTEGER (0..9223372036854775807)
TAMPMsgRef ::= SEQUENCE {
target TargetIdentifier,
seqNum SeqNumber }
TargetIdentifier ::= CHOICE {
hwModules [1] HardwareModuleIdentifierList,
communities [2] CommunityIdentifierList,
allModules [3] NULL,
uri [4] IA5String,
otherName [5] INSTANCE OF OTHER-NAME }
HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF
HardwareModules
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry }
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community
Community ::= OBJECT IDENTIFIER
-- TAMP Status Response Message
-TAMPステータス応答メッセージ
tamp-status-response CONTENT-TYPE ::=
{ TAMPStatusResponse IDENTIFIED BY id-ct-TAMP-statusResponse }
id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 }
TAMPStatusResponse ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
query TAMPMsgRef,
response StatusResponse,
usesApex BOOLEAN DEFAULT TRUE }
StatusResponse ::= CHOICE {
terseResponse [0] TerseStatusResponse,
verboseResponse [1] VerboseStatusResponse }
TerseStatusResponse ::= SEQUENCE {
taKeyIds KeyIdentifiers,
communities CommunityIdentifierList OPTIONAL }
KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier
VerboseStatusResponse ::= SEQUENCE {
taInfo TrustAnchorChoiceList,
continPubKeyDecryptAlg [0] AlgorithmIdentifier
{KEY-WRAP, {SupportedWrapAlgorithms}} OPTIONAL,
communities [1] CommunityIdentifierList OPTIONAL,
tampSeqNumbers [2] TAMPSequenceNumbers OPTIONAL }
TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF
TrustAnchorChoice
TAMPSequenceNumber ::= SEQUENCE {
keyId KeyIdentifier,
seqNumber SeqNumber }
TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF TAMPSequenceNumber
-- Trust Anchor Update Message
- アンカー更新メッセージを信頼します
tamp-update CONTENT-TYPE ::=
{ TAMPUpdate IDENTIFIED BY id-ct-TAMP-update }
id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 }
TAMPUpdate ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
msgRef TAMPMsgRef,
updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate,
tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL }
TrustAnchorUpdate ::= CHOICE {
add [1] TrustAnchorChoice,
remove [2] SubjectPublicKeyInfo,
change [3] EXPLICIT TrustAnchorChangeInfoChoice }
TrustAnchorChangeInfoChoice ::= CHOICE {
tbsCertChange [0] TBSCertificateChangeInfo,
taChange [1] TrustAnchorChangeInfo }
TBSCertificateChangeInfo ::= SEQUENCE {
serialNumber CertificateSerialNumber OPTIONAL,
signature [0] AlgorithmIdentifier
{SIGNATURE-ALGORITHM, {SupportedSigAlgorithms}} OPTIONAL,
issuer [1] Name OPTIONAL,
validity [2] Validity OPTIONAL,
subject [3] Name OPTIONAL,
subjectPublicKeyInfo [4] SubjectPublicKeyInfo,
exts [5] EXPLICIT Extensions{{...}} OPTIONAL }
TrustAnchorChangeInfo ::= SEQUENCE {
pubKey SubjectPublicKeyInfo,
keyId KeyIdentifier OPTIONAL,
taTitle TrustAnchorTitle OPTIONAL,
certPath CertPathControls OPTIONAL,
exts [1] Extensions{{...}} OPTIONAL }
-- Trust Anchor Update Confirm Message
- アンカーアップデートを信頼して、メッセージを確認します
tamp-update-confirm CONTENT-TYPE ::=
{ TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm }
id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 }
TAMPUpdateConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
update TAMPMsgRef,
confirm UpdateConfirm }
UpdateConfirm ::= CHOICE {
terseConfirm [0] TerseUpdateConfirm,
verboseConfirm [1] VerboseUpdateConfirm }
TerseUpdateConfirm ::= StatusCodeList
StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode
VerboseUpdateConfirm ::= SEQUENCE {
status StatusCodeList,
taInfo TrustAnchorChoiceList,
tampSeqNumbers TAMPSequenceNumbers OPTIONAL,
usesApex BOOLEAN DEFAULT TRUE }
-- Apex Trust Anchor Update Message
-Apex Trust Anchor Updateメッセージ
tamp-apex-update CONTENT-TYPE ::=
{ TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate }
id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 }
TAMPApexUpdate ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
msgRef TAMPMsgRef,
clearTrustAnchors BOOLEAN,
clearCommunities BOOLEAN,
seqNumber SeqNumber OPTIONAL,
apexTA TrustAnchorChoice }
-- Apex Trust Anchor Update Confirm Message
-Apex Trustアンカーアップデートメッセージを確認します
tamp-apex-update-confirm CONTENT-TYPE ::=
{ TAMPApexUpdateConfirm IDENTIFIED BY
id-ct-TAMP-apexUpdateConfirm }
id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 }
TAMPApexUpdateConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
apexReplace TAMPMsgRef,
apexConfirm ApexUpdateConfirm }
ApexUpdateConfirm ::= CHOICE {
terseApexConfirm [0] TerseApexUpdateConfirm,
verboseApexConfirm [1] VerboseApexUpdateConfirm }
TerseApexUpdateConfirm ::= StatusCode
VerboseApexUpdateConfirm ::= SEQUENCE {
status StatusCode,
taInfo TrustAnchorChoiceList,
communities [0] CommunityIdentifierList OPTIONAL,
tampSeqNumbers [1] TAMPSequenceNumbers OPTIONAL }
-- Community Update Message
- コミュニティ更新メッセージ
tamp-community-update CONTENT-TYPE ::=
{ TAMPCommunityUpdate IDENTIFIED BY id-ct-TAMP-communityUpdate }
id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 }
TAMPCommunityUpdate ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
msgRef TAMPMsgRef,
updates CommunityUpdates }
CommunityUpdates ::= SEQUENCE {
remove [1] CommunityIdentifierList OPTIONAL,
add [2] CommunityIdentifierList OPTIONAL }
-- At least one must be present
-- Community Update Confirm Message
- コミュニティの更新にメッセージが確認されます
tamp-community-update-confirm CONTENT-TYPE ::=
{ TAMPCommunityUpdateConfirm IDENTIFIED BY
id-ct-TAMP-communityUpdateConfirm }
id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::=
{ id-tamp 8 }
TAMPCommunityUpdateConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
update TAMPMsgRef,
commConfirm CommunityConfirm }
CommunityConfirm ::= CHOICE {
terseCommConfirm [0] TerseCommunityConfirm,
verboseCommConfirm [1] VerboseCommunityConfirm }
TerseCommunityConfirm ::= StatusCode
VerboseCommunityConfirm ::= SEQUENCE {
status StatusCode,
communities CommunityIdentifierList OPTIONAL }
-- Sequence Number Adjust Message
- シーケンス番号調整メッセージ
tamp-sequence-number-adjust CONTENT-TYPE ::=
{ SequenceNumberAdjust IDENTIFIED BY id-ct-TAMP-seqNumAdjust }
id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 }
SequenceNumberAdjust ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
msgRef TAMPMsgRef }
msgref tampmsgref}
-- Sequence Number Adjust Confirm Message
- シーケンス番号を調整して、メッセージを確認します
tamp-sequence-number-adjust-confirm CONTENT-TYPE ::=
{ SequenceNumberAdjustConfirm IDENTIFIED BY
id-ct-TAMP-seqNumAdjustConfirm }
id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= { id-tamp 11 }
SequenceNumberAdjustConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
adjust TAMPMsgRef,
status StatusCode }
-- TAMP Error Message
- タンプエラーメッセージ
tamp-error CONTENT-TYPE ::=
{ TAMPError IDENTIFIED BY id-ct-TAMP-error }
id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 }
TAMPError ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
msgType OBJECT IDENTIFIER,
status StatusCode,
msgRef TAMPMsgRef OPTIONAL }
-- Status Codes
- ステータスコード
StatusCode ::= ENUMERATED {
success (0),
decodeFailure (1),
badContentInfo (2),
badSignedData (3),
badEncapContent (4),
badCertificate (5),
badSignerInfo (6),
badSignedAttrs (7),
badUnsignedAttrs (8),
missingContent (9),
noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
unsupportedParameters (15),
signatureFailure (16),
insufficientMemory (17),
unsupportedTAMPMsgType (18),
apexTAMPAnchor (19),
improperTAAddition (20),
seqNumFailure (21),
contingencyPublicKeyDecrypt (22),
incorrectTarget (23),
communityUpdateFailed (24),
trustAnchorNotFound (25),
unsupportedTAAlgorithm (26),
unsupportedTAKeySize (27),
unsupportedContinPubKeyDecryptAlg (28),
missingSignature (29),
resourcesBusy (30),
versionNumberMismatch (31),
missingPolicySet (32),
revokedCertificate (33),
unsupportedTrustAnchorFormat (34),
improperTAChange (35),
malformed (36),
cmsError (37),
unsupportedTargetIdentifier (38),
other (127) }
-- Object Identifier Arc for Attributes
- 属性のオブジェクト識別子アーク
id-attributes OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16)
us(840) organization(1) gov(101) dod(2) infosec(1) 5 }
-- TAMP Unsigned Attributes
-- These attributes are unsigned attributes and go into the
-- UnsignedAttributes set in [RFC5652]
TAMPUnsignedAttributes ATTRIBUTE ::= {
contingency-public-key-decrypt-key,
... -- Expect additional attributes --
}
-- contingency-public-key-decrypt-key unsigned attribute
-Contingency-Public-Key-Key-Decrypt-Key Unsigned属性
contingency-public-key-decrypt-key ATTRIBUTE ::= {
TYPE PlaintextSymmetricKey IDENTIFIED BY
id-aa-TAMP-contingencyPublicKeyDecryptKey }
id-aa-TAMP-contingencyPublicKeyDecryptKey OBJECT IDENTIFIER ::= {
id-attributes 63 }
PlaintextSymmetricKey ::= OCTET STRING
-- id-pe-wrappedApexContinKey extension
-ID-PE-WRAPPEDAPEXCONTINKEY拡張機能
wrappedApexContinKey EXTENSION ::= {
SYNTAX ApexContingencyKey
IDENTIFIED BY id-pe-wrappedApexContinKey }
id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) pe(1) 20 }
ApexContingencyKey ::= SEQUENCE {
wrapAlgorithm
AlgorithmIdentifier{KEY-WRAP, {SupportedWrapAlgorithms}},
wrappedContinPubKey OCTET STRING }
END
終わり
TAMP-Protocol-v2-88
{ joint-iso-ccitt(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) modules(0) 31 }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
TrustAnchorChoice, TrustAnchorTitle, CertPathControls
FROM TrustAnchorInfoModule-88 -- from [RFC5914]
{ joint-iso-ccitt(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) modules(0) 37 }
AlgorithmIdentifier, Certificate, Name, Attribute, TBSCertificate,
SubjectPublicKeyInfo, CertificateSerialNumber, Validity, Extensions
FROM PKIX1Explicit88 -- from [RFC5280]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) }
KeyIdentifier, AnotherName
FROM PKIX1Implicit88 -- from [RFC5280]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19) } ;
-- Object Identifier Arc for TAMP Message Content Types
-TAMPメッセージコンテンツタイプのオブジェクト識別子アーク
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
-CMSコンテンツタイプ
-- TAMP Status Query Message
-TAMPステータスクエリメッセージ
id-ct-TAMP-statusQuery OBJECT IDENTIFIER ::= { id-tamp 1 }
TAMPStatusQuery ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
query TAMPMsgRef }
TAMPVersion ::= INTEGER { v1(1), v2(2) }
TerseOrVerbose ::= ENUMERATED { terse(1), verbose(2) }
SeqNumber ::= INTEGER (0..9223372036854775807)
TAMPMsgRef ::= SEQUENCE {
target TargetIdentifier,
seqNum SeqNumber }
TargetIdentifier ::= CHOICE {
hwModules [1] HardwareModuleIdentifierList,
communities [2] CommunityIdentifierList,
allModules [3] NULL,
uri [4] IA5String,
otherName [5] AnotherName }
HardwareModuleIdentifierList ::= SEQUENCE SIZE (1..MAX) OF
HardwareModules
HardwareModules ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialEntries SEQUENCE SIZE (1..MAX) OF HardwareSerialEntry }
HardwareSerialEntry ::= CHOICE {
all NULL,
single OCTET STRING,
block SEQUENCE {
low OCTET STRING,
high OCTET STRING } }
CommunityIdentifierList ::= SEQUENCE SIZE (0..MAX) OF Community
Community ::= OBJECT IDENTIFIER
-- TAMP Status Response Message
-TAMPステータス応答メッセージ
id-ct-TAMP-statusResponse OBJECT IDENTIFIER ::= { id-tamp 2 }
TAMPStatusResponse ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
query TAMPMsgRef,
response StatusResponse,
usesApex BOOLEAN DEFAULT TRUE }
StatusResponse ::= CHOICE {
terseResponse [0] TerseStatusResponse,
verboseResponse [1] VerboseStatusResponse }
TerseStatusResponse ::= SEQUENCE {
taKeyIds KeyIdentifiers,
communities CommunityIdentifierList OPTIONAL }
KeyIdentifiers ::= SEQUENCE SIZE (1..MAX) OF KeyIdentifier
VerboseStatusResponse ::= SEQUENCE {
taInfo TrustAnchorChoiceList,
continPubKeyDecryptAlg [0] AlgorithmIdentifier OPTIONAL,
communities [1] CommunityIdentifierList OPTIONAL,
tampSeqNumbers [2] TAMPSequenceNumbers OPTIONAL }
TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF
TrustAnchorChoice
TAMPSequenceNumber ::= SEQUENCE {
keyId KeyIdentifier,
seqNumber SeqNumber }
TAMPSequenceNumbers ::= SEQUENCE SIZE (1..MAX) OF
TAMPSequenceNumber
-- Trust Anchor Update Message
- アンカー更新メッセージを信頼します
id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 }
TAMPUpdate ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
msgRef TAMPMsgRef,
updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate,
tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL }
TrustAnchorUpdate ::= CHOICE {
add [1] TrustAnchorChoice,
remove [2] SubjectPublicKeyInfo,
change [3] EXPLICIT TrustAnchorChangeInfoChoice }
TrustAnchorChangeInfoChoice ::= CHOICE {
tbsCertChange [0] TBSCertificateChangeInfo,
taChange [1] TrustAnchorChangeInfo }
TBSCertificateChangeInfo ::= SEQUENCE {
serialNumber CertificateSerialNumber OPTIONAL,
signature [0] AlgorithmIdentifier OPTIONAL,
issuer [1] Name OPTIONAL,
validity [2] Validity OPTIONAL,
subject [3] Name OPTIONAL,
subjectPublicKeyInfo [4] SubjectPublicKeyInfo,
exts [5] EXPLICIT Extensions OPTIONAL }
TrustAnchorChangeInfo ::= SEQUENCE {
pubKey SubjectPublicKeyInfo,
keyId KeyIdentifier OPTIONAL,
taTitle TrustAnchorTitle OPTIONAL,
certPath CertPathControls OPTIONAL,
exts [1] Extensions OPTIONAL }
-- Trust Anchor Update Confirm Message
- アンカーアップデートを信頼して、メッセージを確認します
id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 }
TAMPUpdateConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
update TAMPMsgRef,
confirm UpdateConfirm }
UpdateConfirm ::= CHOICE {
terseConfirm [0] TerseUpdateConfirm,
verboseConfirm [1] VerboseUpdateConfirm }
TerseUpdateConfirm ::= StatusCodeList
StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode
VerboseUpdateConfirm ::= SEQUENCE {
status StatusCodeList,
taInfo TrustAnchorChoiceList,
tampSeqNumbers TAMPSequenceNumbers OPTIONAL,
usesApex BOOLEAN DEFAULT TRUE }
-- Apex Trust Anchor Update Message
-Apex Trust Anchor Updateメッセージ
id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 }
TAMPApexUpdate ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
msgRef TAMPMsgRef,
clearTrustAnchors BOOLEAN,
clearCommunities BOOLEAN,
seqNumber SeqNumber OPTIONAL,
apexTA TrustAnchorChoice }
-- Apex Trust Anchor Update Confirm Message
-Apex Trustアンカーアップデートメッセージを確認します
id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 }
TAMPApexUpdateConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
apexReplace TAMPMsgRef,
apexConfirm ApexUpdateConfirm }
ApexUpdateConfirm ::= CHOICE {
terseApexConfirm [0] TerseApexUpdateConfirm,
verboseApexConfirm [1] VerboseApexUpdateConfirm }
TerseApexUpdateConfirm ::= StatusCode
VerboseApexUpdateConfirm ::= SEQUENCE {
status StatusCode,
taInfo TrustAnchorChoiceList,
communities [0] CommunityIdentifierList OPTIONAL,
tampSeqNumbers [1] TAMPSequenceNumbers OPTIONAL }
-- Community Update Message
- コミュニティ更新メッセージ
id-ct-TAMP-communityUpdate OBJECT IDENTIFIER ::= { id-tamp 7 }
TAMPCommunityUpdate ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
msgRef TAMPMsgRef,
updates CommunityUpdates }
CommunityUpdates ::= SEQUENCE {
remove [1] CommunityIdentifierList OPTIONAL,
add [2] CommunityIdentifierList OPTIONAL }
-- At least one must be present
-- Community Update Confirm Message
- コミュニティの更新にメッセージが確認されます
id-ct-TAMP-communityUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 8 }
TAMPCommunityUpdateConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
update TAMPMsgRef,
commConfirm CommunityConfirm }
CommunityConfirm ::= CHOICE {
terseCommConfirm [0] TerseCommunityConfirm,
verboseCommConfirm [1] VerboseCommunityConfirm }
TerseCommunityConfirm ::= StatusCode
VerboseCommunityConfirm ::= SEQUENCE {
status StatusCode,
communities CommunityIdentifierList OPTIONAL }
-- Sequence Number Adjust Message
- シーケンス番号調整メッセージ
id-ct-TAMP-seqNumAdjust OBJECT IDENTIFIER ::= { id-tamp 10 }
SequenceNumberAdjust ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
msgRef TAMPMsgRef }
-- Sequence Number Adjust Confirm Message
- シーケンス番号を調整して、メッセージを確認します
id-ct-TAMP-seqNumAdjustConfirm OBJECT IDENTIFIER ::= { id-tamp 11 }
SequenceNumberAdjustConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
adjust TAMPMsgRef,
status StatusCode }
-- TAMP Error Message
- タンプエラーメッセージ
id-ct-TAMP-error OBJECT IDENTIFIER ::= { id-tamp 9 }
TAMPError ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
msgType OBJECT IDENTIFIER,
status StatusCode,
msgRef TAMPMsgRef OPTIONAL }
-- Status Codes
- ステータスコード
StatusCode ::= ENUMERATED {
success (0),
decodeFailure (1),
badContentInfo (2),
badSignedData (3),
badEncapContent (4),
badCertificate (5),
badSignerInfo (6),
badSignedAttrs (7),
badUnsignedAttrs (8),
missingContent (9),
noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
unsupportedParameters (15),
signatureFailure (16),
insufficientMemory (17),
unsupportedTAMPMsgType (18),
apexTAMPAnchor (19),
improperTAAddition (20),
seqNumFailure (21),
contingencyPublicKeyDecrypt (22),
incorrectTarget (23),
communityUpdateFailed (24),
trustAnchorNotFound (25),
unsupportedTAAlgorithm (26),
unsupportedTAKeySize (27),
unsupportedContinPubKeyDecryptAlg (28),
missingSignature (29),
resourcesBusy (30),
versionNumberMismatch (31),
missingPolicySet (32),
revokedCertificate (33),
unsupportedTrustAnchorFormat (34),
improperTAChange (35),
malformed (36),
cmsError (37),
unsupportedTargetIdentifier (38),
other (127) }
-- Object Identifier Arc for Attributes
- 属性のオブジェクト識別子アーク
id-attributes OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16)
us(840) organization(1) gov(101) dod(2) infosec(1) 5 }
-- id-aa-TAMP-contingencyPublicKeyDecryptKey uses
-- PlaintextSymmetricKey syntax
id-aa-TAMP-contingencyPublicKeyDecryptKey OBJECT IDENTIFIER ::= {
id-attributes 63 }
PlaintextSymmetricKey ::= OCTET STRING
-- id-pe-wrappedApexContinKey extension
-ID-PE-WRAPPEDAPEXCONTINKEY拡張機能
id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) pe(1) 20 }
ApexContingencyKey ::= SEQUENCE {
wrapAlgorithm AlgorithmIdentifier,
wrappedContinPubKey OCTET STRING }
END
終わり
Eleven media type registrations are provided in this appendix, one for each content type defined in this specification. As noted in Section 2, in all cases TAMP messages are encapsulated within ContentInfo structures. Signed messages are additionally encapsulated within a SignedData structure.
この付録では、11のメディアタイプの登録が提供されています。1つは、この仕様で定義されているコンテンツタイプごとに1つあります。セクション2で述べたように、すべての場合、TAMPメッセージはContentInfo構造内にカプセル化されています。署名されたメッセージは、signedData構造内でさらにカプセル化されます。
Media type name: application
メディアタイプ名：アプリケーション
Subtype name: tamp-status-query
サブタイプ名：Tamp-Status-Query
Required parameters: None
必要なパラメーター：なし
Optional parameters: None Encoding considerations: binary
オプションのパラメーター：なしエンコーディングに関する考慮事項：バイナリ
Security considerations: Carries a signed request for status information. Integrity protection is discussed in Section 4.1. Replay detection is discussed in Section 6.
セキュリティ上の考慮事項：ステータス情報の署名されたリクエストを搭載しています。整合性保護については、セクション4.1で説明します。リプレイ検出については、セクション6で説明します。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 5934
公開された仕様：RFC 5934
Applications that use this media type: TAMP clients responding to requests for status information.
このメディアタイプを使用するアプリケーション：TAMPクライアントは、ステータス情報のリクエストに応答します。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー：なし
File extension(s): .tsq
ファイル拡張子：.tsq
Macintosh File Type Code(s):
Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Sam Ashmore - srashmo@radium.ncsc.mil
サムアシュモア-srashmo@radium.ncsc.mil
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: None
使用に関する制限：なし
Author: Sam Ashmore - srashmo@radium.ncsc.mil
Change controller: IESG
Change Controller：IESG
Media type name: application
メディアタイプ名：アプリケーション
Subtype name: tamp-status-response
サブタイプ名：TAMP-STATUS-Response
Required parameters: None
必要なパラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: binary
考慮事項のエンコード：バイナリ
Security considerations: Carries optionally signed status information. Integrity protection is discussed in Section 4.2.
セキュリティ上の考慮事項：オプションで署名されたステータス情報を伝えます。整合性保護については、セクション4.2で説明します。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 5934
公開された仕様：RFC 5934
Applications that use this media type: TAMP clients responding to requests for status information.
このメディアタイプを使用するアプリケーション：TAMPクライアントは、ステータス情報のリクエストに応答します。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー：なし
File extension(s): .tsr
ファイル拡張子：.tsr
Macintosh File Type Code(s):
Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Sam Ashmore - srashmo@radium.ncsc.mil
サムアシュモア-srashmo@radium.ncsc.mil
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: None
使用に関する制限：なし
Author: Sam Ashmore - srashmo@radium.ncsc.mil
Change controller: IESG
Change Controller：IESG
Media type name: application
メディアタイプ名：アプリケーション
Subtype name: tamp-update
サブタイプ名：Tamp-Update
Required parameters: None
必要なパラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: binary
考慮事項のエンコード：バイナリ
Security considerations: Carries a signed trust anchor update message. Integrity protection is discussed in Section 4.3. Replay detection is discussed in Section 6.
セキュリティ上の考慮事項：署名されたトラストアンカー更新メッセージを伝えます。整合性保護については、セクション4.3で説明します。リプレイ検出については、セクション6で説明します。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 5934 Applications that use this media type: TAMP clients responding to requests to update trust anchor information.
公開された仕様：このメディアタイプを使用するRFC 5934アプリケーション：TAMPクライアントは、トラストアンカー情報を更新するリクエストに応答します。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー：なし
File extension(s): .tur
ファイル拡張子：.tur
Macintosh File Type Code(s):
Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Sam Ashmore - srashmo@radium.ncsc.mil
サムアシュモア-srashmo@radium.ncsc.mil
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: None
使用に関する制限：なし
Author: Sam Ashmore - srashmo@radium.ncsc.mil
Change controller: IESG
Change Controller：IESG
Media type name: application
メディアタイプ名：アプリケーション
Subtype name: tamp-update-confirm
サブタイプ名：tamp-update-confirm
Required parameters: None
必要なパラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: binary
考慮事項のエンコード：バイナリ
Security considerations: Carries an optionally signed TAMP update response. Integrity protection is discussed in Section 4.4.
セキュリティ上の考慮事項：オプションで署名されたTAMP更新応答が含まれています。整合性保護については、セクション4.4で説明します。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 5934
公開された仕様：RFC 5934
Applications that use this media type: TAMP clients responding to requests to update trust anchor information.
このメディアタイプを使用するアプリケーション：TAMPクライアントは、トラストアンカー情報を更新するためのリクエストに応答します。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー：なし
File extension(s): .tuc
ファイル拡張子：.tuc
Macintosh File Type Code(s):
Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Sam Ashmore - srashmo@radium.ncsc.mil
サムアシュモア-srashmo@radium.ncsc.mil
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: None
使用に関する制限：なし
Author: Sam Ashmore - srashmo@radium.ncsc.mil
Change controller: IESG
Change Controller：IESG
Media type name: application
メディアタイプ名：アプリケーション
Subtype name: tamp-apex-update
サブタイプ名：tamp-apex-update
Required parameters: None
必要なパラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: binary
考慮事項のエンコード：バイナリ
Security considerations: Carries a signed request to update an apex trust anchor information. Integrity protection is discussed in Section 4.5. Replay detection is discussed in Section 6.
セキュリティ上の考慮事項：Apex Trustアンカー情報を更新するための署名済みのリクエストがあります。整合性保護については、セクション4.5で説明します。リプレイ検出については、セクション6で説明します。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 5934
公開された仕様：RFC 5934
Applications that use this media type: TAMP clients responding to requests to update an apex trust anchor.
このメディアタイプを使用するアプリケーション：TAMPクライアントは、Apex Trustアンカーを更新するための要求に応答します。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー：なし
File extension(s): .tau
ファイル拡張子：.tau
Macintosh File Type Code(s):
Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Sam Ashmore - srashmo@radium.ncsc.mil
サムアシュモア-srashmo@radium.ncsc.mil
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: None
使用に関する制限：なし
Author: Sam Ashmore - srashmo@radium.ncsc.mil
Change controller: IESG
Change Controller：IESG
Media type name: application
メディアタイプ名：アプリケーション
Subtype name: tamp-apex-update-confirm
サブタイプ名：tamp-apex-update-confirm
Required parameters: None
必要なパラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: binary
考慮事項のエンコード：バイナリ
Security considerations: Carries an optionally signed response to an apex update request. Integrity protection is discussed in Section 4.6.
セキュリティ上の考慮事項：Apexアップデートリクエストに対するオプションの署名された応答を伝えます。整合性保護については、セクション4.6で説明します。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 5934
公開された仕様：RFC 5934
Applications that use this media type: TAMP clients responding to requests to update an apex trust anchor.
このメディアタイプを使用するアプリケーション：TAMPクライアントは、Apex Trustアンカーを更新するための要求に応答します。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー：なし
File extension(s): .auc
ファイル拡張子：.auc
Macintosh File Type Code(s):
Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Sam Ashmore - srashmo@radium.ncsc.mil
サムアシュモア-srashmo@radium.ncsc.mil
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: None
使用に関する制限：なし
Author: Sam Ashmore - srashmo@radium.ncsc.mil
Change controller: IESG
Change Controller：IESG
Media type name: application
メディアタイプ名：アプリケーション
Subtype name: tamp-community-update
サブタイプ名：tamp-community-update
Required parameters: None
必要なパラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: binary
考慮事項のエンコード：バイナリ
Security considerations: Carries a signed request to update community membership information. Integrity protection is discussed in Section 4.7. Replay detection is discussed in Section 6.
セキュリティ上の考慮事項：コミュニティメンバーシップ情報を更新するための署名済みのリクエストがあります。整合性保護については、セクション4.7で説明します。リプレイ検出については、セクション6で説明します。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 5934
公開された仕様：RFC 5934
Applications that use this media type: TAMP clients responding to requests to update community membership.
このメディアタイプを使用するアプリケーション：TAMPクライアントは、コミュニティメンバーシップを更新するためのリクエストに応答します。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー：なし
File extension(s): .tcu
ファイル拡張子：.tcu
Macintosh File Type Code(s):
Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Sam Ashmore - srashmo@radium.ncsc.mil
サムアシュモア-srashmo@radium.ncsc.mil
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: None
使用に関する制限：なし
Author: Sam Ashmore - srashmo@radium.ncsc.mil
Change controller: IESG
Change Controller：IESG
Media type name: application
メディアタイプ名：アプリケーション
Subtype name: tamp-community-update-confirm
サブタイプ名：tamp-community-update-confirm
Required parameters: None
必要なパラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: binary
考慮事項のエンコード：バイナリ
Security considerations: Carries an optionally signed response to a community update request. Integrity protection is discussed in Section 4.8.
セキュリティ上の考慮事項：コミュニティの更新リクエストに対するオプションで署名された応答を伝えます。整合性保護については、セクション4.8で説明します。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 5934
公開された仕様：RFC 5934
Applications that use this media type: TAMP clients responding to requests to update community membership.
このメディアタイプを使用するアプリケーション：TAMPクライアントは、コミュニティメンバーシップを更新するためのリクエストに応答します。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー：なし
File extension(s): .cuc
ファイル拡張子：.cuc
Macintosh File Type Code(s):
Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Sam Ashmore - srashmo@radium.ncsc.mil
サムアシュモア-srashmo@radium.ncsc.mil
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: None
使用に関する制限：なし
Author: Sam Ashmore - srashmo@radium.ncsc.mil
Change controller: IESG
Change Controller：IESG
Media type name: application
メディアタイプ名：アプリケーション
Subtype name: tamp-sequence-adjust
サブタイプ名：Tamp-Sequence-Adjust
Required parameters: None
必要なパラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: binary
考慮事項のエンコード：バイナリ
Security considerations: Carries a signed request to update sequence number information. Integrity protection is discussed in Section 4.9. Replay detection is discussed in Section 6.
セキュリティ上の考慮事項：シーケンス番号情報を更新するための署名済みのリクエストを搭載しています。整合性保護については、セクション4.9で説明します。リプレイ検出については、セクション6で説明します。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 5934
公開された仕様：RFC 5934
Applications that use this media type: TAMP clients responding to requests to update sequence number information.
このメディアタイプを使用するアプリケーション：TAMPクライアントは、シーケンス番号情報を更新するリクエストに応答します。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー：なし
File extension(s): .tsa
ファイル拡張子：.tsa
Macintosh File Type Code(s):
Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Sam Ashmore - srashmo@radium.ncsc.mil
サムアシュモア-srashmo@radium.ncsc.mil
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: None
使用に関する制限：なし
Author: Sam Ashmore - srashmo@radium.ncsc.mil
Change controller: IESG
Change Controller：IESG
Media type name: application
メディアタイプ名：アプリケーション
Subtype name: tamp-sequence-adjust-confirm
サブタイプ名：Tamp-Sequence-Adjust-Confirm
Required parameters: None
必要なパラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: binary
考慮事項のエンコード：バイナリ
Security considerations: Carries an optionally signed sequence number adjust confirmation message. Integrity protection is discussed in Section 4.10.
セキュリティ上の考慮事項：オプションで署名されたシーケンス番号調整確認メッセージを伝達します。整合性保護については、セクション4.10で説明します。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 5934
公開された仕様：RFC 5934
Applications that use this media type: TAMP clients responding to requests to update sequence number information.
このメディアタイプを使用するアプリケーション：TAMPクライアントは、シーケンス番号情報を更新するリクエストに応答します。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー：なし
File extension(s): .sac
ファイル拡張子：.sac
Macintosh File Type Code(s):
Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Sam Ashmore - srashmo@radium.ncsc.mil
サムアシュモア-srashmo@radium.ncsc.mil
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: None
使用に関する制限：なし
Author: Sam Ashmore - srashmo@radium.ncsc.mil
Change controller: IESG
Change Controller：IESG
Media type name: application
メディアタイプ名：アプリケーション
Subtype name: tamp-error
サブタイプ名：Tamp-Error
Required parameters: None
必要なパラメーター：なし
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: binary
考慮事項のエンコード：バイナリ
Security considerations: Carries optionally signed error information collecting during TAMP processing. Integrity protection is discussed in Section 4.11.
セキュリティ上の考慮事項：TAMP処理中にオプションで署名されたエラー情報収集を伝えます。整合性保護については、セクション4.11で説明します。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 5934
公開された仕様：RFC 5934
Applications that use this media type: TAMP clients processing TAMP messages.
このメディアタイプを使用するアプリケーション：TAMPクライアントTAMPメッセージを処理します。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー：なし
File extension(s): .ter
ファイル拡張子：.ter
Macintosh File Type Code(s):
Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Sam Ashmore - srashmo@radium.ncsc.mil
サムアシュモア-srashmo@radium.ncsc.mil
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: None
使用に関する制限：なし
Author: Sam Ashmore - srashmo@radium.ncsc.mil
Change controller: IESG
Change Controller：IESG
This appendix describes the formatting and transportation conventions for the TAMP messages when carried by HTTP [RFC2616]. Each TAMP message type is covered by a subsection below. Each TAMP request message sent via HTTP is responded to either with an HTTP response containing a TAMP response or error or, if failure occurs prior to invoking TAMP, an HTTP error. TAMP response, confirmation, and error messages are not suitable for caching. In order for TAMP clients and servers using HTTP to interoperate, the following rules apply.
この付録では、HTTP [RFC2616]によって運ばれた場合のTAMPメッセージのフォーマットおよび輸送規則について説明しています。各タンプメッセージタイプは、以下のサブセクションでカバーされています。HTTPを介して送信された各TAMP要求メッセージは、TAMP応答またはエラーを含むHTTP応答を使用して応答されます。また、TAMPを呼び出す前に障害が発生した場合、HTTPエラーが発生します。TAMP応答、確認、およびエラーメッセージは、キャッシュには適していません。TAMPクライアントとサーバーがHTTPを使用して相互運用するためには、次のルールが適用されます。
o Clients MUST use the POST method to submit their requests.
o クライアントは、POSTメソッドを使用してリクエストを送信する必要があります。
o Servers MUST use the 200 response code for successful responses.
o サーバーは、成功した応答のために200の応答コードを使用する必要があります。
o Clients MAY attempt to send HTTPS requests using Transport Layer Security (TLS) 1.0 or later, although servers are not required to support TLS.
o クライアントは、TLSをサポートするためにサーバーは必要ありませんが、トランスポートレイヤーセキュリティ（TLS）1.0以降を使用してHTTPSリクエストを送信しようとする場合があります。
o Servers MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication.
o サーバーは、Cookie、Basic Authentication、またはDigest Authenticationなど、あらゆるタイプのHTTP認証のクライアントサポートを想定してはなりません。
o Clients and servers are expected to follow the other rules and restrictions in [RFC2616]. Note that some of those rules are for HTTP methods other than POST; clearly, only the rules that apply to POST are relevant for this specification.
o クライアントとサーバーは、[RFC2616]の他のルールと制限に従うことが期待されています。これらのルールの一部は、POST以外のHTTPメソッド用であることに注意してください。明らかに、投稿に適用されるルールのみがこの仕様に関連しています。
A TAMP Status Query Message using the POST method is constructed as follows: The Content-Type header MUST have the value "application/ tamp-status-query".
POSTメソッドを使用したTAMPステータスクエリメッセージは、次のように構築されます。コンテンツタイプのヘッダーには、値「アプリケーション/ TAMP-Status-Query」が必要です。
The body of the message is the binary value of the DER encoding of the TAMPStatusQuery, wrapped in a CMS body as described in Section 2.
メッセージの本体は、セクション2で説明されているように、CMSボディに包まれたTampStatusqueryのDERエンコードのバイナリ値です。
An HTTP-based TAMP Status Response message is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the TAMPStatusResponse, wrapped in a CMS body as described in Section 2.
HTTPベースのTAMPステータス応答メッセージは、適切なHTTPヘッダーで構成されており、セクション2で説明されているように、CMSボディに包まれたTampStatusResponseのderエンコードのバイナリ値が続きます。
The Content-Type header MUST have the value "application/ tamp-status-response."
コンテンツタイプのヘッダーには、値「アプリケーション/ TAMP-STATUS-Response」が必要です。
A Trust Anchor Update Message using the POST method is constructed as follows: The Content-Type header MUST have the value "application/ tamp-update".
POSTメソッドを使用したトラストアンカー更新メッセージは、次のように構築されます。コンテンツタイプのヘッダーには、値「アプリケーション/ TAMP-Update」が必要です。
The body of the message is the binary value of the DER encoding of the TAMPUpdate, wrapped in a CMS body as described in Section 2.
メッセージの本体は、セクション2で説明されているように、CMS本体に包まれたTampupdateのderエンコードのバイナリ値です。
An HTTP-based Trust Anchor Update Confirm message is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the TAMPUpdateConfirm, wrapped in a CMS body as described in Section 2.
HTTPベースのトラストアンカー更新確認メッセージは、適切なHTTPヘッダーで構成されており、セクション2で説明されているように、CMSボディに包まれたTampupDateConfirmのDERエンコードのバイナリ値が続きます。
The Content-Type header MUST have the value "application/ tamp-update-confirm".
コンテンツタイプのヘッダーには、値「Application/ Tamp-Update-Confirm」が必要です。
An Apex Trust Anchor Update Message using the POST method is constructed as follows: The Content-Type header MUST have the value "application/tamp-apex-update".
POSTメソッドを使用したApex Trustアンカー更新メッセージは、次のように構築されます。コンテンツタイプのヘッダーには、値「アプリケーション/TAMP-APEX-Update」が必要です。
The body of the message is the binary value of the DER encoding of the TAMPApexUpdate, wrapped in a CMS body as described in Section 2.
メッセージの本体は、セクション2で説明されているように、CMS本体に包まれたTampapexupdateのderエンコードのバイナリ値です。
An HTTP-based Apex Trust Anchor Update Confirm message is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the TAMPApexUpdateConfirm, wrapped in a CMS body as described in Section 2.
HTTPベースのApex Trust Anchor Updateの確認メッセージは、適切なHTTPヘッダーで構成されており、セクション2で説明されているようにCMSボディに包まれたTampapexupDateConfirmのDERエンコードのバイナリ値が続きます。
The Content-Type header MUST have the value "application/ tamp-apex-update-confirm".
コンテンツタイプのヘッダーには、値「Application/ Tamp-Apex-Update-Confirm」が必要です。
A Community Update Message using the POST method is constructed as follows: The Content-Type header MUST have the value "application/ tamp-community-update".
POSTメソッドを使用したコミュニティ更新メッセージは、次のように構築されます。コンテンツタイプのヘッダーには、値「アプリケーション/ TAMP-Community-Update」が必要です。
The body of the message is the binary value of the DER encoding of the TAMPCommunityUpdate, wrapped in a CMS body as described in Section 2.
メッセージの本体は、セクション2で説明されているように、CMS本体に包まれたTampCommunityUpdateのderエンコードのバイナリ値です。
An HTTP-based Community Update Confirm message is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the TAMPCommunityUpdateConfirm, wrapped in a CMS body as described in Section 2.
HTTPベースのコミュニティアップデートでは、メッセージが適切なHTTPヘッダーで構成されており、セクション2で説明されているように、CMSボディに包まれたTAMPCommunityUpDateConfirmのDERエンコードのバイナリ値が続きます。
The Content-Type header MUST have the value "application/ tamp-community-update-confirm".
コンテンツタイプのヘッダーには、値「Application/ TAMP-Community-Update-Confirm」が必要です。
A Sequence Number Adjust Message using the POST method is constructed as follows: The Content-Type header MUST have the value "application/ tamp-sequence-adjust".
POSTメソッドを使用したシーケンス番号調整メッセージは、次のように構築されます。コンテンツタイプのヘッダーには、値「アプリケーション/タンプシーケンスアジャスト」が必要です。
The body of the message is the binary value of the DER encoding of the SequenceNumberAdjust, wrapped in a CMS body as described in Section 2.
メッセージの本体は、セクション2で説明されているように、CMSボディに包まれたシーケンセンサンバーアジュストのderエンコードのバイナリ値です。
An HTTP-based Sequence Number Adjust Confirm message is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the SequenceNumberAdjustConfirm, wrapped in a CMS body as described in Section 2.
HTTPベースのシーケンス番号調整確認メッセージは、適切なHTTPヘッダーで構成されており、セクション2で説明されているように、CMSボディに包まれたシーケンセンサーバーアジュストコンフィルムのDERエンコードのバイナリ値が続きます。
The Content-Type header MUST have the value "application/ tamp-sequence-adjust-confirm".
コンテンツタイプのヘッダーには、値「アプリケーション/タンプシーケンスアジャスト環境」が必要です。
An HTTP-based TAMP Error message is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the TAMPError, wrapped in a CMS body as described in Section 2.
HTTPベースのTAMPエラーメッセージは、適切なHTTPヘッダーで構成されており、セクション2で説明されているように、CMSボディに包まれたタンパーロのderエンコードのバイナリ値が続きます。
The Content-Type header MUST have the value "application/tamp-error".
コンテンツタイプのヘッダーには、値「アプリケーション/タンプエラー」が必要です。
Authors' Addresses
著者のアドレス
Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russ Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USA
EMail: housley@vigilsec.com
Sam Ashmore National Security Agency Suite 6751 9800 Savage Road Fort Meade, MD 20755 USA
サムアシュモア国家安全保障庁スイート6751 9800サベージロードフォートミード、メリーランド20755アメリカ
EMail: srashmo@radium.ncsc.mil
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean, VA 22102 USA
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean、VA 22102 USA
EMail: cwallace@cygnacom.com