Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 5934 Vigil Security, LLC
Category: Standards Track S. Ashmore
ISSN: 2070-1721 National Security Agency
C. Wallace
Cygnacom Solutions
August 2010
Trust Anchor Management Protocol (TAMP)
Abstract
抽象
This document describes a transport independent protocol for the management of trust anchors (TAs) and community identifiers stored in a trust anchor store. The protocol makes use of the Cryptographic Message Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication. The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate, or TrustAnchorInfo objects.
この文書では、トラストアンカーストアに格納されている信頼アンカー（TAS）とコミュニティ識別子の管理のための輸送の独立したプロトコルを記述しています。プロトコルは、暗号メッセージ構文（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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
この文書では、トラストアンカー管理プロトコル（TAMP）について説明します。 TAMPは、デジタル署名を使用する任意のデバイスの信頼アンカーとコミュニティ識別子を管理するために使用されてもよいです。しかし、この仕様は念頭に置いて、暗号モジュールの要件に書かれていました。例えば、TAMPは、トラストアンカーの公開鍵は、ファームウェアパッケージのデジタル署名を検証またはファームウェアパッケージ署名者のX.509証明経路[RFC5280] [X.509]を検証するために使用することができる署名付きファームウェアパッケージ[RFC4108]を、サポートすることができ。
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メッセージが暗号メッセージ構文（CMS）[RFC5652]を使用します。 CMSは、[X.680] ASN.1を利用したデータ保護カプセル化構文です。
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を介しとして、ネットワーク上でリアルタイムに交換することができる、または他の手段を使用して格納され、転送されてもよいです。交換は、トラストアンカーストアするための命令と、必要に応じて、要求の指示を行った結果を報告し、対応する応答メッセージを含むリクエスト・メッセージから成るタンプ。応答メッセージは、すべてのケースで伝播する必要はありません。例えば、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は、トラストアンカーを管理します。トラストアンカーは、デジタル署名を検証するために使用された公開鍵が含まれています。証明書[RFC5280]、たtbsCertificate [RFC5280]、およびTrustAnchorInfo [RFC5914]：TAMPは、トラストアンカーの情報を表現するための3つのフォーマットを認識します。
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種類を認識します。
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.
上記情報に加えて、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.
トラストアンカーの公開鍵は、デジタル署名の検証をサポートするために、2つの異なる方法で使用することができます。第1のアプローチでは、トラストアンカーの公開鍵は、デジタル署名を検証するために直接使用されます。第2のアプローチでは、トラストアンカーの公開鍵は、X.509証明書パスを検証するために使用され、その後、認証パスの最後の証明書の対象の公開鍵は、デジタル署名を検証するために使用されます。第二のアプローチが使用される場合、認定公開鍵は、デジタル署名の検証以外のものに使用することができます。他の可能なアクションは、キーの使用証明書拡張によって制約されています。
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の実装は直接トラストアンカーを使用して検証され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つのトラストアンカーは、他のすべてに優れています。このトラストアンカーは頂点トラストアンカーと呼ばれています。このトラストアンカーは、トラストアンカーストアに対する最終的な権限を表します。この権限の多くは、他の信頼アンカーに委任することができます。
The apex trust anchor private key is expected to be controlled by an entity with information assurance responsibility for the trust anchor store. The apex trust anchor is by definition unconstrained and therefore does not have explicit authorization information associated with it.
頂点トラストアンカー秘密鍵は、トラストアンカーストアの情報保証責任を持つエンティティによって制御されることが期待されます。頂点トラストアンカーは、定義によって制約されないので、それに関連する明示的な認証情報を持っていません。
Due to the special nature of the apex trust anchor, TAMP includes separate facilities to change it. In particular, TAMP includes a facility to securely replace the apex trust anchor. This action might be taken for one or more of the following reasons:
頂点トラストアンカーの特殊な性質のために、TAMPはそれを変更するために別の機能が含まれています。特に、TAMPはしっかり頂点トラストアンカーを交換する機能が含まれています。このアクションは、次の理由の一つ以上のために取られる可能性があります。
o The crypto period for the apex trust anchor public/private key pair has come to an end
oを頂点トラストアンカー公開鍵/秘密鍵のペアのための暗号化期間が終了しました
o The apex trust anchor private key is no longer available
頂点トラストアンカー秘密鍵が使用できなくなったO
o The apex trust anchor public/private key pair needs to be revoked
公開鍵/秘密鍵のペアが取り消される必要がある頂点トラストアンカーO
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.
これらの要件に対応するために、頂点トラストアンカーは、2つのパブリックキーを含んでいてもよいです。頂点トラストアンカーが更新されるたびに、両方の公開鍵が置き換えられます。第1の公開鍵は、運用の公開鍵と呼ばれ、他のトラストアンカーと同様に使用されています。アペックストラストアンカーUpdateメッセージを含むTAMPメッセージの任意のタイプは、運用の公開鍵で検証することができます。不測の公開鍵と呼ばれる第2の公開鍵は、唯一の頂点トラストアンカーを更新するために使用することができます。不測の事態秘密鍵は、時間に一点でのみ使用されるべきです。唯一の独自の代替（だけでなく、運用の公開鍵の交換）になりアペックストラストアンカーUpdateメッセージに署名するために使用されます。不測の事態公開鍵は、暗号化された形で配布されています。偶発公開鍵はアペックストラストアンカー更新メッセージ、偶発公開鍵を解読するために必要な対称キーを検証するために使用されたときに偶発公開鍵で検証する署名済みのApexトラストアンカー更新メッセージの一部として提供されます。
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.
アイデンティティトラストアンカーは、証明書パスを検証するために使用されている、と彼らは、公開鍵インフラストラクチャのトラストアンカーを表します。彼らは、ほとんどの場合、非管理アプリケーションに関連付けられた証明書の検証に使用されています。
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
偶発キーがサポートされている場合、O暗号モジュールは、少なくとも一つの一方向ハッシュ関数、一つのデジタル署名検証アルゴリズム、一つのデジタル署名生成アルゴリズムをサポートしなければならず、アルゴリズムをアンラップ1つの対称鍵。唯一の一方向ハッシュ関数が存在する場合、それは、デジタル署名の検証やデジタル署名生成アルゴリズムと一致していなければなりません。唯一のデジタル署名検証アルゴリズムが存在する場合、それは頂点トラストアンカー運用公開鍵と一致していなければなりません。唯一のデジタル署名生成アルゴリズムが存在する場合、それは、暗号モジュールのデジタル署名秘密鍵と一致していなければなりません。これらのアルゴリズムは[RFC5652]で定義されたコンテンツのタイプを含むTAMPメッセージを処理するため、および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.
証明書パス。このよう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トラストアンカーストアは頂点トラストアンカーの使用をサポートする必要があります。頂点のサポートが提供されている場合は、トラストアンカーストアは、1つの頂点トラストアンカーの安全な保管をサポートしなければなりません。トラストアンカーストアは、少なくとも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トラストアンカーストアを確実TAMPメッセージを生成し、トラストアンカーのキー識別子と共にシーケンス番号を報告することができるように許可各トラストアンカーのシーケンス番号を格納する能力を持たなければなりません。
TAMP processing MUST include the following capabilities:
以下の機能を含まなければならない処理を突き固めます。
o TAMP processing MUST have a means of locating an appropriate trust anchor. Two mechanisms are available. The first mechanism is based on the public key identifier for digital signature verification, and the second mechanism is based on the trust anchor X.500 distinguished name and other X.509 certification path controls for certificate path discovery and validation. The first mechanism MUST be supported, but the second mechanism MAY be supported.
O TAMP処理は、適切なトラストアンカーの位置を特定する手段を持たなければなりません。 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処理は、トラストアンカーストア固有の名前への読み取りアクセス権を持っている必要があります。
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で管理頂点トラストアンカーと管理トラストアンカーはTAMPアプリケーションで使用することができます。他の管理アプリケーションは、トラストアンカーの3種類すべてを利用してもよいが、非管理アプリケーションは、唯一のアイデンティティトラストアンカーの使用をしなければなりません。アプリケーションは、トラストアンカーの使用量がトラストアンカーに関連付けられている任意の制約と一致していることを確認しなければなりません。名前制約は、トラストアンカーに関連付けられている場合たとえば、トラストアンカーで始まり、名前制約に違反する名前の証明書が含まれている証明書パスを拒絶しなければなりません。
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つのメカニズムがアプリケーションに利用できます。第一のメカニズムは、デジタル署名検証用公開鍵識別子に基づいており、そして第二のメカニズムは、トラストアンカー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をトラストアンカーストア固有の名前への読み取りアクセス権を持っている必要があります。
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
CMSは、抽象構文記法1（ASN.1）[X.680]を使用しています。 ASN.1にかかわらず、実装によって使用されるプログラミング言語の、データプロトコルを説明するための正式な表記法です。符号化規則は、ASN.1で定義された値は、送信のために表現する方法を記載しています。基本符号化規則（BER）[X.690]は、最も広く使用されるルールセットですが、彼らは、データ構造を表すために複数の方法を提供します。例えば、明確なレングス符号化及び不定長符号化がサポートされています。デジタル署名が使用される場合、この柔軟性は望ましくありません。その結果、
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.
識別符号化規則（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 }
ContentInfo {contentTypeのID-たsignedData、 - （1.2.840.113549.1.7.2）コンテンツの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 }
SignedData {バージョンCMSVersion、 - つのみencapContentInfo EncapsulatedContentInfo、証明書の証明書群、 - - オプションの署名者証明書のCRLのCertificateRevocationLists、 - のSignerInfoの随意signerInfos SET - つのみ必ず3 digestAlgorithmsのDigestAlgorithmIdentifiersに設定}
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
SignerInfo {バージョンCMSVersion、 - TAMPメッセージのsignatureAlgorithm SignatureAlgorithmIdentifier、署名SignatureValue、unsignedAttrs UnsignedAttributesで必要 - - 常に3のSID SignerIdentifier、digestAlgorithm DigestAlgorithmIdentifier、signedAttrs signedAttributesのに設定オプション。唯一}であってもよい - エイペックス・トラストに存在 - アンカー更新メッセージ
EncapsulatedContentInfo { eContentType OBJECT IDENTIFIER, -- Names TAMP message type eContent OCTET STRING -- Contains TAMP message }
EncapsulatedContentInfo {のeContentTypeオブジェクト識別子、 - 名前TAMPメッセージタイプe-コンテンツオクテット文字列は - TAMPメッセージを含みます}
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.
TAMPメッセージが頂点トラストアンカーを更新するために使用された場合、これと同じ構造が使用されます。しかし、デジタル署名は頂点トラストアンカー運用公開鍵または不測の公開鍵のいずれかを用いて検証されます。偶発公開鍵を使用した場合、以前に格納された緊急時のパブリックキーを解読するために必要な対称キーは、コンティンジェンシー・公開鍵解読キー符号なし属性として提供されます。このドキュメントのセクション4.5は、Apexのトラストアンカー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 }
ContentInfo {contentTypeのオブジェクト識別子、 - 名前TAMPメッセージ型コンテンツオクテット文字列は - TAMPメッセージを含みます}
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のために、カプセル化されたタイプは、のSignedDataまたはunsigned TAMPメッセージに関連付けられたコンテンツタイプ識別子のいずれかです。 ID-たsignedData（1.2.840.113549.1.7.2）オブジェクトIDこのフィールドに存在する場合、次に署名された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またはunsigned 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コンテンツタイプ識別子とコンテンツ自体からなる、署名されたコンテンツです。 EncapsulatedContentInfo型の使用は、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証明書を含むかもしれません。頂点トラストアンカーまたは管理トラストアンカーがTAMPメッセージのデジタル署名を検証するために直接使用されるトラストアンカーストアに送信されたTAMPメッセージの場合、このフィールドは省略されるべきです。頂点トラストアンカーまたは管理トラストアンカーがX.509証明経路[RFC5280]、及び認証パスの最後の証明書のサブジェクトの公開鍵を検証するために使用される場合、TAMPメッセージのデジタル署名を検証するための証明書を用いていますTAMPのメッセージの発信が含まれるべきであり、証明書パスの構築をサポートするための追加の証明書が含まれるかもしれません。トラストアンカーストアによって送信された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のCRLは証明書失効リスト（CRL）のオプションコレクションです。
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のために、コレクションは正確に一つの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、一緒に使用されます。公開鍵はTrustAnchorInfoオブジェクトに含まれている場合、この識別子は、鍵IDフィールドに含まれています。公開鍵は証明書またはた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でdigestAlgorithmsフィールドで運ばものと一致しなければなりません。メッセージダイジェストアルゴリズム識別子は、受信機によってストリーム処理を容易にするために、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の場合、このフィールドは、通常は省略されています。それが唯一の頂点トラストアンカー不測の公開鍵を使って検証することになっているアペックストラストアンカー更新メッセージに存在しています。この場合、属性のSETは、不測の事態-公開鍵解読キー未署名の属性における不測の事態の公開鍵を解読するために必要な対称鍵を含まなければなりません。このドキュメントのセクション2.2.4は、この未署名の属性を記述します。
The EncapsulatedContentInfo structure contains the TAMP message. The fields of EncapsulatedContentInfo are used as follows:
EncapsulatedContentInfo構造は、TAMPメッセージが含まれています。次のようにEncapsulatedContentInfoのフィールドが使用されます。
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 e-コンテンツは、オクテット文字列として符号化TAMPメッセージです。一般的には、CMSは、オクテット文字列を構築する前に、DERでエンコードするe-コンテンツを必要としません。しかし、TAMPメッセージは、DERでエンコードされなければなりません。
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でエンコードされなければなりません。属性の構文は、[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のプロファイルで使用される属性のそれぞれは、単一の属性値を持っています。構文はAttributeValueのセットとして定義されているにもかかわらず、AttributeValueの存在のうちの正確に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つだけ含まなければなりません。この規則は、不正な形式として拒絶しなければなりません違反するメッセージを突き固めます。
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.
コンテンツタイプ属性はEncapsulatedContentInfoに含まれるコンテンツタイプと同じオブジェクト識別子を含まなければなりません。
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のために、未署名の属性は、通常は省略されています。未署名の属性は、頂点トラストアンカー不測の公開鍵で検証することになっているアペックストラストアンカー更新メッセージに存在しています。この場合、対称鍵は、公開鍵が有事-公開鍵解読キー未署名の属性で提供される前の不測の事態を復号化します。この属性をサポートしなければなりません、それは、セクション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つだけ含まなければなりません。この規則は、不正な形式として拒絶しなければなりません違反するメッセージを突き固めます。
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.
コンティンジェンシー・公開鍵解読-key属性は、以前の分散頂点トラストアンカー不測の公開鍵を解読するために必要な平文対称鍵を提供します。対称鍵は、以前に不測の公開鍵を暗号化するために使用される対称アルゴリズムで使用可能でなければなりません。
The contingency-public-key-decrypt-key attribute has the following syntax:
コンティンジェンシー・公開鍵解読キー属性の構文は次のとおりです。
contingency-public-key-decrypt-key ATTRIBUTE ::= {
WITH SYNTAX PlaintextSymmetricKey
SINGLE VALUE TRUE
ID id-aa-TAMP-contingencyPublicKeyDecryptKey }
id-aa-TAMP-contingencyPublicKeyDecryptKey
OBJECT IDENTIFIER ::= { id-attributes 63 }
PlaintextSymmetricKey ::= OCTET STRING
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.
証明書[RFC5280]、たtbsCertificate [RFC5280]、およびTrustAnchorInfo [RFC5914]：TAMP、プロトコル自体の中トラストアンカー情報を表すための3つのフォーマットを認識する。 [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つのオプションをサポートする必要はありません。サポートされていないトラストアンカー形式の領収書にTAMPErrorを生成する場合unsupportedTrustAnchorFormatエラーコードが示されなければなりません。
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ステータスクエリーメッセージが署名する必要があります。これは、次のオブジェクト識別子を使用する：{1、ID-タンプ}。
o The TAMP Status Response message SHOULD be signed. It uses the following object identifier: { id-tamp 2 }.
O TAMPステータス応答メッセージが署名されなければなりません。これは、次のオブジェクト識別子を使用する：{2をID-タンプ}。
o The Trust Anchor Update message MUST be signed. It uses the following object identifier: { id-tamp 3 }.
Oトラストアンカー更新メッセージが署名しなければなりません。これは、次のオブジェクト識別子を使用する：{3をID-タンプ}。
o The Trust Anchor Update Confirm message SHOULD be signed. It uses the following object identifier: { id-tamp 4 }.
Oトラストアンカー更新確認メッセージが署名されるべきです。これは、次のオブジェクト識別子を使用する：{4をID-タンプ}。
o The Apex Trust Anchor Update message MUST be signed. It uses the following object identifier: { id-tamp 5 }.
Oアペックストラストアンカー更新メッセージが署名しなければなりません。これは、次のオブジェクト識別子を使用する：{5をID-タンプ}。
o The Apex Trust Anchor Update Confirm message SHOULD be signed. It uses the following object identifier: { id-tamp 6 }.
Oアペックストラストアンカー更新確認メッセージが署名されるべきです。これは、次のオブジェクト識別子を使用する：{6をID-タンプ}。
o The Community Update message MUST be signed. It uses the following object identifier: { id-tamp 7 }.
OコミュニティUpdateメッセージに署名する必要があります。これは、次のオブジェクト識別子を使用する：{7をID-タンプ}。
o The Community Update Confirm message SHOULD be signed. It uses the following object identifier: { id-tamp 8 }.
Oコミュニティアップデート確認メッセージが署名されなければなりません。これは、次のオブジェクト識別子を使用する：{8 ID-タンプ}。
o The Sequence Number Adjust MUST be signed. It uses the following object identifier: { id-tamp 10 }.
Oシーケンス番号が署名する必要があります調整します。これは、次のオブジェクト識別子を使用する：{10をID-タンプ}。
o The Sequence Number Adjust Confirm message SHOULD be signed. It uses the following object identifier: { id-tamp 11 }.
Oシーケンス番号調節確認メッセージが署名されるべきです。これは、次のオブジェクト識別子を使用する：{11をID-タンプ}。
o The TAMP Error message SHOULD be signed. It uses the following object identifier: { id-tamp 9 }.
O TAMPエラーメッセージが署名されなければなりません。これは、次のオブジェクト識別子を使用する：{9 ID-タンプ}。
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.
トラストアンカーの管理者は、トラストアンカーの更新、アペックス・トラストアンカーの更新、コミュニティ更新、およびシーケンス番号は、メッセージを調整し、TAMPステータスクエリを生成します。トラストアンカーストアは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バインディングは、さらに、トラストアンカーの更新がエラー・メッセージを確認し、タンプサポートしなければならないとのメッセージの次のペアの0またはそれ以上をサポートするかもしれサポートする実装：ステータスクエリをタンピングとステータスクエリ応答を突き固めます。アペックストラストアンカーUpdateおよびApexのトラストアンカーの更新を確認してください。コミュニティ更新とコミュニティの更新を確認してください。シーケンス番号が調整し、シーケンス番号は確認を調整します。切断されたように動作する実装では、応答は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.
トラストアンカーマネージャとトラストアンカー・ストアとの間の典型的な相互作用は、図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クエリおよび更新メッセージは、所望される応答のタイプの指示を含みます。応答は、いずれかの簡潔または冗長にすることができます。すべてのトラストアンカー店は簡潔かつ詳細な応答の両方をサポートしなければならないし、対応する要求に示さタイプの応答を生成する必要があります。簡潔かつ詳細な応答の両方の処理をサポートしなければならない応答プロセッサを突き固めます。
Trust anchor stores SHOULD be able to process and properly act upon the valid payload of the TAMP Status Query message, the Trust Anchor Update message, the Apex Trust Anchor Update message, and the Sequence Number Adjust message. TAMP implementations MAY also process and act upon the valid payload of the Community Update message.
トラストアンカーストアが処理し、適切にTAMPステータスクエリーメッセージの有効なペイロードに作用することができるべきである、トラストアンカーUpdateメッセージ、アペックス・トラストアンカーUpdateメッセージ、およびシーケンス番号は、メッセージを調整します。実装は、プロセスとコミュニティ更新メッセージの有効なペイロードに作用するかもしれ突き固めます。
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、トラストアンカー更新確認メッセージ、アペックス・トラストアンカーアップデート確認メッセージは、シーケンス番号は、確認メッセージ、およびTAMPのエラーメッセージを調整します。 TAMPの実装はコミュニティUpdateメッセージをサポートしている場合もサポートする必要がある（SHOULD）、そしてコミュニティの更新の世代は、メッセージを確認してください。
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ステータスクエリーメッセージが署名する必要があります。クエリメッセージが有効であるために、トラストアンカーストアは、クエリの意図した受信者でなければなりません。 TAMPメッセージの署名者がトラストアンカーの場合に第6節で説明したチェックシーケンス番号が成功しなければなりません。電子署名は、頂点トラストアンカー動作公開鍵、権限管理トラストアンカー、またはそのようなトラストアンカーに由来認可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ステータスクエリーメッセージにデジタル署名が有効である場合は、シーケンス番号のチェックが署名者が承認され、成功し、トラストアンカーストアは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望まれる応答のタイプを示します。簡潔な応答は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.
ターゲットとSEQNUM：Oクエリは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値を含めることはできません。オブジェクト識別子は、トラストアンカー店のコミュニティを識別するために使用されています。複数のコミュニティは、メッセージのターゲットである場合は、これらのオブジェクト識別子のシーケンスが使用されています。それが記載されているコミュニティのいずれかのメンバーである場合、トラストアンカーストアを対象とみなされます。明示的なNULL値がTAMPメッセージの署名者がそのメッセージタイプの認可ソースであると考えるすべてのモジュールを識別するために使用されます。 URIフィールドは、ユニフォームリソース識別子[RFC3986]を使用して、すなわち、トラストアンカーストアをターゲットを識別するために使用することができます。追加の名前タイプは、タイプAnotherNameであるotherNameフィールドを介してサポートされています。 AnotherNameは[RFC5280]で定義されています。名前のフォーマット及びセマンティクスは、タイプIDフィールドにオブジェクト識別子を介して示されています。名前自体はotherNameの値フィールドとして搬送されます。実装はallModulesオプションをサポートしなければならないし、すべてのTargetIdentifierオプションをサポートする必要があります。
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つのオクテットストリングは、他と同じです。オクテットストリング、S1は、S1及びS2は、1つの以上の位置で異なるオクテットを有する場合にのみS1及びS2は、同じ長さを有するS2、別のより大きく、最初のそのような位置に、S1においてオクテットであります符号なし2進数としてオクテットを考慮すると、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ステータスクエリーメッセージにトラストアンカーストアによって返信です。 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のクエリは、トラストアンカーストアが応答されている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応答は簡潔な応答または冗長な応答のいずれかが含まれています。簡潔な応答は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がTRUEである場合には、頂点トラストアンカーは、演算、公開鍵の鍵識別子を含むシーケンスの最初のキー識別子で表されます。
o communities is OPTIONAL. When present, it contains a sequence of object identifiers. Each object identifier names one community to which this trust anchor store belongs. When the trust anchor store belongs to no communities, this field is omitted.
Oのコミュニティはオプションです。存在する場合、それはオブジェクト識別子のシーケンスが含まれています。各オブジェクト識別子名このトラストアンカーストアが属する1人のコミュニティ。トラストアンカーストアが無いのコミュニティに属している場合、このフィールドは省略されています。
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がTRUEである場合には、頂点トラストアンカーは、シーケンスの最初のトラストアンカーです。
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 continPubKeyDecryptAlgはオプションです。存在する場合、それは不測の事態キーが頂点トラストアンカーに関連付けられている場合は、現在インストールされている頂点トラストアンカー不測の公開鍵を解読するために必要な復号化アルゴリズムを示しています。存在する場合、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人のコミュニティ。トラストアンカーストアが無いのコミュニティに属している場合、このフィールドは省略されています。
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メッセージに署名する権限を各トラストアンカーのために、現在開催されたシーケンス番号を示すために使用されます。鍵IDフィールドは、トラストアンカーを識別し、seqNumberフィールドは、トラストアンカーに関連付けられた現在のシーケンス番号を提供します。
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.
トラストアンカーUpdateメッセージは、追加、削除、および管理やアイデンティティトラストアンカーを変更するために使用されます。トラストアンカーUpdateメッセージは頂点トラストアンカーを更新するために使用することはできません。トラストアンカーUpdateメッセージを署名する必要があります。トラストアンカーUpdateメッセージが有効であるために、トラストアンカーストアは、更新の対象となる受信者でなければなりません。 TAMPメッセージの署名者がトラストアンカーの場合に第6節で説明したチェックシーケンス番号が成功しなければなりません。電子署名は、頂点トラストアンカー動作公開鍵、権限管理トラストアンカー、またはそのようなトラストアンカーに由来認可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.
トラストアンカーUpdateメッセージにデジタル署名が有効である場合は、シーケンス番号のチェックは、署名者が認可され、成功し、トラストアンカーストアはTAMPメッセージの意図された受信者は、トラストアンカーストアが指定された更新とリターンを実行しなければなりませんですトラストアンカーの更新は、メッセージを確認します。トラストアンカーアップデート確認メッセージが返されない場合、TAMPのエラーメッセージが返されます。
The Trust Anchor Update content type has the following syntax:
トラストアンカーの更新コンテンツタイプの構文は次のとおりです。
tamp-update CONTENT-TYPE ::=
{ TAMPUpdate IDENTIFIED BY id-ct-TAMP-update }
id-ct-TAMP-update OBJECT IDENTIFIER ::= { id-tamp 3 }
TAMPUpdate ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
msgRef TAMPMsgRef,
updates SEQUENCE SIZE (1..MAX) OF TrustAnchorUpdate,
tampSeqNumbers [2]TAMPSequenceNumbers OPTIONAL }
TrustAnchorUpdate ::= CHOICE {
add [1] TrustAnchorChoice,
remove [2] SubjectPublicKeyInfo,
change [3] EXPLICIT TrustAnchorChangeInfoChoice }
TrustAnchorChangeInfoChoice ::= CHOICE {
tbsCertChange [0] TBSCertificateChangeInfo,
taChange [1] TrustAnchorChangeInfo }
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望まれる応答のタイプを示します。簡潔な応答は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.
ターゲットとSEQNUM：O msgRefは、2つの項目が含まれています。ターゲットは、更新メッセージの対象（複数可）を識別する。 TargetIdentifier構文は4.1節に記述されています。 SEQNUMトラストアンカーアップデート確認メッセージをトラストアンカー更新メッセージを一致させるために使用される使い捨ての値です。シーケンス番号も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のアップデートは、追加、削除、および管理やアイデンティティ信頼アンカーを変更するために使用されているアップデートのシーケンスが含まれています。配列内の各エントリは、これらのアクションのいずれかを表し、TrustAnchorUpdateのインスタンスによって示されています。アクションは、彼らが表示される順序で処理しなければなりませんが、更新のそれぞれが独立して処理され、更新のバッチです。アップデートの1つ以上が、残りの更新を処理しなければならない、失敗した場合でも更新の各々は、セクション7に記載の従属性チェックを満たさなければなりません。これらのアップデートは、頂点トラストアンカーを変更してはなりません。
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トラストアンカーストアに新しい管理やアイデンティティトラストアンカーを挿入するために使用される追加します。 TrustAnchorChoice構造は、信頼できる公開鍵とそれに関連するすべての情報を提供するために使用されます。第7節に記載従属チェックが満足されない場合は、アクションはnotAuthorizedエラーコードで失敗しなければなりません。 TrustAnchorChoice構造の議論については、セクション3を参照してください。頂点トラストアンカーは、このアクションを使用したトラストアンカーストアに導入することはできません。そのため、ID-PE-wrappedApexContinKeyは、拡張フィールドに存在してはなりません。既存のトラストアンカーの制約は、この作用によって変更されません。 TrustAnchorChoice構造内のすべてのフィールドに同じ値を持つ場所にすでにある管理やアイデンティティトラストアンカーを追加しようとする試みは成功したほかとして扱わなければなりません。試みはすでに同じpubkeyで値を持つ存在である管理やアイデンティティトラストアンカーを追加しますが、TrustAnchorChoice構造体のフィールドのいずれかに異なる値で、エラーコードimproperTAAdditionで失敗しなければなりません。これは、トラストアンカーが異なるTrustAnchorChoiceオプションを使用して二回追加することはできませんを意味します。異なるフォーマットを希望する場合は、既存のトラストアンカーを削除する必要がありますし、新しいフォーマットが追加されました。
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削除はTAMPメッセージの署名者に関連付けられた管理トラストアンカーの削除を含む、トラストアンカーストアから既存の管理やアイデンティティトラストアンカーを削除するために使用されます。第7節に記載従属チェックが満足されない場合は、アクションはnotAuthorizedエラーコードで失敗しなければなりません。 SubjectPublicKeyInfoで名で管理やアイデンティティトラストアンカーを含まれる公開鍵を削除します。存在しないトラストアンカーを削除しようとする試みは成功した削除として扱わなければなりません。削除されたトラストアンカーの制約は、任意の方法で他のトラストアンカーに配布されません。頂点トラストアンカーは、このアクションは、回復不能な構成でトラストアンカーストアを置くことができないことが保証され、このアクションを使用して削除することはできません。
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の変化はトラストアンカーストア内の既存の管理やアイデンティティトラストアンカーに関連した情報を更新するために使用されます。証明書は、エラーコードimproperTAChangeに失敗しなければなりませんようトラストアンカーを変更しようとするが追加されました。 TrustAnchorChangeInfoのSubjectPublicKeyInfoでフィールド内またはTBSCertificateChangeInfo名-更新するトラストアンカーのSubjectPublicKeyInfoでフィールドに含まれる公開鍵。第7節に記載従属チェックが満足されない場合は、アクションはnotAuthorizedエラーコードで失敗しなければなりません。存在しないトラストアンカーを変更しようとする試みは、trustAnchorNotFoundステータスコードと失敗をもたらさなければなりません。 TrustAnchorChangeInfo構造やTBSCertificateChangeInfo構造は、管理やアイデンティティトラストアンカーの改訂コンフィギュレーションを提供するために使用されます。アップデートが何らかの理由で失敗した場合は、元のトラストアンカーの設定が保存されなければなりません。頂点トラストアンカー情報は、このアクションを使用して変更することはできません。トラストアンカーを変更しようとすると、improperTAChangeエラーで失敗しなければなりませんTrustAnchorChangeInfoを使用したtbsCertificateとして追加しました。トラストアンカーを変更しようとすると、improperTAChangeエラーで失敗しなければなりませんTBSCertificateChangeInfoを使用してTrustAnchorInfoとして追加しました。
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では、アルゴリズム識別子と管理やアイデンティティトラストアンカーの公開鍵が含まれています。トラストアンカーストアで-更新するトラストアンカーの位置を特定するために使用されます。
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でフィールドに含まれるトラストアンカーの公開鍵の公開鍵識別子が含まれています。このフィールドが存在しない場合、公開鍵識別子は変更されません。このフィールドが存在する場合は、提供された公開鍵識別子は、前のものに置き換えられます。
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はオプションであり、存在する場合、それは管理やアイデンティティトラストアンカーのために人間が読める形式の名前を提供します。ときに欠席変更トラストアンカーのアップデートでは、以前にトラストアンカーに関連付けられたすべてのタイトルが削除されます。同様に、本変更トラストアンカーの更新で、メッセージ内のタイトルは、トラストアンカーと関連付けられています。前回のタイトルがトラストアンカーと関連していた場合、そのタイトルが置き換えられます。タイトルは以前トラストアンカーに関連付けられていなかった場合は、更新メッセージのタイトルが追加されます。
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証明書パスは、任意であり、存在する場合、それは、X.509証明書パスを構築し、検証するのに必要な制御を提供します。ときに欠席変更トラストアンカーのアップデートでは、以前の管理やアイデンティティトラストアンカーに関連付けられたすべてのコントロールが代表団はもはや許されないことを意味され、削除されます。同様に、本変更トラストアンカーの更新で、メッセージのコントロールは、管理又はアイデンティティトラストアンカーに関連付けられています。トラストアンカー識別名を含む以前のコントロールは、トラストアンカーと関連していた場合、そのコントロールは、委任がサポートされ続けていることを意味し、交換されているが、その別の証明書パスが有効になります。コントロールが以前管理やアイデンティティトラストアンカーに関連付けられていなかった場合は、更新メッセージからのコントロールは、委任を可能にする、追加されます。 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.
EXTS Oオプションであり、存在する場合には、トラストアンカーに関連付けられている拡張子の値を提供します。ときに欠席変更トラストアンカーのアップデートでは、以前にトラストアンカーに関連付けられたすべての拡張機能が削除されます。同様に、本変更トラストアンカーの更新で、メッセージ内の拡張機能は、トラストアンカーと関連しています。以前トラストアンカーに関連付けられている任意の拡張子を交換するか、または削除されます。
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.
TBSCertificateChangeInfoのフィールドは、たtbsCertificate構造内のフィールドを変更するために使用されます。たtbsCertificateは、[RFC5280]に記載されています。フィールドは変更のトラストアンカーのアップデートに存在しない場合EXTSを除くすべてのフィールドについては、その後、トラストアンカーに関連するすべての以前の値は変更されません。 EXTSフィールドに対して、もしフィールドは、次にトラストアンカーに関連する任意の以前の値が削除され、変更トラストアンカーの更新には存在しません。フィールドが変更トラストアンカーの更新中に存在する場合、すべてのフィールドについては、その後、トラストアンカーに関連付けられた以前の値は、更新メッセージからの値に置き換えられます。
[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
[RFC5914]は信頼アンカーのリストを搬送するTrustAnchorList構造を定義します。実装がTAMPUpdateに相当するように（[RFC5914]で定義されたID-CT-trustAnchorList OIDを使用してのeContentType（またはcontentTypeのと））TrustAnchorListオブジェクトを処理することができるタンプ
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.
簡潔に簡潔なセットを持つオブジェクトは、msgRefは、（適切なシーケンス番号）allModulesに設定され、追加のフィールド内に含まれるリスト内のすべての要素。 TrustAnchorUpdateこの代替は、別のトラストアンカーストアから信頼アンカーを転送する簡単な手段として、アウト・オブ・バンド整合性および認証チェックを実行実装するために設けられています。これは、トラストアンカーを削除または変更する手段を提供し、何の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.
トラストアンカーアップデート確認メッセージは、有効なトラストアンカーUpdateメッセージにトラストアンカーストアによって返信です。トラストアンカーアップデート確認メッセージは、要求された更新のそれぞれについて、成功と失敗の情報を提供します。トラストアンカーアップデート確認メッセージは、符号付きまたは符号なしかもしれません。実装は、それに署名することができる場合トラストアンカー更新確認メッセージが署名されなければなりません。
The Trust Anchor Update Confirm content type has the following syntax:
トラストアンカーの更新を確認し、コンテンツタイプの構文は次のとおりです。
tamp-update-confirm CONTENT-TYPE ::=
{ TAMPUpdateConfirm IDENTIFIED BY id-ct-TAMP-updateConfirm }
id-ct-TAMP-updateConfirm OBJECT IDENTIFIER ::= { id-tamp 4 }
TAMPUpdateConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
update TAMPMsgRef,
confirm UpdateConfirm }
UpdateConfirm ::= CHOICE {
terseConfirm [0] TerseUpdateConfirm,
verboseConfirm [1] VerboseUpdateConfirm }
TerseUpdateConfirm ::= StatusCodeList
StatusCodeList ::= SEQUENCE SIZE (1..MAX) OF StatusCode
VerboseUpdateConfirm ::= SEQUENCE {
status StatusCodeList,
taInfo TrustAnchorChoiceList,
tampSeqNumbers TAMPSequenceNumbers OPTIONAL,
usesApex BOOLEAN DEFAULT TRUE }
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更新は、トラストアンカーストアが応答されたTAMPUpdateメッセージを識別する。更新構造は、トラストアンカー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の確認は、簡潔な更新確認や詳細な更新確認のいずれかが含まれています。簡潔な更新確認をTerseUpdateConfirmで表され、かつ冗長な応答がVerboseUpdateConfirmで表されます。
The TerseUpdateConfirm contains a sequence of status codes, one for each TrustAnchorUpdate structure in the Trust Anchor Update message. The status codes MUST appear in the same order as the TrustAnchorUpdate structures to which they apply, and the number of elements in the status code list MUST be the same as the number of elements in the trust anchor update list. Each of the status codes is discussed in Section 5.
TerseUpdateConfirmは、ステータスコード、トラストアンカーUpdateメッセージにおける各TrustAnchorUpdate構造のための1つの配列を含みます。ステータスコードは、それらが適用されるTrustAnchorUpdate構造と同じ順序で現れなければならない、とステータスコードのリストの要素の数は、トラストアンカーの更新リスト内の要素の数と同じでなければなりません。ステータスコードの各々は、セクション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ステータスは、ステータスコード、トラストアンカーUpdateメッセージにおける各TrustAnchorUpdate構造のための1つの配列を含みます。ステータスコードは、それらが適用されるTrustAnchorUpdate構造と同じ順序で表示され、ステータスコードリストの要素数は、トラストアンカーの更新リスト内の要素の数と同じでなければなりません。ステータスコードの各々は、セクション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の場合、頂点トラストアンカーは、シーケンスの最初のトラストアンカーです。
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のメッセージに署名する権限を各トラストアンカーのために、現在開催されたシーケンス番号を示すために使用されます。鍵IDフィールドは、トラストアンカーを識別し、seqNumberフィールドは、トラストアンカーに関連付けられた現在のシーケンス番号を提供します。
o usesApex is a Boolean value that indicates whether the first item in the taInfo field identifies the apex TA.
O usesApexはtaInfoフィールドの最初の項目は頂点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.
アペックストラストアンカーUpdateメッセージは、必要に応じて、頂点トラストアンカーに関連した不測の公開鍵を運用する公開鍵を置き換えます。各トラストアンカーストアは、1つの頂点トラストアンカーを持っています。いかなる制約は頂点トラストアンカーに関連付けられていません。運用公開鍵の公開鍵識別子は、後続のTAMPメッセージで頂点トラストアンカーを識別するために使用されます。アペックストラストアンカーUpdateメッセージのデジタル署名は、現在の動作公開鍵または現在の不測の公開鍵のいずれかで検証されます。運用公開鍵で検証されたApexトラストアンカーUpdateメッセージが有効であるために、トラストアンカーストアは、更新の対象は、シーケンス番号が正常に動作し、公開鍵のための最も最近に保存されたシーケンス番号よりも大きくなければなりませんでなければなりません、デジタル署名は、動作公開鍵を直接検証する必要があります。つまり、証明書パスを経由して何の委任は許されません。偶発公開鍵で検証されたApexトラストアンカー更新メッセージが有効であるために、トラストアンカーストアは、更新対象でなければなりません、提供復号鍵は適切に不測の公開鍵を復号化する必要があり、デジタル署名が検証されなければなりません直接復号化されたコンティンジェンシー公開鍵で。ここでも、証明書パスを経由して何の委任は許されません。
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.
エイペックストラストアンカーUpdateメッセージを動作公開鍵を用いて検証された場合、セクション6で説明したように、その後、シーケンス番号処理は、アペックス・トラストアンカーUpdateメッセージが偶発公開鍵を用いて検証される場合、TAMPMsgRefシーケンス番号がなければならず、正常に処理されゼロ値が含まれています。新しい運用公開鍵で検証される後続のメッセージのシーケンス番号は、必要に応じて提供することができます。値を指定しない場合は、トラストアンカーストアは、新しくインストールされた頂点トラストアンカー運用公開鍵で検証し、次TAMPメッセージ内の任意のシーケンス番号を受け入れるように準備しなければなりません。アペックストラストアンカーUpdateメッセージが有効であるとclearTrustAnchorsフラグがTRUEに設定されている場合、トラストアンカーストアに格納されている管理とアイデンティティトラストアンカーのすべてを削除する必要があります。つまり、新しい頂点トラストアンカーは、トラストアンカーストアに残っている唯一のトラストアンカーでなければなりません。アペックストラストアンカーUpdateメッセージが有効であるとclearCommunitiesフラグがTRUEに設定されている場合、トラストアンカーストアに格納されているすべてのコミュニティ識別子を削除する必要があります。
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メッセージのデジタル署名を検証するために使用される頂点トラストアンカー公開鍵を識別する。運用の公開鍵の公開鍵識別子は、事前に知られており、それが頂点トラストアンカーの一部として保存されます。有事の公開鍵の公開鍵識別子は、事前に知られていません。しかし、明確に不測の公開鍵を解読するために必要な対称鍵を格納した符号なし属性の存在はTAMPメッセージの署名者は、Apexのトラストアンカー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.
アペックストラストアンカーUpdateメッセージにデジタル署名が頂点トラストアンカー運用公開鍵または頂点トラストアンカー偶発公開鍵のいずれかを使用して有効である場合は、シーケンス番号のチェックが成功し、そしてトラストアンカーストアはTAMPメッセージの目的の受信者であります、その後、トラストアンカーストアは頂点トラストアンカーを更新し、Apexのトラストアンカーアップデート確認メッセージを返さなければなりません。アペックストラストアンカーアップデート確認メッセージが返されない場合、TAMPのエラーメッセージが返されます。アペックストラストアンカーUpdateメッセージが頂点トラストアンカー不測の公開鍵で検証された場合にシーケンス番号がゼロでなければならないことに注意してください。
The Apex Trust Anchor Update content type has the following syntax:
アペックストラストアンカーの更新コンテンツタイプの構文は次のとおりです。
tamp-apex-update CONTENT-TYPE ::=
{ TAMPApexUpdate IDENTIFIED BY id-ct-TAMP-apexUpdate }
id-ct-TAMP-apexUpdate OBJECT IDENTIFIER ::= { id-tamp 5 }
TAMPApexUpdate ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
terse [1] TerseOrVerbose DEFAULT verbose,
msgRef TAMPMsgRef,
clearTrustAnchors BOOLEAN,
clearCommunities BOOLEAN,
seqNumber SeqNumber OPTIONAL,
apexTA TrustAnchorChoice }
The fields of TAMPApexUpdate are used as follows:
次のように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望まれる応答のタイプを示します。簡潔な応答は1の値で示され、そして冗長応答は、それがデフォルト値であるため、符号化中に省略されている2の値によって示されます。
o msgRef contains two items: the target and the seqNum. target identifies the target(s) of the Apex Trust Anchor Update message.
ターゲットとSEQNUM：O msgRefは、2つの項目が含まれています。ターゲットは、アペックス・トラストアンカーUpdateメッセージの対象（複数可）を識別する。
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節で説明したようにTargetIdentifier構文が使用されています。 SEQNUMはアペックストラストアンカー更新確認メッセージとエイペックストラストアンカー更新メッセージを一致させるために使用される使い捨ての値です。シーケンス番号は、メッセージが頂点トラストアンカー運用公開鍵で検証された場合TAMPメッセージのリプレイを検出するために使用されます。何らかのアクションが取られる前に、第6節で説明したシーケンス番号の処理が正常に完了しなければなりません。メッセージは頂点トラストアンカー不測の公開鍵で検証された場合は、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に設定されている場合、すべてのトラストアンカーストアに格納されている管理とアイデンティティトラストアンカーのは、トラストアンカーストアでのみトラストアンカーとして新しくインストールされた頂点トラストアンカーを残して、削除する必要があります。値が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 clearCommunitiesはブール値です。値がTRUEに設定されている場合、すべてのトラストアンカーストアに格納されているコミュニティ識別子のはどれも残さない、削除する必要があります。値がFALSEに設定されている場合は、コミュニティ識別子のリストを変更してはいけません。
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はオプションであり、存在する場合、それは頂点トラストアンカーのための初期シーケンス番号を提供します。 seqNumberが存在しない場合は、トラストアンカーストアは頂点トラストアンカー運用公開鍵の任意のシーケンス番号の値を受け入れるために準備されます。
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は、交換頂点トラストアンカーのための情報を提供します。 TrustAnchorChoice構造は、信頼できる公開鍵とそれに関連するすべての情報を提供するために使用されます。 pubkeyで、鍵ID、taTitle、証明書パス、およびEXTSフィールドは頂点トラストアンカーの運用公開鍵に適用されます。 ApexTrustAnchorInfo証明書拡張は、拡張機能として表示されることがあります。第9章は、WrappedApexContingencyKey証明書拡張について説明します。
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.
アペックストラストアンカーアップデート確認メッセージは、有効なアペックストラストアンカーUpdateメッセージにトラストアンカーストアによって返信です。アペックストラストアンカーアップデート確認メッセージは頂点トラストアンカーの更新のための成功または失敗の情報を提供します。アペックストラストアンカーアップデート確認メッセージは、符号付きまたは符号なしかもしれません。トラストアンカーストアは、それに署名することができる場合アペックストラストアンカーアップデート確認メッセージが署名する必要があります。
The Apex Trust Anchor Update Confirm content type has the following syntax:
アペックストラストアンカーの更新を確認し、コンテンツタイプの構文は次のとおりです。
tamp-apex-update-confirm CONTENT-TYPE ::=
{ TAMPApexUpdateConfirm IDENTIFIED BY
id-ct-TAMP-apexUpdateConfirm }
id-ct-TAMP-apexUpdateConfirm OBJECT IDENTIFIER ::= { id-tamp 6 }
TAMPApexUpdateConfirm ::= SEQUENCE {
version [0] TAMPVersion DEFAULT v2,
apexReplace TAMPMsgRef,
apexConfirm ApexUpdateConfirm }
ApexUpdateConfirm ::= CHOICE {
terseApexConfirm [0] TerseApexUpdateConfirm,
verboseApexConfirm [1] VerboseApexUpdateConfirm }
TerseApexUpdateConfirm ::= StatusCode
VerboseApexUpdateConfirm ::= SEQUENCE {
status StatusCode,
taInfo TrustAnchorChoiceList,
communities [0] CommunityIdentifierList OPTIONAL,
tampSeqNumbers [1] TAMPSequenceNumbers OPTIONAL }
The fields of TAMPApexUpdateConfirm are used as follows:
次のように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は、トラストアンカーストアが応答されたエイペックストラストアンカー更新メッセージを識別する。 apexReplace構造は、ApexのトラストアンカーUpdateメッセージの先頭からTAMPMsgRefを繰り返し（4.5節を参照してください）。アペックストラストアンカーUpdateメッセージを運用する公開鍵で検証された場合には、第6節で説明したシーケンス番号の処理は、アペックス・トラストアンカーアップデート確認メッセージが生成される前に正常に完了する必要があります。エイペックストラストアンカーUpdateメッセージが偶発公開鍵で検証された場合、通常のシーケンス番号の処理は無視されるが、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は簡潔な更新確認や詳細な更新確認のいずれかが含まれています。簡潔な更新確認を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は頂点トラストアンカーの更新の成功または失敗を示す、一つのステータスコードが含まれています。頂点トラストアンカーの更新が失敗した場合は、ステータスコードは失敗の理由を提供します。ステータスコードの各々は、セクション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ステータスが頂点トラストアンカーの更新の成功または失敗を示す、一つのステータスコードが含まれています。頂点トラストアンカーの更新が失敗した場合は、ステータスコードは失敗の理由を提供します。ステータスコードの各々は、セクション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つのエントリはトラストアンカーストアに含まれる各トラストアンカーのために提供されます。頂点トラストアンカーの更新が処理された後、これらは、トラストアンカーの状態を表しています。 TrustAnchorInfo構造の説明については、[RFC5914]を参照。頂点トラストアンカーは、シーケンスの最初のトラストアンカーです。
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人のコミュニティ。トラストアンカーストアが無いのコミュニティに属している場合、このフィールドは省略されています。
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のメッセージに署名する権限を各トラストアンカーのために、現在開催されたシーケンス番号を示すために使用されます。鍵IDフィールドは、トラストアンカーを識別し、seqNumberフィールドは、トラストアンカーに関連付けられた現在のシーケンス番号を提供します。
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.
トラストアンカーストアは、それがメンバーである地域社会のための識別子のリストを維持します。コミュニティ更新メッセージは、このリストからコミュニティ識別子を削除または追加するために使用することができます。コミュニティUpdateメッセージを署名する必要があります。コミュニティUpdateメッセージが有効であるために、トラストアンカーストアは、更新の対象とする必要があります。 TAMPメッセージの署名者がトラストアンカーの場合に第6節で説明したチェックシーケンス番号が成功しなければなりません。電子署名は、頂点トラストアンカー動作公開鍵、権限管理トラストアンカー、またはそのようなトラストアンカーに由来認可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.
トラストアンカーストアコミュニティUpdateメッセージをサポートしている場合は、コミュニティの更新メッセージのデジタル署名は、署名者が許可され、シーケンス番号のチェックが成功し、有効で、トラストアンカーストアはその後、信頼TAMPメッセージの目的の受信者でありますアンカーストアが指定された更新を行い、コミュニティの更新がメッセージを確認して返さなければなりません。コミュニティアップデート確認メッセージが返されない場合、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.
コミュニティUpdateメッセージは、更新のバッチが含まれており、すべての更新は成功したコミュニティアップデート確認メッセージを返すために、トラストアンカーストアのために受理されなければなりません。削除の更新は、存在する場合、追加のアップデートの前に処理しなければなりません。削除は空のリストを持つ存在する場合、すべてのコミュニティ識別子を削除する必要があります。このアプローチは成功したほか、障害が発生した除去によってインストールされているから、相互に排他的であることが意図されているコミュニティ識別子を防ぐことができます。アドオンが存在する場合、少なくとも一つのコミュニティ識別子は、リストに表示されなければなりません。
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望まれる応答のタイプを示します。簡潔な応答は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.
ターゲットとSEQNUM：O msgRefは、2つの項目が含まれています。ターゲットは、更新メッセージの対象（複数可）を識別する。 4.1節で説明したようにTargetIdentifier構文が使用されています。 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つが存在しなければなりません。最初のシーケンスを削除するコミュニティ識別子が含まれており、どれも存在しない場合、それは存在しません。削除は空のリストを持つ存在する場合、すべてのコミュニティ識別子を削除する必要があります。第二の配列を追加するコミュニティ識別子が含まれており、どれも存在しない場合、それは存在しません。削除の更新は、存在する場合、追加のアップデートの前に処理しなければなりません。要求された削除または追加のいずれかを行うことができない場合、エラーが生成されます。しかし、存在しないコミュニティ識別子を削除する要求が成功した削除として扱われます。同様に、すでに存在しているコミュニティの識別子を追加するための要求が成功した添加物として扱われます。エラーが発生した場合、トラストアンカーストアコミュニティリストを変更してはいけません。
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トラストアンカーストアに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.
コミュニティ更新メッセージを確認し、有効なコミュニティUpdateメッセージにトラストアンカーストアによって返信です。コミュニティアップデート確認メッセージは、要求されたアップデートの成功または失敗の情報を提供します。成功は、更新のバッチ全体が正常に処理されている場合にのみ返されます。要求されたアップデートのいずれかが実行できない場合は、故障が表示され、トラストアンカーストアに格納されているコミュニティ識別子のセットは変更されません。コミュニティアップデート確認メッセージは、符号付きまたは符号なしかもしれません。トラストアンカーストアは、それに署名することができる場合コミュニティアップデート確認メッセージが署名する必要があります。
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更新は、トラストアンカーストアが応答されているコミュニティUpdateメッセージを識別します。更新構造は、コミュニティUpdateメッセージ（4.7節を参照）からTAMPMsgRefを繰り返します。アップデートのいずれかが処理される前に、第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は簡潔なコミュニティ更新確認や詳細な地域社会の更新確認のいずれかが含まれています。簡潔な応答は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のコミュニティはオプションです。存在する場合、更新が処理された後、それがトラストアンカーストアに存在するコミュニティ識別子のシーケンスが含まれています。トラストアンカーストアが無いのコミュニティに属している場合、このフィールドは省略されています。
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.
トラストアンカーストアは頂点トラストアンカーとTAMPメッセージを許可各管理トラストアンカーのための現在のシーケンス番号を維持します。シーケンス番号の処理は、シーケンス番号は、メッセージがそれによって再生の可能性を減少させる、1つ以上のターゲットに最も最近使用されたシーケンス番号を提供するために使用することができる調整セクション6に記載されています。シーケンス番号は、メッセージが署名する必要があります調整します。シーケンス番号が有効であるとのメッセージを調整するために、トラストアンカーストアはシーケンス番号に等しいか又は元のトラストアンカーのための最も最近に格納されたシーケンス番号よりも大きくなければならない、シーケンス番号の意図された受信者がメッセージを調整すること、としなければなりませんデジタル署名は、頂点トラストアンカー運用公開鍵または許可管理トラストアンカーによって検証されなければなりません。
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のエラーメッセージが返されます。
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:
次のようにSequenceNumberAdjustのフィールドが使用されます。
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.
ターゲットとSEQNUM：O msgRefは、2つの項目が含まれています。標的は、シーケンス番号の対象（複数可）メッセージを調整識別する。 4.1節で説明したようにTargetIdentifier構文が使用されています。 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調整は、シーケンス番号がトラストアンカーストアが応答されたメッセージを調整識別する。調整構造（セクション4.9を参照）メッセージを調整シーケンス番号からTAMPMsgRefを繰り返します。第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メッセージへのトラストアンカーストアによって返信です。 TAMPのエラーメッセージには、エラーの原因の指標を提供します。 TAMPのエラーメッセージは、符号付きまたは符号なしかもしれません。トラストアンカーストアは、それに署名することができる場合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:
トラストアンカーの更新確認、アペックス・トラストアンカーアップデート確認、コミュニティの更新確認には、シーケンス番号は確認を調整し、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:
以下の通りのStatusCodeの様々な値が使用されます。
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は、トラストアンカーストアが正常に提供されたメッセージを解読することができなかったことを示すために使用されます。指定されたコンテンツタイプと提供されたコンテンツが一致していません。
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構文が無効であるかのcontentTypeがContentInfo以内に実施することを不明またはサポートされていないことを示すために使用されます。
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.
badSignedDataはSignedDataの構文が無効であることを示すために使用されるO、バージョンが不明またはサポートされていない、または複数のエントリはdigestAlgorithmsに存在しています。
o badEncapContent is used to indicate that the EncapsulatedContentInfo syntax is invalid. This error can be generated due to problems located in SignedData.
O badEncapContentはEncapsulatedContentInfo構文が無効であることを示すために使用されます。このエラーは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はOPTIONAL e-コンテンツは、本明細書で必要とされるEncapsulatedContentInfoに欠けていることを示すために使用されます。このエラーは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つの可能なエラー状況の1つを示すために使用されています。あるケースでは、subjectKeyIdentifierは、トラストアンカーまたはインストールトラストアンカーで終了証明書パスの公開鍵を識別しません。他の場合では、issuerAndSerialNumberは、本明細書で禁止されて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 notAuthorized 2つの可能なエラー状況の1つを示すために使用されています。あるケースでは、のSignerInfo内のSIDがインストールトラストアンカーにつながるが、そのトラストアンカーは、受信TAMPメッセージのコンテンツタイプの認可署名者ではありません。アイデンティティの信頼アンカーはTAMPメッセージコンテンツタイプのいずれかの署名者を認可されていません。他の場合には、トラストアンカー更新メッセージの署名者はセクション7に従属処理の失敗によって決定されるように、更新することがトラストアンカーを管理する権限がありません。
o badDigestAlgorithm is used to indicate that the digestAlgorithm in either SignerInfo or SignedData is unknown or unsupported.
O badDigestAlgorithmはのSignerInfoまたはSignedDataのいずれかでdigestAlgorithmが不明またはサポートされていないことを示すために使用されます。
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 unsupportedKeySizeはの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 insufficientMemoryは、トラストアンカーストアは結果のトラストアンカーの設定やコミュニティの識別子を格納するのに十分なメモリを持っていなかったので、更新が処理できなかったことを示しています。
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は、トラストアンカーストアが提供TAMPメッセージの種類をサポートしていないためTAMPメッセージを処理できなかったことを示しています。 ID-CT-TAMP-communityUpdateコンテンツタイプが用意されている場合、このコードが使用され、トラストアンカーストアはコミュニティ更新メッセージをサポートしていません。 eContentType内contentTypeの値は、本明細書で定義されているものでない場合は、このステータスコードを使用することもあろう。
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は、トラストアンカーUpdateメッセージが頂点トラストアンカーを削除しようとしたため、更新が処理できなかったことを示しています。
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は、トラストアンカーの更新プログラムが既に存在する可能性がある新しいトラストアンカーを追加しようとしているが、それに-追加することがトラストアンカーのいくつかの属性が不適切な方法で変更されていることを示しています。所望のトラストアンカーの構成ではなく、追加操作の変更操作で達成することができます。
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.
入出力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 incorrectTargetは、トラストアンカーストアが目的の受信者ではないため、クエリ、更新、またはメッセージを調整するが処理できなかったことを示しています。
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は、トラストアンカーへの変更が要求されたことを示しているが、参照トラストアンカーは、トラストアンカーストアで表現されていません。
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 unsupportedTAKeySizeは、トラストアンカーがサポートされていないサイズの公開鍵が含まれるであろうことを示しています。
o unsupportedContinPubKeyDecryptAlg indicates that the decryption algorithm for the apex trust anchor contingency public key is not supported.
O unsupportedContinPubKeyDecryptAlgは頂点トラストアンカーの不測の事態のための復号化アルゴリズム、公開鍵はサポートされていないことを示しています。
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は、トラストアンカーに関連付けられているpolicyFlagsが存在するとPOLICYSETを要求する形で設定されていることを示しているが、POLICYSETがありません。
o revokedCertificate indicates that one or more of the certificates needed to properly process the TAMP message have been revoked.
O revokedCertificateが正しく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は、トラストアンカーの更新は、既存のトラストアンカーの形式とは異なる形式を使用して、新しいトラストアンカーを変更しようとしていることを示しています。
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としてTAMPメッセージが、カプセル化されたCMS構造の処理中にエラーを示すか、するMessageDigest属性。
o unsupportedTargetIdentifier indicates that a msgRef with an unsupported TargetIdentifier option was encountered.
O unsupportedTargetIdentifierはサポートされていないTargetIdentifierオプション付き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のステータスクエリー、トラストアンカーの更新、アペックス・トラストアンカーの更新、コミュニティ更新、およびシーケンス番号は、メッセージを調整し、シーケンス番号が含まれます。この使い捨て識別子は、そのTAMPメッセージに応答してTAMPメッセージを一致させるために使用されます。 TAMPメッセージを直接トラストアンカーを使用して検証された場合、シーケンス番号も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メッセージの発信者は、単調に増加する負でない整数としてシーケンス番号を扱わなければなりません。シーケンス番号カウンタは、秘密鍵によって行われる署名操作に関連付けられています。トラストアンカーストアが新たに受信されたTAMPメッセージがトラストアンカーの公開鍵は、その発信元からの最新正常に処理TAMPメッセージよりも大きいシーケンス番号が含まれていることで直接確認されることを保証しなければなりません。シーケンス番号は、その発信元からの最新正常に処理TAMPメッセージ以上である場合にシーケンス番号の調整メッセージが有効と見なされることに注意してください。受信TAMPメッセージ内のシーケンス番号がこれらの条件を満たしていない場合は、トラストアンカーストアは、シーケンス番号の失敗（seqNumFailure）エラーを返す、TAMPメッセージを拒絶しなければなりません。
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.
シーケンス番号値がトラストアンカーUpdateメッセージで提供されていない場合、トラストアンカーは、新しくインストールされたトラストアンカーとして、または既存のトラストアンカーへの変更のいずれかとして、TAMPメッセージを許可されるたびに、メモリは、シーケンス番号のために確保しなければなりませんそしてゼロに設定。第TAMPメッセージは、それがシーケンス番号チェックに基づいて拒絶されないことトラストアンカーを使用して検証され、受信し、その第一TAMPメッセージのシーケンス番号が格納されます。 TAMPメッセージの受信者は、トラストアンカーから正常に処理TAMPメッセージからの最新のシーケンス番号のデータベースを維持しなければなりません。このデータベースのインデックスは、トラストアンカーの公開鍵です。これは、頂点トラストアンカー運用公開鍵または管理トラストアンカーの公開鍵である可能性があります。最初のケースでは、頂点トラストアンカー動作公開鍵はTAMPメッセージのデジタル署名を検証するために直接使用されます。第二のケースでは、管理の信頼アンカー公開鍵は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ビットの負でない整数でなければなりません。 INTEGERのASN.1符号化が常に符号ビットを含むので、TAMPメッセージ署名者はTAMPメッセージの署名者が異なる公開/秘密鍵ペアに移行しなければならない前に、64ビットのシーケンス番号空間を排気する前に9,223,372,036,854,775,807 TAMPメッセージを生成することができます。トラストアンカー更新およびシーケンス番号異なる鍵ペアへの移行を回避するために意図されていないメッセージを調整することによって提供されるシーケンス番号をリセットする能力。むしろ、操作ミスからの回復を支援することを意図しています。比較的小さな不揮発性ストレージ要件は頂点トラストアンカーと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.
頂点トラストアンカーまたは管理トラストアンカーを交換またはトラストアンカー・ストアから削除されると、関連付けられたシーケンス番号記憶は再利用されるべきです。
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メッセージの署名者は、その後、意図された情報をアサートするTrustAnchorInfo構造内部証明書をラップすることができます。
The apex trust anchor is unconstrained, which means that subordination checking need not be performed on Trust Anchor Update messages signed with the apex trust anchor operational public key and that trust anchor information can be stored as it appears in the update message. Subordination checking is performed as part of the validation process of all other Trust Anchor Update messages.
頂点トラストアンカーは、それが更新メッセージに表示される従属チェックが保存することができ頂点トラストアンカー運用公開鍵とそのトラストアンカー情報で署名トラストアンカー更新メッセージ上で実行する必要がないことを意味し、無制約です。劣後チェックは、他のすべてのトラストアンカー更新メッセージの検証プロセスの一部として実行されます。
For a Trust Anchor Update message that is not signed with the apex trust anchor operational public key to be valid, the digital signature MUST be validated using an authorized trust anchor, either directly or via an X.509 certification path originating with the apex trust anchor operational public key or an authorized management trust anchor. The following subordination checks MUST also be performed as part of validation of the update message.
有効であるために頂点トラストアンカー動作公開鍵で署名されていないトラストアンカーUpdateメッセージのために、デジタル署名は、直接または頂点トラストアンカーに由来する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.
各トラストアンカーUpdateメッセージは、追加、変更、またはトラストアンカーを削除するために使用され、それぞれが1つの以上の個別の更新プログラムが含まれています。各個々の更新のために、TAMPメッセージ署名者の制約がより大きくまたは更新の信頼アンカーの制約に等しくなければなりません。具体的には、制約は、（証明書またはたtbsCertificateオブジェクトまたは同等の拡張）TrustAnchorInfoオブジェクトの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.
TAMPUpdateの結果としてトラストアンカーに記憶されたポリシーフラグの値がtrueまたはTAMPメッセージ署名者、すなわち、関連付けられたポリシーフラグの値に等しく、O、更新は偽にフラグを設定することができる場合にのみTAMPメッセージの署名者に関連付けられた値はfalseです。 TAMPメッセージの署名者に関連付けられたポリシーフラグは、署名者がトラストアンカーとして、またはexplicit_policy、policy_mappingから表される場合policyFlagsフィールドまたはPolicyConstraintsのとinhibitAnyPolicy拡張から読み出され、パス検証以下inhibit_anyPolicy状態変数署名者は、以下のように表現されていない場合トラストアンカー。
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.
TAMPUpdateの結果としてトラストアンカーに格納された証明書ポリシーoをTAMPメッセージ署名者と更新からPOLICYSETフィールドまたはcertificatePolicies拡張の値に関連付けられた証明書ポリシーの値の交点に等しいです。署名者がトラストアンカーとして、または署名者がで表現されていない場合は、パスの検証以下返さvalid_policy_treeから表現されている場合TAMPメッセージの署名者に関連付けられた証明書ポリシーは、証明書またはたtbsCertificateでTrustAnchorInfoまたはcertificatePolicies拡張にPOLICYSETフィールドから読み込まれトラストアンカー。 TAMPメッセージ署名者がトラストアンカーとして表現されている場合、ポリシーマッピングは実行されません。交差点がNULLであるとし、保存されていることがrequireExplicitPolicyの値がtrueの場合、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.
TAMPUpdateの結果としてトラストアンカーと共に格納除外名oをTAMPメッセージ署名者と更新からnameConstrフィールド又はいるNameConstraints拡張からの値に関連付けられた除外名の組合に等しいです。署名者がトラストアンカーでない場合、署名者は、パス検証以下のトラストアンカーまたはexcludedSubtrees状態変数からのものである場合TAMPメッセージの署名者に関連付けられている名前制約は、証明書またはたtbsCertificateでTrustAnchorInfoかいるNameConstraints延長でnameConstrフィールドから読み込まれ。アップデートに含まトラストアンカーの名前が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.
TAMPUpdateの結果としてトラストアンカーと共に格納許可名oをTAMPメッセージ署名者と更新からnameConstrフィールド又はいるNameConstraints拡張からの値に関連付けられた許可名の交点に等しいです。署名者がトラストアンカーでない場合、署名者は、パス検証以下のトラストアンカーまたはpermittedSubtrees状態変数からのものである場合TAMPメッセージの署名者に関連付けられている名前制約は、証明書またはたtbsCertificateでTrustAnchorInfoかいるNameConstraints延長でnameConstrフィールドから読み込まれ。アップデートに含まトラストアンカーの名前がTAMPの署名者の許可名前空間内に入らなければなりません。トラストアンカーの名前が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識別名と同じ公開鍵識別子を持つことになりますが、異なる公開鍵がdiminishingly小型である確率。そのため、権限の鍵識別子証明書拡張は、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.
頂点トラストアンカーはWrappedApexContingencyKey拡張子を使用して不測の鍵情報を含むことができます。以下に定義されるように拡張はApexContingencyKey構造を使用します。
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のフィールドは、以下に記載するように使用されています。一つのフィールドが存在する場合、両方が存在しなければなりません。一つのフィールドが存在しない場合、両方が存在してはなりません。フィールドは、対応する公開鍵は、いくつかの信頼当事者によって頂点トラストアンカーとして認識されていることを示すための手段として、この拡張の使用を可能にするために存在しないことが許可されています。
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は頂点トラストアンカー不測の公開鍵を暗号化するために使用される対称アルゴリズムを特定します。この公開鍵は、これまで必要とされている場合は、それを解読するために必要な対称キーは、それを使用して検証されるメッセージで提供されます。アルゴリズム識別子は、オブジェクト識別子とオプションのパラメータが含まれているのAlgorithmIdentifier、です。存在する場合、オブジェクト識別子は、パラメータの構文を示しています。
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 wrappedContinPubKeyは暗号化された頂点トラストアンカー不測の公開鍵です。復号化されると、それは、公開鍵自体が続くアルゴリズム識別子で構成されていPublicKeyInfo構造を生み出します。アルゴリズム識別子は、オブジェクト識別子とオプションのパラメータが含まのAlgorithmIdentifierです。存在する場合、オブジェクト識別子は、公開鍵の形式とパラメータの構文を示しています。公開鍵は、BIT STRINGとして符号化されています。
The WrappedApexContingencyKey certificate extension MAY be critical, and it MUST appear at most one time in a set of extensions. The apex trust anchor info extension is identified by the id-pe-wrappedApexContinKey object identifier:
WrappedApexContingencyKey証明書拡張は重要であり、それは、拡張機能のセットで、せいぜい1時間に現れなければなりません。頂点トラストアンカー情報拡張は、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メッセージの構文とセマンティクスに専念しています。これは、それぞれのトラストアンカー、中間CMSコンテンツタイプ、およびX.509証明書の構文とセマンティクスのために、特に[RFC5914]、[RFC3852]、および[RFC5280]、その他の仕様に依存しています。トラストアンカーストアのトラストアンカー状態を変更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.
この仕様の範囲外のセキュリティ要素が大幅に提供される保証に影響を与えます。その公開鍵に被写体の同一の結合を検証する証明機関（CA）によって使用される手順は、大きくされる証明書に関連付けられた保証に影響を与えます。他の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証明書パスまたは有効なものの拒絶の受け入れにつながることができます。名前の比較は非常に複雑になることがあります。トラストアンカーの店舗に、この複雑さを課すことを避けるために、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）はランダムワンタイム値の生成を必要とします。 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.
アイデンティティの信頼の妥協点は、対応するアイデンティティトラストアンカーで構成されているすべてのトラストアンカーの店舗に許容されるもので証明書を発行するために、秘密鍵の許可に権限のない者をアンカー。不正な秘密鍵ホルダーはアイデンティティトラストアンカーに関連付けられた証明書パスのコントロールによって制限されます。たとえば、アイデンティティトラストアンカーでのクリアランス制約が不正に秘密鍵保持者によって発行された証明書に受け入れられるクリアランスを決定します。
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に記載の従属性チェックの限度内で不正な秘密鍵保持者によって所望されるよう管理トラストアンカーは、その後、不正なプライベート、TAMP以外のコンテンツタイプに関連付けられている場合損なわ管理トラストアンカーを含むすべてのデバイスを構成することができますキーホルダーは、そのタイプの署名されたメッセージを生成することができます。管理トラストアンカーは、ファームウェアパッケージに関連付けられている場合たとえば、その後、無許可の秘密鍵ホルダーは異なるファームウェアをインストールすることができます。
Compromise of the apex trust anchor operational private key permits unauthorized parties to generate signed messages that will be acceptable to all trust anchor stores configured with the corresponding apex trust anchor. All devices that include that apex trust anchor can be configured as desired by the unauthorized private key holder, and the unauthorized private key holder can generate signed messages of any content type. The optional contingency private key offers a potential way to recover from such a compromise.
頂点信託の妥協点は、対応する頂点トラストアンカーで構成されているすべてのトラストアンカーの店舗に許容されるもので署名されたメッセージを生成するために運用する秘密鍵の許可に権限のない者をアンカー。不正な秘密鍵保持者が望むように頂点トラストアンカーを構成することができ、かつ不正な秘密鍵の所有者が任意のコンテンツタイプの署名されたメッセージを生成することができることを含んですべてのデバイス。オプションの不測の事態秘密鍵は、そのような妥協から回復する可能性方法を提供しています。
The compromise of a CA's private key leads to the same type of problems as the compromise of an identity or a management trust anchor private key. The unauthorized private key holder will be limited by the certification path controls and extensions associated with the trust anchor.
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.
エンドエンティティの秘密鍵の妥協は、エンドエンティティは、任意の証明書を発行することができないことを除いて、同一性または管理トラストアンカー秘密鍵の妥協として、問題の同じ種類につながります。不正な秘密鍵保持者は、トラストアンカーに関連付けられた証明書パスのコントロールと拡張によって制限されます。
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.
トラストアンカーストアのデジタル署名秘密鍵の許可の妥協権限のない者トラストアンカーストアとしてマスカレード、署名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.
頂点トラストアンカー不測の公開鍵を暗号化するために使用されるキー暗号化キーの早期開示は頂点トラストアンカー有事公開鍵の初期の暴露をもたらすことができます。
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コンテンツタイプ、属性、証明書、および拡張の構文解析の信頼性を高めるための一つの方法です。
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.
シーケンス番号値はリプレイの試みを検出するために使用されるように、トラストアンカーストアマネージャは、トラストアンカーストア・マネージャによって生成された次TAMPメッセージに含めるために、すなわち、知識のシーケンス番号、独自のシーケンス番号状態を維持するように注意しなければなりません。シーケンス番号状態の損失がseqNumFailureに処理できないTAMPメッセージの生成をもたらす可能性があります。損失の場合には、シーケンス番号の状態は、最近発生したTAMPメッセージを検査することによって復元することができ、メッセージが記録、または成功しTAMPStatusQueryメッセージを発行することができトラストアンカーの店長と共同で提供されます。
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）を使用して通信されます。オブジェクトは、PKIXワーキンググループにIANAによって委任円弧で定義されています。また、このドキュメントでは、IANAによってアクションがこの文書または任意の予想される更新のために必要であるこれ以上の付録Bで11件のメディアタイプ登録を含んでいません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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]ホフマン、P.およびJ. Schaad、RFC 5912、2010年6月 "公開鍵インフラストラクチャの使用X.509（PKIX）のための新しいASN.1モジュール"。
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, June 2010.
[RFC5914] Housley氏、R.、アシュモア、S.、およびC.ウォレス、 "トラストアンカーフォーマット"、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）、Canonicalの符号化規則（CER）と識別符号化規則（DER）の仕様"、1997。
[DSS] "FIPS Pub 186: Digital Signature Standard", May 1994.
[DSS] "FIPSパブ186：デジタル署名標準"、1994年5月。
[PKCS#6] "PKCS #6: Extended-Certificate Syntax Standard, Version 1.5", November 1993.
[PKCS＃6] "PKCS＃6：拡張-証明書構文規格、バージョン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.、ポーク、W.、およびR. Housley氏、RFC 3279、2002年4月 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールのためのアルゴリズムと識別子"。
[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]ターナー、S.およびD.ブラウン、RFC 5753、2010年1月 "暗号メッセージ構文における楕円曲線暗号（ECC）アルゴリズム（CMS）の使用"。
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[RFC5754]ターナー、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]ファレル、S.、Housley氏、R.、およびS.ターナー、 "認可のためのインターネット属性証明書プロフィール"、RFC 5755、2010年1月。
[TA-MGMT-REQS] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", Work in Progress, March 2010.
[TA-MGMT-REQS]レディ、R.とC.ウォレス、 "トラストアンカーの管理の要件"、進歩、2010年3月での作業。
[X.208] "ITU-T Recommendation X.208 - Specification of Abstract Syntax Notation One (ASN.1)", 1988.
[X.208] "ITU-T勧告X.208 - 抽象構文記法1（ASN.1）の仕様"、1988。
[X.509] "ITU-T Recommendation X.509 - The Directory - Authentication Framework", 2000.
[509] "ITU-T勧告X.509 - ディレクトリ - 認証フレームワーク"、2000年。
Appendix A. ASN.1 Modules
付録A. ASN.1モジュール
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機能の使用を除去します。そうでなければ、モジュール、すなわち、モジュールがビット・オン・ザ・ワイヤSEQUENCEとSET成分の制限は別に互換性がある、符号化された表現の点で互換性があります。拡張マーカーが原因[X.208]でのサポートの欠如に使用されていません。付録A.2は、現在のASN.1をサポートしていないASN.1コンパイラを使用する開発者への礼儀として含まれています。付録A.1は、[RFC5280]、[RFC5912]及び[RFC5914]からインポートされた定義を含みます。
A.1. ASN.1 Module Using 1993 Syntax
A.1。 1993構文を使用したASN.1モジュール
TAMP-Protocol-v2 { joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) modules(0) 30 }
TAMP・プロトコルV2 {関節-ISO-CCITT（2）国（16）米国（840）組織（1）GOV（101）DOD（2）INFOSEC（1）モジュール（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{}
輸入TrustAnchorChoice、TrustAnchorTitle、TrustAnchorInfoModule FROM CertPathControls {関節-ISO-CCITT（2）国（16）米国（840）組織（1）GOV（101）DOD（2）INFOSEC（1）モジュール（0）33}のAlgorithmIdentifier {}署名アルゴリズム、KEY-WRAP AlgorithmInformation-2009 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID FROM -mod-algorithmInformation-02（58）}の証明書、名前、たtbsCertificate、CertificateSerialNumber、有効性、SubjectPublicKeyInfoでPKIX1Explicit-2009 FROM - から[RFC5912] {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-pkix1-明示-02（51）} KeyIdentifier、FROM OTHER-NAME PKIX1Implicit-2009 - [RFC5912] {ISOから（1 ）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-pkix1-暗黙-02（59）} EXTENSION、拡張{ }、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) } ;
[RFC5912] {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティから（5）メカニズム（5）PKIX（7）ID-MOD（0）ID - PKIX-CommonTypes-2009 FROM -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
- アペックストラストアンカーの更新メッセージ
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
- アペックストラストアンカーUPDATE CONFIRMメッセージ
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
- コミュニティUPDATE CONFIRMメッセージ
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エラーメッセージ
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]
- TAMP符号なし属性 - [RFC5652]に設定UnsignedAttributes - これらの属性は未署名の属性であると入ります
TAMPUnsignedAttributes ATTRIBUTE ::= {
contingency-public-key-decrypt-key,
... -- Expect additional attributes --
}
-- contingency-public-key-decrypt-key unsigned attribute
- コンティンジェンシー・公開鍵解読キー未署名の属性
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
終わり
A.2. ASN.1 Module Using 1988 Syntax
A.2。 1988構文を使用したASN.1モジュール
TAMP-Protocol-v2-88 { joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) modules(0) 31 }
TAMP・プロトコルv2-88 {関節-ISO-CCITT（2）国（16）米国（840）組織（1）GOV（101）DOD（2）INFOSEC（1）モジュール（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) } ;
TrustAnchorInfoModule-88からの輸入TrustAnchorChoice、TrustAnchorTitle、CertPathControls - [RFC5914] {関節-ISO-CCITT（2）国（16）米国（840）組織（1）GOV（101）DOD（2）INFOSEC（1）モジュールから（0）37}のAlgorithmIdentifier、証明書、名前、属性たtbsCertificate、SubjectPublicKeyInfoで、CertificateSerialNumber、有効性、PKIX1Explicit88 FROM拡張 - [RFC5280]から{ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）機構（5）PKIX（7）ID-MOD（0）ID-pkix1-明示（18）} KeyIdentifier、PKIX1Implicit88 FROM AnotherName - [RFC5280] {ISO（1）同定された組織（3）DOD（から6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-暗黙（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
- アペックストラストアンカーの更新メッセージ
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
- アペックストラストアンカーUPDATE CONFIRMメッセージ
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
- コミュニティUPDATE CONFIRMメッセージ
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
- TAMPエラーメッセージ
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
終わり
Appendix B. Media Type Registrations
付録B.メディアタイプ登録
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.
イレブンメディアタイプ登録は、この付録では、本明細書で定義された各コンテンツタイプに対して1つ設けられています。第2節で述べたように、すべての場合にメッセージをタンプはContentInfo構造内にカプセル化されています。署名されたメッセージは、さらにSignedDataの構造内に封入されています。
B.1. application/tamp-status-query
B.1。アプリケーション/タンピング-ステータスクエリー
Media type name: application
メディア型名：アプリケーション
Subtype name: 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
マジックナンバー（S）：なし
File extension(s): .tsq
ファイルの拡張子（S）：.tsq
Macintosh File Type Code(s):
Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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
著者：サム・モア - srashmo@radium.ncsc.mil
Change controller: IESG
変更コントローラ：IESG
B.2. application/tamp-status-response
B.2。アプリケーション/タンピング-ステータス返信
Media type name: application
メディア型名：アプリケーション
Subtype name: 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
マジックナンバー（S）：なし
File extension(s): .tsr
ファイルの拡張子（S）：.tsr
Macintosh File Type Code(s):
Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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
著者：サム・モア - srashmo@radium.ncsc.mil
Change controller: IESG
変更コントローラ：IESG
B.3. application/tamp-update
B.3。アプリケーション/突き固め更新
Media type name: application
メディア型名：アプリケーション
Subtype name: 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
公開された仕様：RFC 5934
Applications that use this media type: TAMP clients responding to requests to update trust anchor information.
トラストアンカーの情報を更新するための要求に応答タンプクライアント：このメディアタイプを使用するアプリケーション。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー（S）：なし
File extension(s): .tur
ファイルの拡張子（S）：.tur
Macintosh File Type Code(s):
Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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
著者：サム・モア - srashmo@radium.ncsc.mil
Change controller: IESG
変更コントローラ：IESG
B.4. application/tamp-update-confirm
B.4。アプリケーション/タンピング-更新確認
Media type name: application
メディア型名：アプリケーション
Subtype name: 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.
トラストアンカーの情報を更新するための要求に応答タンプクライアント：このメディアタイプを使用するアプリケーション。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー（S）：なし
File extension(s): .tuc
ファイルの拡張子（S）：.tuc
Macintosh File Type Code(s):
Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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
著者：サム・モア - srashmo@radium.ncsc.mil
Change controller: IESG
変更コントローラ：IESG
B.5. application/tamp-apex-update
B.5。アプリケーション/タンピング-頂点更新
Media type name: application
メディア型名：アプリケーション
Subtype name: 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.
セキュリティの考慮事項：頂点トラストアンカー情報を更新するための署名要求を運びます。完全性保護は、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クライアントが頂点トラストアンカーを更新するための要求に応答：このメディアタイプを使用するアプリケーション。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー（S）：なし
File extension(s): .tau
ファイルの拡張子（S）：τは
Macintosh File Type Code(s):
Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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
著者：サム・モア - srashmo@radium.ncsc.mil
Change controller: IESG
変更コントローラ：IESG
B.6. application/tamp-apex-update-confirm
B.6。アプリケーション/タンピング-頂点 - 更新確認
Media type name: application
メディア型名：アプリケーション
Subtype name: 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.
セキュリティの考慮事項：頂点更新要求に応じて署名した応答を運びます。完全性保護は、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クライアントが頂点トラストアンカーを更新するための要求に応答：このメディアタイプを使用するアプリケーション。
Additional information:
追加情報：
Magic number(s): None
マジックナンバー（S）：なし
File extension(s): .auc
ファイルの拡張子（S）：.auc
Macintosh File Type Code(s):
Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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
著者：サム・モア - srashmo@radium.ncsc.mil
Change controller: IESG
変更コントローラ：IESG
B.7. application/tamp-community-update
B.7。アプリケーション/タンピング-コミュニティ更新
Media type name: application
メディア型名：アプリケーション
Subtype name: 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
マジックナンバー（S）：なし
File extension(s): .tcu
ファイルの拡張子（S）：.tcu
Macintosh File Type Code(s):
Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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
著者：サム・モア - srashmo@radium.ncsc.mil
Change controller: IESG
変更コントローラ：IESG
B.8. application/tamp-community-update-confirm
B.8。アプリケーション/タンピング-コミュニティ更新確認
Media type name: application
メディア型名：アプリケーション
Subtype name: 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
マジックナンバー（S）：なし
File extension(s): .cuc
ファイルの拡張子（S）：.cuc
Macintosh File Type Code(s):
Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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
著者：サム・モア - srashmo@radium.ncsc.mil
Change controller: IESG
変更コントローラ：IESG
B.9. application/tamp-sequence-adjust
B.9。アプリケーション/タンピング-配列調整
Media type name: application
メディア型名：アプリケーション
Subtype name: 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
マジックナンバー（S）：なし
File extension(s): .tsa
フィレekstension（C）：.tsa
Macintosh File Type Code(s):
Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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
著者：サム・モア - srashmo@radium.ncsc.mil
Change controller: IESG
変更コントローラ：IESG
B.10. application/tamp-sequence-adjust-confirm
B.10。アプリケーション/タンピング-配列調整-確認
Media type name: application
メディア型名：アプリケーション
Subtype name: 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
マジックナンバー（S）：なし
File extension(s): .sac
ファイルの拡張子（S）：.sac
Macintosh File Type Code(s):
Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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
著者：サム・モア - srashmo@radium.ncsc.mil
Change controller: IESG
変更コントローラ：IESG
B.11. application/tamp-error
B.11。アプリケーション/突き固め、エラー
Media type name: application
メディア型名：アプリケーション
Subtype name: 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
マジックナンバー（S）：なし
File extension(s): .ter
ファイルの拡張子（S）：.ter
Macintosh File Type Code(s):
Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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
著者：サム・モア - srashmo@radium.ncsc.mil
Change controller: IESG
変更コントローラ：IESG
Appendix C. TAMP over HTTP
HTTP経由付録C. TAMP
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メッセージの書式や交通規則について説明します。各TAMPメッセージタイプは、以下のサブセクションで覆われています。 HTTPを介して送信される各TAMP要求メッセージがどちらかに障害が前TAMP、HTTPエラーを呼び出すに発生した場合、TAMP応答またはエラーを含むか、HTTP応答で応答します。応答、確認をタンプ、およびエラーメッセージは、キャッシングには適していません。相互運用するためにHTTPを使用してTAMPクライアントおよびサーバーのためには、次の規則が適用されます。
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.
サーバがTLSをサポートする必要はありませんが、Oクライアントは、トランスポート層セキュリティ（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サーバは、クッキー、基本認証、またはダイジェスト認証など、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メソッドのためのものであることに注意してください。明らかに、唯一のPOSTに適用される規則は、この仕様書に関連しています。
C.1. TAMP Status Query Message
C.1。 TAMPステータスクエリメッセージ
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".
Content-Typeヘッダの値が「アプリケーション/タンプ-ステータスクエリ」を持っている必要があります。次のようにPOSTメソッドを使用してTAMPステータス照会メッセージが構築されます。
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エンコーディングのバイナリ値です。
C.2. TAMP Status Response Message
C.2。 TAMPステータス応答メッセージ
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状態応答メッセージは、セクション2で説明したようにCMS本体に包まTAMPStatusResponseのDERエンコーディングのバイナリ値、続いて適切なHTTPヘッダ、から構成されています。
The Content-Type header MUST have the value "application/ tamp-status-response."
Content-Typeヘッダは、「アプリケーション/タンプステータス応答」の値を持たなければなりません
C.3. Trust Anchor Update Message
C.3。トラストアンカーの更新メッセージ
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メソッドを使用して次のように構成されている：Content-Typeヘッダは、「アプリケーション/タンプ更新」の値を有しなければなりません。
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エンコーディングのバイナリ値です。
C.4. Trust Anchor Update Confirm Message
C.4。トラストアンカー更新確認メッセージ
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ベースのトラストアンカー更新確認メッセージは、第2節で説明したようにCMS本体に包まTAMPUpdateConfirmのDERエンコーディングのバイナリ値、続いて適切なHTTPヘッダ、から構成されています。
The Content-Type header MUST have the value "application/ tamp-update-confirm".
Content-Typeヘッダの値は、「アプリケーション/タンプ-更新確認」を持たなければなりません。
C.5. Apex Trust Anchor Update Message
C.5。アペックストラストアンカー更新メッセージ
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".
Content-Typeヘッダは、「アプリケーション/タンプ頂更新」の値を持っている必要があります。次のようにPOSTメソッドを使用してアペックストラストアンカー更新メッセージが構築されます。
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エンコーディングのバイナリ値です。
C.6. Apex Trust Anchor Update Confirm Message
C.6。アペックストラストアンカー更新確認メッセージ
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トラストアンカー更新確認メッセージは、第2節で説明したようにCMS本体に包まTAMPApexUpdateConfirmのDERエンコーディングのバイナリ値、続いて適切なHTTPヘッダ、から構成されています。
The Content-Type header MUST have the value "application/ tamp-apex-update-confirm".
Content-Typeヘッダの値は、「アプリケーション/タンプ-頂更新確認」をしなければなりません。
C.7. Community Update Message
C.7。コミュニティ更新メッセージ
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メソッドを使用して以下のように構築されます。Content-Typeヘッダの値が「アプリケーション/タンピング-コミュニティ-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エンコーディングのバイナリ値です。
C.8. Community Update Confirm Message
C.8。コミュニティ更新確認メッセージ
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.
第2節で説明したようにHTTPベースのコミュニティ更新確認メッセージは、CMSの本体に包まTAMPCommunityUpdateConfirmのDERエンコーディングのバイナリ値、続いて適切なHTTPヘッダーで構成されています。
The Content-Type header MUST have the value "application/ tamp-community-update-confirm".
Content-Typeヘッダの値は、「アプリケーション/タンピング-コミュニティ更新確認」を持たなければなりません。
C.9. Sequence Number Adjust Message
C.9。シーケンス番号は、メッセージの調整します
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メソッドを使用してメッセージを調整が構成されている：Content-Typeヘッダは、「アプリケーション/タンプ-配列調整」値を有しなければなりません。
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本体に包まSequenceNumberAdjustのDERエンコーディングのバイナリ値です。
C.10. Sequence Number Adjust Confirm Message
C.10。シーケンス番号は、メッセージを確認して調整します
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ベースのシーケンス番号は、セクション2で説明したように確認メッセージは、CMSの本体に包まSequenceNumberAdjustConfirmのDERエンコーディングのバイナリ値、続いて適切なHTTPヘッダーで構成されている調整します。
The Content-Type header MUST have the value "application/ tamp-sequence-adjust-confirm".
Content-Typeヘッダを持たなければならない値を「アプリケーション/タンプシーケンス-確認を調整します」。
C.11. TAMP Error Message
C.11。 TAMPエラーメッセージ
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エラーメッセージは、セクション2で説明したようにCMS本体に包まTAMPErrorのDERエンコーディングのバイナリ値、続いて適切なHTTPヘッダ、から構成されています。
The Content-Type header MUST have the value "application/tamp-error".
Content-Typeヘッダの値は、「アプリケーション/タンプエラー」を持たなければなりません。
Authors' Addresses
著者のアドレス
Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
ラスHousleyビジルセキュリティ、LLC 918春小山Driveハーンドン、VA 20170 USA
EMail: housley@vigilsec.com
メールアドレス：housley@vigilsec.com
Sam Ashmore National Security Agency Suite 6751 9800 Savage Road Fort Meade, MD 20755 USA
サム・アシュモア国家安全保障局（NSA）のスイート6751 9800サベージ道路フォートミード、MD 20755 USA
EMail: srashmo@radium.ncsc.mil
メールアドレス：srashmo@radium.ncsc.mil
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean, VA 22102 USA
カール・ウォレスCygnacomソリューションスイート5400 7925ジョーンズ支店ドライブマクリーン、VA 22102 USA
EMail: cwallace@cygnacom.com
メールアドレス：cwallace@cygnacom.com