Network Working Group T. Freeman
Request for Comments: 5055 Microsoft Corp
Category: Standards Track R. Housley
Vigil Security
A. Malpani
Malpani Consulting Services
D. Cooper
W. Polk
NIST
December 2007
Server-Based Certificate Validation Protocol (SCVP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
The Server-Based Certificate Validation Protocol (SCVP) allows a client to delegate certification path construction and certification path validation to a server. The path construction or validation (e.g., making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies.
サーバーベースの証明書の検証プロトコル（SCVP）は、クライアントがサーバーへの証明書パスの構築と認証パス検証を委任することができます。パス構築または検証（例えば、パス内の証明書のいずれも取り消されていないことを確認すること）は、1つまたは複数のトラストアンカーが含まれている検証ポリシーに従って実行されます。これは、クライアントの実装と定義済みの検証ポリシーのセットの使用を簡素化することができます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. SCVP Overview ..............................................5
1.3. SCVP Requirements ..........................................5
1.4. Validation Policies ........................................6
1.5. Validation Algorithm .......................................7
1.6. Validation Requirements ....................................8
2. Protocol Overview ...............................................9
3. Validation Request ..............................................9
3.1. cvRequestVersion ..........................................12
3.2. query .....................................................12
3.2.1. queriedCerts .......................................13
3.2.2. checks .............................................15
3.2.3. wantBack ...........................................16
3.2.4. validationPolicy ...................................19
3.2.4.1. validationPolRef ..........................20
3.2.4.1.1. Default Validation Policy ......21
3.2.4.2. validationAlg .............................22
3.2.4.2.1. Basic Validation Algorithm .....22
3.2.4.2.2. Basic Validation
Algorithm Errors ...............23
3.2.4.2.3. Name Validation Algorithm ......24
3.2.4.2.4. Name Validation
Algorithm Errors ...............25
3.2.4.3. userPolicySet .............................26
3.2.4.4. inhibitPolicyMapping ......................26
3.2.4.5. requireExplicitPolicy .....................27
3.2.4.6. inhibitAnyPolicy ..........................27
3.2.4.7. trustAnchors ..............................27
3.2.4.8. keyUsages .................................28
3.2.4.9. extendedKeyUsages .........................28
3.2.4.10. specifiedKeyUsages .......................29
3.2.5. responseFlags ......................................30
3.2.5.1. fullRequestInResponse .....................30
3.2.5.2. responseValidationPolByRef ................30
3.2.5.3. protectResponse ...........................31
3.2.5.4. cachedResponse ............................31
3.2.6. serverContextInfo ..................................32
3.2.7. validationTime .....................................32
3.2.8. intermediateCerts ..................................33
3.2.9. revInfos ...........................................34
3.2.10. producedAt ........................................35
3.2.11. queryExtensions ...................................35
3.2.11.1. extnID ...................................35
3.2.11.2. critical .................................35
3.2.11.3. extnValue ................................36
3.3. requestorRef ..............................................36
3.4. requestNonce ..............................................36
3.5. requestorName .............................................37
3.6. responderName .............................................37
3.7. requestExtensions .........................................38
3.7.1. extnID .............................................38
3.7.2. critical ...........................................38
3.7.3. extnValue ..........................................38
3.8. signatureAlg ..............................................38
3.9. hashAlg ...................................................39
3.10. requestorText ............................................39
3.11. SCVP Request Authentication ..............................40
4. Validation Response.............................................40
4.1. cvResponseVersion...........................................43
4.2. serverConfigurationID.......................................43
4.3. producedAt..................................................44
4.4. responseStatus..............................................44
4.5. respValidationPolicy........................................46
4.6. requestRef..................................................47
4.6.1. requestHash ........................................47
4.6.2. fullRequest ........................................48
4.7. requestorRef................................................48
4.8. requestorName...............................................48
4.9. replyObjects................................................49
4.9.1. cert................................................50
4.9.2. replyStatus.........................................50
4.9.3. replyValTime .......................................51
4.9.4. replyChecks ........................................51
4.9.5. replyWantBacks .....................................53
4.9.6. validationErrors ...................................56
4.9.7. nextUpdate .........................................56
4.9.8. certReplyExtensions ................................56
4.10. respNonce..................................................57
4.11. serverContextInfo..........................................57
4.12. cvResponseExtensions ......................................58
4.13. requestorText .............................................58
4.14. SCVP Response Validation ..................................59
4.14.1. Simple Key Validation .............................59
4.14.2. SCVP Server Certificate Validation ................59
5. Server Policy Request...........................................60
5.1. vpRequestVersion...........................................60
5.2. requestNonce...............................................60
6. Validation Policy Response......................................61
6.1. vpResponseVersion..........................................62
6.2. maxCVRequestVersion........................................62
6.3. maxVPRequestVersion........................................62
6.4. serverConfigurationID......................................62
6.5. thisUpdate.................................................63
6.6. nextUpdate and requestNonce................................63
6.7. supportedChecks............................................63
6.8. supportedWantBacks.........................................64
6.9. validationPolicies.........................................64
6.10. validationAlgs............................................64
6.11. authPolicies..............................................64
6.12. responseTypes.............................................64
6.13. revocationInfoTypes.......................................64
6.14. defaultPolicyValues.......................................65
6.15. signatureGeneration ......................................65
6.16. signatureVerification ....................................65
6.17. hashAlgorithms ...........................................66
6.18. serverPublicKeys .........................................66
6.19. clockSkew ................................................66
7. SCVP Server Relay...............................................67
8. SCVP ASN.1 Module...............................................68
9. Security Considerations.........................................76
10.IANA Considerations.............................................78
11. References.....................................................78
11.1. Normative References.....................................78
11.2. Informative References...................................79
12. Acknowledgments................................................80
Appendix A. MIME Media Type Registrations..........................81
A.1. application/scvp-cv-request..............................81
A.2. application/scvp-cv-response.............................82
A.3. application/scvp-vp-request..............................83
A.4. application/scvp-vp-response.............................84
Appendix B. SCVP over HTTP.........................................85
B.1. SCVP Request.............................................85
B.2. SCVP Response............................................85
B.3. SCVP Policy Request......................................86
B.4. SCVP Policy Response.....................................86
Certificate validation is complex. If certificate handling is to be widely deployed in a variety of applications and environments, the amount of processing an application needs to perform before it can accept a certificate needs to be reduced. There are a variety of applications that can make use of public key certificates, but these applications are burdened with the overhead of constructing and validating the certification paths. SCVP reduces this overhead for two classes of certificate-using applications.
証明書の検証は複雑です。証明書処理が広くアプリケーションとさまざまな環境に配備する場合、アプリケーションの処理量は、それが証明書を低減する必要が受け入れることができる前に実行する必要があります。そこ公開鍵証明書を利用することができ、さまざまなアプリケーションがありますが、これらのアプリケーションを構築し、証明書パスを検証するオーバーヘッドを抱えています。 SCVPは、証明書使用したアプリケーションの二つのクラスのために、このオーバーヘッドを軽減します。
The first class of applications wants just two things: confirmation that the public key belongs to the identity named in the certificate and confirmation that the public key can be used for the intended purpose. Such clients can completely delegate certification path construction and validation to the SCVP server. This is often referred to as delegated path validation (DPV).
アプリケーションの最初のクラスは、ちょうど2つの事を望んでいる：公開鍵は、公開鍵が意図した目的のために使用することができる証明書と確認書に名前のアイデンティティーに属して確認することを。このようなクライアントは、完全にSCVPサーバへの証明書パスの構築と検証を委任することができます。これは、多くの場合、委任パス検証（DPV）と呼ばれています。
The second class of applications can perform certification path validation, but they lack a reliable or efficient method of constructing a valid certification path. Such clients delegate certification path construction to the SCVP server, but not validation of the returned certification path. This is often referred to as delegated path discovery (DPD).
アプリケーションの第二のクラスは、証明書パスの検証を行うことができますが、それらは、有効な証明書パスを構築する信頼性や効率的な方法を欠いています。このようなクライアントはSCVPサーバへの証明書パスの構築を委任しますが、返された証明書パスの検証ではありません。これは、多くの場合、委任パスの検出（DPD）と呼ばれています。
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 [STDWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります【STDWORDS]に記載されているように解釈されます。
The primary goals of SCVP are to make it easier to deploy Public Key Infrastructure (PKI)-enabled applications by delegating path discovery and/or validation processing to a server, and to allow central administration of validation policies within an organization. SCVP can be used by clients that do much of the certificate processing themselves but simply want an untrusted server to collect information for them. However, when the client has complete trust in the SCVP server, SCVP can be used to delegate the work of certification path construction and validation, and SCVP can be used to ensure that policies are consistently enforced throughout an organization.
SCVPの主な目標は、サーバーへのパスの検出および/または検証処理を委譲することにより、公開鍵インフラストラクチャ（PKI）対応アプリケーションをデプロイすると、組織内での検証ポリシーの集中管理を可能にし、それを容易にするためです。 SCVPは、自分自身を処理し、証明書の多くを行うが、単に信頼されていないサーバーが彼らのために情報を収集するクライアントで使用することができます。クライアントはSCVPサーバで完全な信頼を持っている場合しかし、SCVPは、証明書パスの構築と検証の作業を委任するために使用することができ、かつSCVPはポリシーが一貫して組織全体に施行されることを保証するために使用することができます。
Untrusted SCVP servers can provide clients the certification paths. They can also provide clients the revocation information, such as Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) responses, that the clients need to validate the certification paths constructed by the SCVP server. These services can be valuable to clients that do not implement the protocols needed to find and download intermediate certificates, CRLs, and OCSP responses.
信頼されていないSCVPサーバはクライアントに証明書パスを提供することができます。彼らはまた、クライアントはSCVPサーバによって構築証明書パスを検証する必要があるということは、そのような証明書失効リスト（CRL）とオンライン証明書状態プロトコル（OCSP）の応答として、クライアントに失効情報を提供することができます。これらのサービスは、中間証明書、CRLの、およびOCSP応答を見つけてダウンロードするために必要なプロトコルを実装していないクライアントに価値があることができます。
Trusted SCVP servers can perform certification path construction and validation for the client. For a client that uses these services, the client inherently trusts the SCVP server as much as it would its own certification path validation software (if it contained such software). There are two main reasons that a client may want to trust such an SCVP server:
信頼されたSCVPサーバは、クライアントの証明書パスの構築と検証を行うことができます。これらのサービスを利用するクライアントの場合、クライアントは、本質的にそれが（それは、このようなソフトウェアが含まれている場合）は、独自の証明書パス検証ソフトウェアと同じように限りSCVPサーバを信頼します。クライアントは、このようなSCVPサーバを信頼することができます2つの主な理由があります：
1. The client does not want to incur the overhead of including certification path validation software and running it for each certificate it receives.
1.クライアントは、証明書パス検証ソフトウェアを含めて、それが受信した各証明書のためにそれを実行しているのオーバーヘッドが発生する必要はありません。
2. The client is in an organization or community that wants to centralize management of validation policies. These policies might dictate that particular trust anchors are to be used and the types of policy checking that are to be performed during certification path validation.
2.クライアントは、検証ポリシーの管理を一元化したい組織やコミュニティです。これらのポリシーは、特定のトラストアンカーを使用することを指示すると、証明書パスの検証中に実行されるポリシーチェックの種類があります。
SCVP meets the mandatory requirements documented in [RQMTS] for DPV and DPD.
SCVPはDPVとDPDのために[RQMTS]に記載の必須要件を満たしています。
Note that RFC 3379 states the following requirement:
そのRFCに3379の状態次の要件に注意してください。
The DPD response MUST indicate one of the following status alternatives:
DPD応答は以下のステータスの選択肢のいずれかを示す必要があります：
1) one or more certification paths was found according to the path discovery policy, with all of the requested revocation information present.
1）一つ以上の証明書パスは、要求された失効情報の存在のすべてと、経路発見ポリシーに従って見出されました。
2) one or more certification paths was found according to the path discovery policy, with a subset of the requested revocation information present.
2）1種以上の証明書パスは、要求された失効情報の存在のサブセットと、経路発見ポリシーに従って見出されました。
3) one or more certification paths was found according to the path discovery policy, with none of the requested revocation information present.
3）1種以上の証明書パスは、要求された失効情報の存在なしで、経路発見ポリシーに従って見出されました。
4) no certification path was found according to the path discovery policy.
4）は、認証パスは、パス検出ポリシーに従って見出されませんでした。
5) path construction could not be performed due to an error.
5）パス構築は、エラーのため実行できませんでした。
DPD responses constructed by SCVP servers do not differentiate between states 2) and 3). This property was discussed on the PKIX working group list and determined to be conformant with the intent of [RQMTS].
SCVPサーバによって構築DPD応答は状態2）と3）を区別しません。このプロパティは、PKIXワーキンググループリストに議論及び[RQMTS]の意図に準拠することを決定しました。
A validation policy (as defined in RFC 3379 [RQMTS]) specifies the rules and parameters to be used by the SCVP server when validating a certificate. In SCVP, the validation policy to be used by the server either can be fully referenced in the request by the client (and thus no additional parameters are necessary) or can be referenced in the request by the client with additional parameters.
検証ポリシーは、（RFC 3379 [RQMTS]で定義されるように）証明書を検証するときSCVPサーバによって使用されるルールおよびパラメータを指定します。 SCVPにおいて、検証ポリシーは、完全にクライアントによって要求で参照することができるサーバによって使用される（従って追加のパラメータは必要ありません）または追加のパラメータを持つクライアントによる要求の中で参照することができます。
Policy definitions can be quite long and complex, and some policies may allow for the setting of a few parameters. The request can therefore be very simple if an object identifier (OID) is used to specify both the algorithm to be used and all the associated parameters of the validation policy. The request can be more complex if the validation policy fixes many of the parameters but allows the client to specify some of them. When the validation policy defines every parameter necessary, an SCVP request needs only to contain the certificate to be validated, the referenced validation policy, and any run-time parameters for the request.
ポリシーの定義は非常に長くて複雑になることがあり、いくつかのポリシーは、いくつかのパラメータの設定を可能にしてもよいです。オブジェクト識別子（OID）が使用するアルゴリズムと検証ポリシーのすべての関連するパラメータの両方を指定するために使用されている場合、要求は、したがって、非常に単純であることができます。要求は、検証ポリシーは、パラメータの多くが修正されていますが、クライアントはそれらのいくつかを指定することができます場合は、より複雑になることがあります。検証ポリシーは、必要なすべてのパラメータを定義するとき、SCVP要求のみを検証する証明書は、参照検証ポリシー、および要求のための任意の実行時パラメータを含める必要があります。
A server publishes the references of the validation policies it supports. When these policies have parameters that may be overridden, the server communicates the default values for these parameters as well. The client can simplify the request by omitting a parameter from a request if the default value published by the server for a given validation policy reference is acceptable. However, if there is a desire to demonstrate to someone else that a specific validation policy with all its parameters has been used, the client will need to ask the server for the inclusion of the full validation policy with all the parameters in the response.
サーバはそれがサポートする検証ポリシーの参照を発行しています。これらのポリシーを上書きすることができるパラメータを持っている場合は、サーバーは、これらのパラメータのデフォルト値を通信します。与えられた検証ポリシーの参考のために、サーバによって発行されたデフォルト値が許容可能である場合、クライアントがリクエストからパラメータを省略することにより、要求を簡素化することができます。そのすべてのパラメータを持つ固有の検証ポリシーが使用されていることを他の誰かに証明したいがある場合は、クライアントは、応答のすべてのパラメータとの完全な検証ポリシーの包含のためにサーバーを依頼する必要があります。
The inputs to the basic certification path processing algorithm used by SCVP are defined by [PKIX-1] in Section 6.1.1 and comprise:
SCVPによって使用される基本的な認証パス処理アルゴリズムへの入力は、セクション6.1.1で[PKIX-1]で定義される含みます。
Certificate to be validated (by value or by reference);
（値または参照によって）検証される証明書。
Validation time;
検証時間。
The initial policy set;
初期ポリシーセット。
Initial inhibit policy mapping setting;
初期禁止ポリシーマッピング設定。
Initial inhibit anyPolicy setting; and
初期禁止anyPolicy設定。そして
Initial require explicit policy setting.
初期には、明示的なポリシー設定が必要です。
The basic certification path processing algorithm also supports specification of one or more trust anchors (by value or reference) as an input. Where the client demands a certification path originating with a specific Certification Authority (CA), a single trust anchor is specified. Where the client is willing to accept paths beginning with any of several CAs, a set of trust anchors is specified.
基本的な認証パス処理アルゴリズムは、入力として（値または参照によって）一つ以上のトラストアンカーの仕様をサポートします。クライアントが特定の認証局（CA）に由来証明書パスを要求する場合は、単一の信頼アンカーが指定されています。クライアントは、いくつかのCAのいずれかで始まるパスを受け入れて喜んでいる場合は、信頼アンカーのセットが指定されています。
The basic certification path processing algorithm also supports the following parameters, which are defined in [PKIX-1], Section 4:
基本的な認証パス処理アルゴリズムは、[PKIX-1]で定義される以下のパラメータは、セクション4をサポートしています。
The usage of the key contained in the certificate (e.g., key encipherment, key agreement, signature); and
証明書（例えば、鍵暗号化、鍵合意、署名）に含まれるキーの使用。そして
Other application-specific purposes for which the certified public key may be used.
認定される公開鍵が使用される他のアプリケーション固有の目的。
The validation algorithm is determined by agreement between the client and the server and is represented as an OID. The algorithm defines the checking that will be performed by the server to determine whether the certificate is valid. A validation algorithm is one of the parameters to a validation policy. SCVP defines a basic validation algorithm that implements the basic path validation algorithm as defined in [PKIX-1], and it permits the client to request additional information about the certificate to be validated. New validation algorithms can be specified that define additional checks if needed. These new validation algorithms may specify additional parameters. The values for these parameters may be defined by any validation policy that uses the algorithm or may be included by the client in the request.
検証アルゴリズムは、クライアントとサーバー間の合意によって決定され、OIDとして表されます。このアルゴリズムは、証明書が有効であるかどうかを判断するために、サーバによって実行されるチェックを定義します。検証アルゴリズムは、検証ポリシーへのパラメータの一つです。 SCVPは[PKIX-1]で定義されるように、基本的なパス検証アルゴリズムを実装する基本的な検証アルゴリズムを定義し、それが検証される証明書に関する追加情報を要求するクライアントを可能にします。新しい検証アルゴリズムは、必要に応じて追加チェックを定義することを指定することができます。これらの新しい検証アルゴリズムは、追加のパラメータを指定することもできます。これらのパラメータの値は、アルゴリズムを使用するか、または要求にクライアントが含まれていてもよい、任意の検証ポリシーによって定義することができます。
Application-specific validation algorithms, in addition to those defined in this document, can be defined to meet specific requirements not covered by the basic validation algorithm. The validation algorithms documented here should serve as a guide for the development of further application-specific validation algorithms. For example, a new application-specific validation algorithm might require the presence of a particular name form in the subject alternative name extension of the certificate.
アプリケーション固有の検証アルゴリズムは、この文書で定義されたものに加えて、基本的な検証アルゴリズムによってカバーされない特定の要件を満たすように定義することができます。ここでは、文書化検証アルゴリズムは、さらに、アプリケーション固有の検証アルゴリズムの開発のためのガイドとして役立つはずです。例えば、新しいアプリケーション固有の検証アルゴリズムは、証明書のサブジェクト代替名の拡張子に特定の名前フォームの存在を必要とするかもしれません。
For a certification path to be considered valid under a particular validation policy, it MUST be a valid certification path as defined in [PKIX-1], and all validation policy constraints that apply to the certification path MUST be verified.
認証パスは、特定の検証ポリシーの下で有効と見なされるためには、[PKIX-1]で定義されるように、有効な証明書パス、および検証されなければならない証明書パスに適用されるすべての検証ポリシーの制約でなければなりません。
Revocation checking is one aspect of certification path validation defined in [PKIX-1]. However, revocation checking is an optional feature in [PKIX-1], and revocation information is distributed in multiple formats. Clients specify in requests whether revocation checking should be performed and whether revocation information should be returned in the response.
失効チェックは[PKIX-1]で定義された認証パスの検証の一の態様です。しかしながら、失効チェックが複数の形式で配布されている[PKIX-1]、及び失効情報のオプション機能です。クライアントは、失効チェックを実行するかどうか要求に失効情報が応答で返されるべきかどうかを指定します。
Servers MUST be capable of indicating the sources of revocation information that they are capable of processing:
サーバは、それらが処理することが可能な失効情報のソースを示すことができなければなりません。
SCVP uses a simple request-response model. That is, the SCVP client creates a request and sends it to the SCVP server, and then the SCVP server creates a single response and sends it to the client. The typical use of SCVP is expected to be over HTTP [HTTP], but it can also be used with email or any other protocol that can transport digitally signed objects. Appendices A and B provide the details necessary to use SCVP with HTTP.
SCVPは、単純な要求 - 応答モデルを使用しています。それはSCVPクライアントが要求を作成し、SCVPサーバに送信し、その後、SCVPサーバは、単一の応答を作成し、それをクライアントに送信し、です。 SCVPの典型的な使用は、[HTTP] HTTP上であることが期待されるが、それはまた、電子メールまたはデジタル署名されたオブジェクトを移送することができる任意の他のプロトコルと共に使用することができます。付録AおよびBは、HTTPとSCVPを使用するために必要な詳細を提供します。
SCVP includes two request-response pairs. The primary request-response pair handles certificate validation. The secondary request-response pair is used to determine the list of validation policies and default parameters supported by a specific SCVP server.
SCVPは2リクエスト・レスポンスのペアが含まれています。主な要求と応答のペアは、証明書の検証を処理します。二次要求と応答のペアは、特定のSCVPサーバでサポートされている検証ポリシーとデフォルトパラメータのリストを決定するために使用されます。
Section 3 defines the certificate validation request.
第3節では、証明書の検証要求を定義します。
Section 4 defines the corresponding certificate validation response.
セクション4は、対応する証明書検証応答を定義します。
Section 5 defines the validation policies request.
第5節では、検証ポリシー要求を定義します。
Section 6 defines the corresponding validation policies response.
第6節は、対応する検証ポリシーの応答を定義します。
Appendix A registers MIME types for SCVP requests and responses, and Appendix B describes the use of these MIME types with HTTP.
付録AはSCVP要求と応答のためのMIMEタイプを登録し、付録Bは、HTTPでこれらのMIMEタイプの使用が記載されています。
An SCVP client request to the server MUST be a single CVRequest item. When a CVRequest is encapsulated in a MIME body part, application/scvp-cv-request MUST be used. There are two forms of SCVP request: unprotected and protected. A protected request is used to authenticate the client to the server or to provide anonymous client integrity over the request-response pair. The protection is provided by a digital signature or message authentication code (MAC). In the later case, the MAC key is derived using a key agreement algorithm, such as Diffie-Hellman. If the client's public key is contained in a certificate, then it may be used to authenticate the client. More commonly, the client's key agreement public key will be ephemeral, supporting anonymous client integrity.
サーバーへのSCVPクライアントの要求は、単一CVRequest項目でなければなりません。 CVRequestはMIMEボディ部、アプリケーション/ SCVP-CV-要求内にカプセル化されるときに使用されなければなりません。保護されていないと、保護された：SCVP要求の2つの形式があります。保護された要求は、サーバーにクライアントを認証したり、リクエスト・レスポンスのペア上で匿名クライアントの整合性を提供するために使用されます。保護は、デジタル署名又はメッセージ認証コード（MAC）によって提供されます。後者の場合、MACキーは、ディフィー・ヘルマン等の鍵合意アルゴリズムを用いて導出されます。クライアントの公開鍵を証明書に含まれている場合、クライアントを認証するために使用することができます。より一般的には、クライアントの鍵協定公開鍵は、匿名クライアントの整合性をサポートし、短命になります。
A server MAY require all requests to be protected, and a server MAY discard all unprotected requests. Alternatively, a server MAY choose to process unprotected requests.
サーバーは、すべての要求を保護する必要があり、サーバーはすべて保護されていない要求を捨てるかもしれ。また、サーバは保護されていない要求を処理するために選ぶかもしれません。
The unprotected request consists of a CVRequest encapsulated in a Cryptographic Message Syntax (CMS) ContentInfo [CMS]. An overview of this structure is provided below and is only intended as illustrative. The definitive ASN.1 is found in [CMS]. Many details are not shown, but the way that SCVP makes use of CMS is clearly illustrated.
保護されていない要求は、暗号メッセージ構文（CMS）ContentInfo [CMS]の中にカプセル化CVRequestから成ります。この構成の概要を以下に提供され、単なる例示として意図されています。決定的なASN.1は、[CMS]で発見されました。多くの詳細が示されていないが、SCVPがCMSを利用した方法が明確に示されています。
ContentInfo { contentType id-ct-scvp-certValRequest, -- (1.2.840.113549.1.9.16.1.10) content CVRequest }
ContentInfo {contentTypeのID-CT-SCVP-certValRequest、 - （1.2.840.113549.1.9.16.1.10）コンテンツCVRequest}
The protected request consists of a CVRequest encapsulated in either a SignedData or AuthenticatedData, which is in turn encapsulated in a ContentInfo. That is, the EncapsulatedContentInfo field of either SignedData or AuthenticatedData consists of an eContentType field with a value of id-ct-scvp-certValRequest and an eContent field that contains a Distinguished Encoding Rules (DER)-encoded CVRequest. SignedData is used when the request is digitally signed. AuthenticatedData is used with a message authentication code (MAC).
保護された要求は、順番にContentInfoに封入されているのSignedData又はAuthenticatedDataのいずれかの中にカプセル化CVRequest、から成ります。すなわちCVRequestをでエンコードのSignedDataまたはAuthenticatedDataのいずれかのEncapsulatedContentInfoフィールドがID-CT-SCVP-certValRequestの値と識別符号化規則（DER）が含まe-コンテンツフィールドとのeContentTypeフィールドで構成されています。要求がデジタル署名されたときのSignedDataが使用されています。 AuthenticatedDataは、メッセージ認証コード（MAC）で使用されています。
All SCVP clients and servers MUST support SignedData for signed requests and responses. SCVP clients and servers SHOULD support AuthenticatedData for MAC-protected requests and responses.
すべてのSCVPクライアントとサーバは、署名された要求と応答のためのSignedDataをサポートしなければなりません。 SCVPクライアントとサーバは、MAC-保護された要求と応答のためにAuthenticatedDataをサポートする必要があります。
If the client uses SignedData, it MUST have a public key that has been bound to a subject identity by a certificate that conforms to the PKIX profile [PKIX-1], and that certificate MUST be suitable for signing the SCVP request. That is:
クライアントがのSignedDataを使用している場合、それはPKIXプロフィール[PKIX-1]に準拠した証明書によって、対象のアイデンティティにバインドされた公開鍵を持っている必要があり、その証明書はSCVP要求に署名するために適したものでなければなりません。あれは：
1. If the key usage extension is present, either the digital signature or the non-repudiation bit MUST be asserted.
1.鍵用途拡張が存在する場合は、デジタル署名または否認防止ビットのいずれかがアサートされなければなりません。
2. If the extended key usage extension is present, it MUST contain either the SCVP client OID (see Section 3.11), the anyExtendedKeyUsage OID, or another OID acceptable to the SCVP server.
2.拡張鍵用途拡張が存在する場合、それは、anyExtendedKeyUsage OID、またはSCVPサーバに許容可能な別のOID（3.11節を参照）のいずれかSCVPクライアントOIDを含まなければなりません。
The client MUST put an unambiguous reference to its certificate in the SignedData that encapsulates the request. The client SHOULD include its certificate in the request, but MAY omit the certificate to reduce the size of the request. The client MAY include other certificates in the request to aid the validation of its certificates by the SCVP server. The signerInfos field of SignedData MUST include exactly one SignerInfo. The SignedData MUST NOT include the unsignedAttrs field.
クライアントが要求をカプセル化するSignedDataの中にその証明書への明確な参照を置く必要があります。クライアントは、要求にその証明書を含める必要がありますが、要求のサイズを小さくするための証明書を省略することができます。クライアントはSCVPサーバによって、その証明書の検証を支援するための要求で他の証明書を含むかもしれません。 SignedDataのsignerInfosフィールドは正確に一つのSignerInfoを含まなければなりません。 SignedDataはunsignedAttrsフィールドを含んではいけません。
The client MUST put its key agreement public key, or an unambiguous reference to a certificate that contains its key agreement public key, in the AuthenticatedData that encapsulates the request. If an ephemeral key agreement key pair is used, then the ephemeral key agreement public key is carried in the originatorKey field of KeyAgreeRecipientInfo, which requires the client to obtain the server's key agreement public key before computing the message authentication code (MAC). An SCVP server's key agreement key is included in its validation policy response message (see Section 6). The recipientInfos field of AuthenticatedData MUST include exactly one RecipientInfo, which contains information for the SCVP server. The AuthenticatedData MUST NOT include the unauthAttrs field.
クライアントは、その主要な協定公開鍵、または要求をカプセル化しAuthenticatedDataにおけるその重要な協定公開鍵を含む証明書への明確な言及を、置く必要があります。短期キー合意の鍵ペアを使用する場合は、短期キー合意公開鍵は、メッセージ認証コード（MAC）を計算する前に、サーバーの主要な協定公開鍵を取得するためにクライアントが必要ですKeyAgreeRecipientInfoのoriginatorKey分野で行われています。 SCVPサーバの鍵合意鍵はその検証ポリシー応答メッセージに含まれている（第6節を参照してください）。 AuthenticatedDataののrecipientInfosフィールドはSCVPサーバの情報が含まれている正確に一つのRecipientInfoを含まなければなりません。 AuthenticatedDataはunauthAttrsフィールドを含んではいけません。
The syntax and semantics for SignedData, AuthenticatedData, and ContentInfo are defined in [CMS]. The syntax and semantics for CVRequest are defined below. The CVRequest item contains the client request. The CVRequest contains the cvRequestVersion and query items; the CVRequest MAY also contain the requestorRef, requestNonce, requestorName, responderName, requestExtensions, signatureAlg, and hashAlg items.
SignedData、AuthenticatedData、およびContentInfoの構文およびセマンティクスは、[CMS]で定義されています。 CVRequestための構文と意味は以下に定義されています。 CVRequest項目は、クライアントの要求が含まれています。 CVRequestはcvRequestVersionと、クエリの項目が含まれています。 CVRequestもrequestorRef、requestNonce、requestorName、responderName、requestExtensions、signatureAlg、およびhashAlg項目を含むかもしれません。
The CVRequest MUST have the following syntax:
CVRequestは、次の構文を持っている必要があります。
CVRequest ::= SEQUENCE {
cvRequestVersion INTEGER DEFAULT 1,
query Query,
requestorRef [0] GeneralNames OPTIONAL,
requestNonce [1] OCTET STRING OPTIONAL,
requestorName [2] GeneralName OPTIONAL,
responderName [3] GeneralName OPTIONAL,
requestExtensions [4] Extensions OPTIONAL,
signatureAlg [5] AlgorithmIdentifier OPTIONAL,
hashAlg [6] OBJECT IDENTIFIER OPTIONAL,
requestorText [7] UTF8String (SIZE (1..256)) OPTIONAL }
Conforming clients MUST be able to construct requests with cvRequestVersion and query. Conforming clients MUST DER encode the CVRequest in both protected and unprotected messages to facilitate unambiguous hash-based referencing in the corresponding response message. SCVP clients that insist on creation of a fresh response (e.g., to protect against a replay attack or ensure information is up to date) MUST support requestNonce. Support for the remaining items is optional in client implementations.
準拠クライアントはcvRequestVersionとクエリとのリクエストを構築することができなければなりません。準拠クライアントは、対応する応答メッセージに一義的なハッシュベースの参照を容易にするために、エンコードを両方保護され、保護されていないメッセージでCVRequestをDERしなければなりません。新鮮な応答の作成を主張するSCVPクライアントが（例えば、リプレイ攻撃から保護したり、情報を確実にするためには最新のものである）requestNonceをサポートしなければなりません。残りの項目のサポートは、クライアントの実装ではオプションです。
Conforming servers MUST be able to parse CVRequests that contain any or all of the optional items.
準拠したサーバーは、オプション項目のいずれかまたは全てを含んでいCVRequestsを解析できなければなりません。
Each of the items within the CVRequest is described in the following sections.
CVRequest内の各アイテムは、次のセクションに記載されています。
The cvRequestVersion item defines the version of the SCVP CVRequest used in a request. The subsequent response MUST use the same version number. The value of the cvRequestVersion item MUST be one (1) for a client implementing this specification. Future updates to this specification must specify other values if there are any changes to syntax or semantics. However, new extensions may be defined without changing the version number.
cvRequestVersion項目は、要求に使用SCVP CVRequestのバージョンを定義します。その後の応答は、同じバージョン番号を使用しなければなりません。 cvRequestVersion項目の値は、この仕様を実装するクライアントのための1つの（1）でなければなりません。構文やセマンティクスに変更があった場合、この仕様の今後の更新は、他の値を指定する必要があります。しかし、新しい拡張機能は、バージョン番号を変更せずに定義することができます。
SCVP clients MUST support asserting this value and SCVP servers MUST be capable of processing this value.
SCVPクライアントは、この値をアサートサポートしなければならないとSCVPサーバはこの値を処理することができなければなりません。
The query item specifies one or more certificates that are the subject of the request; the certificates can be either public key certificates [PKIX-1] or attribute certificates [PKIX-AC]. A query MUST contain a queriedCerts item as well as one checks item, and one validationPolicy item; a query MAY also contain wantBack, responseFlags, serverContextInfo, validationTime, intermediateCerts, revInfos, producedAt, and queryExtensions items.
質問項目は、要求の対象である1つ以上の証明書を指定します。証明書は、公開鍵証明書[PKIX-1]または属性証明書[PKIX-AC]のいずれかにすることができます。クエリはqueriedCerts項目ならびに1つのチェック項目、および1つのvalidationPolicy項目を含まなければなりません。クエリはwantBack、responseFlags、serverContextInfo、validationTime、intermediateCerts、revInfos、producedAt、およびqueryExtensionsアイテムをも含むかもしれません。
A Query MUST have the following syntax:
クエリは、次の構文を持っている必要があります。
Query ::= SEQUENCE {
queriedCerts CertReferences,
checks CertChecks,
-- Note: tag [0] not used --
wantBack [1] WantBack OPTIONAL,
validationPolicy ValidationPolicy,
responseFlags ResponseFlags OPTIONAL,
serverContextInfo [2] OCTET STRING OPTIONAL,
validationTime [3] GeneralizedTime OPTIONAL,
intermediateCerts [4] CertBundle OPTIONAL,
revInfos [5] RevocationInfos OPTIONAL,
producedAt [6] GeneralizedTime OPTIONAL,
queryExtensions [7] Extensions OPTIONAL }
The list of certificate references in the queriedCerts item tells the server the certificate(s) for which the client wants information. The checks item specifies the checking that the client wants performed. The wantBack item specifies the objects that the client wants the server to return in the response. The validationPolicy item specifies the validation policy that the client wants the server to employ. The responseFlags item allows the client to request optional features for the response. The serverContextInfo item tells the server that additional information from a previous request-response is desired. The validationTime item tells the date and time relative to which the client wants the server to perform the checks. The intermediateCerts and revInfos items provide context for the client request. The queryExtensions item provides for future expansion of the query syntax. The syntax and semantics of each of these items are discussed in the following sections.
queriedCerts項目内の証明書参照のリストは、クライアントが情報を望んでいる証明書（複数可）するサーバーに指示します。チェック項目は、クライアントが行っ望んでいることを確認を指定します。 wantBack項目は、クライアントがサーバーが応答で返したいオブジェクトを指定します。 validationPolicy項目は、クライアントがサーバを採用したい検証ポリシーを指定します。 responseFlags項目は、クライアントが応答のためのオプション機能を要求することができます。 serverContextInfo項目は、前の要求応答からの追加情報が要求されるサーバに伝えます。 validationTime項目は、クライアントがサーバにチェックを実行したいに日付と時刻の相対的に指示します。 intermediateCertsとrevInfos項目は、クライアント要求のコンテキストを提供します。 queryExtensions項目は、クエリ構文の将来の拡張のために用意されています。これらの各項目の構文とセマンティクスは、次のセクションで説明されています。
Conforming clients MUST be able to construct a Query with a queriedCerts item that specifies at least one certificate, checks, and validationPolicy. Conforming SCVP clients MAY support specification of multiple certificates and MAY support the optional items in the Query structure.
準拠クライアントは、少なくとも一つの証明書、チェック、およびvalidationPolicyを指定queriedCerts項目でクエリを構築することができなければなりません。 SCVPクライアントを準拠することは、複数の証明書の仕様をサポートし、クエリ構造のオプション項目をサポートするかもしれません。
SCVP clients that support delegated path discovery (DPD) as defined in [RQMTS] MUST support wantBack and responseFlags. SCVP clients that insist on creation of a fresh response (e.g., to protect against a replay attack or ensure information is up to date) MUST support responseFlags.
【RQMTS]で定義されるように委任パス検出（DPD）をサポートするSCVPクライアントはwantBackとresponseFlagsをサポートしなければなりません。新鮮な応答の作成を主張するSCVPクライアントが（例えば、リプレイ攻撃から保護したり、情報を確実にするためには最新のものである）responseFlagsをサポートしなければなりません。
Conforming servers MUST be able to process a Query that contains any of the optional items, and MUST be able to process a Query that specifies multiple certificates.
準拠のサーバーは、オプションの項目のいずれかを含むクエリを処理できなければならない、と複数の証明書を指定するクエリを処理できなければなりません。
The queriedCerts item is a SEQUENCE of one or more certificates, each of which is a subject of the request. The specified certificates are either public key certificates or attribute certificates; if more than one certificate is specified, all must be of the same type. Each certificate is either directly included, or it is referenced. When referenced, a hash value of the referenced item is included to ensure that the SCVP client and the SCVP server both obtain the same certificate when the referenced certificate is fetched. Certificate references use the SCVPCertID type, which is described below. A single request MAY contain both directly included and referenced certificates.
queriedCerts項目は、要求の対象である各々が1つ以上の証明書の配列です。指定された証明書は、公開鍵証明書または属性証明書のいずれかです。複数の証明書が指定されている場合は、すべて同じ型でなければなりません。各証明書は、直接含まれている、またはそれが参照されています。参照される場合、参照アイテムのハッシュ値を参照証明書を取得するときにSCVPクライアントとSCVPサーバの両方が同じ証明書を得ることを確実にするために含まれています。証明書の参照は、以下に説明されてSCVPCertIDタイプを使用します。単一の要求は、両方の直接含まれており、参照する証明書を含むかもしれません。
CertReferences has the following syntax:
CertReferencesの構文は次のとおりです。
CertReferences ::= CHOICE {
pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference,
acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference }
PKCReference ::= CHOICE {
cert [0] Certificate,
pkcRef [1] SCVPCertID }
ACReference ::= CHOICE {
attrCert [2] AttributeCertificate,
acRef [3] SCVPCertID }
SCVPCertID ::= SEQUENCE {
certHash OCTET STRING,
issuerSerial SCVPIssuerSerial,
hashAlgorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 } }
The ASN.1 definition of Certificate is imported from [PKIX-1] and the definition of AttributeCertificate is imported from [PKIX-AC].
証明書のASN.1定義は[PKIX-1]からインポートされ、AttributeCertificateの定義は、[PKIX-AC]からインポートされています。
When creating a SCVPCertID, the certHash is computed over the entire DER-encoded certificate including the signature. The hash algorithm used to compute certHash is specified in hashAlgorithm. The hash algorithm used to compute certHash SHOULD be one of the hash algorithms specified in the hashAlgorithms item of the server's validation policy response message.
SCVPCertIDを作成する場合、CERTHASHは署名を含む全体のDER符号化された証明書にわたって計算されます。 CERTHASHを計算するために使用されるハッシュアルゴリズムはhashAlgorithmに指定されています。 CERTHASHを計算するために使用されるハッシュアルゴリズムは、サーバの検証方針応答メッセージのhashAlgorithms項目で指定されたハッシュアルゴリズムのいずれかでなければなりません。
When encoding SCVPIssuerSerial, serialNumber is the serial number that uniquely identifies the certificate. For public key certificates, the issuer MUST contain only the issuer name from the certificate encoded in the directoryName choice of GeneralNames. For attribute certificates, the issuer MUST contain the issuer name field from the attribute certificate.
SCVPIssuerSerialをコードする場合、serialNumberを一意の証明書を識別するシリアル番号です。公開鍵証明書については、発行者はGeneralNamesのdirectoryNameでの選択でエンコードされた証明書からのみ発行者名を含まなければなりません。属性証明書については、発行者は、属性証明書から発行者名フィールドを含まなければなりません。
Conforming clients MUST be able to reference a certificate by direct inclusion. Clients SHOULD be able to specify a certificate using the SCVPCertID. Conforming clients MAY be able to reference multiple certificates and MAY be able to reference both public key and attribute certificates.
準拠クライアントが直接含めることによって証明書を参照することができなければなりません。クライアントは、SCVPCertIDを使用して証明書を指定できるようにすべきです。クライアントが準拠して複数の証明書を参照することができるかもしれなくて、公開鍵と属性証明書の両方を参照することができるかもしれません。
Conforming SCVP Server implementations MUST be able to process CertReferences with multiple certificates. Conforming SCVP server implementations MUST be able to parse CertReferences that contain either public key or attribute certificates. Conforming SCVP server implementations MUST be able to parse both the cert and pkcRef choices in PKCReference. Conforming SCVP server implementations that process attribute certificates MUST be able to parse both the attrCert and acRef choices in ACReference.
SCVPサーバ実装を準拠することは、複数の証明書をCertReferencesを処理できなければなりません。 SCVPサーバ実装を準拠することは、公開鍵または属性証明書のいずれかを含むCertReferencesを解析できなければなりません。準拠SCVPサーバ実装はPKCReferenceでCERTとpkcRefの選択肢の両方を解析できなければなりません。属性証明書をプロセス準拠SCVPサーバ実装はACReferenceにattrCertとacRef選択肢の両方を解析できなければなりません。
The checks item describes the checking that the SCVP client wants the SCVP server to perform on the certificate(s) in the queriedCerts item. The checks item contains a sequence of object identifiers (OIDs). Each OID tells the SCVP server what checking the client expects the server to perform. For each check specified in the request, the SCVP server MUST perform the requested check, or return an error. A server may choose to perform additional checks (e.g., a server that is only asked to build a validated certification path may choose to also perform revocation status checks), although the server cannot indicate in the response that the additional checks have been performed, except in the case of an error response.
チェック項目はSCVPクライアントはSCVPサーバがqueriedCerts項目内の証明書（複数可）に実行したいことを確認について説明します。チェック項目はオブジェクト識別子（OID）の配列を含みます。各OIDは、クライアントがサーバーを実行する予定のチェック何SCVPサーバに指示します。要求で指定された各チェックについて、SCVPサーバは、要求されたチェックを実行、またはエラーを返さなければなりません。サーバーは追加のチェックを実行することもできます（例えば、また、失効状態のチェックを実行することを選択することが検証され、証明書パスを構築するために頼まのみされているサーバー）サーバーは追加のチェックが実行されたことを受けて示すことができないものの除き、エラー応答の場合には
The checks item uses the CertChecks type, which has the following syntax:
チェック項目は、次の構文を持っていCertChecksタイプを、使用しています。
CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
For public key certificates, the following checks are defined in this document:
公開鍵証明書の場合は、以下のチェックは、この文書で定義されています。
- id-stc-build-pkc-path: Build a prospective certification path to a trust anchor (as defined in Section 6.1 of [PKIX-1]);
- ID-STC-ビルドPKC経路：トラストアンカー（[PKIX-1]のセクション6.1で定義されるように）に将来の認証パスを構築。
- id-stc-build-valid-pkc-path: Build a validated certification path to a trust anchor (revocation checking not required);
- ID-STC-ビルド有効-PKC-パス：トラストアンカー（失効不要チェック）に検証された証明書パスを構築します。
- id-stc-build-status-checked-pkc-path: Build a validated certification path to a trust anchor and perform revocation status checks on the certification path.
- ID-STC-ビルドステータス確認-PKC-パス：トラストアンカーに検証された証明書パスを構築し、証明書パスに失効状態のチェックを行います。
Conforming SCVP server implementations that support delegated path discovery (DPD) as defined in [RQMTS] MUST support the id-stc-build-pkc-path check. Conforming SCVP server implementations that support delegated path validation (DPV) as defined in [RQMTS] MUST support the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc-path checks.
ID-STC-ビルドPKC-パスチェックをサポートしなければならない[RQMTS]で定義されるように委任パス検出（DPD）をサポートするSCVPサーバ実装を従わ。 ID-STC-ビルド有効-PKC経路とID-STC-ビルドステータスチェック-PKC-パスチェックをサポートしなければならない[RQMTS]で定義されるように委任パス検証（DPV）をサポートするSCVPサーバ実装を従わ。
For attribute certificates, the following checks are defined in this document:
属性証明書の場合は、以下のチェックは、この文書で定義されています。
- id-stc-build-aa-path: Build a prospective certification path to a trust anchor for the Attribute Certificate (AC) issuer;
- ID-STC-ビルド-AA-パス：属性証明書（AC）発行者の信頼アンカーへの将来の証明書パスを構築します。
- id-stc-build-valid-aa-path: Build a validated certification path to a trust anchor for the AC issuer;
- ID-STC-ビルド有効-AA-パス：AC発行者の信頼アンカーに検証済みの証明書パスを構築します。
- id-stc-build-status-checked-aa-path: Build a validated certification path to a trust anchor for the AC issuer and perform revocation status checks on the certification path for the AC issuer;
- ID-STC-ビルドステータス確認-AA-パス：AC発行者の信頼アンカーに検証された証明書パスを構築し、AC発行者のための認証パス上の失効状態のチェックを行います。
- id-stc-status-check-ac-and-build-status-checked-aa-path: Build a validated certification path to a trust anchor for the AC issuer and perform revocation status checks on the AC as well as the certification path for the AC issuer.
- ID-STC-ステータスチェック-AC-とビルド・ステータス確認-AA-パス：AC発行者の信頼アンカーに検証された証明書パスを構築し、証明書パスだけでなく、AC上の失効状態のチェックを行いますAC発行者のために。
Conforming SCVP server implementations MAY support the attribute certificates checks.
準拠SCVPサーバの実装は、属性証明書のチェックをサポートするかもしれません。
For these purposes, the following OIDs are defined:
これらの目的のために、次のOIDが定義されています。
id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 }
id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 }
id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 }
id-stc-build-status-checked-pkc-path
OBJECT IDENTIFIER ::= { id-stc 3 }
id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 }
id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 }
id-stc-build-status-checked-aa-path
OBJECT IDENTIFIER ::= { id-stc 6 }
id-stc-status-check-ac-and-build-status-checked-aa-path
OBJECT IDENTIFIER ::= { id-stc 7 }
Other specifications may define additional checks.
その他の仕様は、追加チェックを定義することもできます。
Conforming client implementations MUST support assertion of at least one of the standard checks. Conforming clients MAY support assertion of multiple checks. Conforming clients need not support all of the checks defined in this section.
準拠クライアントの実装は、標準的なチェックの少なくとも一方の主張を支持しなければなりません。準拠のクライアントは複数のチェックの主張をサポートしていてもよい（MAY）。準拠のクライアントは、このセクションで定義されたチェックのすべてをサポートしている必要はありません。
The optional wantBack item describes any information the SCVP client wants from the SCVP server for the certificate(s) in the queriedCerts item in addition to the results of the checks specified in the checks item. If present, the wantBack item MUST contain a sequence of object identifiers (OIDs). Each OID tells the SCVP server what the client wants to know about the queriedCerts item. For each type of information specified in the request, the server MUST return information regarding its finding (in a successful response).
任意wantBack項目はSCVPクライアントはチェック項目で指定されたチェックの結果に加えてqueriedCerts項目における証明書（複数可）のためのSCVPサーバから望む任意の情報を記載しています。存在する場合、wantBack項目はオブジェクト識別子（OID）の配列を含まなければなりません。各OIDは、クライアントがqueriedCerts項目について知って欲しいものSCVPサーバに指示します。要求で指定された情報の種類ごとに、サーバは（成功した応答して）その知見に関する情報を返さなければなりません。
For example, a request might include a checks item that only specifies certification path building and include a wantBack item that requests the return of the certification path built by the server. In this case, the response would not include a status for the validation of the certification path, but it would include a prospective certification path. A client that wants to perform its own certification path validation might use a request of this form.
例えば、要求は、証明経路ビルを指定するチェック項目を含めると、サーバーによって構築された証明書パスのリターンを要求wantBack項目が含まれる場合があります。この場合、応答は、証明書パスの検証のためのステータスが含まれていないだろうが、それは将来の証明経路が含まれるであろう。独自の証明書パス検証を実行したいクライアントは、このフォームの要求を使用する場合があります。
Alternatively, a request might include a checks item that requests the server to build a certification path and validate it, including revocation checking, and not include a wantBack item. In this case, the response would include only a status for the validation of the certification path. A client that completely delegates certification path validation might use a request of this form.
また、要求は、失効チェックなどの証明書パスを構築し、それを検証するためにサーバに要求チェック項目が含まれ、かつwantBack項目が含まれない場合があります。この場合、応答は、認証パスの検証のための唯一のステータスを含むことになります。完全に委譲証明書パスの検証は、この形式の要求を使用する場合がありますクライアント。
The wantBack item uses the WantBack type, which has the following syntax:
wantBack項目は、次の構文を持っていWantBack型を使用しています。
WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
For public key certificates, the following wantBacks are defined in this document:
公開鍵証明書の場合は、以下のwantBacksは、この文書で定義されています。
- id-swb-pkc-cert: The certificate that was the subject of the request;
- ID-SWB-PKC-CERT：要求の対象となった証明書。
- id-swb-pkc-best-cert-path: The certification path built for the certificate including the certificate that was validated;
- ID-SWB-PKC-最高-CERT-パス：検証された証明書を含む証明書のために構築された証明書パス。
- id-swb-pkc-revocation-info: Proof of revocation status for each certificate in the certification path;
- ID-SWB-PKC-失効情報：認証パス内の各証明書の失効ステータスの証明。
- id-swb-pkc-public-key-info: The public key from the certificate that was the subject of the request;
- ID-SWB-PKC-公開鍵情報：要求の対象となった証明書から公開鍵。
- id-swb-pkc-all-cert-paths: A set of certification paths for the certificate that was the subject of the request;
- ID-SWB-PKC-全て-CERT-パス：要求の対象となった証明書の認証パスのセット。
- id-swb-pkc-ee-revocation-info: Proof of revocation status for the end entity certificate in the certification path; and
- ID-SWB-PKC-EE-失効情報：証明書パス内のエンドエンティティ証明書の失効ステータスの証明。そして
- id-swb-pkc-CAs-revocation-info: Proof of revocation status for each CA certificate in the certification path.
- ID-SWB-PKC-CAS-失効-情報：証明書パス内の各CA証明書の失効ステータスの証明。
All conforming SCVP server implementations MUST support the id-swb-pkc-cert and id-swb-pkc-public-key-info wantBacks. Conforming SCVP server implementations that support delegated path discovery (DPD) as defined in [RQMTS] MUST support the id-swb-pkc-best-cert-path and id-swb-pkc-revocation-info wantBacks.
すべての準拠SCVPサーバの実装は、ID-SWB-PKC-CERTとid-SWB-PKC-公開鍵情報wantBacksをサポートしなければなりません。サポートしなければならない[RQMTS]で定義されるように委任パス検出（DPD）をサポートするSCVPサーバ実装を従わID-SWB-PKC-最良-CERT-パス及びID-SWB-PKC-失効情報wantBacks。
SCVP provides two methods for a client to obtain multiple certification paths for a certificate. The client could use serverContextInfo to request one path at a time (see Section 3.2.6). After obtaining each path, the client could submit the serverContextInfo from the previous request to obtain another path until either the client found a suitable path or the server indicated (by not returning a serverContextInfo) that no more paths were available. Alternatively, the client could send a single request with an id-swb-pkc-all-cert-paths wantBack, in which case the server would return all of the available paths in a single response.
SCVPは、証明書のために複数の証明書パスを取得するために、クライアントのための2つのメソッドを提供します。クライアントは、時間（3.2.6項を参照）で、一つのパスを要求するためにserverContextInfoを使用することができます。クライアントは適切なパスを発見し、またはサーバが指示するまで、それぞれのパスを取得した後、クライアントは、それ以上のパスが利用可能でなかったこと（serverContextInfoを返さないことによって）別のパスを取得するために以前の要求からserverContextInfoを提出することができました。あるいは、クライアントは、サーバが、単一の反応で使用可能なパスのすべてを返すことになる場合には、ID-SWB-PKC-全て-CERT-パスwantBack、を有する単一の要求を送信することができます。
The server may, at its discretion, limit the number of paths that it returns in response to the id-swb-pkc-all-cert-paths. When the request includes an id-swb-pkc-all-cert-paths wantBack, the response SHOULD NOT include a serverContextInfo.
サーバは、その裁量で、それはID-SWB-PKC-全て-CERT-経路に応じて、戻り経路の数を制限することができます。要求がwantBack ID-SWB-PKC-全て-CERT-パスを含む場合、応答はserverContextInfoを含むべきではありません。
For attribute certificates, the following wantBacks are defined in this document:
属性証明書の場合は、以下のwantBacksは、この文書で定義されています。
- id-swb-ac-cert: The attribute certificate that was the subject of the request;
- ID-SWB-AC-CERT：要求の対象となった属性証明書。
- id-swb-aa-cert-path: The certification path built for the AC issuer certificate;
- ID-SWB-AA-CERT-パス：ACの発行者証明書のために構築された証明経路;
- id-swb-ac-revocation-info: Proof of revocation status for each certificate in the AC issuer certification path; and
- ID-SWB-AC-失効情報：AC発行者認証パス内の各証明書の失効ステータスの証明。そして
- id-swb-aa-revocation-info: Proof of revocation status for the attribute certificate.
- ID-SWB-AA-失効-情報：属性証明書の失効ステータスの証明。
Conforming SCVP server implementations MAY support the attribute certificate wantBacks.
SCVPサーバ実装を準拠して属性証明書wantBacksをサポートするかもしれません。
The following wantBack can be used for either public key or attribute certificates:
次wantBackは、公開鍵または属性証明書のいずれかのために使用することができます。
- id-swb-relayed-responses: Any SCVP responses received by the server that were used to generate the response to this query.
- ID-SWB-中継-応答：このクエリに対する応答を生成するために使用されたサーバーが受信した任意のSCVP応答。
Conforming SCVP servers MAY support the id-swb-relayed-responses wantBack.
準拠SCVPサーバは、ID-SWB-中継-応答wantBackをサポートするかもしれません。
For these purposes, the following OIDs are defined:
これらの目的のために、次のOIDが定義されています。
id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 }
id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 }
id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 }
id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 }
id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 }
id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 }
id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 }
id-swb-relayed-responses OBJECT IDENTIFIER ::= { id-swb 9 }
id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10}
id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11}
id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12}
id-swb-pkc-ee-revocation-info OBJECT IDENTIFIER ::= { id-swb 13}
id-swb-pkc-CAs-revocation-info OBJECT IDENTIFIER ::= { id-swb 14}
Other specifications may define additional wantBacks.
その他の仕様は、追加wantBacksを定義することもできます。
Conforming client implementations that support delegated path validation (DPV) as defined in [RQMTS] SHOULD support assertion of at least one wantBack. Conforming client implementations that support delegated path discovery (DPD) as defined in [RQMTS] MUST support assertion of at least one wantBack. Conforming clients MAY support assertion of multiple wantBacks. Conforming clients need not support all of the wantBacks defined in this section.
【RQMTS]で定義されるように委任パス検証（DPV）をサポートするクライアントの実装を準拠し、少なくとも1つのwantBackの主張をサポートしなければなりません。 【RQMTS]で定義されるように委任パス検出（DPD）をサポートするクライアントの実装を準拠し、少なくとも1つのwantBackの主張をサポートしなければなりません。準拠のクライアントは、複数のwantBacksの主張をサポートしていてもよい（MAY）。準拠のクライアントは、このセクションで定義されてwantBacksのすべてをサポートしている必要はありません。
The validationPolicy item defines the validation policy that the client wants the SCVP server to use during certificate validation. If this policy cannot be used for any reason, then the server MUST return an error response.
validationPolicy項目は、クライアントがSCVPサーバは、証明書の検証時に使用したい検証ポリシーを定義します。このポリシーは、何らかの理由で使用できない場合、サーバはエラー応答を返さなければなりません。
A validation policy MUST define default values for all parameters necessary for processing an SCVP request. For each parameter, a validation policy may either allow the client to specify a non-default value or forbid the use of a non-default value. If the client wishes to use the default values for all of the parameters, then the client need only supply a reference to the policy in this item. If the client wishes to use non-default values for one or more parameters, then the client supplies a reference to the policy plus whatever parameters are necessary to complete the request in this item. If there are any conflicts between the policy referenced in the request and any supplied parameter values in the request, then the server MUST return an error response.
検証ポリシーはSCVP要求を処理するために必要なすべてのパラメータのデフォルト値を定義しなければなりません。各パラメータについて、検証ポリシーは、いずれかのクライアントがデフォルト以外の値を指定するか、デフォルト以外の値の使用を禁止することを可能にします。クライアントは、すべてのパラメータのデフォルト値を使用したい場合は、クライアントにのみ、この項目にポリシーへの参照を供給する必要が。クライアントは、1つまたは複数のパラメータにデフォルト以外の値を使用したい場合、クライアントはパラメータがこちらの要求を完了するために必要なものは何でも政策プラスへの参照を提供します。要求と要求内の任意の指定されたパラメータ値で参照ポリシー間の競合がある場合、サーバはエラー応答を返さなければなりません。
The syntax of the validationPolicy item is:
validationPolicy項目の構文は次のとおりです。
ValidationPolicy ::= SEQUENCE {
validationPolRef ValidationPolRef,
validationAlg [0] ValidationAlg OPTIONAL,
userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT
IDENTIFIER OPTIONAL,
inhibitPolicyMapping [2] BOOLEAN OPTIONAL,
requireExplicitPolicy [3] BOOLEAN OPTIONAL,
inhibitAnyPolicy [4] BOOLEAN OPTIONAL,
trustAnchors [5] TrustAnchors OPTIONAL,
keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL,
extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL,
specifiedKeyUsages [8] SEQUENCE OF KeyPurposeId OPTIONAL }
The validationPolRef item is required, but the remaining items are optional. The optional items are used to provide validation policy parameters. When the client uses the validation policy's default values for all parameters, all of the optional items are absent.
validationPolRef項目が要求されるが、残りの項目は任意です。オプションの項目は、検証ポリシーパラメータを提供するために使用されています。クライアントは、すべてのパラメータの検証ポリシーのデフォルト値を使用する場合、オプション項目のすべてが存在しません。
At a minimum, conforming SCVP client implementations MUST support the validationPolRef item. Conforming client implementations MAY support any or all of the optional items in ValidationPolicy.
最低でも、準拠SCVPクライアント実装はvalidationPolRefアイテムをサポートしなければなりません。準拠クライアント実装はValidationPolicy内のオプション項目のいずれかまたはすべてをサポートするかもしれません。
Conforming SCVP servers MUST support processing of a ValidationPolicy that contains any or all of the optional items.
準拠SCVPサーバは、オプション項目のいずれか、またはすべてが含まれていValidationPolicyの処理をサポートしなければなりません。
The validationAlg item specifies the validation algorithm. The userPolicySet item provides an acceptable set of certificate policies. The inhibitPolicyMapping item inhibits certificate policy mapping during certification path validation. The requireExplicitPolicy item requires at least one valid certificate policy in the certificate policies extension. The inhibitAnyPolicy item indicates whether the anyPolicy certificate policy OID is processed or ignored when evaluating certificate policy. The trustAnchors item indicates the trust anchors that are acceptable to the client. The keyUsages item indicates the technical usage of the public key that is to be confirmed by the server as acceptable. The extendedKeyUsages item indicates the application-specific usage of the public key that is to be confirmed by the server as acceptable. The syntax and semantics of each of these items are discussed in the following sections.
validationAlgアイテムは、検証アルゴリズムを指定します。 userPolicySet項目は、証明書ポリシーの許容可能なセットを提供します。 inhibitPolicyMapping項目は、認証パス検証中の証明書ポリシーマッピングを抑制する。 requireExplicitPolicy項目は証明書ポリシー拡張の少なくとも1つの有効な証明書ポリシーが必要です。 inhibitAnyPolicy項目がanyPolicy証明書ポリシーOIDが処理または証明書ポリシーを評価する際に無視されるかどうかを示します。 trustAnchors項目がクライアントに受け入れられる信頼アンカーを示しています。 keyUsages項目が許容できるように、サーバーによって確認される公開鍵の技術的な使用法を示します。 extendedKeyUsages項目は、許容されるように、サーバによって確認される公開鍵のアプリケーション固有の使用方法を示しています。これらの各項目の構文とセマンティクスは、次のセクションで説明されています。
The reference to the validation policy is an OID that the client and server have agreed represents a particular validation policy.
検証ポリシーを参照するには、クライアントとサーバーが合意しているOIDは、特定の検証ポリシーを表しています。
The syntax of the validationPolRef item is:
validationPolRef項目の構文は次のとおりです。
ValidationPolRef::= SEQUENCE {
valPolId OBJECT IDENTIFIER,
valPolParams ANY DEFINED BY valPolId OPTIONAL }
Where a validation policy supports additional policy-specific parameter settings, these values are specified using the valPolParams item. The syntax and semantics of the parameters structure are defined by the object identifier encoded as the valPolId. Where a validation policy has no parameters, such as the default validation policy (see Section 3.2.4.1.1), this item MUST be omitted.
検証ポリシーは、追加のポリシー固有のパラメータ設定をサポートしている場合は、これらの値はvalPolParamsアイテムを使用して指定されています。パラメータ構造のシンタックスおよびセマンティクスはvalPolIdとしてエンコードオブジェクト識別子によって定義されます。検証ポリシーは、デフォルトの検証ポリシー（セクション3.2.4.1.1を参照）としてはパラメータを、持っていない場合は、この項目は省略しなければなりません。
Parameters specified in this item are independent of the validation algorithm and the validation algorithm's parameters (see Section 3.2.4.2). For example, a server may support a validation policy where it validates a certificate using the name validation algorithm and also makes a determination regarding the creditworthiness of the subject. In this case, the validation policy parameters could be used to specify the value of the transaction. The validation algorithm parameters are used to specify the application identifier and name for the name validation algorithm.
この項目で指定されたパラメータは、検証アルゴリズムと検証アルゴリズムのパラメータ（セクション3.2.4.2を参照）から独立しています。例えば、サーバは、それが名前の検証アルゴリズムを使用して証明書を検証し、対象の信用に関する決意を行う検証ポリシーをサポートすることができます。この場合、検証ポリシーパラメータは、トランザクションの値を指定するために使用することができます。検証アルゴリズムパラメータは、名前の検証アルゴリズムのアプリケーション識別子と名前を指定するために使用されます。
Conforming SCVP client implementations MUST support specification of a validation policy. Conforming SCVP client implementations MAY be able to specify parameters for a validation policy. Conforming SCVP server implementations MUST be able to process valPolId and MAY be able to process valPolParams.
準拠SCVPクライアント実装は、検証ポリシーの仕様をサポートしなければなりません。 SCVPクライアント実装を準拠して検証ポリシーのパラメータを指定することができます。 SCVPサーバ実装を準拠してvalPolIdを処理できなければならないとvalPolParamsを処理することができるかもしれません。
The client can request the SCVP server's default validation policy or another validation policy. The default validation policy corresponds to standard certification path processing as defined in [PKIX-1] with server-chosen default values (e.g., with a server-determined policy set and trust anchors). The default values can be distributed out of band or using the policy request mechanism (see Section 5). This mechanism permits the deployment of an SCVP server without obtaining a new object identifier.
クライアントはSCVPサーバのデフォルトの検証ポリシーまたは別の検証ポリシーを要求することができます。 [PKIX-1]で定義されるように、デフォルトの検証ポリシーは、サーバ選択されたデフォルト値（例えば、サーバ決定ポリシー・セットと信頼アンカーを有する）と、標準的な認証パス処理に相当します。デフォルト値は、帯域外分散またはポリシー要求機構（セクション5を参照）を使用することができます。このメカニズムは、新しいオブジェクト識別子を得ることなくSCVPサーバの展開が可能になります。
The object identifier that identifies the default validation policy is:
デフォルトの検証ポリシーを識別するオブジェクト識別子は、次のとおりです。
id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 }
id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }
The default validation policy MUST use the basic validation algorithm as its default validation algorithm (see Section 3.2.4.2.1), and has no validation policy parameters (see Section 3.2.4.1).
デフォルトの検証ポリシーがデフォルトの検証アルゴリズム（セクション3.2.4.2.1を参照）などの基本的な検証アルゴリズムを使用して、何の検証ポリシーのパラメータを持っていないしなければならない（セクション3.2.4.1を参照）。
When using the default validation policy, the client can override any of the default parameter values by supplying a specific value in the request. The SCVP server MUST make use of the provided parameter values or return an error response.
デフォルトの検証ポリシーを使用している場合、クライアントは要求に特定の値を供給することにより、デフォルトのパラメータ値のいずれかをオーバーライドすることができます。 SCVPサーバが提供するパラメータ値を利用したり、エラー応答を返さなければなりません。
Conforming implementations of SCVP servers MUST support the default policy. However, an SCVP server may be configured to send an error response to all requests using the default policy to meet local security requirements.
SCVPサーバの実装を準拠すると、デフォルトのポリシーをサポートしなければなりません。しかし、SCVPサーバは、ローカルのセキュリティ要件を満たすために、デフォルトのポリシーを使用して、すべての要求にエラー応答を送信するように構成することができます。
The optional validationAlg item defines the validation algorithm to be used by the SCVP server during certificate validation. The value of this item can be determined by agreement between the client and the server. The validation algorithm is represented by an object identifier.
任意validationAlg項目は、証明書の検証中SCVPサーバによって使用される検証アルゴリズムを定義します。この項目の値は、クライアントとサーバー間の合意によって決定することができます。検証アルゴリズムは、オブジェクト識別子によって表されます。
The syntax of the validationAlg item is:
validationAlg項目の構文は次のとおりです。
ValidationAlg ::= SEQUENCE {
valAlgId OBJECT IDENTIFIER,
parameters ANY DEFINED BY valAlgId OPTIONAL }
The following section specifies the basic validation algorithm and the name validation algorithm.
次のセクションでは、基本的な検証アルゴリズムと名の検証アルゴリズムを指定します。
SCVP servers MUST recognize and support both validation algorithms defined in this section. SCVP clients that support explicit assertion of the validation algorithm MUST support the basic validation algorithm and SHOULD support the name validation algorithm. Other validation algorithms can be specified in other documents for use with specific applications. SCVP clients and servers MAY support any such validation algorithms.
SCVPサーバは、このセクションで定義され、両方の検証アルゴリズムを認識し、サポートしなければなりません。検証アルゴリズムの明示的な主張をサポートするSCVPクライアントは、基本的な検証アルゴリズムをサポートしなければならないし、名前の検証アルゴリズムをサポートする必要があります。その他の検証アルゴリズムは、特定のアプリケーションで使用するための他の文書で指定することができます。 SCVPクライアントとサーバは、どのように検証アルゴリズムをサポートするかもしれません。
The client can request use of the SCVP basic validation algorithm or another algorithm. For identity certificates, the basic validation algorithm MUST implement the certification path validation algorithm as defined in Section 6 of [PKIX-1]. For attribute certificates, the basic validation algorithm MUST implement certification path validation as defined in Section 5 of [PKIX-AC]. Other validation algorithms MAY implement functions over and above those in the basic algorithm, but validation algorithms MUST generate results compliant with the basic validation algorithm. That is, none of the validation requirements in the basic algorithm may be omitted from any newly defined validation algorithms. However, other validation algorithms MAY reject paths that are valid using the basic validation algorithm. The object identifier to identify the basic validation algorithm is:
クライアントはSCVP基本的な検証アルゴリズムまたは他のアルゴリズムの使用を要求することができます。 [PKIX-1]のセクション6で定義されるようにアイデンティティ証明書は、基本的な検証アルゴリズムは、認証パス検証アルゴリズムを実装しなければなりません。 [PKIX-AC]のセクション5で定義された属性証明書については、基本的な検証アルゴリズムは、認証パス検証を実装しなければなりません。その他の検証アルゴリズムを超えると基本的なアルゴリズムでは、これらの上記の機能を実装してもよい（MAY）が、検証アルゴリズムは、基本的な検証アルゴリズムに準拠した結果を生成しなければなりません。つまり、基本的なアルゴリズムで検証要件のいずれも、任意の新たに定義された検証アルゴリズムから省略することはできない、です。しかし、他の検証アルゴリズムは、基本的な検証アルゴリズムを使用して、有効なパスを拒否することがあります。基本的な検証アルゴリズムを識別するためのオブジェクト識別子は、次のとおりです。
id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 }
When id-svp-basicValAlg appears in valAlgId, the parameters item MUST be absent.
-SVPは、基本的にvalAlgIdに表示されたら、パラメータ項目が存在してはなりません。
The following errors are defined for the basic validation algorithm for inclusion in the validationErrors item in the response (see Section 4.9.6). These errors can be used by any other validation algorithm since all validation algorithms MUST implement the functionality of the basic validation algorithm.
次のエラーが応答（セクション4.9.6を参照）によりvalidationErrors項目に含めるために基本的な検証アルゴリズムのために定義されています。すべての検証アルゴリズムは、基本的な検証アルゴリズムの機能を実装しなければならないので、これらのエラーは、他の検査アルゴリズムで使用することができます。
id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg
id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 }
id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 }
id-bvae-wrongTrustAnchor OBJECT IDENTIFIER ::= { id-bvae 3 }
id-bvae-noValidCertPath OBJECT IDENTIFIER ::= { id-bvae 4 }
id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 5 }
id-bvae-invalidKeyPurpose OBJECT IDENTIFIER ::= { id-bvae 9 }
id-bvae-invalidKeyUsage OBJECT IDENTIFIER ::= { id-bvae 10 }
id-bvae-invalidCertPolicy OBJECT IDENTIFIER ::= { id-bvae 11 }
The id-bvae-expired value means that the validation time used for the request was later than the notAfter time in the end certificate (the certificate specified in the queriedCerts item).
ID-bvae-期限切れ値を要求するために使用検証時刻が終了証明書（queriedCerts項目で指定された証明書）でnotAfterの時間よりもあったことを意味します。
The id-bvae-not-yet-valid value means that the validation time used for the request was before the notBefore time in the end certificate.
ID-bvae-未有効な値は、要求に使用検証時間が終了証明書内のnotBeforeの時間の前にあったことを意味します。
The id-bvae-wrongTrustAnchor value means that a certification path could not be constructed for the client-specified trust anchor(s), but a path exists for one of the trust anchors specified in the server's default validation policy.
ID-bvae-wrongTrustAnchor値は、証明書パスは、クライアント指定トラストアンカー（S）のために構築することができなかったことを意味しますが、パスはサーバのデフォルトの検証ポリシーで指定されたトラストアンカーの一つのために存在します。
The id-bvae-noValidCertPath value means that the server could not construct a sequence of intermediate certificates between the trust anchor and the target certificate that satisfied the request.
ID-bvae-noValidCertPath値は、サーバーがトラストアンカーと要求を満たし、目標証明書の間に中間証明書の配列を構築できなかったことを意味します。
The id-bvae-revoked value means that the end certificate has been revoked.
ID-bvae-失効値は、エンド証明書が取り消されたことを意味します。
The id-bvae-invalidKeyPurpose value means that the extended key usage extension ([PKIX-1], Section 4.2.1.13) in the end certificate does not satisfy the validation policy.
ID-bvae-invalidKeyPurpose値は、最終証明書の拡張鍵使用拡張（[PKIX-1]、セクション4.2.1.13）は検証ポリシーを満たしていないことを意味します。
The id-bvae-invalidKeyUsage value means that the keyUsage extension ([PKIX-1], Section 4.2.1.3) in the end certificate does not satisfy the validation policy. For example, the keyUsage extension in the certificate may assert only the keyEncipherment bit, but the validation policy specifies in the keyUsages item that digitalSignature is required.
ID-bvae-invalidKeyUsage値は、エンド証明書keyUsage拡張子（[PKIX-1]、セクション4.2.1.3）は検証ポリシーを満たしていないことを意味します。例えば、証明書内のkeyUsage拡張子は、keyEnciphermentビットをアサートすることができるが、検証ポリシーは、デジタル署名が必要であることkeyUsages項目で指定します。
The id-bvae-invalidCertPolicy value means that the path is not valid under any of the policies specified in the user policy set and explicit policies are required. That is, the valid_policy_tree is NULL and the explicit_policy variable is zero ([PKIX-1], Section 6.1.5).
ID-bvae-invalidCertPolicy値は、ユーザーのポリシーセットと明示的ポリシーで指定されたポリシーのいずれかが必要とされているの下にパスが有効でないことを意味します。すなわち、valid_policy_treeがNULLでexplicit_policy変数がゼロ（[PKIX-1]、セクション6.1.5）です。
The name validation algorithm allows the client to specify one or more subject names that MUST appear in the end certificate in addition to the requirements specified for the basic validation algorithm. The name validation algorithm allows the client to supply an application identifier and a name to the server. The application identifier defines the name matching rules to use in comparing the name supplied in the request with the names in the certificate.
名前の検証アルゴリズムは、クライアントが基本的な検証アルゴリズムに指定された要件に加えて、エンド証明書に表示されなければなら一つ以上のサブジェクト名を指定することができます。名前の検証アルゴリズムは、クライアントがサーバーにアプリケーション識別子と名前を供給することができます。アプリケーション識別子は、証明書内の名前の要求で指定された名前を比較する際に使用するためのルールに一致する名前を定義します。
id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 }
When the id-svp-nameValAlg appears as a valAlgId, the parameters MUST use the NameValidationAlgParms syntax:
ID-SVP-nameValAlgがvalAlgIdとして表示されたら、パラメータはNameValidationAlgParms構文を使用する必要があります。
NameValidationAlgParms ::= SEQUENCE {
nameCompAlgId OBJECT IDENTIFIER,
validationNames GeneralNames }
GeneralNames is defined in [PKIX-1].
GeneralNamesは[PKIX-1]で定義されています。
If more than one name is supplied in the validationNames value, all names MUST be of the same type. The certificate must contain a matching name for each of the names supplied in validationNames according to the name matching rules associated with the nameCompAlgId. This specification defines three sets of name matching rules.
複数の名前がvalidationNames値で提供されている場合は、すべての名前は同じタイプでなければなりません。証明書はnameCompAlgIdに関連付けられた名前マッチングルールに従ってvalidationNamesに供給される名前のそれぞれについて一致する名前を含んでいなければなりません。この仕様は、名前マッチングルール3セットを定義します。
If the nameCompAlgId supplied in the request is id-nva-dnCompAlg, then GeneralNames supplied in the request MUST be a directoryName, and the matching rules to be used are defined in [PKIX-1]. The certificate must contain a matching name in either the subject field or a directoryName in the subjectAltName extension. This specification defines the OID for id-nva-dnCompAlg as follows:
要求で供給nameCompAlgIdである場合、ID-NVA-dnCompAlg、次に使用するdirectoryNameでなければなりません要求で供給GeneralNames、マッチングルールは[PKIX-1]で定義されています。証明書は、サブジェクトフィールドまたはsubjectAltName拡張でdirectoryNameでいずれかに一致する名前が含まれている必要があります。以下、本明細書は、ID-NVA-dnCompAlgためのOIDを定義します。
id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 }
If the nameCompAlgId supplied in the request is id-kp-serverAuth [PKIX-1], then GeneralNames supplied in the request MUST be a dNSName, and the matching rules to be used are defined in [PKIX-1].
nameCompAlgId要求で供給した場合、ID-KP-serverAuth [PKIX-1]であり、その要求に供給GeneralNamesはのdNSNameでなければなりません、そして、使用するマッチング規則は[PKIX-1]で定義されています。
If a subjectAltName extension is present and includes one or more names of type dNSName, a match in any one of the set is considered acceptable. If the subjectAltName extension is omitted, or does not include any names of type dNSName, the (most specific) Common Name field in the subject field of the certificate MUST be used.
subjectAltName拡張が存在し、型のdNSNameの一人の以上の名前が含まれている場合、セットのいずれかに一致が許容されると考えられます。 subjectAltName拡張が省略されている、またはタイプのdNSNameのいずれかの名前が含まれていない場合は、証明書のサブジェクトフィールドで（最も特定の）Common Nameフィールドを使用しなければなりません。
Names may contain the wildcard character *, which is considered to match any single domain name component. That is, *.a.com matches foo.a.com but not bar.foo.a.com.
名前は任意の単一のドメイン名コンポーネントに一致するように考えられているワイルドカード文字*を含むことができます。それは* .a.comがbar.foo.a.com foo.a.comと一致するではなく、です。
If the nameCompAlgId supplied in the request is id-kp-mailProtection [PKIX-1], then GeneralNames supplied in the request MUST be an rfc822Name, and the matching rules are defined in [SMIME-CERT].
nameCompAlgId要求で供給した場合、ID-KP-mailProtection [PKIX-1]であり、その要求に供給GeneralNamesはrfc822Nameでなければなりません、とのマッチング規則は[SMIME-CERT]で定義されています。
Conforming SCVP servers MUST support the name validation algorithm and the matching rules associated with id-nva-dnCompAlg, id-kp-serverAuth, and id-kp-mailProtection. SCVP servers MAY support other name matching rules.
SCVPサーバを適合する名前検証アルゴリズム及びID-NVA-dnCompAlg、ID-KP-serverAuth、及びID-KP-mailProtectionに関連付けられたマッチングルールをサポートしなければなりません。 SCVPサーバは、他の名前の一致規則をサポートするかもしれません。
The following errors are defined for the name validation algorithm:
次のエラーが名前の検証アルゴリズムのために定義されています。
id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg
id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 }
id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 }
id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 }
id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 }
id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 }
id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 }
The id-nvae-name-mismatch value means the client supplied a name with the request, which the server recognized and the server found a corresponding name type in the certificate, but was unable to find a match to the name supplied. For example, the client supplied a DNS name of example1.com, and the certificate contained a DNS name of example.com.
ID-nvae名不一致値は、クライアントがサーバが認識要求、と名前を入力し、サーバーが証明書内の対応する名前のタイプを見つけましたが、指定された名前に一致するものを見つけることができませんでした。意味します例えば、クライアントはexample1.comのDNS名を入力し、証明書は、example.comのDNS名が含まれています。
The id-nvae-no-name value means the client supplied a name with the request, which the server recognized, but the server could not find the corresponding name type in the certificate. For example, the client supplied a DNS name of example1.com, and the certificate only contained a rfc822Name of user@example.com.
ID-nvae-NO-name値は、クライアントがサーバが認識要求、と名前を供給しますが、サーバーが証明書に対応する名前の種類を見つけることができなかったことを意味します。例えば、クライアントはexample1.comのDNS名を入力し、証明書はuser@example.comのrfc822Nameで含まれていました。
The id-nvae-unknown-alg value means the client supplied a nameCompAlgId that the server does not recognize.
ID-nvae-不明-ALG値は、クライアントがサーバーが認識しないnameCompAlgIdを供給意味します。
The id-nvae-bad-name value means the client supplied either an empty or malformed name in the request.
ID-nvae-悪い-name値は、クライアントが要求のいずれかで空または不正な形式の名前を供給意味します。
The id-nvae-bad-name-type value means the client supplied an inappropriate name type for the application identifier. For example, the client specified a nameCompAlgId of id-kp-serverAuth, and an rfc822Name of user@example.com.
ID-nvae-不良名型の値は、クライアントがアプリケーション識別子の不適切な名前の種類を供給します。例えば、クライアントは、ID-KP-serverAuthのnameCompAlgId、及びuser@example.comのrfc822Nameで指定しました。
The id-nvae-mixed-names value means the client supplied multiple names in the request of different types.
ID-nvae混合-名値は、クライアントが、異なるタイプの要求で複数の名前を供給します。
The userPolicySet item specifies a list of certificate policy identifiers that the SCVP server MUST use when constructing and validating a certification path. The userPolicySet item specifies the user-initial-policy-set as defined in Section 6 of [PKIX-1]. A userPolicySet containing the anyPolicy OID indicates a user-initial-policy-set of any-policy.
userPolicySet項目は、証明書パスを構築し、検証時にSCVPサーバが使用しなければならない証明書ポリシー識別子のリストを指定します。 userPolicySet項目は、ユーザ初期ポリシーセット[PKIX-1]のセクション6で定義されるように指定します。 anyPolicy OIDを含むuserPolicySetは、任意のポリシーのユーザ初期ポリシー・セットを示しています。
SCVP clients SHOULD support the userPolicySet item in requests, and SCVP servers MUST support the userPolicySet item in requests.
SCVPクライアントは要求でuserPolicySet項目をサポートする必要があり、SCVPサーバは、リクエストにuserPolicySet項目をサポートしなければなりません。
The inhibitPolicyMapping item specifies an input to the certification path validation algorithm, and it controls whether policy mapping is allowed during certification path validation (see [PKIX-1], Section 6.1.1). If the client wants the server to inhibit policy mapping, inhibitPolicyMapping is set to TRUE in the request. SCVP clients MAY support inhibiting policy mapping. SCVP servers SHOULD support inhibiting policy mapping.
inhibitPolicyMapping項目は、認証パス検証アルゴリズムに入力を指定し、それは、ポリシーマッピングが認証パス検証（[PKIX-1]、セクション6.1.1を参照）の間に許可されるかどうかを制御します。クライアントがポリシーマッピングを阻害するサーバーを望んでいる場合は、inhibitPolicyMappingはリクエストにTRUEに設定されています。 SCVPクライアントは阻害ポリシーマッピングをサポートするかもしれません。 SCVPサーバは、阻害ポリシーマッピングをサポートする必要があります。
The requireExplicitPolicy item specifies an input to the certification path validation algorithm, and it controls whether there must be at least one valid policy in the certificate policies extension (see [PKIX-1], Section 6.1.1). If the client wants the server to require at least one policy, requireExplicitPolicy is set to TRUE in the request.
requireExplicitPolicy項目は、認証パス検証アルゴリズムに入力を指定し、それは（[PKIX-1]、セクション6.1.1を参照）証明書ポリシー拡張中に少なくとも1つの有効なポリシーが存在しなければならないかどうかを制御します。クライアントは、サーバが少なくとも一つの政策を必要としたい場合は、requireExplicitPolicyはリクエストにTRUEに設定されています。
SCVP clients MAY support requiring explicit policies. SCVP servers SHOULD support requiring explicit policies.
SCVPクライアントは、明示的ポリシーを必要とするサポートするかもしれません。 SCVPサーバは、明示的な政策が必要なサポートすべきです。
The inhibitAnyPolicy item specifies an input to the certification path validation algorithm (see [PKIX-1], Section 6.1.1), and it controls whether the anyPolicy OID is processed or ignored when evaluating certificate policy. If the client wants the server to ignore the anyPolicy OID, inhibitAnyPolicy MUST be set to TRUE in the request.
inhibitAnyPolicy項目は、（[PKIX-1]、セクション6.1.1を参照）認証パス検証アルゴリズムに入力を指定し、それは証明書ポリシーを評価する際にanyPolicy OIDが処理または無視されるかどうかを制御します。クライアントは、サーバがanyPolicy OIDを無視したい場合は、inhibitAnyPolicyはリクエストにtrueに設定する必要があります。
SCVP clients MAY support ignoring the anyPolicy OID. SCVP servers SHOULD support ignoring the anyPolicy OID.
SCVPクライアントはanyPolicy OIDを無視してサポートすることができます。 SCVPサーバは、anyPolicy OIDを無視してサポートする必要があります。
The trustAnchors item specifies the trust anchors at which the certification path must terminate if the path is to be considered valid by the SCVP server for the request. If a trustAnchors item is present, the server MUST NOT consider any certification paths ending in other trust anchors as valid.
trustAnchors項目はパスが要求に対するSCVPサーバによって有効であると考えられるのであれば、証明書パスが終了しなければならないのトラストアンカーを指定します。 trustAnchors項目が存在する場合、サーバーは有効なものとして、他のトラストアンカーで終わるすべての証明書パスを検討してはなりません。
The TrustAnchors type contains one or more trust anchor specifications. A certificate reference can be used to identify the trust anchor by certificate hash and distinguished name with serial number. Alternatively, trust anchors can be provided directly. The order of trust anchor specifications within the sequence is not important. Any CA certificate that meets the requirements of [PKIX-1] for signing certificates can be provided as a trust anchor. If a trust anchor is supplied that does not meet these requirements, the server MUST return an error response.
TrustAnchorsタイプは、一つ以上のトラストアンカーの仕様が含まれています。証明書の参照は、シリアル番号と証明書のハッシュと識別名によって信頼アンカーを識別するために使用することができます。また、トラストアンカーを直接提供することができます。シーケンス内のトラストアンカーの仕様の順序は重要ではありません。署名証明書の[PKIX-1]の要件を満たしている任意のCA証明書は、トラストアンカーとして提供することができます。トラストアンカーがこれらの要件を満たしていないと供給されている場合、サーバはエラー応答を返さなければなりません。
The trust anchor itself, regardless of its form, MUST NOT be included in any certification path returned by the SCVP server.
トラストアンカー自体は、関係なく、その形の、SCVPサーバから返された証明書パスに含まれてはいけません。
TrustAnchors has the following syntax:
TrustAnchorsの構文は次のとおりです。
TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference
SCVP servers MUST support trustAnchors. SCVP clients SHOULD support trustAnchors.
SCVPサーバは、trustAnchorsをサポートしなければなりません。 SCVPクライアントはtrustAnchorsをサポートする必要があります。
The key usage extension ([PKIX-1], Section 4.2.1.3) in the certificate defines the technical purpose (such as encipherment, signature, and CRL signing) of the key contained in the certificate. If the client wishes to confirm the technical usage, then it can communicate the usage it wants to validate by the same structure using the same semantics as defined in [PKIX-1]. For example, if the client obtained the certificate in the context of a digital signature, it can confirm this use by including a keyUsage structure with the digital signature bit set.
証明書内の鍵用途拡張（[PKIX-1]、セクション4.2.1.3）は、証明書に含まれるキーの（例えば、暗号化、署名、及びCRLの署名など）の技術的目的を定義します。クライアントは、技術の使用状況を確認したい場合、それは[PKIX-1]で定義されるのと同じセマンティクスを使用して同じ構造によって検証したい利用を通信することができます。クライアントは、デジタル署名の文脈で証明書を取得した場合、例えば、それがデジタル署名ビットが設定されたkeyUsageの構造を含むことにより、この使用を確認することができます。
If the keyUsages item is present and contains an empty sequence, it indicates that the client does not require any particular key usage.
keyUsages項目が存在し、空のシーケンスが含まれている場合は、クライアントは、特定のキーの使用を必要としないことを示しています。
If the keyUsages item contains one or more keyUsage definitions, then the certificate MUST satisfy at least one of the specified keyUsage definitions. If the client is willing to accept multiple possibilities, then the client passes in a sequence of possible patterns. Each keyUsage can contain a set of one or more bits set in the request, all bits MUST be set in the certificate to match against an instance of the keyUsage in the SCVP request. The certificate key usage extension may contain more usages than requested. For example, if a client wishes to check for either digital signature or non-repudiation, then the client provides two keyUsage values, one with digital signature set and the other with non-repudiation set. If the key usage extension is absent from the certificate, the certificate MUST be considered good for all usages and therefore any pattern in the SCVP request will match.
keyUsagesアイテムが1つの以上のkeyUsage定義が含まれている場合は、その証明書が指定されたkeyUsage定義の少なくとも一つを満たしている必要があります。クライアントは複数の可能性を受け入れることを望んでいる場合、クライアントは、可能なパターンのシーケンスに渡します。それぞれのkeyUsageは、すべてのビットがSCVP要求内のkeyUsageのインスタンスに対して一致する証明書で設定する必要があり、要求に設定された1つまたは複数のビットのセットを含むことができます。証明書の鍵用途拡張は、要求されたよりも多くの用途が含まれていてもよいです。クライアントがデジタル署名または否認防止のいずれかを確認したい場合、例えば、クライアントは、二つのkeyUsageの値、否認防止が設定されたデジタル署名セットと他のものを提供します。鍵用途拡張が証明書に存在しない場合、証明書は、したがって、すべての使用と一致しますSCVP要求で任意のパターンのための良い考えなければなりません。
SCVP clients SHOULD support keyUsages, and SCVP servers MUST support keyUsages.
SCVPクライアントはkeyUsagesをサポートする必要があり、SCVPサーバは、keyUsagesをサポートしなければなりません。
The extended key usage extension ([PKIX-1], Section 4.2.1.13) defines more specific technical purposes, in addition to, or in place of, the purposes indicated in the key usage extension, for which the certified public key may be used. If the client will accept certificates that are consistent with a particular value (or values) in the extended key usage extension, then it can communicate the appropriate usages using the same semantics as defined in [PKIX-1].
拡張鍵使用拡張は、（[PKIX-1]、セクション4.2.1.13）は、に加えて、より具体的な技術的目的を定義し、又は認定公開鍵が使用されるための鍵使用拡張、に示され、目的の場所で。クライアントは、拡張鍵使用拡張に特定の値（または値）と一致する証明書を受け入れる場合は、[PKIX-1]で定義されるように、それは同じセマンティクスを使用して、適切な用法を通信することができます。
For example, if the client obtained the certificate in the context of a Transport Layer Security (TLS) server, it can confirm the certificate is consistent with this usage by including the extended key usage structure with the id-kp-serverAuth object identifier.
クライアントは、トランスポート層セキュリティ（TLS）サーバーのコンテキストで証明書を取得した場合、それは証明書ID-KP-serverAuthオブジェクト識別子と拡張鍵使用構造を含むことにより、この用法と一致して確認することができます。
If the extension is absent, or is present and asserts the anyExtendedKeyUsage OID, then all usages specified in the request are a match. If the extension is present and does not assert the anyExtendedKeyUsage OID, all usages in the request MUST be present in the certificate. The certificate extension may contain more usages than requested.
拡張が存在しない、または存在し、anyExtendedKeyUsage OIDをアサートした場合、その要求で指定されたすべての用途が一致しています。拡張子が存在し、anyExtendedKeyUsage OIDを主張しない場合は、リクエスト内のすべての使用は、証明書の中に存在しなければなりません。証明書の拡張機能は、要求されたよりも多くの用途が含まれていてもよいです。
Where the client does not require any particular extended key usage, the client can specify an empty SEQUENCE. This may be used to override extended key usage requirements imposed in the validation policy specified by valPolId.
クライアントは、特定の拡張キー使用法を必要としない場合は、クライアントは空のシーケンスを指定することができます。これはvalPolIdによって指定された検証ポリシーに課される拡張鍵使用要件を上書きするために使用されてもよいです。
SCVP clients SHOULD support extendedKeyUsages, and SCVP servers MUST support extendedKeyUsages.
SCVPクライアントはextendedKeyUsagesをサポートする必要があり、SCVPサーバは、extendedKeyUsagesをサポートしなければなりません。
The extended key usage extension ([PKIX-1], Section 4.2.1.13) defines more specific technical purposes, in addition to or in place of the purposes indicated in the key usage extension, for which the certified public key may be used. If the client requires that a particular value (or values) appear in the extended key usage extension, then it can specify the required usage(s) using the same semantics as defined in [PKIX-1]. For example, if the client obtained the certificate in the context of a TLS server, it might require that the server certificate include the extended key usage structure with the id-kp-serverAuth object identifier. In this case, the client would include a specifiedKeyUsages item in the request and assert the id-kp-serverAuth object identifier.
拡張鍵使用拡張（[PKIX-1]、セクション4.2.1.13）は、に加えて、又は認定公開鍵が使用されるための鍵使用拡張に示す目的の代わりに、より具体的な技術的目的を定義します。クライアントが特定の値（または値）が拡張鍵使用拡張に表示されていることを必要とする場合、[PKIX-1]で定義されるように、それは同じセマンティクスを使用して、必要な使用（複数可）を指定することができます。クライアントは、TLSサーバーのコンテキストで証明書を取得した場合、それはサーバ証明書がID-KP-serverAuthオブジェクト識別子と拡張鍵使用構造を含むことが必要になる場合があります。この場合、クライアントは要求にspecifiedKeyUsages項目を含み、ID-KP-serverAuthオブジェクト識別子をアサートするであろう。
If one or more specified usages are included in the request, the certificate MUST contain the extended key usage extension, and all usages specified in the request MUST be present in the certificate extension. The certificate extension may contain more usages than specified in the request. Specified key usages are not satisfied by the presence of the anyExtendedKeyUsage OID.
1つ以上の指定された用途は、要求に含まれている場合、証明書は、拡張鍵使用拡張を含まなければならない、と要求で指定されたすべての用途では、証明書の拡張中に存在しなければなりません。証明書拡張は、リクエストで指定されたよりも多くの用途が含まれていてもよいです。指定されたキーの使用法はanyExtendedKeyUsage OIDの存在によって満たされていません。
Where the client does not require any particular extended key usage, the client can specify an empty SEQUENCE. This may be used to override specified key usage requirements imposed in the validation policy specified by valPolId.
クライアントは、特定の拡張キー使用法を必要としない場合は、クライアントは空のシーケンスを指定することができます。これはvalPolIdで指定された検証ポリシーに課せられた指定されたキーの使用要件を上書きするために使用することができます。
SCVP clients SHOULD support specifiedKeyUsages, and SCVP servers MUST support specifiedKeyUsages.
SCVPクライアントはspecifiedKeyUsagesをサポートする必要があり、SCVPサーバは、specifiedKeyUsagesをサポートしなければなりません。
The optional responseFlags item allows the client to indicate which optional features in the CVResponse it wants the server to include. If the default values for all of the flags are used, then the responseFlags item MUST NOT be included in the request.
オプションのresponseFlags項目は、クライアントがCVResponseで、それはサーバが含ましたいオプション機能を示すことができます。フラグのすべてのデフォルト値が使用されている場合は、responseFlags項目が要求に含まれてはなりません。
The syntax of the responseFlags item is:
responseFlags項目の構文は次のとおりです。
ResponseFlags ::= SEQUENCE {
fullRequestInResponse [0] BOOLEAN DEFAULT FALSE,
responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE,
protectResponse [2] BOOLEAN DEFAULT TRUE,
cachedResponse [3] BOOLEAN DEFAULT TRUE }
Each of the response flags is described in the following sections.
応答フラグのそれぞれは、以下のセクションに記載されています。
By default, the server includes a hash of the request in non-cached responses to allow the client to identify the response. If the client wants the server to include the full request in the non-cached response, fullRequestInResponse is set to TRUE. The main reason a client would request the server to include the full request in the response is to archive the request-response exchange in a single object. That is, the client wants to archive a single object that includes both request and response.
デフォルトでは、サーバーは、クライアントが応答を識別できるようにする非キャッシュの応答の要求のハッシュを含んでいます。クライアントは、サーバが非キャッシュされた応答で完全な要求を含めることを希望する場合は、fullRequestInResponseがTRUEに設定されています。クライアントが応答で完全な要求を含めるようにサーバーを要求する主な理由は、単一のオブジェクトで要求 - 応答交換をアーカイブすることです。つまり、クライアントは、要求と応答の両方を含む単一のオブジェクトをアーカイブしたいと考えています。
SCVP clients and servers MUST support the default behavior. SCVP clients MAY support requesting and processing the full request. SCVP servers SHOULD support returning the full request.
SCVPクライアントとサーバは、デフォルトの動作をサポートしなければなりません。 SCVPクライアントは、完全な要求を要求し、処理をサポートするかもしれません。 SCVPサーバは、完全な要求を返すことをサポートすべきです。
The responseValidationPolByRef item controls whether the response includes just a reference to the policy or a reference to the policy plus all the parameters by value of the policy used to process the request. The response MUST contain a reference to the validation policy. If the client wants the validation policy parameters to be included by value also, then responseValidationPolByRef is set to FALSE. The main reason a client would request the server to include validation policy to be included by value is to archive the request-response exchange in a single object. That is, the client wants to archive the CVResponse and have it include every aspect of the validation policy.
responseValidationPolByRefアイテムはレスポンスがポリシーまたはポリシーへの参照に加え、リクエストを処理するために使用されるポリシーの値によってすべてのパラメータを単に参照を含むかどうかを制御します。応答は、検証ポリシーへの参照を含まなければなりません。クライアントが検証ポリシーのパラメータも値によって含まれることを希望する場合は、responseValidationPolByRefはFALSEに設定されています。クライアントが値に含まれる検証ポリシーを含めるようにサーバーを要求する主な理由は、単一のオブジェクトで要求 - 応答交換をアーカイブすることです。これは、クライアントがCVResponseをアーカイブし、それが検証ポリシーのあらゆる側面を含める持って望んでいる、です。
SCVP clients MUST support requesting and processing the validation policy by reference, and SCVP servers MUST support returning the validation policy by reference. SCVP clients MAY support requesting and processing the validation policy by values. SVCP servers SHOULD support returning the validation policy by values.
SCVPクライアントが要求して参照することによって検証ポリシーの処理をサポートしなければならない、とSCVPサーバは、参照することにより、検証ポリシーを返すサポートしなければなりません。 SCVPクライアントが要求した値によって検証ポリシーの処理をサポートするかもしれません。 SVCPサーバは、値によって検証ポリシーを返すことをサポートすべきです。
The protectResponse item indicates whether the client requires the server to protect the response. If the client is performing full certification path validation on the response and it is not concerned about the source of the response, then the client does not benefit from a digital signature or MAC on the response. In this case, the client can indicate to the server that protecting the message is unnecessary. However, the server is always permitted to return a protected response.
protectResponse項目は、クライアントが応答を保護するためにサーバを必要とするかどうかを示します。クライアントが応答に完全な認証パスの検証を行うことであり、それは応答のソースが心配されていない場合、クライアントは、応答のデジタル署名またはMAC恩恵を受けるありません。この場合、クライアントは、メッセージを保護することは不要であることをサーバーに指示することができます。ただし、サーバーは常に保護された応答を返すことが許可されています。
SCVP clients that support delegated path discovery (DPD) as defined in [RQMTS] MUST support setting this value to FALSE.
【RQMTS]で定義されるように委任パス検出（DPD）をサポートするSCVPクライアントはこの値をfalseに設定をサポートしなければなりません。
SCVP clients that support delegated path validation (DPV) as defined in [RQMTS] require an authenticated response. Unless a protected transport mechanism (such as TLS) is used, such clients MUST always set this value to TRUE or omit the responseFlags item entirely, which requires the server to return a protected response.
【RQMTS]で定義されるように委任パス検証（DPV）をサポートするSCVPクライアントは認証応答を必要とします。 （例えばTLSなど）保護トランスポートメカニズムを使用しない限り、そのようなクライアントは、常にTRUEにこの値を設定するか、または保護された応答を返すためにサーバを必要とする完全responseFlags項目を省略しなければなりません。
SCVP servers MUST support returning protected responses, and SCVP servers SHOULD support returning unprotected responses. Based on local policy, the server can be configured to return protected or unprotected responses if this value is set to FALSE. If, based on local policy, the server is unable to return protected responses, then the server MUST return an error if this value is set to TRUE.
SCVPサーバは、保護されたレスポンスを返すサポートしなければならない、とSCVPサーバは、保護されていないレスポンスを返すことをサポートすべきです。ローカルポリシーに基づいて、サーバーは、この値がFALSEに設定されている場合、保護または保護されていないレスポンスを返すように設定することができます。 、ローカルポリシーに基づいて、サーバは保護された応答を返すことができない場合、この値をtrueに設定すると、サーバーはエラーを返さなければなりません。
The cachedResponse item indicates whether the client will accept a cached response. To enhance performance and limit the exposure of signing keys, an SCVP service may be designed to cache responses until new revocation information is expected. Where cachedResponse is set to TRUE, the client will accept a previously cached response.
cachedResponse項目は、クライアントがキャッシュされたレスポンスを受け入れるかどうかを示します。パフォーマンスを向上させ、署名鍵の露出を制限するために、SCVPサービスは、新たな失効情報が予想されるまでの応答をキャッシュするように設計することができます。 cachedResponseがTRUEに設定されている場合、クライアントは、以前にキャッシュされた応答を受け入れます。
Clients may insist on creation of a fresh response to protect against a replay attack and ensure that information is up to date. Where cachedResponse is FALSE, the client will not accept a cached response. To ensure that a response is fresh, the client MUST also include the requestNonce as defined in Section 3.4.
クライアントは、リプレイ攻撃から保護し、その情報が最新のものであることを確認するために、新鮮な応答の作成を主張することがあります。 cachedResponseがFALSEである場合は、クライアントがキャッシュされた応答を受け付けません。 3.4節で定義された応答が新鮮であることを確認するために、クライアントもrequestNonceを含まなければなりません。
Servers MUST process the cachedResponse flag. Where cachedResponse is FALSE, servers that cannot produce fresh responses MUST reply with an error message. Servers MAY choose to provide fresh responses even where cachedResponse is set to TRUE.
サーバーはcachedResponseフラグを処理しなければなりません。 cachedResponseがFALSEである場合には、新鮮な応答を生成することはできませんサーバーは、エラーメッセージで応答しなければなりません。サーバーはcachedResponseがTRUEに設定されていても、新鮮な応答を提供することを選択するかもしれません。
The optional serverContextInfo item, if present, contains context from a previous request-response exchange with the same SCVP server. It allows the server to return more than one certification path for the same certificate to the client. For example, if a server constructs a particular certification path for a certificate, but the client finds it unacceptable, the client can then send the same query back to the server with the serverContextInfo from the first response, and the server will be able to provide a different certification path (if another one can be found).
任意serverContextInfo項目は、存在する場合、同じSCVPサーバとの以前の要求 - 応答交換のコンテキストを含んでいます。これは、サーバーがクライアントに同じ証明書に複数の証明書パスを返すことができます。サーバー証明書のための特定の証明書パスを構築しますが、クライアントはそれが受け入れられない見つけた場合、クライアントは、最初の応答からバックserverContextInfoでサーバに同じクエリを送信することができ、およびサーバが提供することができるようになります（別のものを見つけることができる場合）は、異なる認証パス。
Contents of the serverContextInfo are opaque to the SCVP client. That is, the client only knows that it needs to return the value provided by the server with the subsequent request to get a different certification path. Note that the subsequent query needs to be identical to the previous query with the exception of the following:
serverContextInfoの内容はSCVPクライアントに不透明です。つまり、クライアントは、それが別の証明書パスを取得するための後続の要求をサーバにより提供された値を返すために必要があることを知っています。その後のクエリは、次の例外を除いて、前のクエリと同じにする必要があることに注意してください。
- requestNonce,
- requestNonce、
- serverContextInfo, and
- serverContextInfo、および
- the client's digital signature or MAC on the request.
- ご要望に応じてクライアントのデジタル署名やMAC。
SCVP clients MAY support serverContextInfo, and SCVP servers SHOULD support serverContextInfo.
SCVPクライアントはserverContextInfoをサポートすることができ、SCVPサーバは、serverContextInfoをサポートする必要があります。
The optional validationTime item, if present, tells the date and time relative to which the SCVP client wants the server to perform the checks. If the validationTime is not present, the server MUST perform the validation using the date and time at which the server processes the request. If the validationTime is present, it MUST be encoded as GeneralizedTime. The validationTime provided MUST be a retrospective time since the server can only perform a validity check using the current time (default) or previous time. A server can ignore the validationTime provided in the request if the time is within the clock skew of the server's current time.
オプションのvalidationTime項目は、存在する場合、SCVPクライアントはサーバがチェックを実行したいに日付と時刻の相対的に指示します。 validationTimeが存在しない場合、サーバは、サーバがリクエストを処理した日付と時刻を使用して検証を実行しなければなりません。 validationTimeが存在する場合、それはGeneralizedTimeとしてエンコードする必要があります。 validationTimeは、サーバーが、現在の時間（デフォルト）または前の時間を利用して妥当性チェックを行うことができますので、遡及時間でなければなりません提供しました。時間は、サーバーの現在時刻のクロック・スキューの範囲内であれば、サーバはリクエストで提供さvalidationTimeを無視することができます。
The revocation status information is obtained with respect to the validation time. When specifying a validation time other than the current time, the validation time should not necessarily be identical to the time when the private key was used. The validation time specified by the client may be adjusted to compensate for:
失効状態情報は、検証時間に関して得られます。現在の時間以外の検証時間を指定する場合、検証時間は必ずしも秘密鍵を使用した時と同じであってはなりません。クライアントが指定した検証時間が補償するために調整することができます。
1) time for the end-entity to realize that its private key has been, or could possibly be, compromised, and/or
エンドエンティティのための1）の時間は、その秘密鍵があったことを実現するために、または可能性、危険にさらされる可能性があり、および/または
2) time for the end-entity to report the key compromise, and/or
2）エンドエンティティが鍵の危殆化を報告するための時間を、および/または
3) time for the revocation authority to process the revocation request from the end-entity, and/or
3）エンドエンティティから失効要求を処理するために失効権限のための時間、及び/又は
4) time for the revocation authority to update and distribute the revocation status information.
4）失効状態情報を更新し、配布する取消し権威のための時間を。
GeneralizedTime values MUST be expressed in Universal Coordinated Time (UTC) (which is also known as Greenwich Mean Time and Zulu time) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds.
GeneralizedTimeの値は、（また、グリニッジ標準時とズールー時間として知られている）、秒数がゼロであっても、秒（すなわち、倍YYYYMMDDHHMMSSZいる）を含める必要があり協定世界時（UTC）で表現されなければなりません。 GeneralizedTimeの値は、小数点以下の秒を含んではいけません。
The information in the corresponding CertReply item in the response MUST be formatted as if the server created the response at the time indicated in the validationTime. However, if the server does not have appropriate historical information, the server MUST return an error response.
サーバはvalidationTimeに示された時間に応答を作成したかのように応答して、対応するCertReply項目の情報をフォーマットする必要があります。サーバーが適切な履歴情報を持っていない場合は、サーバがエラー応答を返さなければなりません。
SCVP servers MUST apply a clock skew to the validation time to allow for minor time synchronization errors. The default value is 10 minutes. If the server uses a value other than the default, it MUST include the clock skew value in the validation policy response.
SCVPサーバは、マイナータイム同期誤差を許容するために、検証時にクロック・スキューを適用しなければなりません。デフォルト値は10分です。サーバがデフォルト以外の値を使用している場合、それは検証ポリシー応じてクロック・スキュー値を含まなければなりません。
SCVP clients MAY support validationTime other than the current time. SCVP servers MUST support using its current time, and SHOULD support the client setting the validationTime in the request.
SCVPクライアントは、現在の時間以外のvalidationTimeをサポートするかもしれません。 SCVPサーバは、その現在の時刻を使用してサポートしなければならない、とのリクエストにvalidationTimeを設定し、クライアントをサポートする必要があります。
The optional intermediateCerts item may help the SCVP server create valid certification paths. The intermediateCerts item, when present, provides certificates that the server MAY use when forming a certification path. When building certification paths, the server MAY use the certificates in the intermediateCerts item in addition to any other certificates that the server can access. When present, the intermediateCerts item MUST contain at least one certificate, and the intermediateCerts item MUST be structured as a CertBundle. The certificates in the intermediateCerts item MUST NOT be considered as valid by the server just because they are present in this item.
オプションのintermediateCerts項目はSCVPサーバが有効な証明書パスを作成するのに役立つことがあります。 intermediateCerts項目は、存在する場合、証明書パスを形成する際にサーバが使用する可能性証明書を提供します。証明書パスを構築する場合、サーバは、サーバがアクセスできる任意の他の証明書に加えてintermediateCerts項目で証明書を使用するかもしれません。存在する場合、intermediateCerts項目は、少なくとも一つの証明書を含まなければなりません、そしてintermediateCerts項目がCertBundleように構成されなければなりません。 intermediateCertsアイテム内の証明書は、彼らがこの項目に存在しているという理由だけで、サーバーによって有効とみなされてはなりません。
The CertBundle type contains one or more certificates. The order of the entries in the bundle is not important. CertBundle has the following syntax:
CertBundleタイプは、1つ以上の証明書が含まれています。バンドル内のエントリの順序は重要ではありません。 CertBundleの構文は次のとおりです。
CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate
SCVP clients SHOULD support intermediateCerts, and SCVP servers MUST support intermediateCerts.
SCVPクライアントはintermediateCertsをサポートする必要があり、SCVPサーバは、intermediateCertsをサポートしなければなりません。
The optional revInfos item specifies revocation information such as CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP server MAY use when validating certification paths. The purpose of the revInfos item is to provide revocation information to which the server might not otherwise have access, such as an OCSP response that the client received along with the certificate. Note that the information in the revInfos item might not be used by the server. For example, the revocation information might be associated with certificates that the server does not use in the certification path that it constructs.
任意revInfos項目は、CRLに、デルタのCRL [PKIX-1]、及びOCSPレスポンス[OCSP]認証パスの検証時にSCVPサーバが使用できることとして、失効情報を指定します。 revInfos項目の目的は、サーバがそうでなければ、このようなクライアントが証明書とともに受信したOCSP応答などのアクセスを、持っていないかもしれないために失効情報を提供することです。 revInfos項目の情報がサーバーによって使用されない可能性があることに注意してください。たとえば、失効情報は、サーバが構築証明書パスに使用していない証明書と関連付けられている可能性があります。
Clients SHOULD be courteous to the SCVP server by separating CRLs and delta CRLs. However, since the two share a common syntax, SCVP servers SHOULD accept delta CRLs even if they are identified as regular CRLs by the SCVP client.
クライアントは、CRLとデルタCRLを分離することにより、SCVPサーバへの礼儀であるべきです。 2は、共通の構文を共有しているため、彼らはSCVPクライアントによる定期的なCRLのように識別されている場合でもしかし、SCVPサーバは、デルタCRLを受け入れる必要があります。
CRLs, delta CRLs, and OCSP responses can be provided as revocation information. If needed, additional object identifiers can be assigned for additional revocation information types in the future.
CRL、デルタCRLの、およびOCSP応答が失効情報として提供することができます。必要に応じて、追加のオブジェクト識別子は、将来的に追加の失効情報のタイプのために割り当てることができます。
The revInfos item uses the RevocationInfos type, which has the following syntax:
revInfos項目は、次の構文を持っていRevocationInfos型を使用しています。
RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo
RevocationInfo ::= CHOICE {
crl [0] CertificateList,
delta-crl [1] CertificateList,
ocsp [2] OCSPResponse,
other [3] OtherRevInfo }
OtherRevInfo ::= SEQUENCE {
riType OBJECT IDENTIFIER,
riValue ANY DEFINED BY riType }
The client MAY allow the server to use a cached SCVP response. When doing so, the client MAY use the producedAt item to express requirements on the freshness of the cached response. The producedAt item tells the earliest date and time at which an acceptable cached response could have been produced. The producedAt item represents the date and time in UTC, using the GeneralizedTime type. The value in the producedAt item is independent of the validation time.
クライアントは、サーバがキャッシュされたSCVP応答を使用することを可能にします。その際、クライアントはキャッシュされたレスポンスの鮮度の要件を表現するためにproducedAtアイテムを使用するかもしれません。 producedAt項目が許容できるキャッシュされた応答が生成されている可能性が最も早い日付と時刻を伝えます。 producedAt項目はGeneralizedTimeのタイプを使用して、UTCの日付と時刻を表します。 producedAt項目の値は、検証時間とは無関係です。
GeneralizedTime value MUST be expressed in UTC, as defined in Section 3.2.7.
セクション3.2.7で定義されるようにGeneralizedTimeの値は、UTCで表現されなければなりません。
SCVP clients MAY support using producedAt values in the request. SCVP servers MAY support the producedAt values in the request. SCVP servers that support cached responses SHOULD support the producedAt value in requests.
SCVPクライアントは要求にproducedAt値を使用してサポートしてもよい（MAY）。 SCVPサーバは、リクエストにproducedAt値をサポートするかもしれません。キャッシュされた応答をサポートするSCVPサーバは、リクエスト中producedAt値をサポートする必要があります。
The optional queryExtensions item contains extensions. If present, each extension in the sequence extends the query. This specification does not define any extensions; the facility is provided to allow future specifications to extend SCVP. The syntax for Extensions is imported from [PKIX-1]. The queryExtensions item, when present, MUST contain a sequence of Extension items, and each of the extensions MUST contain extnID, critical, and extnValue items. Each of these is described in the following sections.
オプションのqueryExtensions項目は拡張子が含まれています。存在する場合、シーケンス内の各拡張機能は、クエリを拡張します。この仕様は、任意の拡張子を定義していません。施設は、将来の仕様がSCVPを拡張できるようにするために提供されます。拡張のための構文は[PKIX-1]からインポートされます。 queryExtensions項目は、存在する場合、拡張項目の配列を含有しなければならない、拡張機能のそれぞれが重要なextnID、およびextnValueの項目を含まなければなりません。これらのそれぞれは、次のセクションで説明されています。
The extnID item is an identifier for the extension. It contains the object identifier that names the extension.
extnID項目は、拡張のための識別子です。これは、その名の拡張子オブジェクト識別子が含まれています。
The critical item is a BOOLEAN. Each extension is designated as either critical (with a value of TRUE) or non-critical (with a value of FALSE). By default, the extension is non-critical. An SCVP server MUST reject the query if it encounters a critical extension that it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.
重要な項目がBOOLEANです。各拡張は（FALSEの値を有する）（TRUEの値を有する）クリティカルまたは非クリティカルのいずれかとして指定されます。デフォルトでは、拡張子は重要ではありません。それが認識しないことが重要拡張子が発生した場合、SCVPサーバはクエリを拒絶しなければなりません。しかし、非クリティカルな拡張は、それが認識されない場合は無視されるかもしれないが、それが認識された場合に処理しなければなりません。
The extnValue item contains an OCTET STRING. Within the OCTET STRING is the extension value. An ASN.1 type is specified for each extension, identified by the associated extnID object identifier.
extnValue項目はオクテット文字列が含まれています。オクテット文字列内の拡張値です。 ASN.1タイプは関連extnIDオブジェクト識別子によって識別された各拡張、指定されています。
The optional requestorRef item contains a list of names identifying SCVP servers, and it is intended for use in environments where SCVP relay is employed. Although requestorRef is encoded as a SEQUENCE, no order is implied. The requestorRef item is used to detect looping in some configurations. The value and use of requestorRef are described in Section 7.
オプションのrequestorRef項目はSCVPサーバを識別する名前のリストが含まれ、それはSCVPリレーが採用されている環境での使用を目的としています。 requestorRefシーケンスとしてエンコードされているが、いかなる順序が暗示されていません。 requestorRef項目は、いくつかの構成でループを検出するために使用されます。 requestorRefの値と使用はセクション7に記載されています。
Conforming SCVP clients MAY support specification of the requestorRef value. Conforming SCVP server implementations MUST process the requestorRef value if present. If the SCVP client includes a requestorRef value in the request, then the SCVP server MUST return the same value in a non-cached response. The SCVP server MAY omit the requestorRef value from cached SCVP responses.
準拠SCVPクライアントはrequestorRef値の仕様をサポートするかもしれません。適合SCVPサーバ実装が存在する場合requestorRef値を処理しなければなりません。 SCVPクライアントが要求でrequestorRef値が含まれている場合、SCVPサーバは非キャッシュ応答で同じ値を返さなければなりません。 SCVPサーバは、キャッシュされたSCVP応答からrequestorRef値を省略することができます。
The requestorRef item MUST be a sequence of GeneralName. No provisions are made to ensure uniqueness of the requestorRef GeneralName values.
requestorRef項目はいるGeneralNameの順序でなければなりません。いかなる規定はrequestorRefのGeneralName値の一意性を保証するために行われません。
The optional requestNonce item contains a request identifier generated by the SCVP client. If the client includes a requestNonce value in the request, it is expressing a preference that the SCVP server SHOULD return a non-cached response. If the server returns a non-cached response, it MUST include the value of requestNonce from the request in the response as the respNonce item; however, the server MAY return a cached response which MUST NOT have a respNonce.
オプションのrequestNonce項目はSCVPクライアントによって生成された要求識別子が含まれています。クライアントが要求でrequestNonce値が含まれている場合、それはSCVPサーバは非キャッシュされたレスポンスを返すべき優先度を表現しています。サーバは非キャッシュ応答を返した場合、それはrespNonceアイテムとして応答における要求からrequestNonceの値を含まなければなりません。ただし、サーバーはrespNonceを持ってはいけません、キャッシュされた応答を返す場合があります。
SCVP clients that insist on creation of a fresh response (e.g., to protect against a replay attack or ensure information is up to date) MUST support requestNonce. Conforming SCVP server implementations MUST process the requestNonce value if present.
新鮮な応答の作成を主張するSCVPクライアントが（例えば、リプレイ攻撃から保護したり、情報を確実にするためには最新のものである）requestNonceをサポートしなければなりません。存在する場合SCVPサーバ実装を従わせるrequestNonce値を処理しなければなりません。
If the client includes a requestNonce and also sets the cachedResponse flag to FALSE as described in Section 3.2.5.4, the client is indicating that the SCVP server MUST return either a non-cached response including the respNonce or an error response. The client SHOULD include a requestNonce item in every request to prevent an attacker from acting as a man-in-the-middle by replaying old responses from the server. The requestNonce value SHOULD change with every request sent by the client.
クライアントはrequestNonceを含み、セクション3.2.5.4に記載されるようにもFALSEにcachedResponseフラグを設定した場合、クライアントはSCVPサーバがrespNonceまたはエラー応答を含む非キャッシュ応答のどちらかを返さなければならないことを示しています。クライアントは、サーバから古い応答を再生することによってのman-in-the-middleとして作用する攻撃を防ぐために、すべての要求にrequestNonce項目を含むべきです。 requestNonce値は、クライアントから送信されたすべての要求を変更する必要があります。
The client MUST NOT set the cachedResponse flag to FALSE without also including a requestNonce. A server receiving such a request SHOULD return an invalidRequest error response.
また、クライアントはrequestNonce含めずにFALSEにcachedResponseフラグを設定してはいけません。このような要求を受信したサーバはinvalidRequestエラー応答を返すべきです。
The requestNonce item, if present, MUST be an OCTET STRING that was generated exclusively for this request.
requestNonce項目は、存在する場合、この要求のために排他的に生成されたオクテットストリングでなければなりません。
The optional requestorName item is used by the client to include an identifier in the request. The client MAY include this information for the DPV server to copy into the response.
任意requestorName項目は、要求に識別子を含めるためにクライアントによって使用されます。クライアントはDPVサーバが応答にコピーするために、この情報を含むことができます。
Conforming SCVP clients MAY support specification of this item in requests. SCVP servers MUST be able to process requests that include this item.
準拠SCVPクライアントはリクエストでこのアイテムの仕様をサポートするかもしれません。 SCVPサーバは、このアイテムが含まれるリクエストを処理できなければなりません。
The optional responderName item is used by the client to indicate the identity of the SCVP server that the client expects to sign the SCVP response if the response is digitally signed. The responderName item SHOULD only be included if:
オプションのresponderName項目は、クライアントが応答がデジタル署名されている場合SCVP応答に署名する予定SCVPサーバのアイデンティティを示すために、クライアントによって使用されます。 responderName項目が場合にのみ含まれるべきです。
1. the request is either unprotected or digitally signed (i.e., is not protected using a MAC), and
1.リクエストが保護されていない、またはデジタル署名のいずれかである（すなわち、MACを使用して保護されていない）、および
2. the responseFlags item is either absent or present with the protectResponse set to TRUE.
2. responseFlagsアイテムがTRUEに設定されprotectResponseと不在又は存在のいずれかです。
Conforming SCVP clients MAY support specification of this item in requests. SCVP servers MUST be able to process requests that include this item. SCVP servers that maintain a single private key for signing SCVP responses or that are unable to return digitally signed responses MAY ignore the value in this item. SCVP servers that maintain more than one private key for signing SCVP responses SHOULD either (a) digitally sign the response using a private key that corresponds to a certificate that includes the name specified in responderName in either subject field or subjectAltName extension or (b) return a error indicating that the server does not possess a certificate that asserts the specified name.
準拠SCVPクライアントはリクエストでこのアイテムの仕様をサポートするかもしれません。 SCVPサーバは、このアイテムが含まれるリクエストを処理できなければなりません。 SCVP応答を署名するための単一の秘密鍵を維持するか、SCVPサーバは、この項目の値を無視するかもしれデジタル署名された応答を返すことができません。 SCVP応答に署名するための複数の秘密鍵を維持するSCVPサーバは、（a）は、デジタル対象フィールドまたはsubjectAltName拡張または（b）のリターンのいずれかでresponderNameに指定した名前を含む、証明書に対応する秘密鍵を使用して応答を署名する必要がありどちらかサーバは指定された名前をアサートし、証明書を所持していないことを示すエラー。
The OPTIONAL requestExtensions item contains extensions. If present, each extension in the sequence extends the request. This specification does not define any extensions; the facility is provided to allow future specifications to extend SCVP. The syntax for Extensions is imported from [PKIX-1]. The requestExtensions item, when present, MUST contain a sequence of Extension items, and each of the extensions MUST contain extnID, critical, and extnValue items. Each of these is described in the following sections.
オプションrequestExtensions項目は拡張子が含まれています。存在する場合、シーケンス内の各拡張は、リクエストを拡張します。この仕様は、任意の拡張子を定義していません。施設は、将来の仕様がSCVPを拡張できるようにするために提供されます。拡張のための構文は[PKIX-1]からインポートされます。 requestExtensions項目は、存在する場合、拡張項目の配列を含有しなければならない、拡張機能のそれぞれが重要なextnID、およびextnValueの項目を含まなければなりません。これらのそれぞれは、次のセクションで説明されています。
The extnID item is an identifier for the extension. It contains the object identifier that names the extension.
extnID項目は、拡張のための識別子です。これは、その名の拡張子オブジェクト識別子が含まれています。
The critical item is a BOOLEAN. Each extension is designated as either critical (with a value of TRUE) or non-critical (with a value of FALSE). By default, the extension is non-critical. An SCVP server MUST reject the query if it encounters a critical extension it does not recognize. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.
重要な項目がBOOLEANです。各拡張は（FALSEの値を有する）（TRUEの値を有する）クリティカルまたは非クリティカルのいずれかとして指定されます。デフォルトでは、拡張子は重要ではありません。それはそれは認識していない重要な拡張が発生した場合SCVPサーバはクエリを拒絶しなければなりません。非クリティカルな拡張は、それが認識されない場合は無視されるかもしれないが、それが認識された場合に処理しなければなりません。
The extnValue item contains an OCTET STRING. Within the OCTET STRING is the extension value. An ASN.1 type is specified for each extension, identified by the associated extnID object identifier.
extnValue項目はオクテット文字列が含まれています。オクテット文字列内の拡張値です。 ASN.1タイプは関連extnIDオブジェクト識別子によって識別された各拡張、指定されています。
The signatureAlg item contains an AlgorithmIdentifier indicating which algorithm the server should use to sign the response message. The signatureAlg item SHOULD only be included if:
signatureAlg項目は、サーバが応答メッセージに署名するために使用するアルゴリズムを示すのAlgorithmIdentifierが含ま。 signatureAlg項目が場合にのみ含まれるべきです。
1. the request is either unprotected or digitally signed (i.e., is not protected using a MAC), and
1.リクエストが保護されていない、またはデジタル署名のいずれかである（すなわち、MACを使用して保護されていない）、および
2. the responseFlags item is either absent or present with the protectResponse set to TRUE.
2. responseFlagsアイテムがTRUEに設定されprotectResponseと不在又は存在のいずれかです。
If included, the signatureAlg item SHOULD specify one of the signature algorithms specified in the signatureGeneration item of the server's validation policy response message.
含まれている場合、signatureAlg項目は、サーバの検証方針応答メッセージのsignatureGeneration項目で指定された署名アルゴリズムのいずれかを特定すべきです。
SCVP servers MUST be able to process requests that include this item. If the server is returning a digitally signed response to this message, then:
SCVPサーバは、このアイテムが含まれるリクエストを処理できなければなりません。次に、サーバーは、このメッセージにデジタル署名された応答を返している場合：
1. If the signatureAlg item is present and specifies an algorithm that is included in the signatureGeneration item of the server's validation policy response message, the server MUST sign the response using the signature algorithm specified in signatureAlg.
1. signatureAlg項目が存在し、サーバの検証方針応答メッセージのsignatureGeneration項目に含まれるアルゴリズムを指定している場合、サーバはsignatureAlgで指定された署名アルゴリズムを使用して応答に署名しなければなりません。
2. Otherwise, if the signatureAlg item is absent or is present but specifies an algorithm that is not supported by the server, the server MUST sign the response using the server's default signature algorithm as specified in the signatureGeneration item of the server's validation policy response message.
2. signatureAlg項目が存在しないか、または存在するが、サーバによってサポートされていないアルゴリズムを指定する場合、サーバーの検証方針応答メッセージのsignatureGeneration項目で指定されるようにそうでなければ、サーバは、サーバのデフォルトの署名アルゴリズムを使用して応答に署名する必要があります。
The hashAlg item contains an object identifier indicating which hash algorithm the server should use to compute the hash value for the requestHash item in the response. SCVP clients SHOULD NOT include this item if fullRequestInResponse is set to TRUE. If included, the hashAlg item SHOULD specify one of the hash algorithms specified in the hashAlgorithms item of the server's validation policy response message.
hashAlg項目は、サーバが応答してrequestHashアイテムのハッシュ値を計算するために使用するハッシュアルゴリズムを示すオブジェクト識別子を含みます。 fullRequestInResponseがTRUEに設定されている場合SCVPクライアントは、この項目を含めるべきではありません。含まれている場合、hashAlgアイテムはサーバーの検証方針応答メッセージのhashAlgorithms項目に指定されたハッシュアルゴリズムのいずれかを指定する必要があります。
SCVP servers MUST be able to process requests that include this item. If the server is returning a response to this message that includes a requestHash, then:
SCVPサーバは、このアイテムが含まれるリクエストを処理できなければなりません。次に、サーバは、requestHashを含み、このメッセージへの応答を返している場合：
1. If the hashAlg item is present and specifies an algorithm that is included in the hashAlgorithms item of the server's validation policy response message, the server MUST use the algorithm specified in hashAlg to compute the requestHash.
1. hashAlg項目が存在し、サーバの検証方針応答メッセージのhashAlgorithms項目に含まれるアルゴリズムを指定する場合、サーバーはrequestHashを計算するhashAlgで指定されたアルゴリズムを使用しなければなりません。
2. Otherwise, if the hashAlg item is absent or is present but specifies an algorithm that is not supported by the server, the server MUST compute the requestHash using the server's default hash algorithm as specified in the hashAlgorithms item of the server's validation policy response message.
2. hashAlg項目が存在しないか、または存在するが、サーバによってサポートされていないアルゴリズムを指定する場合、サーバーの検証方針応答メッセージのhashAlgorithms項目で指定されるようにそうでなければ、サーバは、サーバのデフォルトのハッシュアルゴリズムを使用してrequestHashを計算しなければなりません。
SCVP clients MAY use the requestorText item to provide text for inclusion in the corresponding response. For example, this field may describe the nature or reason for the request.
SCVPクライアントは、対応する応答に含めるためのテキストを提供するために、requestorTextアイテムを使用するかもしれません。たとえば、このフィールドには、要求のための自然や理由を記述することができます。
Conforming SCVP client implementations MAY support inclusion of this item in requests. Conforming SCVP server implementations MUST accept requests that include this item. When generating non-cached responses, conforming SCVP server implementations MUST copy the contents of this item into the requestorText item in the corresponding response (see Section 4.13).
準拠SCVPクライアント実装は、リクエストでこの項目を含めることをサポートするかもしれません。 SCVPサーバ実装を準拠することは、このアイテムが含まれる要求を受け入れなければなりません。非キャッシュされた応答を生成する際に、適合SCVPサーバ実装は、対応する応答でrequestorText項目にこの項目の内容をコピーする必要があります（セクション4.13を参照）。
It is a matter of local policy what validation policy the server uses when authenticating requests. When authenticating protected SCVP requests, the SCVP servers SHOULD use the validation algorithm defined in Section 6 of [PKIX-1].
これは、要求を認証するときにサーバーが使用するどのような検証ポリシーローカルポリシーの問題です。保護SCVP要求を認証するとき、SCVPサーバは[PKIX-1]のセクション6で定義された検証アルゴリズムを使用すべきです。
If the certificate used to validate a SignedData validation request includes the key usage extension ([PKIX-1], Section 4.2.1.3), it MUST have either the digital signature bit set, the non-repudiation bit set, or both bits set.
SignedData検証要求を検証するために使用される証明書は、鍵使用拡張（[PKIX-1]、セクション4.2.1.3）を含む場合、それは、デジタル署名のビットのセット、否認防止ビットのセット、またはセット両方のビットのいずれかがなければなりません。
If the certificate used to validate an AuthenticatedData validation request includes the key usage extension, it MUST have the key agreement bit set.
AuthenticatedDataの検証要求を検証するために使用する証明書は、鍵用途拡張が含まれている場合、それは重要な合意ビットを設定する必要があります。
If the certificate used on a validation request contains the extended key usage extension ([PKIX-1], Section 4.2.1.13), the server SHALL verify that it contains the SCVP client OID, the anyExtendedKeyUsage OID, or another OID acceptable to the server. The SCVP client OID is defined as follows:
検証要求に使用される証明書は、拡張鍵使用拡張（[PKIX-1]、セクション4.2.1.13）が含まれている場合、サーバは、サーバに受け入れSCVPクライアントOID、anyExtendedKeyUsage OID、または別のOIDが含まれていることを検証しなければなりません。次のようにSCVPクライアントOIDが定義されています。
id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 }
id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 }
If a protected request fails to meet the validation policy of the server, it MUST be treated as an unauthenticated request.
保護された要求は、サーバーの検証ポリシーを満たすために失敗した場合は、未認証の要求として扱わなければなりません。
An SCVP server response to the client MUST be a single CVResponse item. When a CVResponse is encapsulated in a MIME body part, application/scvp-cv-response MUST be used.
クライアントへのSCVPサーバの応答は、単一CVResponse項目でなければなりません。 CVResponseはMIME本体部分内にカプセル化された場合、アプリケーション/ SCVP-CV応答を使用しなければなりません。
There are a number of forms of an SCVP response:
SCVP応答のフォームの数があります。
1. A success response to a request that has protectResponse set to FALSE. These responses SHOULD NOT be protected by the server.
1. protectResponseがFALSEに設定された要求に対する成功応答。これらの応答は、サーバによって保護されるべきではありません。
2. The server MUST protect all other success responses. If the server is unable to return a protected success response due to local policy, then it MUST return an error response.
2.サーバーは、他のすべての成功応答を保護する必要があります。サーバーが原因ローカルポリシーに保護された成功応答を返すことができないなら、それはエラー応答を返さなければなりません。
3. An error response to a request made over a protected transport such as TLS. These responses SHOULD NOT be protected by the server.
3.このようなTLSなどの保護されたトランスポートを介して行われた要求に対するエラー応答。これらの応答は、サーバによって保護されるべきではありません。
4. An error response to a request that has protectResponse set to FALSE. These responses SHOULD NOT be protected by the server.
4. protectResponseがFALSEに設定された要求に対するエラー応答。これらの応答は、サーバによって保護されるべきではありません。
5. An error response to an authenticated request. The server SHOULD protect these responses.
5.認証された要求に対するエラー応答。サーバーは、これらの応答を保護する必要があります。
6. An error response to an AuthenticatedData request where MAC is valid. The server MUST protect these responses.
6. MACが有効であるAuthenticatedData要求に対するエラー応答。サーバーは、これらの応答を保護する必要があります。
Successful responses are made when the server has fully complied with the request. That is, the server was able to attempt to build a certification path using the referenced or supplied validation policy, and it was able to comply with all the requested parameters. If the server is unable to perform validations using the required validation policy or the request contains an unsupported option, then the server MUST return an error response.
サーバーが完全に要求を遵守しているときの成功応答がなされています。つまり、サーバが参照または付属検証ポリシーを使用して、証明書パスを構築しようとすることができました、そしてすべての要求されたパラメータに準拠することができました。サーバが必要な検証ポリシーを使用して検証を実行することができないか、要求がサポートされていないオプションが含まれている場合、サーバはエラー応答を返さなければなりません。
For protected requests and responses, SCVP servers MUST support SignedData and SHOULD support AuthenticatedData. It is a matter of local policy which types are used. Where a protected response is required, SCVP servers MUST use SignedData or AuthenticatedData, even if the transaction is performed using a protected transport (e.g., TLS).
保護された要求と応答のために、SCVPサーバはSignedDataのをサポートしなければならないとAuthenticatedDataをサポートする必要があります。これは、型が使用されているローカルポリシーの問題です。保護された応答が要求される場合、SCVPサーバはトランザクションを保護輸送（例えば、TLS）を使用して行っても、のSignedData又はAuthenticatedDataを使用しなければなりません。
If the server is making a protected response to a protected request, then the server MUST use the same protection mechanism (SignedData or AuthenticatedData) as in the request.
サーバーが保護された要求に保護された応答を行っている場合、サーバは、要求と同じ保護メカニズム（のSignedDataかAuthenticatedData）を使用する必要があります。
An overview of the structure used for an unprotected response is provided below. Many details are not shown, but the way that SCVP makes use of CMS is clearly illustrated.
保護されていない応答のために使用される構造の概要を以下に提供されます。多くの詳細が示されていないが、SCVPがCMSを利用した方法が明確に示されています。
ContentInfo { contentType id-ct-scvp-certValResponse, -- (1.2.840.113549.1.9.16.1.11) content CVResponse }
ContentInfo {contentTypeのID-CT-SCVP-certValResponse、 - （1.2.840.113549.1.9.16.1.11）コンテンツCVResponse}
The protected response consists of a CVResponse encapsulated in either a SignedData or an AuthenticatedData, which is in turn encapsulated in a ContentInfo. That is, the EncapsulatedContentInfo field of either SignedData or AuthenticatedData consists of an eContentType field with a value of id-ct-scvp-certValResponse and an eContent field that contains a DER-encoded CVResponse.
保護された応答は、のSignedDataまたは順番にContentInfoにカプセル化されAuthenticatedData、いずれかの中にカプセル化CVResponseから成ります。すなわち、のSignedData又はAuthenticatedDataのいずれかのEncapsulatedContentInfoフィールドは、ID-CT-SCVP-certValResponseの値とDERエンコードCVResponseが含まe-コンテンツフィールドとのeContentTypeフィールドから成ります。
The SCVP server MUST include its own certificate in the certificates field within SignedData. Other certificates MAY also be included.
SCVPサーバはSignedDataの中に、証明書の分野で独自の証明書を含まなければなりません。他の証明書も含まれるかもしれません。
The SCVP server MAY also provide one or more CRLs in the crls field within SignedData. The signerInfos field of SignedData MUST include exactly one SignerInfo. The SignedData MUST NOT include the unsignedAttrs field.
SCVPサーバはSignedDataの内のCRLフィールド内の1つまたは複数のCRLを提供することができます。 SignedDataのsignerInfosフィールドは正確に一つのSignerInfoを含まなければなりません。 SignedDataはunsignedAttrsフィールドを含んではいけません。
The signedAttrs field within SignerInfo MUST include the content-type and message-digest attributes defined in [CMS], and it SHOULD include the signing-certificate attribute as defined in [ESS]. Within the signing-certificate attribute, the first certificate identified in the sequence of certificate identifiers MUST be the certificate of the SCVP server. The inclusion of other certificate identifiers in the signing-certificate attribute is OPTIONAL. The inclusion of policies in the signing-certificate is OPTIONAL.
SignerInfo内signedAttrsフィールドは、コンテンツタイプおよび[CMS]で定義されたメッセージダイジェスト属性を含まなければなりません、そして、[ESS]で定義されるように、それは、署名証明書の属性を含めるべきです。署名証明書の属性の中で、証明書識別子のシーケンスで同定された最初の証明書はSCVPサーバの証明書でなければなりません。署名証明書の属性に他の証明書の識別子を含めることは任意です。署名証明書でポリシーを含めることは任意です。
The recipientInfos field of AuthenticatedData MUST include exactly one RecipientInfo, which contains information for the client that sent the request. The AuthenticatedData MUST NOT include the unauthAttrs field.
AuthenticatedDataののrecipientInfosフィールドには、要求を送信したクライアントの情報が含まれています正確に一つのRecipientInfoを含まなければなりません。 AuthenticatedDataはunauthAttrsフィールドを含んではいけません。
The CVResponse item contains the server's response. The CVResponse MUST contain the cvResponseVersion, serverConfigurationID, producedAt, and responseStatus items. The CVResponse MAY also contain the respValidationPolicy, requestRef, requestorRef, requestorName, replyObjects, respNonce, serverContextInfo, and cvResponseExtensions items. The replyObjects item MUST contain exactly one CertReply item for each certificate requested. The requestorRef item MUST be included if the request included a requestorRef item and a non-cached response is provided. The respNonce item MUST be included if the request included a requestNonce item and a non-cached response is provided.
CVResponse項目は、サーバーの応答が含まれています。 CVResponseはcvResponseVersion、serverConfigurationID、producedAt、およびresponseStatus項目を含まなければなりません。 CVResponseもrespValidationPolicy、requestRef、requestorRef、requestorName、replyObjects、respNonce、serverContextInfo、およびcvResponseExtensions項目を含むかもしれません。 replyObjects項目が要求された証明書ごとに正確に1 CertReply項目を含まなければなりません。要求がrequestorRef項目が含まれている場合requestorRef項目が含まれなければならなくて、非キャッシュ応答が提供されます。要求がrequestNonce項目が含まれている場合respNonce項目が含まれなければならなくて、非キャッシュ応答が提供されます。
The CVResponse MUST have the following syntax:
CVResponseは、次の構文を持っている必要があります。
CVResponse ::= SEQUENCE {
cvResponseVersion INTEGER,
serverConfigurationID INTEGER,
producedAt GeneralizedTime,
responseStatus ResponseStatus,
respValidationPolicy [0] RespValidationPolicy OPTIONAL,
requestRef [1] RequestReference OPTIONAL,
requestorRef [2] GeneralNames OPTIONAL,
requestorName [3] GeneralNames OPTIONAL,
replyObjects [4] ReplyObjects OPTIONAL,
respNonce [5] OCTET STRING OPTIONAL,
serverContextInfo [6] OCTET STRING OPTIONAL,
cvResponseExtensions [7] Extensions OPTIONAL,
requestorText [8] UTF8String (SIZE (1..256)) OPTIONAL }
Conforming SCVP servers MAY be capable of constructing a CVResponse that includes the serverContextInfo or cvResponseExtensions items. Conforming SCVP servers MUST be capable of constructing a CVResponse with any of the remaining optional items. Conforming SCVP clients MUST be capable of processing a CVResponse with the following optional items: respValidationPolicy, requestRef, requestorName, replyObjects, and respNonce.
SCVPサーバを準拠することserverContextInfoまたはcvResponseExtensions項目が含まれてCVResponseを構築することが可能であってもよいです。 SCVPサーバを準拠することは、残りのオプション項目のいずれかにCVResponseを構築することができなければなりません。 respValidationPolicy、requestRef、requestorName、replyObjects、及びrespNonce：SCVPクライアントが準拠すると、次のオプション項目とCVResponseを処理できなければなりません。
Conforming SCVP clients that are capable of including requestorRef in a request MUST be capable of processing a CVResponse that includes the requestorRef item. Conforming SCVP clients MUST be capable of processing a CVResponse that includes the serverContextInfo or cvResponseExtensions items. Conforming clients MUST be able to determine if critical extensions are present in the cvResponseExtensions item.
要求にrequestorRefを含むことが可能であるSCVPクライアントが準拠するrequestorRef項目を含むCVResponseを処理できなければなりません。 SCVPクライアントを適合するserverContextInfo又はcvResponseExtensions項目を含むCVResponseを処理できなければなりません。準拠のクライアントは、重要な機能拡張がcvResponseExtensions項目に存在しているかどうかを判断できなければなりません。
The syntax and semantics of cvResponseVersion are the same as cvRequestVersion as described in Section 3.1. The cvResponseVersion MUST match the cvRequestVersion in the request. If the server cannot generate a response with a matching version number, then the server MUST return an error response that indicates the highest version number that the server supports as the version number.
cvResponseVersionの構文と意味論はセクション3.1で説明したようにcvRequestVersionと同じです。 cvResponseVersionは、要求にcvRequestVersionと一致しなければなりません。サーバが一致するバージョン番号を持つ応答を生成することができない場合、サーバーは、サーバーはバージョン番号としてサポートしている最大のバージョン番号を示すエラー応答を返さなければなりません。
The server configuration ID item represents the version of the SCVP server configuration when it processed the request. See Section 6.4 for details.
それが要求を処理したときにサーバの構成IDの項目はSCVPサーバ構成のバージョンを表します。詳細については、6.4節を参照してください。
The producedAt item tells the date and time at which the SCVP server generated the response. The producedAt item MUST be expressed in UTC, and it MUST be interpreted as defined in Section 3.2.7. This value is independent of the validation time.
producedAt項目はSCVPサーバが応答を生成した日時を伝えます。 producedAt項目は、UTCで表現されなければならない、およびセクション3.2.7で定義されるようには解釈されなければなりません。この値は、検証時間とは無関係です。
The responseStatus item gives status information to the SCVP client about its request. The responseStatus item has a numeric status code and an optional string that is a sequence of characters from the ISO/IEC 10646-1 character set encoded with the UTF-8 transformation format defined in [UTF8].
responseStatus項目は、その要求に関するSCVPクライアントにステータス情報を提供します。 responseStatus項目は数値ステータスコードと[UTF8]で定義されたUTF8変換フォーマットでエンコードされたISO / IEC 10646-1文字セットからの文字のシーケンスである任意の文字列を有しています。
The string MAY be used to transmit status information. The client MAY choose to display the string to a human user. However, because there is often no way to know the languages understood by a human user, the string may be of little or no assistance.
文字列は、ステータス情報を送信するために使用されるかもしれません。クライアントは、人間のユーザに文字列を表示するために選ぶかもしれません。多くの場合、人間のユーザが理解言語を知る方法はありませんので、しかし、文字列はほとんど、あるいはまったく助けになることがあります。
The responseStatus item uses the ResponseStatus type, which has the following syntax:
responseStatus項目は、次の構文を持っていResponseStatus型を使用しています。
ResponseStatus ::= SEQUENCE {
statusCode CVStatusCode DEFAULT okay,
errorMessage UTF8String OPTIONAL }
CVStatusCode ::= ENUMERATED {
okay (0),
skipUnrecognizedItems (1),
tooBusy (10),
invalidRequest (11),
internalError (12),
badStructure (20),
unsupportedVersion (21),
abortUnrecognizedItems (22),
unrecognizedSigKey (23),
badSignatureOrMAC (24),
unableToDecode (25),
notAuthorized (26),
unsupportedChecks (27),
unsupportedWantBacks (28),
unsupportedSignatureOrMAC (29),
invalidSignatureOrMAC (30),
protectedResponseUnsupported (31),
unrecognizedResponderName (32),
relayingLoop (40),
unrecognizedValPol (50), unrecognizedValAlg (51),
fullRequestInResponseUnsupported (52),
fullPolResponseUnsupported (53),
inhibitPolicyMappingUnsupported (54),
requireExplicitPolicyUnsupported (55),
inhibitAnyPolicyUnsupported (56),
validationTimeUnsupported (57),
unrecognizedCritQueryExt (63),
unrecognizedCritRequestExt (64) }
The CVStatusCode values have the following meaning:
CVStatusCode値の意味は以下のとおりです。
0 The request was fully processed. 1 The request included some unrecognized non-critical extensions; however, processing was able to continue ignoring them. 10 Too busy; try again later. 11 The server was able to decode the request, but there was some other problem with the request. 12 An internal server error occurred. 20 The structure of the request was wrong. 21 The version of request is not supported by this server. 22 The request included unrecognized items, and the server was not able to continue processing. 23 The server could not validate the key used to protect the request. 24 The signature or message authentication code did not match the body of the request. 25 The encoding was not understood. 26 The request was not authorized. 27 The request included unsupported checks items, and the server was not able to continue processing. 28 The request included unsupported wantBack items, and the server was not able to continue processing. 29 The server does not support the signature or message authentication code algorithm used by the client to protect the request. 30 The server could not validate the client's signature or message authentication code on the request. 31 The server could not generate a protected response as requested by the client. 32 The server does not have a certificate matching the requested responder name. 40 The request was previously relayed by the same server. 50 The request contained an unrecognized validation policy reference. 51 The request contained an unrecognized validation algorithm OID. 52 The server does not support returning the full request in the response.
0要求が完全に処理されました。 1要求は、いくつかの認識されていない非クリティカルな拡張機能が含まれ;しかし、処理はそれらを無視して継続することができました。 10あまりにも忙しいです。あとでもう一度試してみてください。 11サーバーは要求を解読することができましたが、要求に他のいくつかの問題がありました。 12内部サーバーエラーが発生しました。 20リクエストの構造が間違っていました。 21リクエストのバージョンは、このサーバーでサポートされていません。 22リクエストが認識されていない項目が含まれており、サーバは処理を継続することができませんでした。 23サーバーは要求を保護するために使用されるキーを検証することができませんでした。 24署名又はメッセージ認証コードは、要求の本体と一致しませんでした。 25符号化は理解されていませんでした。 26要求が承認されませんでした。 27リクエストがサポートされていないチェック項目が含まれており、サーバは処理を継続することができませんでした。 28リクエストがサポートされていないwantBack項目が含まれ、サーバは処理を継続することができませんでした。 29サーバは、要求を保護するために、クライアントによって使用される署名やメッセージ認証コードのアルゴリズムをサポートしていません。 30サーバは、リクエストに応じて、クライアントの署名やメッセージ認証コードを検証することができませんでした。クライアントが要求したとして31サーバーは、保護された応答を生成できませんでした。 32サーバは、要求された応答者名と一致する証明書を持っていません。 40要求は、以前に同じサーバーで中継されました。 50要求が認識されていない検証ポリシー参照を含んでいました。 51要求が認識されていない検証アルゴリズムのOIDを含んでいました。 52サーバが応答で完全な要求を返すことはできません。
53 The server does not support returning the full validation policy by value in the response. 54 The server does not support the requested value for inhibit policy mapping. 55 The server does not support the requested value for require explicit policy. 56 The server does not support the requested value for inhibit anyPolicy. 57 The server only validates requests using current time. 63 The query item in the request contains a critical extension whose OID is not recognized. 64 The request contains a critical request extension whose OID is not recognized.
53サーバが応答して値によって完全な検証ポリシーを返すことはできません。 54サーバは禁止ポリシーマッピングのために要求された値をサポートしていません。 55サーバは、明示的な政策が必要なため、要求された値をサポートしていません。 56サーバは禁止anyPolicyのために要求された値をサポートしていません。 57サーバは、現在の時刻を使用して要求を検証します。 63リクエストでクエリー項目は、そのOID認識されていないクリティカルな拡張機能が含まれています。 64要求は、そのOIDに認識されていない重要な要求拡張が含まれています。
Status codes 0-9 are reserved for codes that indicate the request was processed by the server and therefore MUST be sent in a success response. Status codes 10 and above indicate an error and MUST therefore be sent in an error response.
ステータスコード0-9は、成功応答を送らなければなりませんので、サーバーによって処理された要求を示すとコードのために予約されています。ステータスコード10と上記エラーを示し、したがって、エラー応答を送らなければなりません。
The respValidationPolicy item contains either a reference to the full validation policy or the full policy by value used by the server to validate the request. It MUST be present in success responses and MUST NOT be present in error responses. The choice between returning the policy by reference or by value is controlled by the responseValidationPolByRef item in the request. The resultant validation policy is the union of the following:
respValidationPolicy項目は、要求を検証するためにサーバによって使用される値によって完全検証ポリシーまたは完全ポリシーへの参照のいずれかを含みます。それは成功応答でなければならず、これはエラーレスポンスに存在してはなりません。参照することにより、または値によって、ポリシーを返すとの間の選択は、要求にresponseValidationPolByRef項目によって制御されます。結果検証ポリシーは、以下の労働組合です。
2. For values that are not explicitly included in the request, values from the validation policy specified by reference in the request.
明示的要求に含まれていない値について2は、要求が参照により指定された検証ポリシーからの値。
The RespValidationPolicy syntax is:
RespValidationPolicyの構文は次のとおりです。
RespValidationPolicy ::= ValidationPolicy
The validationPolicy item is defined in Section 3.2.4. When responseValidationPolByRef is set to FALSE in the request, all items in the validationPolicy item MUST be populated. When responseValidationPolByRef is set to TRUE, OPTIONAL items in the validationPolicy item only need to be populated for items for which the value in the request differs from the value from the referenced validation policy.
validationPolicy項目は、3.2.4項で定義されています。 responseValidationPolByRefがリクエストにFALSEに設定されている場合、validationPolicy項目内のすべての項目が取り込まれなければなりません。 responseValidationPolByRefがvalidationPolicy項目にTRUE、オプション項目に設定されている場合にのみ、要求の値が参照される検証ポリシーの値と異なるため項目に移入する必要があります。
Conforming SCVP clients MUST be capable of processing the validation policy by reference. SCVP clients MAY be capable of processing the optional items in the validation policy.
SCVPクライアントが準拠する基準によって検証ポリシーを処理できなければなりません。 SCVPクライアントは、検証ポリシーでオプション項目を処理することが可能です。
Conforming SCVP server implementations MUST be capable of asserting the policy by reference, and MUST be capable of including the optional items.
適合SCVPサーバ実装は、参照することによって、ポリシーをアサートすることができなければなりません、そして任意のアイテムを含むことができなければなりません。
The requestRef item allows the SCVP client to identify the request that corresponds to this response from the server. It associates the response to a particular request using either a hash of the request or a copy of CVRequest from the request.
requestRef項目はSCVPクライアントがサーバからこの応答に対応する要求を識別することができます。これは、リクエストからリクエストのハッシュまたはCVRequestのコピーのいずれかを使用して、特定の要求に対する応答を関連付けます。
The requestRef item does not provide authentication, but does allow the client to determine that the request was not maliciously modified.
requestRef項目は、認証を提供していませんが、クライアントが要求を悪意を持って変更されていないことを決定することができません。
The requestRef item allows the client to associate a response with a request. The requestNonce provides an alternative mechanism for matching requests and responses. When the fullRequest alternative is used, the response provides a single data structure that is suitable for archive of the transaction.
requestRef項目は、クライアントが要求と応答を関連付けることができます。 requestNonceは、要求と応答をマッチングするための代替メカニズムを提供します。 fullRequest代替を使用した場合、応答は、トランザクションのアーカイブするのに適した単一のデータ構造を提供します。
The requestRef item uses the RequestReference type, which has the following syntax:
requestRef項目は、次の構文を持っていRequestReference型を使用しています。
RequestReference ::= CHOICE {
requestHash [0] HashValue, -- hash of CVRequest
fullRequest [1] CVRequest }
SCVP clients MUST support requestHash, and they MAY support fullRequest. SCVP servers MUST support using requestHash, and they SHOULD support using fullRequest.
SCVPクライアントはrequestHashをサポートしなければならない、と彼らはfullRequestをサポートするかもしれません。 SCVPサーバは、requestHashを使用してサポートしなければならない、と彼らはfullRequestを使用してサポートすべきです。
The requestHash item is the hash of the CVRequest. The one-way hash function used to compute the hash of the CVRequest is as specified in Section 3.9. The requestHash item serves two purposes. First, it allows a client to determine that the request was not maliciously modified. Second, it allows the client to associate a response with a request when using connectionless protocols. The requestNonce provides an alternative mechanism for matching requests and responses.
requestHash項目はCVRequestのハッシュです。セクション3.9で指定されるようにCVRequestのハッシュを計算するために使用される一方向ハッシュ関数です。 requestHash項目は、2つの目的を果たします。まず、クライアントは、要求が不正に変更が加えられていなかったことを判断することができます。第二に、それはコネクションレスのプロトコルを使用している場合、クライアントは、要求と応答を関連付けることができます。 requestNonceは、要求と応答をマッチングするための代替メカニズムを提供します。
The requestHash item uses the HashValue type, which has the following syntax:
requestHash項目は、以下の構文を持っているハッシュ値の種類を、使用しています。
HashValue ::= SEQUENCE {
algorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 },
value OCTET STRING }
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It is repeated here for convenience.
SHA-1アルゴリズム識別子は[PKIX-ALG]からインポートされています。これは、便宜上、ここで繰り返されます。
Like requestHash, the fullRequest alternative allows a client to determine that the request was not maliciously modified. It also provides a single data structure that is suitable for archive of the transaction.
requestHashと同様に、fullRequestの代替は、クライアントが要求が不正に変更が加えられていなかったことを判断することができます。また、トランザクションのアーカイブに適しており、単一のデータ構造を提供します。
The fullRequest item uses the CVRequest type. The syntax and semantics of the CVRequest type are described in Section 3.
fullRequest項目はCVRequestタイプを使用しています。 CVRequestタイプの構文と意味論はセクション3で説明されています。
The optional requestorRef item is used by the client to identify the original requestor in cases where SCVP relay is used. The value is only of local significance to the client. If the SCVP client includes a requestorRef value in the request, then the SCVP server MUST return the same value if the server is generating a non-cached response.
任意requestorRef項目はSCVPリレーが使用される場合には、元の要求者を識別するためにクライアントによって使用されます。値は、クライアントにローカルな意義があります。 SCVPクライアントが要求でrequestorRef値が含まれている場合、サーバーが非キャッシュされた応答を生成している場合は、SCVPサーバは、同じ値を返さなければなりません。
The optional requestorName item is used by the server to return one or more identities associated with the client in the response.
オプションのrequestorName項目は応答して、クライアントに関連付けられた1つのまたは複数のIDを返すためにサーバーによって使用されます。
The SCVP server MAY choose to include any or all of the following:
SCVPサーバは、次のいずれかまたはすべてを含めるように選択できます。
(1) the identity asserted by the client in the requestorName item of the request,
（1）要求のrequestorName項目にクライアントによってアサートアイデンティティ、
(2) an authenticated identity for the client from a certificate or other credential used to authenticate the request, or
（2）要求を認証するために使用される証明書または他の資格情報からクライアントの認証されたアイデンティティを、または
(3) a client identifier from an out-of-band mechanism.
（3）アウトオブバンド機構からクライアント識別子。
Alternatively, the SCVP server MAY omit this item.
また、SCVPサーバは、この項目を省略することができます。
In the case of non-cached responses to authenticated requests, the SCVP server SHOULD return a requestor name.
認証された要求への非キャッシュの応答の場合は、SCVPサーバは、要求者の名前を返すべきです。
SCVP servers that support authenticated requests SHOULD support this item.
認証された要求をサポートするSCVPサーバはこのアイテムをサポートする必要があります。
SCVP clients MUST be able to process responses that include this item, although the item value might not impact the processing in any manner.
項目の値は任意の方法で処理に影響を与えないかもしれないがSCVPクライアントは、このアイテムを含む応答を処理できなければなりません。
The replyObjects item returns requested objects to the SCVP client, each of which tells the client about a single certificate from the request. The replyObjects item MUST be present in the response, unless the response is reporting an error. The CertReply item MUST contain cert, replyStatus, replyValTime, replyChecks, and replyWantBacks items, and the CertReply item MAY contain the validationErrors, nextUpdate, and certReplyExtensions items.
replyObjects項目のリターンは要求から単一の証明書についてクライアントに伝える、それぞれが、SCVPクライアントにオブジェクトを要求しました。応答がエラーを報告していない限りreplyObjects項目は、応答中に存在しなければなりません。 CertReply項目は証明書、replyStatus、replyValTime、replyChecks、およびreplyWantBacks項目を含まなければならない、とCertReply項目はによりvalidationErrors、nextUpdateの、およびcertReplyExtensions項目を含むかもしれません。
A success response MUST contain one CertReply for each certificate specified in the queriedCerts item in the request. The order is important. The first CertReply in the sequence MUST correspond to the first certificate in the request, the second CertReply in the sequence MUST correspond to the second certificate in the request, and so on.
成功応答を要求してqueriedCerts項目で指定された各証明書のための1 CertReplyを含まなければなりません。順序が重要です。シーケンスの最初CertReplyは、要求内の最初の証明書に対応している必要があり、シーケンス内の第二CertReplyのようにリクエストに第二の証明書に対応し、しなければなりません。
The checks item in the request determines the content of the replyChecks item in the response. The wantBack item in the request determines the content of the replyWantBacks item in the response. The queryExtensions items in the request controls the absence or the presence and content of the certReplyExtensions item in the response.
要求におけるチェック項目は、応答replyChecks項目の内容を決定します。要求にwantBack項目が応答replyWantBacks項目の内容を決定します。要求にqueryExtensions項目が存在しない又は応答certReplyExtensionsアイテムの存在及び内容を制御します。
The replyObjects item uses the ReplyObjects type, which has the following syntax:
replyObjects商品は、次の構文を持っていReplyObjects型を使用しています。
ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply
CertReply ::= SEQUENCE {
cert CertReference,
replyStatus ReplyStatus DEFAULT success,
replyValTime GeneralizedTime,
replyChecks ReplyChecks,
replyWantBacks ReplyWantBacks,
validationErrors [0] SEQUENCE SIZE (1..MAX) OF
OBJECT IDENTIFIER OPTIONAL,
nextUpdate [1] GeneralizedTime OPTIONAL,
certReplyExtensions [2] Extensions OPTIONAL }
The cert item contains either the certificate or a reference to the certificate about which the client is requesting information. If the certificate was specified by reference in the request, the request included either the id-swb-pkc-cert or id-swb-aa-cert wantBack, and the server was able to obtain the referenced certificate, then this item MUST include the certificate. Otherwise, this item MUST include the same value as was used in the queriedCerts item in the request.
CERT項目は、証明書またはクライアントが情報を要求しているかについての証明書への参照のいずれかを含みます。証明書が要求に参照により指定された場合、要求はID-SWB-PKC-CERTまたはID-SWB-AA-CERT wantBackのいずれかが含まれ、そしてサーバーが参照証明書を取得することができた場合、この項目は含まなければなりません証明書。そうでない場合、この項目は、要求にqueriedCerts項目で使用したのと同じ値を含まなければなりません。
CertReference has the following syntax:
CertReferenceの構文は次のとおりです。
CertReference ::= CHOICE {
pkc PKCReference,
ac ACReference }
The replyStatus item gives status information to the client about the request for the specific certificate. Note that the responseStatus item is different from the replyStatus item. The responseStatus item is the status of the whole request, while the replyStatus item is the status for the individual query item.
replyStatus項目は、特定の証明書の要求について、クライアントにステータス情報を提供します。 responseStatus項目がreplyStatus項目は異なることに注意してください。 replyStatus項目は、個々のクエリーアイテムのステータスである一方、responseStatus項目は、全体の要求の状態です。
The replyStatus item uses the ReplyStatus type, which has the following syntax:
replyStatus項目は、次の構文を持っていReplyStatus型を使用しています。
ReplyStatus ::= ENUMERATED {
success (0),
malformedPKC (1),
malformedAC (2),
unavailableValidationTime (3),
referenceCertHashFail (4),
certPathConstructFail (5),
certPathNotValid (6),
certPathNotValidNow (7),
wantBackUnsatisfied (8) }
The meanings of the various ReplyStatus values are:
様々なReplyStatus値の意味は以下のとおりです。
0 Success: all checks were performed successfully. 1 Failure: the public key certificate was malformed. 2 Failure: the attribute certificate was malformed. 3 Failure: historical data for the requested validation time is not available. 4 Failure: the server could not locate the reference certificate or the referenced certificate did not match the hash value provided. 5 Failure: no certification path could be constructed.
0成功：すべてのチェックが正常に行われました。 1つの失敗：公開鍵証明書が不正でした。 2失敗：属性証明書が不正な形式でした。 3失敗：要求された検証時間の履歴データは利用できません。 4失敗：サーバーが参照証明書または提供されたハッシュ値と一致しませんでした参照証明書を見つけることができませんでした。 5失敗：なし証明書パスを構築することができました。
6 Failure: the constructed certification path is not valid with respect to the validation policy. 7 Failure: the constructed certification path is not valid with respect to the validation policy, but a query at a later time may be successful. 8 Failure: all checks were performed successfully; however, one or more of the wantBacks could not be satisfied.
6失敗：構築証明書パス検証の方針に関しては有効ではありません。 7失敗：構築証明書パス検証の方針に関して有効ではありませんが、後でクエリが成功することがあります。 8失敗：すべてのチェックが正常に行われました。しかし、wantBacksの一つ以上を満足することができませんでした。
Codes 1 and 2 are used to tell the client that the request was properly formed, but the certificate in question was not. This is especially useful to clients that do not parse certificates.
コード1と2は、要求が正常に形成されたクライアントに通知するために使用されますが、問題の証明書がありませんでした。これは、証明書を解析していないクライアントに特に便利です。
Code 7 is used to tell the client that a valid certification path was found with the exception that a certificate in the path is on hold, current revocation information is unavailable, or the validation time precedes the notBefore time in one or more certificates in the path.
コード7は、有効な証明書パスがパス内の証明書が保留されていることを除いて発見されたことをクライアントに伝えるために使用され、現在の失効情報が利用できない、または検証時間がパスに1つ以上の証明書にnotBeforeの時間の前に。
For codes 1, 2, 3, and 4, the replyChecks and replyWantBacks items are not populated (i.e., they MUST be an empty sequence). For codes 5, 6, 7, and 8, replyChecks MUST include an entry corresponding to each check in the request; the replyWantBacks item is not populated.
コード1、2、3、4、replyChecksアイテムが取り込まれていないreplyWantBacksため（すなわち、それらが空のシーケンスでなければなりません）。符号5、6、7、および8では、replyChecksは要求内の各検査に対応するエントリを含まなければなりません。 replyWantBacks項目が移入されません。
The replyValTime item tells the time at which the information in the CertReply was correct. The replyValTime item represents the date and time in UTC, using GeneralizedTime type. The encoding rules for GeneralizedTime in Section 3.2.7 MUST be used.
replyValTime項目はCertReplyの情報が正しかった時刻を伝えます。 replyValTime項目はGeneralizedTimeのタイプを使用して、UTCの日付と時刻を表します。セクション3.2.7におけるGeneralizedTimeのための符号化規則を使用しなければなりません。
Within the request, the optional validationTime item tells the date and time relative to which the SCVP client wants the server to perform the checks. If the validationTime is not present, the server MUST respond as if the client provided the date and time at which the server processes the request.
要求の中で、オプションのvalidationTime項目はSCVPクライアントは、サーバがチェックを実行したいに日付と時刻の相対的に指示します。 validationTimeが存在しない場合、サーバーは、クライアントがサーバが要求を処理した日付と時間を提供しているかのように応答しなければなりません。
The information in the CertReply item MUST be formatted as if the server created this portion of the response at the time indicated in the validationTime item of the query. However, if the server does not have appropriate historical information, the server MAY either return an error or return information for a later time.
サーバがクエリのvalidationTime項目に示されている時の応答のこの部分を作成した場合のようCertReply項目の情報は、フォーマットする必要があります。サーバーが適切な履歴情報を持っていない場合は、サーバーは、いずれかのエラーを返すか、後でのための情報を返す可能性があります。
The replyChecks item contains the responses to the checks item in the query. The replyChecks item includes the object identifier (OID) from the query and an integer. The value of the integer indicates whether the requested check was successful. The OIDs in the checks item of the query are used to identify the corresponding replyChecks values. Each OID specified in the checks item in the request MUST be matched by an OID in the replyChecks item of the response. In the case of an error response, the server MAY include additional checks in the response to further explain the error. Clients MUST ignore any unrecognized ReplyCheck included in the response.
replyChecks項目は、クエリ内のチェック項目への応答が含まれています。 replyChecks項目は、クエリと整数からオブジェクト識別子（OID）を含みます。整数の値は、要求されたチェックが成功したかどうかを示します。クエリのチェック項目に対応するOIDはreplyChecks値を識別するために使用されます。要求にチェック項目で指定された各OIDは、応答のreplyChecks項目にOIDによって整合されなければなりません。エラー応答の場合には、サーバは、さらに、エラーを説明するために応じて追加の検査を含むかもしれません。クライアントは応答に含まれ、認識されないReplyCheckを無視しなければなりません。
The replyChecks item uses the ReplyChecks type, which has the following syntax:
replyChecks商品は、次の構文を持っていReplyChecks型を使用しています。
ReplyChecks ::= SEQUENCE OF ReplyCheck
ReplyCheck ::= SEQUENCE {
check OBJECT IDENTIFIER,
status INTEGER DEFAULT 0 }
The status value for public key certification path building to a trusted root, { id-stc 1 }, can be one of the following:
信頼されたルートの公開鍵認証パス構築のための状態値、{ID-STC 1}は、以下のいずれかとすることができます。
0: Built a path 1: Could not build a path
0：パスを構築することができませんでした：パス1を内蔵
The status value for public key certification path building to a trusted root along with simple validation processing, { id-stc 2 }, can be one of the following:
単純な検証処理、{ID-STC 2}と一緒に信頼されたルートの公開鍵認証パス構築のステータス値は、次のいずれかとすることができます。
0: Valid 1: Not valid
0：有効1：無効です
The status value for public key certification path building to a trusted root along with complete status checking, { id-stc 3 }, can be one of the following:
完全ステータス・チェックとともに信頼されたルートの公開鍵認証パス構築のための状態値、{ID-STC 3}は、以下のいずれかとすることができます。
0: Valid 1: Not valid 2: Revocation off-line 3: Revocation unavailable 4: No known source for revocation information
0：有効1：有効ていない2：失効はオフライン3：失効利用できない4：失効情報については知られていないソース
Revocation off-line means that the server or distribution point for the revocation information was connected to successfully without a network error but either no data was returned or if data was returned it was stale. Revocation unavailable means that a network error was returned when an attempt was made to reach the server or distribution point. No known source for revocation information means that the server was able to build a valid certification path but was unable to locate a source for revocation information for one or more certificates in the path.
オフラインの失効は、失効情報のためのサーバーまたは配布ポイントは、ネットワークエラーなしに正常に接続されていたが、何のデータのいずれかが返されなかったか、データが返された場合、それが古くなったことを意味します。使用できない失効は、試行がサーバーまたは配布ポイントに到達するためになされたときにネットワークエラーが返されたことを意味します。失効情報に対する既知のソースは、サーバーが有効な証明書パスを構築することができましたが、パス内の1つまたは複数の証明書の失効情報のソースを見つけることができなかったことを意味しません。
The status value for AC issuer certification path building to a trusted root, { id-stc 4 }, can be one of the following:
信頼されたルートにAC発行者の認証パス構築のための状態値、{ID-STC 4}は、以下のいずれかとすることができます。
0: Built a path 1: Could not build a path
0：パスを構築することができませんでした：パス1を内蔵
The status value for AC issuer certification path building to a trusted root along with simple validation processing, { id-stc 5 }, can be one of the following:
単純な検証処理、{ID-STC 5}と一緒に信頼されたルートにAC発行者の認証パス構築のステータス値は、次のいずれかとすることができます。
0: Valid 1: Not valid
0：有効1：無効です
The status value for AC issuer certification path building to a trusted root along with complete status checking, { id-stc 6 }, can be one of the following:
完全ステータス・チェックとともに、信頼されたルートにAC発行者の認証パス構築のステータス値は、{ID-STC 6}は、以下のいずれかとすることができます。
0: Valid 1: Not valid 2: Revocation off-line 3: Revocation unavailable 4: No known source for revocation information
0：有効1：有効ていない2：失効はオフライン3：失効利用できない4：失効情報については知られていないソース
The status value for revocation status checking of an AC as well as AC issuer certification path building to a trusted root along with complete status checking, { id-stc 7 }, can be one of the following:
完全ステータス・チェックとともに、信頼されたルートにACの失効ステータスのチェック、並びにAC発行者の認証パス構築、{ID-STC 7}のステータス値は、次のいずれかとすることができます。
0: Valid 1: Not valid 2: Revocation off-line 3: Revocation unavailable 4: No known source for revocation information
0：有効1：有効ていない2：失効はオフライン3：失効利用できない4：失効情報については知られていないソース
The replyWantBacks item contains the responses to the wantBack item in the request. The replyWantBacks item includes the object identifier (OID) from the wantBack item in the request and an OCTET STRING. Within the OCTET STRING is the requested value. The OIDs in the wantBack item in the request are used to identify the corresponding reply value. The OIDs in the replyWantBacks item MUST match the OIDs in the wantBack item in the request. For a non-error response, replyWantBacks MUST include exactly one ReplyWantBack for each wantBack specified in the request (excluding id-swb-pkc-cert and id-swb-ac-cert, where the requested information is included in the cert item).
replyWantBacks項目は、要求にwantBack項目への応答が含まれています。 replyWantBacks項目は、要求にwantBack項目とOCTET文字列からオブジェクト識別子（OID）を含みます。オクテット文字列の中で要求された値です。要求にwantBackアイテム内のOIDは、対応する応答値を識別するために使用されます。 replyWantBacksアイテム内のOIDは、要求にwantBack項目内のOIDと一致しなければなりません。非エラー応答のために、replyWantBacksリクエストで指定された各wantBackための正確に一つReplyWantBackを含まなければなりません（ID-SWB-PKC-CERT及び要求された情報は、証明書の項目に含まれているID-SWB-AC-CERTを除きます）。
The replyWantBacks item uses the ReplyWantBacks type, which has the following syntax:
replyWantBacks商品は、次の構文を持っていReplyWantBacks型を使用しています。
ReplyWantBacks ::= SEQUENCE OF ReplyWantBack
ReplyWantBack::= SEQUENCE {
wb OBJECT IDENTIFIER,
value OCTET STRING }
The OCTET STRING value for the certification path used to verify the certificate in the request, { id-swb 1 }, contains the CertBundle type. The syntax and semantics of the CertBundle type are described in Section 3.2.8. This CertBundle includes all the certificates in the path, starting with the end certificate and ending with the certificate issued by the trust anchor.
リクエスト、{ID-SWB 1}で証明書を検証するために使用される証明書パスのためのOCTET STRINGの値は、CertBundleタイプを含みます。 CertBundleタイプの構文と意味論はセクション3.2.8で説明されています。このCertBundleは終了証明書で始まり、トラストアンカーによって発行された証明書で終わる、パス内のすべての証明書が含まれています。
The OCTET STRING value for the proof of revocation status, { id-swb 2 }, contains the RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the RevocationInfos type and an optional CertBundle. The syntax and semantics of the RevocationInfos type are described in Section 3.2.9. The CertBundle MUST be included if any certificates required to validate the revocation information were not returned in the id-swb-pkc-best-cert-path or id-swb-pkc-all-cert-paths wantBack. The CertBundle MUST include all such certificates, but there are no ordering requirements.
失効状態、{ID-SWB 2}の証明のためのOCTET STRINGの値は、RevInfoWantBackタイプを含んでいます。 RevInfoWantBack型はRevocationInfosタイプおよび任意CertBundleの配列です。 RevocationInfosタイプの構文と意味論はセクション3.2.9で説明されています。失効情報を検証するために必要な証明書がID-SWB-PKC-最良-CERT-パスに返さまたはID-SWB-PKC-全て-CERT-パスwantBackなかった場合CertBundleを含まなければなりません。 CertBundleは、そのようなすべての証明書を含める必要がありますが、何の注文要件はありません。
RevInfoWantBack ::= SEQUENCE {
revocationInfo RevocationInfos,
extraCerts CertBundle OPTIONAL }
The OCTET STRING value for the public key information, { id-swb 4 }, contains the SubjectPublicKeyInfo type. The syntax and semantics of the SubjectPublicKeyInfo type are described in [PKIX-1].
公開鍵情報のためのOCTET STRINGの値は、{ID-SWB 4}は、SubjectPublicKeyInfoでタイプを含んでいます。 SubjectPublicKeyInfoでタイプの構文及び意味論は[PKIX-1]に記載されています。
The OCTET STRING value for the AC issuer certification path used to verify the certificate in the request, { id-swb 5 }, contains the CertBundle type. The syntax and semantics of the CertBundle type are described in Section 3.2.8. This CertBundle includes all the certificates in the path, beginning with the AC issuer certificate and ending with the certificate issued by the trust anchor.
リクエスト、{ID-SWB 5}で証明書を検証するために使用されるAC発行者認証パスのOCTET STRINGの値は、CertBundleタイプを含みます。 CertBundleタイプの構文と意味論はセクション3.2.8で説明されています。このCertBundleはACの発行者証明書で始まり、トラストアンカーによって発行された証明書で終わる、パス内のすべての証明書が含まれています。
The OCTET STRING value for the proof of revocation status of the AC issuer certification path, { id-swb 6 }, contains the RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the RevocationInfos type and an optional CertBundle. The syntax and semantics of the RevocationInfos type are described in Section 3.2.9. The CertBundle
AC発行者認証パスの取消し状態の証拠のためのOCTET STRING値は、{ID-SWB 6}は、RevInfoWantBackタイプを含んでいます。 RevInfoWantBack型はRevocationInfosタイプおよび任意CertBundleの配列です。 RevocationInfosタイプの構文と意味論はセクション3.2.9で説明されています。 CertBundle
MUST be included if any certificates required to validate the revocation information were not returned in the id-aa-cert-path wantBack. The CertBundle MUST include all such certificates, but there are no ordering requirements.
失効情報を検証するために必要な証明書がID-AA-CERT-パスwantBackに返されなかった場合に含まれなければなりません。 CertBundleは、そのようなすべての証明書を含める必要がありますが、何の注文要件はありません。
The OCTET STRING value for the proof of revocation status of the attribute certificate, { id-swb 7 }, contains the RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the RevocationInfos type and an optional CertBundle. The syntax and semantics of the RevocationInfos type are described in Section 3.2.9. The CertBundle MUST be included if any certificates required to validate the revocation information were not returned in the id-swb-aa-cert-path wantBack. The CertBundle MUST include all such certificates, but there are no ordering requirements.
属性証明書の失効ステータスの証明のためのOCTET STRINGの値は、{ID-SWB 7}は、RevInfoWantBackタイプを含んでいます。 RevInfoWantBack型はRevocationInfosタイプおよび任意CertBundleの配列です。 RevocationInfosタイプの構文と意味論はセクション3.2.9で説明されています。失効情報を検証するために必要な証明書がID-SWB-AA-CERT-パスwantBackに返されなかった場合CertBundleを含まなければなりません。 CertBundleは、そのようなすべての証明書を含める必要がありますが、何の注文要件はありません。
The OCTET STRING value for returning all paths, { id-swb 12 }, contains an ASN.1 type CertBundles, as defined below. The syntax and semantics of the CertBundle type are described in Section 3.2.8. Each CertBundle includes all the certificates in one path, starting with the end certificate and ending with the certificate issued by the trust anchor.
以下に定義されるすべてのパスを戻すためのOCTET STRINGの値は、{ID-SWB 12}は、ASN.1型CertBundlesを含有します。 CertBundleタイプの構文と意味論はセクション3.2.8で説明されています。各CertBundleは終了証明書で始まり、トラストアンカーによって発行された証明書で終わる、1つのパス内のすべての証明書が含まれています。
CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle
The OCTET STRING value for relayed responses, { id-swb 9 }, contains an ASN.1 type SCVPResponses, as defined below. If the SCVP server used information obtained from other SCVP servers when generating this response, then SCVPResponses MUST include each of the SCVP responses received from those servers. If the SCVP server did not use information obtained from other SCVP servers when generating the response, then SCVPResponses MUST be an empty sequence.
以下に定義されるように中継された応答、{ID-SWB 9}のOCTET STRINGの値は、ASN.1型SCVPResponsesを含有します。この応答を生成する際に、他のSCVPサーバから取得したSCVPサーバ使用情報場合、SCVPResponsesがそれらのサーバから受信したSCVP応答のそれぞれを含まなければなりません。 SCVPサーバが応答を生成するときに、他のSCVPサーバから取得した情報を使用しなかった場合は、SCVPResponsesは空のシーケンスでなければなりません。
SCVPResponses ::= SEQUENCE OF ContentInfo
The OCTET STRING value for the proof of revocation status of the path's target certificate, { id-swb-13 }, contains the RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the RevocationInfos type and an optional CertBundle. The syntax and semantics of the RevocationInfos type are described in Section 3.2.9. The CertBundle MUST be included if any certificates required to validate the revocation information were not returned in the id-swb-pkc-best-cert-path or id-swb-pkc-all-cert-paths wantBack. The CertBundle MUST include all such certificates, but there are no ordering requirements.
パスの対象証明書の失効ステータスの証明のためのOCTET STRINGの値は、{ID-SWB-13}、RevInfoWantBackタイプを含んでいます。 RevInfoWantBack型はRevocationInfosタイプおよび任意CertBundleの配列です。 RevocationInfosタイプの構文と意味論はセクション3.2.9で説明されています。失効情報を検証するために必要な証明書がID-SWB-PKC-最良-CERT-パスに返さまたはID-SWB-PKC-全て-CERT-パスwantBackなかった場合CertBundleを含まなければなりません。 CertBundleは、そのようなすべての証明書を含める必要がありますが、何の注文要件はありません。
The OCTET STRING value for the proof of revocation status of the intermediate certificates in the path, { id-swb 14 }, contains the RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the
パス内の中間証明書の失効ステータスの証明のためのOCTET STRINGの値は、{ID-SWB 14}は、RevInfoWantBackタイプを含んでいます。 RevInfoWantBackタイプは、一連のです
RevocationInfos type and an optional CertBundle. The syntax and semantics of the RevocationInfos type are described in Section 3.2.9. The CertBundle MUST be included if any certificates required to validate the revocation information were not returned in the id-swb-pkc-best-cert-path or id-swb-pkc-all-cert-paths wantBack. The CertBundle MUST include all such certificates, but there are no ordering requirements.
RevocationInfosタイプとオプションのCertBundle。 RevocationInfosタイプの構文と意味論はセクション3.2.9で説明されています。失効情報を検証するために必要な証明書がID-SWB-PKC-最良-CERT-パスに返さまたはID-SWB-PKC-全て-CERT-パスwantBackなかった場合CertBundleを含まなければなりません。 CertBundleは、そのようなすべての証明書を含める必要がありますが、何の注文要件はありません。
The validationErrors item MUST only be present in failure responses. If present, it MUST contain one or more OIDs representing the reason the validation failed (validation errors for the basic validation algorithm and name validation algorithm are defined in Sections 3.2.4.2.2 and 3.2.4.2.4). The validationErrors item SHOULD only be included when the replyStatus is 3, 5, 6, 7, or 8. SCVP servers are not required to specify all of the reasons that validation failed. SCVP clients MUST NOT assume that the OIDs included in validationErrors represent all of the validation errors for the certification path.
validationErrors項目は唯一の失敗応答中に存在しなければなりません。存在する場合、それは検証が失敗した理由（基本的な検証アルゴリズムと名の検証アルゴリズムの検証エラーがセクション3.2.4.2.2および3.2.4.2.4に定義されている）を表す1つの以上のOIDを含まなければなりません。 replyStatus 3、5、6、7、または8 SCVPサーバは、検証が失敗したことを理由のすべてを指定する必要はありませんである場合によりvalidationErrorsアイテムのみ含まれるべきです。 SCVPクライアントはOIDがによりvalidationErrorsに含まと仮定してはいけません証明書パスの検証エラーのすべてを表しています。
The nextUpdate item tells the time at which the server expects a refresh of information regarding the validity of the certificate to become available. The nextUpdate item is especially interesting if the certificate revocation status information is not available or the certificate is suspended. The nextUpdate item represents the date and time in UTC, using the GeneralizedTime type. The encoding rules for GeneralizedTime in Section 3.2.7 MUST be used.
nextUpdateの項目は、サーバーが証明書の有効性に関する情報の更新が利用可能になることを期待した時刻を伝えます。証明書の失効状態情報が利用できない場合、または証明書が中断された場合にnextUpdateの項目は特に興味深いものです。 nextUpdateの項目は、GeneralizedTimeのタイプを使用して、UTCの日付と時刻を表します。セクション3.2.7におけるGeneralizedTimeのための符号化規則を使用しなければなりません。
The certReplyExtensions item contains the responses to the queryExtensions item in the request. The certReplyExtensions item uses the Extensions type defined in [PKIX-1]. The object identifiers (OIDs) in the queryExtensions item in the request are used to identify the corresponding reply values. The certReplyExtensions item, when present, contains a sequence of Extension items, each of which contains an extnID item, a critical item, and an extnValue item.
certReplyExtensions項目は、要求にqueryExtensions項目への応答が含まれています。 certReplyExtensionsアイテムは[PKIX-1]で定義された拡張タイプを使用します。要求にqueryExtensions項目のオブジェクト識別子（OID）は、対応する応答値を識別するために使用されます。 certReplyExtensionsアイテムは、存在する場合、extnID項目、重要な項目、およびextnValue項目を含むそれぞれが拡張アイテムの配列を含みます。
The extnID item is an identifier for the extension. It contains the OID that names the extension, and it MUST match one of the OIDs in the queryExtensions item in the request.
extnID項目は、拡張のための識別子です。これは、その名の拡張子OIDが含まれており、その要求でqueryExtensions項目でのOIDのいずれかと一致しなければなりません。
The critical item is a BOOLEAN, and it MUST be set to FALSE.
重要な項目はBOOLEANであり、それはfalseに設定する必要があります。
The extnValue item contains an OCTET STRING. Within the OCTET STRING is the extension value. An ASN.1 type is specified for each extension, identified by the associated extnID object identifier.
extnValue項目はオクテット文字列が含まれています。オクテット文字列内の拡張値です。 ASN.1タイプは関連extnIDオブジェクト識別子によって識別された各拡張、指定されています。
The respNonce item contains an identifier to bind the request to the response.
respNonce項目は、応答への要求をバインドするための識別子が含まれています。
If the client includes a requestNonce value in the request and the server is generating a specific non-cached response to the request then the server MUST return the same value in the response.
クライアントが要求でrequestNonce値が含まれており、サーバが要求に特定の非キャッシュされた応答を生成している場合は、サーバが応答して同じ値を返さなければなりません。
If the server is using a cached response to the request then it MUST omit the respNonce item.
サーバが要求にキャッシュされた応答を使用している場合、それはrespNonce項目を省略しなければなりません。
If the server is returning a specific non-cached response to a request without a nonce, then the server MAY include a message-specific nonce. For digitally signed messages, the server MAY use the value of the message-digest attribute in the signedAttrs within SignerInfo of the request as the value in the respNonce item.
サーバーは、ナンスなしで要求に特定の非キャッシュされた応答を返している場合、サーバは、メッセージ固有のnonceを含むかもしれません。デジタル署名されたメッセージの場合、サーバはrespNonce項目の値として要求の内のSignerInfo signedAttrsにおけるメッセージダイジェスト属性の値を使用することができます。
The requestNonce item uses the OCTET STRING type.
requestNonce項目は、オクテット文字列タイプを使用しています。
Conforming client implementations MUST be able to process a response that includes this item. Conforming servers MUST support respNonce.
クライアント実装を準拠することは、この項目を含む応答を処理できなければなりません。準拠のサーバーはrespNonceをサポートしなければなりません。
The serverContextInfo item in a response is a mechanism for the server to pass some opaque context information to the client. If the client does not like the certification path returned, it can make a new query and pass along this context information.
応答でserverContextInfo項目は、クライアントにいくつかの不透明なコンテキスト情報を渡すためのサーバーのメカニズムです。クライアントは、返された証明書パスを好まない場合は、新しいクエリを作成し、このコンテキスト情報に沿って渡すことができます。
Section 3.2.6 contains information about the client's usage of this item.
3.2.6は、この項目のクライアントの使用状況に関する情報が含まれています。
The context information is opaque to the client, but it provides information to the server that ensures that a different certification path will be returned (if another one can be found). The context information could indicate the state of the server, or it could contain a sequence of hashes of certification paths that have already been returned to the client. The protocol does not dictate any structure or requirements for this item. However, implementers should review the Security Considerations section of this document before selecting a structure.
コンテキスト情報は、クライアントには不透明であるが、それは（別の1を見つけることができるならば）別の証明書パスが返されることを保証し、サーバーに情報を提供します。コンテキスト情報は、サーバの状態を示している可能性があり、またはそれはすでにクライアントに返された証明書パスのハッシュの配列を含むことができます。プロトコルは、この項目の任意の構造や要件を規定していません。しかし、実装者は構造を選択する前に、このドキュメントのSecurity Considerations部を確認してください。
Servers that are incapable of returning additional paths MUST NOT include the serverContextInfo item in the response.
追加のパスを返すことができないサーバーが応答してserverContextInfo項目を含んではいけません。
If present, the cvResponseExtensions item contains a sequence of extensions that extend the response. This specification does not define any extensions. The facility is provided to allow future specifications to extend SCVP. The syntax for Extensions is imported from [PKIX-1]. The cvResponseExtensions item, when present, contains a sequence of Extension items, each of which contains an extnID item, a critical item, and an extnValue item.
存在する場合、cvResponseExtensions項目が応答を拡張するエクステンションのシーケンスが含まれています。この仕様は、任意の拡張子を定義していません。施設は、将来の仕様がSCVPを拡張できるようにするために提供されます。拡張のための構文は[PKIX-1]からインポートされます。 cvResponseExtensions項目は、存在する場合、extnID項目、重要な項目、およびextnValue項目を含むそれぞれが拡張アイテムの配列を含みます。
The extnID item is an identifier for the extension. It contains the object identifier (OID) that names the extension.
extnID項目は、拡張のための識別子です。これは、その名の拡張子オブジェクト識別子（OID）が含まれています。
The critical item is a BOOLEAN. Each extension is designated as either critical (with a value of TRUE) or non-critical (with a value of FALSE). An SCVP client MUST reject the response if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized.
重要な項目がBOOLEANです。各拡張は（FALSEの値を有する）（TRUEの値を有する）クリティカルまたは非クリティカルのいずれかとして指定されます。それはそれは認識していない重要な拡張が発生した場合SCVPクライアントが応答を拒絶しなければなりません。それが認識されない場合が、非クリティカルな拡張は無視されるかもしれません。
The extnValue item contains an OCTET STRING. Within the OCTET STRING is the extension value. An ASN.1 type is specified for each extension, identified by the associated extnID object identifier.
extnValue項目はオクテット文字列が含まれています。オクテット文字列内の拡張値です。 ASN.1タイプは関連extnIDオブジェクト識別子によって識別された各拡張、指定されています。
The requestorText item contains a text field supplied by the client.
requestorText項目は、クライアントによって提供されるテキストフィールドが含まれています。
If the client includes a requestorText value in the request and the server is generating a specific non-cached response to the request, then the server MUST return the same value in the response.
クライアントが要求でrequestorText値が含まれており、サーバが要求に特定の非キャッシュされた応答を生成している場合、サーバーは応答して同じ値を返さなければなりません。
If the server is using a cached response to the request, then it MUST omit the requestorText item.
サーバが要求にキャッシュされた応答を使用している場合、それはrequestorText項目を省略しなければなりません。
The requestNonce item uses the UTF8 string type.
requestNonce項目は、UTF8の文字列型を使用しています。
Conforming client implementations that support the requestorText item in requests (see Section 3.10) MUST be able to process a response that includes this item. Conforming servers MUST support requestorText in responses.
（3.10節を参照）の要求にrequestorText項目をサポートするクライアント実装を準拠することは、この項目を含む応答を処理できなければなりません。準拠のサーバーが応答でrequestorTextをサポートしなければなりません。
There are two mechanisms for validation of SCVP responses, one based on the client's knowledge of a specific SCVP server key and the other based on validation of the certificate corresponding to the private key used to protect the SCVP response.
SCVP応答の検証のための2つのメカニズム、SCVP応答を保護するために使用される秘密鍵に対応する証明書の検証に基づいて特定のSCVPサーバキーと他のクライアントの知識に基づくものがあります。
The simple key validation method is where the SCVP client has a local policy of one or more SCVP server keys that directly identify the set of valid SCVP servers. Mechanisms for storage of server keys or identifiers are a local matter. For example, a client could store cryptographic hashes of public keys used to verify SignedData responses. Alternatively, a client could store shared symmetric keys used to verify MACs in AuthenticatedData responses.
SCVPクライアントが直接、有効なSCVPサーバのセットを識別する1つ以上のSCVPサーバキーのローカルポリシーを有する場合、簡単なキーの検証方法があります。サーバーキーまたは識別子を格納するためのメカニズムは、ローカルの問題です。例えば、クライアントはSignedDataの応答を検証するために使用される公開鍵の暗号化ハッシュを格納することができます。また、クライアントはAuthenticatedData応答でMACを検証するために使用される共有対称鍵を格納することができます。
Simple key validation MUST be used by SCVP clients that cannot validate PKIX-1 certificates and are therefore making delegated path validation requests to the SCVP server [RQMTS]. It is a matter of local policy with these clients whether to use SignedData or AuthenticatedData. Simple key validation MAY be used by other SCVP clients for other reasons.
シンプルなキー検証はPKIX-1証明書を検証することはできませんので、[RQMTS] SCVPサーバに委任パス検証要求を行っている。SCVPクライアントによって使用されなければなりませんそれはのSignedDataかAuthenticatedDataを使用するかどうか、これらのクライアントのローカルポリシーの問題です。シンプルなキーの検証は、他の理由のために他のSCVPクライアントによって使用されるかもしれません。
It is a matter of local policy what validation policy the client uses when validating responses. When validating protected SCVP responses, SCVP clients SHOULD use the validation algorithm defined in Section 6 of [PKIX-1]. SCVP clients may impose additional limitations on the algorithm, such as limiting the number of certificates in the path or establishing initial name constraints, as specified in Section 6.2 of [PKIX-1].
これは、応答を検証するときに、クライアントが使用するものを検証ポリシーローカルポリシーの問題です。保護されたSCVP応答を検証するとき、SCVPクライアントは[PKIX-1]のセクション6で定義された検証アルゴリズムを使用すべきです。 [PKIX-1]のセクション6.2で指定されるようにSCVPクライアントは、そのような経路に証明書の数を制限するか、最初の名前制約を確立するように、アルゴリズムに追加の制限を課すことができます。
If the certificate used to sign the validation policy responses and SignedData validation responses contains the key usage extension ([PKIX-1], Section 4.2.1.3), it MUST have either the digital signature bit set, the non-repudiation bit set, or both bits set.
証明書検証ポリシーの応答に署名するために使用されるとのSignedData検証応答は、鍵使用拡張（[PKIX-1]、セクション4.2.1.3）が含まれ、それはデジタル署名ビットセット、否認防止ビットのセットのいずれかを持っている必要がある場合、または両方のビットがセット。
If the certificate for AuthenticatedData validation responses contains the key usage extension, it MUST have the key agreement bit set.
AuthenticatedData検証応答のための証明書が鍵用途拡張が含まれている場合は、キー合意ビットを設定する必要があります。
If the certificate used on a validation policy response or a validation response contains the extended key usage extension ([PKIX-1], Section 4.2.1.13), it MUST contain either the anyExtendedKeyUsage OID or the following OID:
検証ポリシー応答又は確認応答に使用される証明書は、拡張鍵使用拡張（[PKIX-1]、セクション4.2.1.13）が含まれている場合、それはanyExtendedKeyUsage OID以下OIDのいずれかを含まなければなりません。
id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 }
An SCVP client uses the ValPolRequest item to request information about an SCVP server's policies and configuration information, including the list of validation policies supported by the SCVP server. When a ValPolRequest is encapsulated in a MIME body part, it MUST be carried in an application/scvp-vp-request MIME body part.
SCVPクライアントはSCVPサーバでサポートされている検証ポリシーのリストを含むSCVPサーバのポリシーと設定情報、情報を要求するためにValPolRequestアイテムを使用しています。 ValPolRequestはMIME本体部分内にカプセル化されている場合、それはアプリケーション/ SCVP-VP-要求MIMEボディ部に実行されなければなりません。
The request consists of a ValPolRequest encapsulated in a ContentInfo. The client does not sign the request.
リクエストはContentInfoでカプセル化ValPolRequestで構成されています。クライアントが要求に署名しません。
ContentInfo { contentType id-ct-scvp-valPolRequest, -- (1.2.840.113549.1.9.16.1.12) content ValPolRequest }
ContentInfo {contentTypeのID-CT-SCVP-valPolRequest、 - （1.2.840.113549.1.9.16.1.12）コンテンツValPolRequest}
The ValPolRequest type has the following syntax:
ValPolRequestタイプの構文は次のとおりです。
ValPolRequest ::= SEQUENCE {
vpRequestVersion INTEGER DEFAULT 1,
requestNonce OCTET STRING }
Conforming SCVP server implementations MUST recognize and process the server policy request. Conforming clients SHOULD support the server policy request.
準拠SCVPサーバの実装は、サーバポリシー要求を認識し、処理しなければなりません。準拠クライアントは、サーバポリシー要求をサポートする必要があります。
The syntax and semantics of vpRequestVersion are the same as cvRequestVersion as described in Section 3.1.
vpRequestVersionの構文と意味論はセクション3.1で説明したようにcvRequestVersionと同じです。
The requestNonce item contains a request identifier generated by the SCVP client. If the server returns a specific response, it MUST include the requestNonce from the request in the response, but the server MAY return a cached response, which MUST NOT include a requestNonce.
requestNonce項目はSCVPクライアントによって生成された要求識別子が含まれています。サーバが特定の応答を返した場合、それが応答でリクエストからrequestNonceを含まなければならないが、サーバーはrequestNonceを含んではいけません、キャッシュされた応答を、返してもよいです。
In response to a ValPolRequest, the SCVP server provides a ValPolResponse. The ValPolResponse may not be unique to any ValPolRequest, so may be reused by the server in response to multiple ValPolRequests. The ValPolResponse also has an indication of how frequently the ValPolResponse may be reissued. The server MUST sign the response using its digital signature certificate. When a ValPolResponse is encapsulated in a MIME body part, it MUST be carried in an application/scvp-vp-response MIME body part.
ValPolRequestに応じて、SCVPサーバはValPolResponseを提供します。 ValPolResponseはどのValPolRequestに固有ではないかもしれないので、複数ValPolRequestsに応じてサーバによって再利用することができます。 ValPolResponseもValPolResponseを再発行することができる頻度の指標を有しています。サーバは、そのデジタル署名証明書を使用して応答に署名しなければなりません。 ValPolResponseはMIME本体部分内にカプセル化されている場合、それはアプリケーション/ SCVP-VP-応答MIMEボディ部に実行されなければなりません。
The response consists of a ValPolResponse encapsulated in a SignedData, which is in turn encapsulated in a ContentInfo. That is, the EncapsulatedContentInfo field of SignedData consists of an eContentType field with a value of id-ct-scvp-valPolResponse (1.2.840.113549.1.9.16.1.13) and an eContent field that contains a DER-encoded ValPolResponse. The SCVP server MUST include its own certificate in the certificates field within SignedData, and the signerInfos field of SignedData MUST include exactly one SignerInfo. The SignedData MUST NOT include the unsignedAttrs field.
応答は、順番にContentInfo中に封入されているのSignedData、中に封入ValPolResponseから成ります。すなわち、のSignedDataのEncapsulatedContentInfoフィールドは、ID-CT-SCVP-valPolResponse（1.2.840.113549.1.9.16.1.13）とDERエンコードValPolResponseが含まe-コンテンツフィールドの値とのeContentTypeフィールドから成ります。 SCVPサーバはSignedDataの中に、証明書の分野で独自の証明書を含まなければならない、とのSignedDataのsignerInfosフィールドは正確に一つのSignerInfoを含まなければなりません。 SignedDataはunsignedAttrsフィールドを含んではいけません。
The ValPolResponse type has the following syntax:
ValPolResponseタイプの構文は次のとおりです。
ValPolResponse ::= SEQUENCE {
vpResponseVersion INTEGER,
maxCVRequestVersion INTEGER,
maxVPRequestVersion INTEGER,
serverConfigurationID INTEGER,
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime OPTIONAL,
supportedChecks CertChecks,
supportedWantBacks WantBack,
validationPolicies SEQUENCE OF OBJECT IDENTIFIER,
validationAlgs SEQUENCE OF OBJECT IDENTIFIER,
authPolicies SEQUENCE OF AuthPolicy,
responseTypes ResponseTypes,
defaultPolicyValues RespValidationPolicy,
revocationInfoTypes RevocationInfoTypes,
signatureGeneration SEQUENCE OF AlgorithmIdentifier,
signatureVerification SEQUENCE OF AlgorithmIdentifier,
hashAlgorithms SEQUENCE SIZE (1..MAX) OF
OBJECT IDENTIFIER,
serverPublicKeys SEQUENCE OF KeyAgreePublicKey
OPTIONAL,
clockSkew INTEGER DEFAULT 10,
requestNonce OCTET STRING OPTIONAL }
ResponseTypes ::= ENUMERATED {
cached-only (0),
non-cached-only (1),
cached-and-non-cached (2) }
RevocationInfoTypes ::= BIT STRING {
fullCRLs (0),
deltaCRLs (1),
indirectCRLs (2),
oCSPResponses (3) }
SCVP clients that support validation policy requests MUST support validation policy responses. SCVP servers MUST support validation policy responses.
検証ポリシー要求をサポートするSCVPクライアントは検証政策対応をサポートしなければなりません。 SCVPサーバは、検証政策対応をサポートしなければなりません。
SCVP servers MUST support cached policy responses and MAY support specific responses to policy requests.
SCVPサーバは、キャッシュされた政策対応をサポートしなければならないし、政策要求への特定の応答をサポートするかもしれません。
The syntax and semantics of the vpResponseVersion item are the same as cvRequestVersion as described in Section 3.1. The vpResponseVersion used MUST be the same as the vpRequestVersion unless the client has used a value greater than the values the server supports. If the client submits a vpRequestVersion greater than the version supported by the server, the server MUST return a vpResponseVersion using the highest version number the server supports as the version number.
vpResponseVersion項目の構文と意味論はセクション3.1で説明したようにcvRequestVersionと同じです。クライアントは、サーバーがサポートしている値よりも大きい値を使用していない限り、vpResponseVersionはvpRequestVersionと同じでなければならない使用しました。クライアントがサーバによってサポートされているバージョンよりも大きいvpRequestVersionを送信した場合、サーバは、サーバは、バージョン番号としてサポートしている最大のバージョン番号を使用してvpResponseVersionを返さなければなりません。
The maxCVRequestVersion item defines the maximum version number for CV requests that the server supports.
maxCVRequestVersion項目は、サーバーがサポートCV要求の最大バージョン番号を定義します。
The maxVPRequestVersion item defines the maximum version number for VP requests that the server supports.
maxVPRequestVersion項目は、VPの最大バージョン番号は、サーバがサポートしていることを要求定義します。
The serverConfigurationID item is an integer that uniquely represents the version of the server configuration as represented by the validationPolicies, validationAlgs, authPolicies, defaultPolicyValues, and clockSkew. If any of these values change, the server MUST create a new ValPolResponse with a new serverConfigurationID. If the configuration has not changed, then the server may reuse serverConfigurationID across multiple
serverConfigurationID項目は一意validationPolicies、validationAlgs、authPolicies、defaultPolicyValues、及びクロックスキューによって表されるようなサーバ構成のバージョンを表す整数です。これらの値のいずれかが変更された場合、サーバーは新しいserverConfigurationIDで新しいValPolResponseを作成する必要があります。設定が変更されていない場合、サーバーは、複数の間でserverConfigurationIDを再利用すること
ValPolResponse messages. However, if the server reverts to an earlier configuration, the server MUST NOT revert the configuration ID as well, but MUST select another unique value.
ValPolResponseメッセージ。サーバは、以前の設定に戻ります場合は、サーバーは、同様の構成IDを戻してはならないが、別の一意の値を選択する必要があります。
This item indicates the signing date and time of this policy response.
このアイテムは、このポリシー応答の署名の日付と時刻を示しています。
GeneralizedTime values MUST be expressed in Greenwich Mean Time (Zulu) and interpreted as defined in Section 3.2.7.
GeneralizedTimeの値は、グリニッジ標準時（ズールー）において発現され、セクション3.2.7で定義されるように解釈されなければなりません。
These items are used to indicate whether policy responses are specific to policy requests. Where policy responses are cached, these items indicate when the information will be updated. The optional nextUpdate item indicates the time by which the next policy response will be published. The optional requestNonce item links the response to a specific request by returning the nonce provided in the request.
これらの項目は、政策対応がポリシー要求に固有であるかどうかを示すために使用されています。政策対応がキャッシュされている場合、これらの項目は、情報が更新される時期を示しています。オプションのnextUpdateの項目は次の政策対応が公開されることで、時間を示しています。任意requestNonce項目が要求に設けられたnonceを返すことによって、特定の要求に対する応答をリンクします。
If the nextUpdate item is omitted, it indicates a non-cached response generated in response to a specific request (i.e., the ValPolResponse is bound to a specific request). If this item is omitted, the requestNonce item MUST be present and MUST include the requestNonce value from the request.
nextUpdateの項目が省略された場合、それは特定の要求（即ち、ValPolResponseは、特定の要求にバインドされている）に応答して生成された非キャッシュされた応答を示します。この項目を省略した場合、requestNonceアイテムが存在しなければならないと要求からrequestNonce値を含まなければなりません。
If the nextUpdate item is present, it indicates a cached response that is not bound to a specific request. An SCVP server MUST periodically generate a new response as defined by the next update time, but MAY use the same ValPolResponse to respond to multiple requests. The requestNonce is omitted if the nextUpdate item is present.
nextUpdateの項目が存在する場合、それは特定の要求にバインドされていないキャッシュされた応答を示します。 SCVPサーバは、次の更新時間によって定義されるように、定期的に新しいレスポンスを生成しなければならないが、複数の要求に応えるために同じValPolResponseを使用するかもしれません。 nextUpdateの項目が存在する場合requestNonceが省略されています。
It is a matter of local server policy to return a cached or non-cached specific response.
これは、ローカルサーバのポリシーの問題は、キャッシュまたは非キャッシュ固有の応答を返すことです。
GeneralizedTime values in nextUpdate MUST be expressed in Greenwich Mean Time (Zulu) as specified in Section 3.2.7.
セクション3.2.7で指定されるようにnextUpdateのでGeneralizedTimeの値は、グリニッジ標準時（ズールー）で発現されなければなりません。
The supportedChecks item contains a sequence of object identifiers representing the checks supported by the server.
supportedChecks項目は、サーバでサポートされているチェックを表すオブジェクト識別子の配列を含みます。
The supportedWantBacks item contains a sequence of object identifiers representing the wantBacks supported by the server.
supportedWantBacks項目はサーバによってサポートwantBacksを表すオブジェクト識別子の配列を含みます。
The validationPolicies item contains a sequence of object identifiers representing the validation policies supported by the server. It is a matter of local policy if the server wishes to process requests using the default validation policy, and if it does not, then it MUST NOT include the id-svp-defaultValPolicy in this list.
validationPolicies項目は、サーバーでサポートされている検証ポリシーを表すオブジェクト識別子のシーケンスが含まれています。サーバはデフォルトの検証ポリシーを使用して要求を処理したい場合には、ローカルポリシーの問題であり、そうでない場合は、それがこのリストにID-SVP-defaultValPolicyを含めることはできません。
The validationAlgs item contains a sequence of OIDs. Each OID identifies a validation algorithm supported by the server.
validationAlgs項目はOIDの配列を含みます。各OIDは、サーバでサポートされている検証アルゴリズムを特定します。
The authPolicies item contains a sequence of policy references for authenticating to the SCVP server.
authPolicies項目はSCVPサーバに認証するためのポリシー参照の配列を含みます。
The reference to the authentication policy is an OID that the client and server have agreed represents an authentication policy. The list of policies is intended to document to the client if authentication is required for some requests and if so how.
認証ポリシーを参照するには、クライアントとサーバが認証ポリシーを表し合意したOIDです。ポリシーのリストは、認証が一部の要求のために、どのようにその場合に必要とされている場合、クライアントに文書化することを意図しています。
AuthPolicy ::= OBJECT IDENTIFIER
The responseTypes item allows the server to publish the range of response types it supports. Cached only means the server will only return cached responses to requests. Non-cached only means the server will return a specific response to the request, i.e., containing the requestor's nonce. Both means that the server supports both cached and non-cached response types and will return either a cached or non- cached response, depending on the request.
responseTypes項目は、サーバーがサポートしている応答のタイプの範囲を公開することができます。キャッシュされただけで、サーバーが要求だけにキャッシュされた応答を返すことを意味します。すなわち、要求側のノンスを含む、唯一の非キャッシュサーバが要求に特定の応答を返すことを意味します。どちらも、サーバが両方のキャッシュされ、非キャッシュ応答の種類をサポートしており、要求に応じて、キャッシュされたまたは非キャッシュされた応答のいずれかを返すことを意味します。
The revocationInfoTypes item allows the server to indicate the sources of revocation information that it is capable of processing. For each bit in the RevocationInfoTypes BIT STRING, the server MUST set the bit to one if it is capable of processing the corresponding revocation information type and to zero if it cannot.
revocationInfoTypesアイテムは、サーバが処理することが可能であることを失効情報のソースを示すことができます。それができない場合、対応する失効情報タイプを処理してゼロにすることが可能である場合RevocationInfoTypesビット列の各ビットのために、サーバは1つにビットを設定しなければなりません。
This is the default validation policy used by the server. It contains a RespValidationPolicy, which is defined in Section 4.5. All OPTIONAL items in the validationPolicy item MUST be populated. A server will use these default values when the request references the default validation policy and the client does not override the default values by supplying other values in the request.
これは、サーバで使用されるデフォルトの検証ポリシーです。これは、4.5節で定義されているRespValidationPolicyが含まれています。 validationPolicyアイテム内のすべてのオプション項目が居住しなければなりません。リクエストがデフォルトの検証ポリシーを参照し、クライアントが要求して他の値を供給することにより、デフォルト値を上書きしていない場合、サーバーは、これらのデフォルト値を使用します。
This allows the client to optimize the request by omitting parameters that match the server default values.
これは、クライアントがサーバのデフォルト値と一致するパラメータを省略することによって、要求を最適化することができます。
This sequence specifies the set of digital signature algorithms supported by an SCVP server for signing CVResponse messages. Each digital signature algorithm is specified as an AlgorithmIdentifier, using the encoding rules associated with the signatureAlgorithm field in a public key certificate [PKIX-1]. Supported algorithms are defined in [PKIX-ALG] and [PKIX-ALG2], but other signature algorithms may also be supported.
この配列はCVResponseメッセージに署名するためのSCVPサーバによってサポートされるデジタル署名アルゴリズムのセットを指定します。各デジタル署名アルゴリズムは、公開鍵証明書[PKIX-1]中のsignatureAlgorithmフィールドに関連付けられた符号化ルールを使用して、のAlgorithmIdentifierとして指定されています。サポートされているアルゴリズムは[PKIX-ALG]と[PKIX-ALG2]で定義されているが、他の署名アルゴリズムもサポートすることができます。
By including an algorithm (e.g., RSA with SHA-1) in this list, the server states that it has a private key and corresponding certified public key for that asymmetric algorithm, and supports the specified hash algorithm. The list is ordered; the first digital signature algorithm is the server's default algorithm. The default algorithm will be used by the server to protect signed messages unless the client specifies another algorithm.
このリストの（SHA-1と、例えば、RSA）アルゴリズムを含めることにより、サーバは、秘密鍵を持っており、その非対称アルゴリズムの公開鍵を認定対応し、指定されたハッシュアルゴリズムをサポートしていることを述べています。リストは順序付けられています。第1のデジタル署名アルゴリズムは、サーバのデフォルトのアルゴリズムです。クライアントは別のアルゴリズムを指定しない限り、デフォルトのアルゴリズムは、署名されたメッセージを保護するために、サーバによって使用されます。
For servers that do not have an on-line private key, and cannot sign CVResponse messages, the signatureGeneration item is encoded as an empty sequence.
オンラインの秘密鍵を持っていない、とCVResponseメッセージに署名することができないサーバの場合、signatureGeneration項目が空のシーケンスとしてエンコードされます。
This sequence specifies the set of digital signature algorithms that can be verified by this SCVP server. Each digital signature algorithm is specified as an AlgorithmIdentifier, using the encoding rules associated with the signatureAlgorithm field in a public key certificate [PKIX-1]. Supported algorithms are defined in [PKIX-ALG] and [PKIX-ALG2], but other signature algorithms may also be supported.
この配列は、このSCVPサーバによって確認することができるデジタル署名アルゴリズムのセットを指定します。各デジタル署名アルゴリズムは、公開鍵証明書[PKIX-1]中のsignatureAlgorithmフィールドに関連付けられた符号化ルールを使用して、のAlgorithmIdentifierとして指定されています。サポートされているアルゴリズムは[PKIX-ALG]と[PKIX-ALG2]で定義されているが、他の署名アルゴリズムもサポートすることができます。
For servers that do not verify signatures on CVRequest messages, the signatureVerification item is encoded as an empty sequence.
CVRequestメッセージに署名を検証していないサーバの場合、signatureVerification項目が空のシーケンスとしてエンコードされます。
This sequence specifies the set of hash algorithms that the server can use to hash certificates and requests. The list is ordered; the first hash algorithm is the server's default algorithm. The default algorithm will be used by the server to compute hashes included in responses unless the client specifies another algorithm. Each hash algorithm is specified as an object identifier. [PKIX-ALG2] specifies object identifiers for SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. Other hash algorithms may also be supported.
このシーケンスは、サーバーが証明書と要求をハッシュするために使用できるハッシュアルゴリズムのセットを指定します。リストは順序付けられています。最初のハッシュアルゴリズムは、サーバのデフォルトのアルゴリズムです。クライアントは別のアルゴリズムを指定しない限り、デフォルトのアルゴリズムは、応答に含まれてハッシュを計算するために、サーバによって使用されます。各ハッシュアルゴリズムはオブジェクト識別子として指定されています。 [PKIX-ALG2]はSHA-1、SHA-224、SHA-256、SHA-384およびSHA-512のためのオブジェクト識別子を指定します。他のハッシュアルゴリズムもサポートすることができます。
The serverPublicKeys item is a sequence of one or more key agreement public keys and associated parameters. It is used by clients making AuthenticatedData requests to the server. Each item in the serverPublicKeys sequence is of the KeyAgreePublicKey type:
serverPublicKeysアイテムは、一つ以上の鍵協定公開鍵および関連するパラメータのシーケンスです。これは、サーバーへのAuthenticatedData要求を行うクライアントが使用されます。 serverPublicKeysシーケンス内の各項目はKeyAgreePublicKeyタイプのものです：
KeyAgreePublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING,
macAlgorithm AlgorithmIdentifier,
kDF AlgorithmIdentifier OPTIONAL }
The KeyAgreePublicKey includes the algorithm identifier and the server's public key. SCVP servers that support the key agreement mode of AuthenticatedData for SCVP requests MUST support serverPublicKeys and the Diffie-Hellman key agreement algorithm as specified in [PKIX-ALG]. SCVP servers that support serverPublicKeys MUST support the 1024-bit Modular Exponential (MODP) group key (group 2) as defined in [IKE]. SCVP servers that support serverPublicKeys MAY support other Diffie-Hellman groups [IKE-GROUPS], as well as other key agreement algorithms.
KeyAgreePublicKeyは、アルゴリズム識別子とサーバの公開鍵を含んでいます。 [PKIX-ALG]で指定されたSCVP要求のためにAuthenticatedDataの鍵合意モードをサポートするSCVPサーバはserverPublicKeysとのDiffie-Hellman鍵合意アルゴリズムをサポートしなければなりません。 [IKE]で定義されるようserverPublicKeysをサポートするSCVPサーバは、1024ビットのモジュラ指数（MODP）グループ鍵（グループ2）をサポートしなければなりません。 serverPublicKeysをサポートするSCVPサーバは、他のDiffie-Hellmanグループ[IKE-GROUPS]だけでなく、他の鍵合意アルゴリズムをサポートするかもしれません。
The macAlgorithm item specifies the symmetric algorithm the server expects the client to use with the result of the key agreement algorithm. A key derivation function (KDF), which derives symmetric key material from the key agreement result, may be implied by the macAlgorithm. Alternatively, the KDF may be explicitly specified using the optional kDF item.
macAlgorithm項目は、サーバは、クライアントが鍵合意アルゴリズムの結果で使用する予定の対称アルゴリズムを指定します。鍵合意の結果から、対称鍵を導出する鍵導出関数（KDF）は、macAlgorithmによって暗示されてもよいです。あるいは、KDFは、明示的に任意KDF項目を使用して指定することができます。
The clockSkew item is the number of minutes the server will allow for clock skew. The default value is 10 minutes.
クロックスのアイテムは、クロック・スキューを可能にするサーバー分の数です。デフォルト値は10分です。
In some network environments, especially ones that include firewalls, an SCVP server might not be able to obtain all of the information that it needs to process a request. However, the server might be configured to use the services of one or more other SCVP servers to fulfill all requests. In such cases, the SCVP client is unaware that the initial SCVP server is using the services of other SCVP servers. The initial SCVP server acts as a client to another SCVP server. Unlike the original client, the SCVP server is expected to have moderate computing and memory resources. This section describes SCVP server-to-SCVP server exchanges. This section does not impose any requirements on SCVP clients that are not also SCVP servers. Further, this section does not impose any requirements on SCVP servers that do not relay requests to other SCVP servers.
一部のネットワーク環境で、ファイアウォールが含まれ、特にもので、SCVPサーバは、要求を処理するために必要なすべての情報を得ることができない場合があります。ただし、サーバーはすべての要求を満たすために、1台のまたは複数の他のSCVPサーバのサービスを使用するように設定される可能性があります。このような場合には、SCVPクライアントは、最初のSCVPサーバが他のSCVPサーバのサービスを使用していることを認識しません。初期のSCVPサーバは別のSCVPサーバへのクライアントとして機能します。元のクライアントとは異なり、SCVPサーバは、適度なコンピューティングおよびメモリリソースを持つことが期待されています。このセクションでは、SCVPサーバツーSCVPサーバの交換について説明します。また、このセクションでは、SCVPサーバではありませんSCVPクライアント上の任意の要件を課していません。さらに、このセクションでは、他のSCVPサーバにリクエストを中継していないSCVPサーバ上の任意の要件を課していません。
When one SCVP server relays a request to another server, in an incorrectly configured system of servers, it is possible that the same request will be relayed back again. Any SCVP server that relays requests MUST implement the conventions described in this section to detect and break loops.
1台のSCVPサーバは、サーバの間違って構成されたシステムでは、別のサーバに要求を中継するとき、同じ要求が再び中継される可能性があります。リクエストを中継どれSCVPサーバが検出し、ループを切断するために、このセクションで説明する規則を実装しなければなりません。
When an SCVP server relays a request, the request MUST include the requestorRef item. If the request to be relayed already contains a requestorRef item, then the server-generated request MUST contain a requestorRef item constructed from this value and an additional GeneralName that contains an identifier of the SCVP server. If the request to be relayed does not contain a requestorRef item, then the server-generated request MUST contain a requestorRef item that includes a GeneralName that contains an identifier of the SCVP server.
SCVPサーバは要求を中継する場合、要求はrequestorRef項目を含まなければなりません。既に中継する要求がrequestorRef項目が含まれている場合、サーバー生成要求は、この値とSCVPサーバの識別子を含む追加のGeneralNameから構築requestorRef項目を含まなければなりません。中継する要求がrequestorRef項目が含まれていない場合、サーバー生成要求はSCVPサーバの識別子を含むのGeneralNameを含むrequestorRef項目を含まなければなりません。
To prevent false loop detection, servers should use identifiers that are unique within their network of cooperating SCVP servers. SCVP servers that support relay SHOULD populate this item with the DNS name of the server or the distinguished name in the server's certificate. SCVP servers MAY choose other procedures for generating identifiers that are unique within their community.
偽のループ検出を防ぐために、サーバは、SCVPサーバの協働、ネットワーク内で一意である識別子を使用する必要があります。リレーをサポートするSCVPサーバは、サーバのDNS名またはサーバーの証明書の識別名を持つこのアイテムを移入すべきです。 SCVPサーバは、そのコミュニティ内で一意である識別子を生成するための他の手順を選ぶかもしれません。
When an SCVP server receives a request that contains a requestorRef item, the server MUST check the sequence of names in the requestorRef item for its own identifier. If the server discovers its own identifier in the requestorRef item, it MUST respond with an error, setting the statusCode in the responseStatus item to 40.
SCVPサーバはrequestorRef項目が含まれている要求を受信すると、サーバーは、自身の識別子のためにrequestorRef項目の名前のシーケンスをチェックしなければなりません。サーバがrequestorRef項目に自身の識別子を検出した場合、それは40にresponseStatus項目でからstatusCodeを設定し、エラーで応じなければなりません。
When an SCVP server generates a non-cached response to a relayed request, the server MUST include the requestorRef item from the request in the response.
SCVPサーバが中継要求に対する非キャッシュ応答を生成するとき、サーバは、応答要求からrequestorRef項目を含まなければなりません。
This section defines the syntax for SCVP request-response pairs. The semantics for the messages are defined in Sections 3, 4, 5, and 6. The SCVP ASN.1 module follows.
このセクションでは、SCVP要求応答ペアの構文を定義します。メッセージのセマンティクスはセクション3、4、5で定義され、そして6 SCVP ASN.1モジュールは、以下の通りです。
SCVP
SCVP
{ iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 21 }
{ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）21}
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
輸入
AlgorithmIdentifier, Attribute, Certificate, Extensions, -- Import UTF8String if required by compiler -- UTF8String, -- CertificateList, CertificateSerialNumber FROM PKIX1Explicit88 -- RFC 3280 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 18 }
AlgorithmIdentifier、属性証明書、拡張、 - インポートUTF8Stringをコンパイラが必要な場合 - UTF8Stringを、 - CertificateListの、CertificateSerialNumber PKIX1Explicit88 FROM - RFC 3280 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）18}
GeneralNames, GeneralName, KeyUsage, KeyPurposeId FROM PKIX1Implicit88 -- RFC 3280 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 19 }
GeneralNames、のGeneralName、のKeyUsage、KeyPurposeId PKIX1Implicit88 FROM - RFC 3280 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0） 19}
AttributeCertificate FROM PKIXAttributeCertificate -- RFC 3281 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 12 }
PKIXAttributeCertificate FROM AttributeCertificate - RFC 3281 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）12}
OCSPResponse FROM OCSP -- RFC 2560 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 14 }
OCSP FROM OCSPResponse - RFC 2560 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）14}
ContentInfo FROM CryptographicMessageSyntax2004 -- RFC 3852 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } ;
CryptographicMessageSyntax2004 FROM ContentInfo - RFC 3852 {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（0）CMS-2004（16）モジュール（24） }。
-- SCVP Certificate Validation Request
- SCVP証明書の検証要求
id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) 1 }
id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 }
CVRequest ::= SEQUENCE {
cvRequestVersion INTEGER DEFAULT 1,
query Query,
requestorRef [0] GeneralNames OPTIONAL,
requestNonce [1] OCTET STRING OPTIONAL,
requestorName [2] GeneralName OPTIONAL,
responderName [3] GeneralName OPTIONAL,
requestExtensions [4] Extensions OPTIONAL,
signatureAlg [5] AlgorithmIdentifier OPTIONAL,
hashAlg [6] OBJECT IDENTIFIER OPTIONAL,
requestorText [7] UTF8String (SIZE (1..256)) OPTIONAL }
Query ::= SEQUENCE {
queriedCerts CertReferences,
checks CertChecks,
wantBack [1] WantBack OPTIONAL,
validationPolicy ValidationPolicy,
responseFlags ResponseFlags OPTIONAL,
serverContextInfo [2] OCTET STRING OPTIONAL,
validationTime [3] GeneralizedTime OPTIONAL,
intermediateCerts [4] CertBundle OPTIONAL,
revInfos [5] RevocationInfos OPTIONAL,
producedAt [6] GeneralizedTime OPTIONAL,
queryExtensions [7] Extensions OPTIONAL }
CertReferences ::= CHOICE {
pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference,
acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference }
CertReference::= CHOICE {
pkc PKCReference,
ac ACReference }
PKCReference ::= CHOICE {
cert [0] Certificate,
pkcRef [1] SCVPCertID }
ACReference ::= CHOICE {
attrCert [2] AttributeCertificate,
acRef [3] SCVPCertID }
SCVPCertID ::= SEQUENCE {
certHash OCTET STRING,
issuerSerial SCVPIssuerSerial,
hashAlgorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 } }
SCVPIssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
ValidationPolicy ::= SEQUENCE {
validationPolRef ValidationPolRef,
validationAlg [0] ValidationAlg OPTIONAL,
userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT
IDENTIFIER OPTIONAL,
inhibitPolicyMapping [2] BOOLEAN OPTIONAL,
requireExplicitPolicy [3] BOOLEAN OPTIONAL,
inhibitAnyPolicy [4] BOOLEAN OPTIONAL,
trustAnchors [5] TrustAnchors OPTIONAL,
keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL,
extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL,
specifiedKeyUsages [8] SEQUENCE OF KeyPurposeId OPTIONAL }
CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
ValidationPolRef ::= SEQUENCE {
valPolId OBJECT IDENTIFIER,
valPolParams ANY DEFINED BY valPolId OPTIONAL }
ValidationAlg ::= SEQUENCE {
valAlgId OBJECT IDENTIFIER,
parameters ANY DEFINED BY valAlgId OPTIONAL }
NameValidationAlgParms ::= SEQUENCE {
nameCompAlgId OBJECT IDENTIFIER,
validationNames GeneralNames }
TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference
KeyAgreePublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING,
macAlgorithm AlgorithmIdentifier,
kDF AlgorithmIdentifier OPTIONAL }
ResponseFlags ::= SEQUENCE {
fullRequestInResponse [0] BOOLEAN DEFAULT FALSE,
responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE,
protectResponse [2] BOOLEAN DEFAULT TRUE,
cachedResponse [3] BOOLEAN DEFAULT TRUE }
CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate
RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo
RevocationInfo ::= CHOICE {
crl [0] CertificateList,
delta-crl [1] CertificateList,
ocsp [2] OCSPResponse,
other [3] OtherRevInfo }
OtherRevInfo ::= SEQUENCE {
riType OBJECT IDENTIFIER,
riValue ANY DEFINED BY riType }
-- SCVP Certificate Validation Response
- SCVP証明書の検証レスポンス
id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 }
CVResponse ::= SEQUENCE {
cvResponseVersion INTEGER,
serverConfigurationID INTEGER,
producedAt GeneralizedTime,
responseStatus ResponseStatus,
respValidationPolicy [0] RespValidationPolicy OPTIONAL,
requestRef [1] RequestReference OPTIONAL,
requestorRef [2] GeneralNames OPTIONAL,
requestorName [3] GeneralNames OPTIONAL,
replyObjects [4] ReplyObjects OPTIONAL,
respNonce [5] OCTET STRING OPTIONAL,
serverContextInfo [6] OCTET STRING OPTIONAL,
cvResponseExtensions [7] Extensions OPTIONAL,
requestorText [8] UTF8String (SIZE (1..256)) OPTIONAL }
ResponseStatus ::= SEQUENCE {
statusCode CVStatusCode DEFAULT okay,
errorMessage UTF8String OPTIONAL }
CVStatusCode ::= ENUMERATED {
okay (0),
skipUnrecognizedItems (1),
tooBusy (10),
invalidRequest (11),
internalError (12),
badStructure (20),
unsupportedVersion (21),
abortUnrecognizedItems (22),
unrecognizedSigKey (23),
badSignatureOrMAC (24), unableToDecode (25),
notAuthorized (26),
unsupportedChecks (27),
unsupportedWantBacks (28),
unsupportedSignatureOrMAC (29),
invalidSignatureOrMAC (30),
protectedResponseUnsupported (31),
unrecognizedResponderName (32),
relayingLoop (40),
unrecognizedValPol (50),
unrecognizedValAlg (51),
fullRequestInResponseUnsupported (52),
fullPolResponseUnsupported (53),
inhibitPolicyMappingUnsupported (54),
requireExplicitPolicyUnsupported (55),
inhibitAnyPolicyUnsupported (56),
validationTimeUnsupported (57),
unrecognizedCritQueryExt (63),
unrecognizedCritRequestExt (64) }
RespValidationPolicy ::= ValidationPolicy
RequestReference ::= CHOICE {
requestHash [0] HashValue, -- hash of CVRequest
fullRequest [1] CVRequest }
HashValue ::= SEQUENCE {
algorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 },
value OCTET STRING }
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply
CertReply ::= SEQUENCE {
cert CertReference,
replyStatus ReplyStatus DEFAULT success,
replyValTime GeneralizedTime,
replyChecks ReplyChecks,
replyWantBacks ReplyWantBacks,
validationErrors [0] SEQUENCE SIZE (1..MAX) OF
OBJECT IDENTIFIER OPTIONAL,
nextUpdate [1] GeneralizedTime OPTIONAL,
certReplyExtensions [2] Extensions OPTIONAL }
ReplyStatus ::= ENUMERATED {
success (0),
malformedPKC (1),
malformedAC (2),
unavailableValidationTime (3),
referenceCertHashFail (4),
certPathConstructFail (5),
certPathNotValid (6),
certPathNotValidNow (7),
wantBackUnsatisfied (8) }
ReplyChecks ::= SEQUENCE OF ReplyCheck
ReplyCheck ::= SEQUENCE {
check OBJECT IDENTIFIER,
status INTEGER DEFAULT 0 }
ReplyWantBacks ::= SEQUENCE OF ReplyWantBack
ReplyWantBack::= SEQUENCE {
wb OBJECT IDENTIFIER,
value OCTET STRING }
CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle
RevInfoWantBack ::= SEQUENCE {
revocationInfo RevocationInfos,
extraCerts CertBundle OPTIONAL }
SCVPResponses ::= SEQUENCE OF ContentInfo
-- SCVP Validation Policies Request
- SCVP確認ポリシーリクエスト
id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 }
ValPolRequest ::= SEQUENCE {
vpRequestVersion INTEGER DEFAULT 1,
requestNonce OCTET STRING }
-- SCVP Validation Policies Response
- SCVP確認ポリシー応答
id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 }
ValPolResponse ::= SEQUENCE {
vpResponseVersion INTEGER,
maxCVRequestVersion INTEGER,
maxVPRequestVersion INTEGER,
serverConfigurationID INTEGER, thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime OPTIONAL,
supportedChecks CertChecks,
supportedWantBacks WantBack,
validationPolicies SEQUENCE OF OBJECT IDENTIFIER,
validationAlgs SEQUENCE OF OBJECT IDENTIFIER,
authPolicies SEQUENCE OF AuthPolicy,
responseTypes ResponseTypes,
defaultPolicyValues RespValidationPolicy,
revocationInfoTypes RevocationInfoTypes,
signatureGeneration SEQUENCE OF AlgorithmIdentifier,
signatureVerification SEQUENCE OF AlgorithmIdentifier,
hashAlgorithms SEQUENCE SIZE (1..MAX) OF
OBJECT IDENTIFIER,
serverPublicKeys SEQUENCE OF KeyAgreePublicKey
OPTIONAL,
clockSkew INTEGER DEFAULT 10,
requestNonce OCTET STRING OPTIONAL }
ResponseTypes ::= ENUMERATED {
cached-only (0),
non-cached-only (1),
cached-and-non-cached (2) }
RevocationInfoTypes ::= BIT STRING {
fullCRLs (0),
deltaCRLs (1),
indirectCRLs (2),
oCSPResponses (3) }
AuthPolicy ::= OBJECT IDENTIFIER
-- SCVP Check Identifiers
- SCVPチェック識別子
id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 }
id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 }
id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 }
id-stc-build-status-checked-pkc-path
OBJECT IDENTIFIER ::= { id-stc 3 }
id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 }
id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 }
id-stc-build-status-checked-aa-path
OBJECT IDENTIFIER ::= { id-stc 6 }
id-stc-status-check-ac-and-build-status-checked-aa-path
OBJECT IDENTIFIER ::= { id-stc 7 }
-- SCVP WantBack Identifiers
- SCVP WantBack識別子
id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 }
id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 }
id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 }
id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 }
id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 }
id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 }
id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 }
id-swb-relayed-responses OBJECT IDENTIFIER ::= { id-swb 9 }
id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10}
id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11}
id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12}
id-swb-pkc-ee-revocation-info OBJECT IDENTIFIER ::= { id-swb 13}
id-swb-pkc-CAs-revocation-info OBJECT IDENTIFIER ::= { id-swb 14}
-- SCVP Validation Policy and Algorithm Identifiers
- SCVP確認ポリシーおよびアルゴリズムの識別子
id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 }
id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }
-- SCVP Basic Validation Algorithm Identifier
- SCVP基本的な検証アルゴリズム識別子
id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 }
-- SCVP Basic Validation Algorithm Errors
- SCVP基本的な検証アルゴリズムのエラー
id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg
id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 }
id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 }
id-bvae-wrongTrustAnchor OBJECT IDENTIFIER ::= { id-bvae 3 }
id-bvae-noValidCertPath OBJECT IDENTIFIER ::= { id-bvae 4 }
id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 5 }
id-bvae-invalidKeyPurpose OBJECT IDENTIFIER ::= { id-bvae 9 }
id-bvae-invalidKeyUsage OBJECT IDENTIFIER ::= { id-bvae 10 }
id-bvae-invalidCertPolicy OBJECT IDENTIFIER ::= { id-bvae 11 }
-- SCVP Name Validation Algorithm Identifier
- SCVP名前の検証アルゴリズム識別子
id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 }
-- SCVP Name Validation Algorithm DN comparison algorithm
- SCVP名前検証アルゴリズムDN比較アルゴリズム
id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 }
-- SCVP Name Validation Algorithm Errors
- SCVP名前の検証アルゴリズムのエラー
id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg
id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 }
id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 }
id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 }
id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 }
id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 }
id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 }
-- SCVP Extended Key Usage Key Purpose Identifiers
- SCVP拡張キー使用法キー目的識別子
id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 }
id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 }
id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 }
END
終わり
For security considerations specific to the Cryptographic Message Syntax message formats, see [CMS]. For security considerations specific to the process of PKI certification path validation, see [PKIX-1].
暗号メッセージ構文メッセージ形式に固有のセキュリティ上の考慮事項については、[CMS]を参照してください。 PKI認証パス検証のプロセスに固有のセキュリティ問題のために、[PKIX-1]を参照。
A client that trusts a server's response for validation of a certificate inherently trusts that server as much as it would trust its own validation software. This means that if an attacker compromises a trusted SCVP server, the attacker can change the validation processing for every client that relies on that server. Thus, an SCVP server must be protected at least as well as the trust anchors that the SCVP server trusts.
証明書の検証のためのサーバの応答を信頼し、クライアントは、本質的にそれは、独自の検証ソフトウェアを信頼してしまうと同じくらい、そのサーバーを信頼します。これにより、攻撃者は、信頼できるSCVPサーバを危険にさらした場合、攻撃者はそのサーバーに依存しているすべてのクライアントの検証処理を変更することができることを意味します。このように、SCVPサーバは、少なくとも保護されなければならないだけでなく、信頼はSCVPサーバを信頼することをアンカー。
Clients MUST verify that the response matches their original request. Clients need to ensure that the server has performed the appropriate checks for the correct certificates under the requested validation policy for the specified validation time, and that the response includes the requested wantBacks and meets the client's freshness requirements.
クライアントは、応答が元の要求と一致していることを確かめなければなりません。クライアントは、サーバーが指定した検証の時間のために要求された検証ポリシーの下で正しい証明書の適切なチェックを行い、応答が要求されたwantBacksが含まれており、クライアントの鮮度要件を満たしていることをしていることを確認する必要があります。
When the SCVP response is used to determine the validity of a certificate, the client MUST validate the digital signature or MAC on the response to ensure that the expected SCVP server generated it. If the client does not check the digital signature or MAC on the response, a man-in-the-middle attack could fool the client into believing modified responses from the server or responses to questions the client did not ask.
SCVP応答が証明書の有効性を決定するために使用される場合、クライアントは、予想SCVPサーバは、それを生成することを保証するために、応答のデジタル署名またはMACを検証しなければなりません。クライアントが応答のデジタル署名またはMACをチェックしない場合は、man-in-the-middle攻撃は、サーバーまたはクライアントが要求していない質問への回答から変更された応答を信じるようにクライアントをだますことができます。
If the client does not include a requestNonce item, or if the client does not check that the requestNonce in the response matches the value in the request, an attacker can replay previous responses from the SCVP server.
クライアントがrequestNonce項目が含まれていない場合は、クライアントが応答requestNonceリクエストで値と一致していることを確認していない場合、または、攻撃者はSCVPサーバから前の応答を再生することができます。
If the server does not require some sort of authorization (such as signed requests), an attacker can get the server to respond to arbitrary requests. Such responses may give the attacker information about weaknesses in the server or about the timeliness of the server's checking. This information may be valuable for a future attack.
サーバが（署名要求など）の認可のいくつかの並べ替えを必要としない場合、攻撃者は、サーバーが任意の要求に応答するために取得することができます。このような応答は、サーバまたはサーバのチェックの適時性についての弱点について、攻撃者の情報を与えることができます。この情報は、今後の攻撃のために価値があります。
If the server uses the serverContextInfo item to indicate some server state associated with a requestor, implementers must take appropriate measures against denial-of-service attacks where an attacker sends in a lot of requests at one time to force the server to keep a lot of state information.
サーバは要求者に関連付けられているいくつかのサーバーの状態を示すためにserverContextInfoアイテムを使用している場合、実装者は、多くのを維持するために、サーバーを強制的に、攻撃者が一度に要求の多くに送信し、サービス拒否攻撃に対する適切な措置を取らなければなりません状態情報。
SCVP does not include any confidentiality mechanisms. If confidentiality is needed, it can be achieved with a lower-layer security protocol such as TLS [TLS].
SCVPは、任意の機密性のメカニズムが含まれていません。機密性が必要な場合、そのようなTLS [TLS]のように下位層セキュリティプロトコルを用いて達成することができます。
If an SCVP client is not operating on a network with good physical protection, it must ensure that there is integrity over the SCVP request-response pair. The client can ensure integrity by using a protected transport such as TLS. It can ensure integrity by using MACs or digital signatures to individually protect the request and response messages.
SCVPクライアントは、良好な物理的保護機能を備えたネットワーク上で動作していない場合、それはSCVP要求応答ペアオーバー整合性があることを確認する必要があります。クライアントは、TLSとして保護トランスポートを使用して整合性を確保することができます。これは、個別の要求と応答メッセージを保護するためのMACまたはデジタル署名を使用して整合性を確保することができます。
If an SCVP client populates the userPolicySet in a request with a value other than anyPolicy, but does not set the requireExplicitPolicy flag, the server may return an affirmative answer for paths that do not satisfy any of the specified policies. In general, when a client populates the userPolicySet in a request with a value other than anyPolicy, the requireExplicitPolicy flag should also be set. This guarantees that all valid paths satisfy at least one of the requested policies.
SCVPクライアントがanyPolicy以外の値を持つリクエストでuserPolicySetを移入しますが、requireExplicitPolicyフラグを設定しない場合、サーバーは、指定したポリシーのいずれかを満たしていないパスの肯定的な答えを返すことがあります。クライアントがanyPolicy以外の値を持つリクエストにuserPolicySetを移入するとき、一般的に、requireExplicitPolicyフラグも設定されなければなりません。これは、すべての有効なパスが要求されたポリシーの少なくとも一つを満たすことを保証します。
In SCVP, historical validation of a certificate returns the known status of the certificate at the time specified in validationTime. This may be used to demonstrate due diligence, but does not necessarily provide the most complete information. A certificate may have been revoked after the time specified in validationTime, but the revocation notice may specify an invalidity date that precedes the validationTime. The SCVP server would provide an affirmative response even though the most current information available indicates the certificate should not be trusted at that time. SCVP clients may wish to specify a validationTime later than the actual time of interest to mitigate this risk.
SCVPでは、証明書の歴史的検証はvalidationTimeで指定された時点で証明書の既知のステータスを返します。これは、デューデリジェンスを実証するために使用することができるが、必ずしも最も完全な情報を提供していません。証明書はvalidationTimeで指定した時間後に取り消された可能性がありますが、失効通知がvalidationTimeの前に無効日付を指定することもできます。 SCVPサーバは、入手可能な最新の情報は、証明書がその時に、信頼するべきではありません示していても、肯定的な応答を提供します。 SCVPクライアントは、このリスクを軽減するために、関心の実際の時間より後validationTimeを指定することもできます。
The details of SCVP 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 four MIME type registrations in Appendix A. No further action by IANA is necessary for this document or any anticipated updates.
SCVP要求と応答の詳細は、オブジェクト識別子（OID）を使用して通信されます。オブジェクトは、PKIXワーキンググループにIANAによって委任アークで定義されています。また、このドキュメントでは、IANAによってそれ以上のアクションは、この文書または予想されるアップデートの必要はありません付録Aの4件のMIMEタイプの登録が含まれています。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[PKIX-1] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIX-1] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[PKIX-AC] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[PKIX-AC]ファレル、S.とR. Housley氏、 "認可のためのインターネット属性証明書プロフィール"、RFC 3281、2002年4月。
[PKIX-ALG] 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.
[PKIX-ALG] Bassham、L.、ポーク、W.、およびR. Housley氏、RFC 3279、2002年4月 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールのためのアルゴリズムと識別子"。
[PKIX-ALG2] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[PKIX-ALG2] Schaad、J.、Kaliski、B.、およびR. Housley氏、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールで使用するRSA暗号のための追加のアルゴリズムと識別子"、 RFC 4055、2005年6月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF8] Yergeau、F.、 "UTF8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、エド。、 "セキュリティ強化サービスS / MIMEのために"、RFC 2634、1999年6月。
[SMIME-CERT] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[SMIME-CERT] Ramsdell、B.、エド。、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1証明書の取扱い"、RFC 3850、2004年7月。
[IKE] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKE]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[HTTP] 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.
[HTTP]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[IKE-GROUPS] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[IKE-GROUPS] Kivinen、T.およびM.古城、 "インターネット鍵交換のためのより多くのモジュラー指数（MODP）のDiffie-Hellmanグループ（IKE）"、RFC 3526、2003年5月。
[RQMTS] Pinkas, D. and R. Housley, "Delegated Path Validation and Delegated Path Discovery Protocol Requirements", RFC 3379, September 2002.
[RQMTS]ピンカス、D.とR. Housley氏は、 "委任パス検証と委任パス発見プロトコル要件"、RFC 3379、2002年9月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
The lively debate in the PKIX Working Group has made a significant impact on this protocol. Special thanks to the following for their contributions to this document and diligence in greatly improving it.
PKIXワーキンググループでの活発な議論は、このプロトコルに大きな影響を与えてきました。大幅にそれを改善するには、この文書と勤勉への貢献のために、以下に感謝します。
Paul Hoffman Phillip Hallam-Baker Mike Myers Frank Balluffi Ameya Talwalkar John Thielens Peter Sylvester Yuriy Dzambasow Sean P. Turner Wen-Cheng Wang Francis Dupont Dave Engberg Faisal Maqsood
ポール・ホフマンフィリップハラム - ベイカーマイク・マイヤーズフランクBalluffi Talwalkar市長ジョンThielensピーターシルベスターユーリーDzambasowショーン・P.ターナーウェン・チェン王フランシスデュポンデイブEngbergファイサルMaqsood
Thanks also to working group chair Steve Kent for his support and help.
彼のサポートとヘルプのためにも、ワーキンググループの議長スティーブ・ケントに感謝します。
Appendix A. MIME Media Type Registrations
付録A. MIMEメディアタイプ登録
Four MIME media type registrations are provided in this appendix.
四のMIMEメディアタイプの登録は、この付録で提供されています。
A.1. application/scvp-cv-request
A.1。アプリケーション/ SCVP-CV-要求
To: ietf-types@iana.org Subject: Registration of MIME media type application/scvp-cv-request
To：ietf-types@iana.org件名：MIMEメディアタイプapplication / SCVP-CV-要求の登録
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: scvp-cv-request
MIMEサブタイプ名：SCVP-CV-要求
Required parameters: None
必須パラメータ：なし
Optional parameters: None
オプションのパラメータ：なし
Encoding considerations: Binary
エンコードの考慮事項：バイナリ
Security considerations: Carries a request for information. This request may optionally be cryptographically protected.
セキュリティの考慮事項：情報の要求を運びます。この要求は、必要に応じて暗号で保護されてもよいです。
Interoperability considerations: None
相互運用性に関する注意事項：なし
Published specification: RFC 5055
公開された仕様：RFC 5055
Applications that use this media type: SCVP clients sending certificate validation requests
SCVPクライアントは、証明書の検証要求を送信する：このメディアタイプを使用するアプリケーション
Additional information:
追加情報：
Magic number(s): None File extension(s): .SCQ Macintosh File Type Code(s): None
マジックナンバー（S）：なしファイルの拡張子（S）：.SCQマッキントッシュファイルタイプコード（S）：なし
Person & email address to contact for further information: Ambarish Malpani <ambarish@yahoo.com>
人とEメールアドレスは、詳細のために連絡する：Ambarish Malpani <ambarish@yahoo.com>
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: This media type can be used with any protocol that can transport digitally signed objects.
使用上の制限：このメディアタイプは、デジタル署名されたオブジェクトを輸送することができる任意のプロトコルと共に使用することができます。
Author: Ambarish Malpani <ambarish@yahoo.com>
著者：Malpaniをアンベアイーッシュ<अम्बरीष@याहू.कॉम>
Change controller: IESG
変更コントローラ：IESG
A.2. application/scvp-cv-response
A.2。アプリケーション/ SCVP-CV-応答
To: ietf-types@iana.org Subject: Registration of MIME media type application/scvp-cv-response
To：ietf-types@iana.org件名：MIMEメディアタイプapplication / SCVP-CV-応答の登録
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: scvp-cv-response
MIMEサブタイプ名：SCVP-CV-応答
Required parameters: None
必須パラメータ：なし
Optional parameters: None
オプションのパラメータ：なし
Encoding considerations: Binary
エンコードの考慮事項：バイナリ
Security considerations: The client may require that this response be cryptographically protected, or may choose to use a secure transport mechanism. DPD responses may be unprotected, but the client validates the information provided in the request.
セキュリティに関する注意事項：クライアントは、この応答は暗号で保護されることを必要とするかもしれない、または安全なトランスポートメカニズムを使用することもできます。 DPD応答は保護されていないかもしれませんが、クライアントが要求において提供された情報を検証します。
Interoperability considerations: None
相互運用性に関する注意事項：なし
Published specification: RFC 5055
公開された仕様：RFC 5055
Applications that use this media type: SCVP servers responding to certificate validation requests
このメディアタイプを使用するアプリケーション：SCVPサーバ証明書検証要求に応答
Additional information:
追加情報：
Magic number(s): None File extension(s): .SCS Macintosh File Type Code(s): none
マジックナンバー（S）：なしファイルの拡張子（S）：.SCSマッキントッシュファイルタイプコード（S）：なし
Person & email address to contact for further information: Ambarish Malpani <ambarish@yahoo.com>
人とEメールアドレスは、詳細のために連絡する：Ambarish Malpani <ambarish@yahoo.com>
Intended usage: COMMON Restrictions on usage: This media type can be used with any protocol that can transport digitally signed objects.
使用目的：使用上の共通の制限：このメディアタイプは、デジタル署名されたオブジェクトを輸送することができる任意のプロトコルと共に使用することができます。
Author: Ambarish Malpani <ambarish@yahoo.com>
著者：Malpaniをアンベアイーッシュ<अम्बरीष@याहू.कॉम>
Change controller: IESG
変更コントローラ：IESG
A.3. application/scvp-vp-request
A.3。アプリケーション/ SCVP-VP-要求
To: ietf-types@iana.org Subject: Registration of MIME media type application/scvp-vp-request
To：ietf-types@iana.org件名：MIMEメディアタイプapplication / SCVP-VP-要求の登録
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: scvp-vp-request
MIMEサブタイプ名：SCVP-VP-要求
Required parameters: None
必須パラメータ：なし
Optional parameters: None
オプションのパラメータ：なし
Encoding considerations: Binary
エンコードの考慮事項：バイナリ
Security considerations: Carries a request for information.
セキュリティの考慮事項：情報の要求を運びます。
Interoperability considerations: None
相互運用性に関する注意事項：なし
Published specification: RFC 5055
公開された仕様：RFC 5055
Applications that use this media type: SCVP clients sending validation policy requests
検証ポリシー要求を送信SCVPクライアント：このメディアタイプを使用するアプリケーション
Additional information:
追加情報：
Magic number(s): None File extension(s): .SPQ Macintosh File Type Code(s): none
マジックナンバー（S）：なしファイルの拡張子（S）：.SPQマッキントッシュファイルタイプコード（S）：なし
Person & email address to contact for further information: Ambarish Malpani <ambarish@yahoo.com>
人とEメールアドレスは、詳細のために連絡する：Ambarish Malpani <ambarish@yahoo.com>
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: None
使用に関する制限：なし
Author: Ambarish Malpani <ambarish@yahoo.com>
著者：Malpaniをアンベアイーッシュ<अम्बरीष@याहू.कॉम>
Change controller: IESG
変更コントローラ：IESG
A.4. application/scvp-vp-response
A.4。アプリケーション/ SCVP-VP-応答
To: ietf-types@iana.org Subject: Registration of MIME media type application/scvp-vp-response
To：ietf-types@iana.org件名：MIMEメディアタイプapplication / SCVP-VP-応答の登録
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: scvp-vp-response
MIMEサブタイプ名：SCVP-VP-応答
Required parameters: None
必須パラメータ：なし
Optional parameters: None
オプションのパラメータ：なし
Encoding considerations: Binary
エンコードの考慮事項：バイナリ
Security considerations: None
セキュリティの考慮事項：なし
Interoperability considerations: None
相互運用性に関する注意事項：なし
Published specification: RFC 5055
公開された仕様：RFC 5055
Applications that use this media type: SCVP servers responding to validation policy requests
このメディアタイプを使用するアプリケーション：SCVPサーバ検証ポリシー要求に応答
Additional information:
追加情報：
Magic number(s): None File extension(s): .SPP Macintosh File Type Code(s): none
マジックナンバー（S）：なしファイルの拡張子（S）：.SPPマッキントッシュファイルタイプコード（S）：なし
Person & email address to contact for further information: Ambarish Malpani <ambarish@yahoo.com>
人とEメールアドレスは、詳細のために連絡する：Ambarish Malpani <ambarish@yahoo.com>
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: This media type can be used with any protocol that can transport digitally signed objects.
使用上の制限：このメディアタイプは、デジタル署名されたオブジェクトを輸送することができる任意のプロトコルと共に使用することができます。
Author: Ambarish Malpani <ambarish@yahoo.com>
著者：Malpaniをアンベアイーッシュ<अम्बरीष@याहू.कॉम>
Change controller: IESG
変更コントローラ：IESG
Appendix B. SCVP over HTTP
付録B. SCVP HTTP経由
This appendix describes the formatting and transportation conventions for the SCVP request and response when carried by HTTP.
この付録では、HTTPによって運ばSCVP要求と応答の書式や交通規則について説明します。
In order for SCVP clients and servers using HTTP to interoperate, the following rules apply.
SCVPクライアントと相互運用するためにHTTPを使用してサーバーためには、次の規則が適用されます。
- Clients MUST use the POST method to submit their requests.
- クライアントは、彼らの要求を提出するPOSTメソッドを使用する必要があります。
- Servers MUST use the 200 response code for successful responses.
- サーバは成功応答を200応答コードを使用しなければなりません。
- Clients MAY attempt to send HTTPS requests using TLS 1.0 or later, although servers are not required to support TLS.
- サーバがTLSをサポートする必要はありませんが、クライアントは、TLS 1.0以降を使用してHTTPS要求を送信しようとすることができます。
- Servers MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication.
- サーバは、クッキー、基本認証、またはダイジェスト認証など、HTTP認証のいずれかのタイプのクライアントのサポートを仮定してはいけません。
- Clients and servers are expected to follow the other rules and restrictions in [HTTP]. 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.
- クライアントとサーバは、[HTTP]で他のルールと制限に従うことが期待されています。これらのルールの一部がPOST以外のHTTPメソッドのためのものであることに注意してください。明らかに、唯一のPOSTに適用される規則は、この仕様書に関連しています。
B.1. SCVP Request
B.1。 SCVP要求
An SCVP request using the POST method is constructed as follows:
次のようにPOSTメソッドを使用してSCVP要求が構築されます。
The Content-Type header MUST have the value "application/scvp-cv-request".
Content-Typeヘッダの値は、 "アプリケーション/ SCVP-CV-要求" を持たなければなりません。
The body of the message is the binary value of the DER encoding of the CVRequest, wrapped in a CMS body as described in Section 3.
メッセージの本体は、第3節で説明したようにCMS本体に包まCVRequestのDERエンコーディングのバイナリ値です。
B.2. SCVP Response
B.2。 SCVP応答
An HTTP-based SCVP response is composed of the appropriate HTTP headers, followed by the binary value of the BER encoding of the CVResponse, wrapped in a CMS body as described in Section 4.
HTTPベースSCVP応答は、セクション4で説明したようにCMS本体に包まCVResponseのBERエンコーディングのバイナリ値、続いて適切なHTTPヘッダ、から構成されています。
The Content-Type header MUST have the value "application/scvp-cv-response".
Content-Typeヘッダの値は、 "アプリケーション/ SCVP-CV-応答" を持たなければなりません。
B.3. SCVP Policy Request
B.3。 SCVPポリシー要求
An SCVP request using the POST method is constructed as follows:
次のようにPOSTメソッドを使用してSCVP要求が構築されます。
The Content-Type header MUST have the value "application/scvp-vp-request".
Content-Typeヘッダの値は、 "アプリケーション/ SCVP-VP-要求" を持たなければなりません。
The body of the message is the binary value of the BER encoding of the ValPolRequest, wrapped in a CMS body as described in Section 5.
メッセージの本体は、セクション5で説明したようにCMS本体に包まValPolRequestのBERエンコーディングのバイナリ値です。
B.4. SCVP Policy Response
B.4。 SCVP政策対応
An HTTP-based SCVP policy response is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the ValPolResponse, wrapped in a CMS body as described in Section 6. The Content-Type header MUST have the value "application/scvp-vp-response".
セクション6に記載されるようにHTTPベースSCVPポリシー応答はContent-Typeヘッダの値が「アプリケーションを持たなければならないCMS本体に包まValPolResponseのDERエンコーディングのバイナリ値、続いて適切なHTTPヘッダ、から構成されています/ SCVP-VP-応答」。
Authors' Addresses
著者のアドレス
Trevor Freeman Microsoft Corporation, One Microsoft Way Redmond, WA 98052 USA. EMail: trevorf@microsoft.com
トレバー・フリーマンマイクロソフトコーポレーション、1つのマイクロソフト道、レッドモンド、WA 98052 USA。メールアドレス：trevorf@microsoft.com
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
ラッセルHousley氏ビジルセキュリティ、LLC 918春小山Driveハーンドン、VA 20170 USA電子メール：housley@vigilsec.com
Ambarish Malpani Malpani Consulting Services EMail: ambarish@yahoo.com
Ambarish Malpani MalpaniコンサルティングサービスEメール：ambarish@yahoo.com
David Cooper National Institute of Standards and Technology 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 EMail: david.cooper@nist.gov
デビッド・クーパー国立標準技術研究所100局ドライブ、メールストップ8930ゲイサーズバーグ、MD 20899から8930 Eメール：david.cooper@nist.gov
Tim Polk National Institute of Standards and Technology 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 EMail: wpolk@nist.gov
標準のティムポーク国立技術研究所100局ドライブ、メールストップ8930ゲイサーズバーグ、MD 20899から8930 Eメール：wpolk@nist.gov
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。