[要約] RFC 5055は、サーバーベースの証明書検証プロトコル（SCVP）に関する仕様です。このプロトコルの目的は、証明書の検証をサーバーに委任し、信頼性と効率性を向上させることです。
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)
サーバーベースの証明書検証プロトコル（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は、2つのクラスの証明書使用アプリケーションでこのオーバーヘッドを削減します。
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).
アプリケーションの最初のクラスは、公開鍵が証明書に命名されたIDに属していることの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).
2番目のクラスのアプリケーションは、認証パス検証を実行できますが、有効な認証パスを構築する信頼できるまたは効率的な方法がありません。このようなクライアントは、認定パスの構築を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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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サーバーによって構築された認証パスを検証する必要があることを、証明書の取り消しリスト（CRLS）やオンライン証明書ステータスプロトコル（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) パスディスカバリーポリシーに従って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) Path Discoveryポリシーに従って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.
基本的な認証パス処理アルゴリズムは、入力として（値または参照による）1つ以上の信頼アンカーの仕様もサポートしています。クライアントが特定の認証機関（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として表されます。アルゴリズムは、サーバーによって実行されるチェックを定義して、証明書が有効かどうかを判断します。検証アルゴリズムは、検証ポリシーのパラメーターの1つです。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]で定義されている認証パス検証の1つの側面です。ただし、取り消しチェックは[PKIX-1]のオプション機能であり、取り消し情報は複数の形式で配布されます。クライアントは、取り消しチェックを実行する必要があるかどうか、および回復情報を応答で返品すべきかどうかをリクエストで指定します。
Servers MUST be capable of indicating the sources of revocation information that they are capable of processing:
サーバーは、取り消し情報のソースを処理できることを示すことができる必要があります。
1. full CRLs (or full Authority Revocation Lists);
1. 完全なCRL（または完全な権限の取り消しリスト）;
2. OCSP responses, using [OCSP];
2. [OCSP]を使用したOCSP応答。
3. delta CRLs; and
3. デルタCRLS;と
4. indirect CRLs.
4. 間接CRL。
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は、SCVPをHTTPで使用するために必要な詳細を提供します。
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ではこれらのMIMEタイプのHTTPを使用して説明しています。
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-Requestを使用する必要があります。SCVPリクエストには2つの形式があります。保護されておらず保護されています。保護されたリクエストは、クライアントをサーバーに認証するか、リクエスト応答ペアに対して匿名のクライアントの整合性を提供するために使用されます。保護は、デジタル署名またはメッセージ認証コード（MAC）によって提供されます。後の場合、MACキーは、Diffie-Hellmanなどのキー契約アルゴリズムを使用して導出されます。クライアントの公開キーが証明書に含まれている場合、クライアントの認証に使用される場合があります。より一般的には、クライアントのキー契約の公開鍵は一時的なものであり、匿名のクライアントの完全性をサポートします。
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 }
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).
保護された要求は、signedDataまたはAuthenticatedDataのいずれかにカプセル化されたCVRequestで構成されており、ContentInfoでカプセル化されています。つまり、SignedDataまたはAuthenticatedDataのいずれかのcontestiNFOフィールドは、ID-CT-SCVP-CertValRequestの値を持つecontentTypeフィールドと、際立ったエンコードルール（der）にエンコードされたcvrequestを含むecontentフィールドで構成されています。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]に準拠する証明書によってサブジェクトIDにバインドされた公開キーが必要であり、その証明書は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. 拡張されたキーの使用拡張機能が存在する場合、SCVPクライアントOID（セクション3.11を参照）、ayextedededKeyUsage OID、または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サーバーによる証明書の検証を支援するために、リクエストに他の証明書を含めることができます。SigneDataのSignerinFosフィールドには、Signerinfoが1つだけ含まれている必要があります。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.
クライアントは、キー契約の公開キー、またはリクエストをカプセル化する認証されたDataに、キー契約の公開キーを含む証明書を明確に参照する必要があります。Epememeral Key Asmiralキーペアが使用されている場合、Epememeral Key Asmiral Public Keyは、KeyAgreerecipientInfoのOriginatorKeyフィールドに掲載されます。SCVPサーバーのキー契約キーは、検証ポリシー応答メッセージに含まれています（セクション6を参照）。認証されたDataのReciontientInfosフィールドには、SCVPサーバーの情報を含む正確に1つのRecipientIntInfoを含める必要があります。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、AuthentivedData、および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をエンコードする必要があります。新鮮な応答の作成を主張するSCVPクライアント（例えば、リプレイ攻撃から保護するため、または情報が最新であることを確認するため）は、RequestNonceをサポートする必要があります。残りのアイテムのサポートは、クライアントの実装ではオプションです。
Conforming servers MUST be able to parse CVRequests that contain any or all of the optional items.
適合サーバーは、オプションのアイテムの一部またはすべてを含むcVrequestを解析できる必要があります。
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つでなければなりません。この仕様の将来の更新では、構文やセマンティクスに変更がある場合は、他の値を指定する必要があります。ただし、バージョン番号を変更せずに新しい拡張機能を定義できます。
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、生産、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アイテムは、クライアントがサーバーに応答で返すことを望んでいるオブジェクトを指定します。VaridationPolicyアイテムは、クライアントがサーバーに使用することを望んでいる検証ポリシーを指定します。ResponseFlagsアイテムにより、クライアントは応答のオプション機能を要求できます。ServerContextInfoアイテムは、以前のリクエスト応答からの追加情報が必要であることをサーバーに伝えます。検証時間項目は、クライアントがサーバーにチェックを実行することを望んでいる日付と時刻を示します。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.
適合クライアントは、少なくとも1つの証明書、チェック、および検証policyを指定する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]からインポートされ、属性の定義は[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を計算するために使用されるハッシュアルゴリズムは、ハサルゴリズムで指定されています。Certhashを計算するために使用されるハッシュアルゴリズムは、サーバーの検証ポリシー応答メッセージのハスハルゴリズム項目で指定されたハッシュアルゴリズムの1つである必要があります。
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は証明書を一意に識別するシリアル番号です。公開キーの証明書の場合、発行者は、一般名の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サーバーの実装の適合は、複数の証明書を使用してcertreferenceを処理できる必要があります。SCVPサーバーの実装の適合は、公開キーまたは属性証明書のいずれかを含むcertreferenceを解析できる必要があります。SCVPサーバーの実装の適合は、PKCReferenceでCERTとPKCREFの選択の両方を解析できる必要があります。属性証明書を処理するSCVPサーバーの実装の適合は、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-BUILD-PKC-PATH：トラストアンカーへの前向き認証パスを構築します（[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-BUILD-VALID-PKC-PATH：信頼アンカーへの検証済み認定パスを構築します（不要）。
- 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-BUILD-STATUS-CHECKED-PKC-PATH：信頼のアンカーへの検証済み認定パスを構築し、認定パスで取り消しステータスチェックを実行します。
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.
[RQMTS]で定義されている委任パスディスカバリー（DPD）をサポートするSCVPサーバー実装の適合は、ID-STC-Build-PKC-PATHチェックをサポートする必要があります。[RQMTS]で定義されている委任パス検証（DPV）をサポートするSCVPサーバー実装の適合は、ID-STC-Build-Valid-PKC-PATHおよびID-STC-Build-Status-Checked-PKC-PATHチェックをサポートする必要があります。
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-BUILD-AA-PATH：属性証明書（AC）発行者のトラストアンカーへの将来の認証パスを構築します。
- id-stc-build-valid-aa-path: Build a validated certification path to a trust anchor for the AC issuer;
- ID-STC-BUILD-VALID-AA-PATH：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-BUILD-STATUS-CHECKED-AA-PATH：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-STATUS-AC-AND-BUILD-STATUS-CHECKED-AA-PATH：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.
適合クライアントの実装は、標準チェックの少なくとも1つのアサーションをサポートする必要があります。適合クライアントは、複数のチェックのアサーションをサポートする場合があります。適合クライアントは、このセクションで定義されているすべてのチェックをサポートする必要はありません。
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アイテムは、チェックアイテムで指定されたチェックの結果に加えて、QuerieDCertsアイテムの証明書のSCVPサーバーから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:
公開キーの証明書の場合、次のWantBackがこのドキュメントで定義されています。
- 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-BEST-CERT-PATH：検証された証明書を含む証明書用に構築された認定パス。
- id-swb-pkc-revocation-info: Proof of revocation status for each certificate in the certification path;
- ID-SWB-PKC-Revocation-INFO：認定パスの各証明書の取り消しステータスの証明。
- id-swb-pkc-public-key-info: The public key from the certificate that was the subject of the request;
- ID-SWB-PKC-PUBLIC-KEY-INFO：リクエストの対象となった証明書の公開鍵。
- id-swb-pkc-all-cert-paths: A set of certification paths for the certificate that was the subject of the request;
- ID-SWB-PKC-ALL-CERT-PATHS：リクエストの対象となった証明書の認証パスのセット。
- id-swb-pkc-ee-revocation-info: Proof of revocation status for the end entity certificate in the certification path; and
- ID-SWB-PKC-EE-Revocation-INFO：認定パスの最終エンティティ証明書の取り消しステータスの証明。と
- id-swb-pkc-CAs-revocation-info: Proof of revocation status for each CA certificate in the certification path.
- ID-SWB-PKC-CAS-revocation-info：認定パスの各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-PKC-PUBLIC-KEY-INFO Wantbacksをサポートする必要があります。[RQMTS]で定義されている委任パスディスカバリー（DPD）をサポートするSCVPサーバーの実装の適合は、ID-SWB-PKC-Best-Cert-PathおよびID-SWB-PKC-Revocation-Info Wantbackをサポートする必要があります。
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つの方法を提供します。クライアントは、ServerContextInfoを使用して、一度に1つのパスを要求できます（セクション3.2.6を参照）。各パスを取得した後、クライアントは前のリクエストからServerContextInfoを送信して、クライアントが適切なパスを見つけたか、サーバーが（ServerContextInfoを返さないことで）これ以上のパスが使用できないことを示す（ServerContextInfoを返さないことによって）見つけることができます。あるいは、クライアントは、ID-SWB-PKC-All-Cert Paths Wantbackを使用して単一の要求を送信することができます。その場合、サーバーは1つの応答で利用可能なすべてのパスを返します。
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-ALL-CERTパスに応じて戻るパスの数を制限する場合があります。リクエストにID-SWB-PKC-ALL-CERT PATHS WANTBACKが含まれている場合、応答にはServerContextInfoを含めるべきではありません。
For attribute certificates, the following wantBacks are defined in this document:
属性証明書の場合、次のWantBackはこのドキュメントで定義されています。
- 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-PATH：AC発行者証明書用に構築された認証パス。
- id-swb-ac-revocation-info: Proof of revocation status for each certificate in the AC issuer certification path; and
- ID-SWB-AC-REVOCOTION-INFO：AC発行者認定パスの各証明書の取り消しステータスの証明。と
- id-swb-aa-revocation-info: Proof of revocation status for the attribute certificate.
- ID-SWB-AA-Revocation-INFO：属性証明書の取り消しステータスの証明。
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.
その他の仕様は、追加のウォンバックを定義する場合があります。
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をサポートする必要はありません。
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:
検証policyアイテムの構文は次のとおりです。
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クライアントの実装が適合している必要があります。適合クライアントの実装は、検証policyのオプションアイテムのいずれかまたはすべてをサポートする場合があります。
Conforming SCVP servers MUST support processing of a ValidationPolicy that contains any or all of the optional items.
適合SCVPサーバーは、オプションのアイテムのいずれかまたはすべてを含む検証policyの処理をサポートする必要があります。
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アイテムは、許容可能な証明書ポリシーセットを提供します。阻害ポリックマッピングアイテムは、認証パス検証中の証明書ポリシーマッピングを阻害します。requirexplicitPolicyアイテムには、証明書ポリシー拡張に少なくとも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アイテムを使用して指定されます。パラメーター構造の構文とセマンティクスは、バルポリドとしてエンコードされたオブジェクト識別子によって定義されます。検証ポリシーには、デフォルトの検証ポリシーなどのパラメーターがない場合（セクション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基本検証アルゴリズムまたは別のアルゴリズムの使用を要求できます。ID証明書の場合、基本的な検証アルゴリズムは、[PKIX-1]のセクション6で定義されているように、認証パス検証アルゴリズムを実装する必要があります。属性証明書の場合、[PKIX-AC]のセクション5で定義されているように、基本的な検証アルゴリズムは認証パス検証を実装する必要があります。その他の検証アルゴリズムは、基本アルゴリズムの関数以上の関数を実装する場合がありますが、検証アルゴリズムは基本的な検証アルゴリズムに準拠した結果を生成する必要があります。つまり、基本アルゴリズムの検証要件は、新たに定義された検証アルゴリズムから省略できません。ただし、他の検証アルゴリズムは、基本的な検証アルゴリズムを使用して有効なパスを拒否する場合があります。基本的な検証アルゴリズムを識別するオブジェクト識別子は次のとおりです。
id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 }
When id-svp-basicValAlg appears in valAlgId, the parameters item MUST be absent.
id-svp-basicvalalgが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を参照）。これらのエラーは、すべての検証アルゴリズムが基本的な検証アルゴリズムの機能を実装する必要があるため、他の検証アルゴリズムで使用できます。
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アイテムで指定された証明書）よりも遅いことを意味します。
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-not-yet-valid値は、リクエストに使用された検証時間が最後の証明書の前にあったことを意味します。
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の価値は、クライアント指定の信頼アンカーに対して認証パスを構築できないことを意味しますが、サーバーのデフォルト検証ポリシーで指定された信頼アンカーの1つにはパスが存在します。
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-INVALIDKEYPURSIPS値は、最終証明書の拡張キー使用拡張（[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であり、rebricit_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.
名前検証アルゴリズムにより、クライアントは、基本的な検証アルゴリズムに指定された要件に加えて、最終証明書に表示する必要がある1つ以上のサブジェクト名を指定できます。名前検証アルゴリズムにより、クライアントはアプリケーション識別子と名前をサーバーに提供できます。アプリケーション識別子は、リクエストで提供された名前と証明書の名前を比較する際に使用する名前の一致ルールを定義します。
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].
一般名は[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.
検証名で複数の名前が提供されている場合、すべての名前は同じタイプでなければなりません。証明書には、namecompalgidに関連付けられた名前の一致ルールに従って、検証名で提供された各名前の一致名を含める必要があります。この仕様では、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でなければならず、使用する一致するルールは[pkix-1]で定義されます。証明書には、件名フィールドまたはsubjectaltname拡張子のディレクトリ名のいずれかに一致する名前が含まれている必要があります。この仕様では、次のように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]である場合、リクエストで提供される一般名は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の1つ以上の名前が含まれている場合、セットのいずれかの一致が許容できると見なされます。subjectaltname拡張子が省略されている場合、または型dnsnameの名前が含まれていない場合、証明書のサブジェクトフィールドの（最も具体的な）一般名フィールドを使用する必要があります。
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はfoo.a.comと一致しますが、bar.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]である場合、リクエストで提供される一般名は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-name-mismatch値は、クライアントが要求に名前を提供したことを意味します。これは、サーバーが認識し、サーバーは証明書に対応する名前タイプを見つけましたが、付属の名前と一致することができませんでした。たとえば、クライアントは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-unnknown-alg値は、クライアントがサーバーが認識していないというnamecompalgidを提供したことを意味します。
The id-nvae-bad-name value means the client supplied either an empty or malformed name in the request.
ID-nvae-bad-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-bad-name-type値は、クライアントがアプリケーション識別子に不適切な名前タイプを提供したことを意味します。たとえば、クライアントは、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サーバーが使用する必要がある証明書ポリシー識別子のリストを指定します。ユーザーPolicySetアイテムは、[PKIX-1]のセクション6で定義されているように、ユーザーInitial-Policy-Setを指定します。AnyPolicy OIDを含むユーザーPolicySetは、Any-PolicyのユーザーInitial-Policy-Setを示します。
SCVP clients SHOULD support the userPolicySet item in requests, and SCVP servers MUST support the userPolicySet item in requests.
SCVPクライアントは、リクエストでuserPolicySetアイテムをサポートする必要があり、SCVPサーバーはリクエストでユーザーポリシセットアイテムをサポートする必要があります。
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を参照）。クライアントがサーバーにポリシーマッピングを阻害することを望んでいる場合、リクエストで阻害されたポリックマッピングが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.
requirexplicitPolicyアイテムは、認証パス検証アルゴリズムへの入力を指定し、証明書ポリシー拡張に少なくとも1つの有効なポリシーが必要かどうかを制御します（[PKIX-1]、セクション6.1.1を参照）。クライアントがサーバーに少なくとも1つのポリシーを要求することを望んでいる場合、requesexplicitPolicyはリクエストで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タイプには、1つ以上の信頼のアンカー仕様が含まれています。証明書の参照を使用して、証明書のハッシュと識別名で信頼アンカーを識別することができます。または、信頼のアンカーを直接提供することができます。シーケンス内の信頼のアンカー仕様の順序は重要ではありません。証明書に署名するための[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定義の少なくとも1つを満たす必要があります。クライアントが複数の可能性を受け入れることをいとわない場合、クライアントは可能なパターンのシーケンスに合格します。各keyUSAGEには、リクエストに設定された1つ以上のビットのセットを含めることができます。すべてのビットを証明書に設定して、SCVPリクエストのkeyUSAGEのインスタンスと一致する必要があります。証明書キーの使用拡張機能には、要求されるよりも多くの使用法が含まれる場合があります。たとえば、クライアントがデジタル署名または非繰り返しのいずれかをチェックしたい場合、クライアントは2つのキーユーザー値を提供します。1つはデジタル署名セットを備え、もう1つは非repudiationセットを備えています。主要な使用法延長が証明書に存在しない場合、証明書はすべての使用法に対して適切であると考える必要があります。したがって、SCVP要求のパターンは一致します。
SCVP clients SHOULD support keyUsages, and SCVP servers MUST support keyUsages.
SCVPクライアントはKeyUSAGEをサポートする必要があり、SCVPサーバーはKeyUSAGEをサポートする必要があります。
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.
たとえば、クライアントがTransport Layer Security（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.
拡張機能が存在しない場合、または存在してAnyextededKeyUsage oidを主張する場合、リクエストで指定されたすべての使用法が一致します。拡張機能が存在し、ayextedededkeyusage 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クライアントは、拡張キーユーザーをサポートする必要があり、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 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オブジェクト識別子を備えた拡張キー使用構造を含める必要がある場合があります。この場合、クライアントはリクエストに指定されたKeyUsagesアイテムを含め、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つ以上の指定された使用法がリクエストに含まれている場合、証明書には拡張キー使用延長を含める必要があり、リクエストで指定されたすべての使用法は証明書延長に存在する必要があります。証明書延長には、リクエストで指定されているよりも多くの使用法が含まれる場合があります。指定されたキー使用は、ayextededkeyusage 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クライアントは、特定のKeyUsagesをサポートする必要があり、SCVPサーバーはSpeciedKeyUsagesをサポートする必要があります。
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はfalsに設定されます。クライアントが値に含めるために検証ポリシーを含めるようにサーバーに要求する主な理由は、単一のオブジェクトでリクエスト応答交換をアーカイブすることです。つまり、クライアントは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サーバーは保護されていない応答を返すことをサポートする必要があります。ローカルポリシーに基づいて、この値がfalsに設定されている場合、サーバーは保護または保護されていない応答を返すように構成できます。ローカルポリシーに基づいて、サーバーが保護された応答を返すことができない場合、この値が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.
オプションの検証タイムアイテムは、存在する場合、SCVPクライアントがサーバーにチェックの実行を望んでいる日付と時刻を指示します。検証時間が存在しない場合、サーバーがリクエストを処理する日付と時刻を使用して、サーバーは検証を実行する必要があります。検証時間が存在する場合、一般化された時間としてエンコードする必要があります。サーバーは現在の時刻（デフォルト）または前の時間を使用して有効性チェックのみを実行できるため、提供される検証時間は遡及時間でなければなりません。サーバーの現在の時刻の時計のスキュー内である場合、サーバーはリクエストで提供されている検証時間を無視できます。
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.
一般化された時間の値は、ユニバーサル調整時間（UTC）（グリニッジ平均時間とズールー時間とも呼ばれます）で表現する必要があり、秒数がゼロであっても、秒（つまり、時間はyyyymmdhhmmssz）を含める必要があります。一般化された時間値は、分数秒を含めてはなりません。
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.
応答中の対応する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クライアントは、現在の時刻以外の検証時間をサポートする場合があります。SCVPサーバーは、現在の時刻を使用してサポートする必要があり、クライアントがリクエストで検証時間を設定することをサポートする必要があります。
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アイテムには少なくとも1つの証明書が含まれている必要があり、中間科は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クライアントは中間科のサポートをサポートする必要があり、SCVPサーバーはインターメディアテカートをサポートする必要があります。
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アイテムは、CRLS、Delta CRLS [PKIX-1]、およびSCVPサーバーが認証パスの検証時に使用できるOCSP応答[OCSP]などの取り消し情報を指定します。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.
クライアントは、CRLSとDelta CRLを分離することにより、SCVPサーバーに礼儀正しくする必要があります。ただし、2つは共通の構文を共有するため、SCVPサーバーは、SCVPクライアントによって通常のCRLとして識別されている場合でも、Delta 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.
CRLS、Delta CRLS、およびOCSP応答は、取り消し情報として提供できます。必要に応じて、追加のオブジェクト識別子を将来の追加の取り消し情報タイプに割り当てることができます。
The revInfos item uses the RevocationInfos type, which has the following syntax:
Revinfosアイテムは、次の構文を備えたRegocationInfosタイプを使用します。
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応答を使用できるようにする場合があります。そうするとき、クライアントは生産項目を使用して、キャッシュされた応答の新鮮さに関する要件を表現することができます。プロデューわったアイテムは、許容可能なキャッシュされた応答が生成された可能性がある最も早い日付と時刻を示しています。生成されたアイテムは、一般化されたタイプのタイプを使用して、UTCの日付と時刻を表します。生成されたアイテムの値は、検証時間とは無関係です。
GeneralizedTime value MUST be expressed in UTC, as defined in Section 3.2.7.
セクション3.2.7で定義されているように、一般化された時間値は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クライアントは、リクエストで生産値を使用してサポートする場合があります。SCVPサーバーは、リクエストで生産値をサポートする場合があります。キャッシュされた応答をサポートするSCVPサーバーは、リクエストの生成価値をサポートする必要があります。
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.
重要なアイテムはブール値です。各拡張機能は、クリティカル（真の値を持つ）または非批判（falsの値を持つ）のいずれかとして指定されます。デフォルトでは、拡張機能は非クリティカルです。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アイテムには、オクテット文字列が含まれています。Octet文字列内には拡張値があります。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アイテムは、一般名のシーケンスでなければなりません。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サーバーがキャッシュされていない応答を返す必要があることを好むことを表明しています。サーバーがキャッシュされていない応答を返す場合、応答のリクエストからのReprectNonceの値をRESPNONCEアイテムとして含める必要があります。ただし、サーバーは、repnonceを持ってはならないキャッシュされた応答を返す場合があります。
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で説明されているようにcachedResponseフラグをfalseに設定する場合、クライアントはSCVPサーバーがRespnonceを含む非キャッシュ応答またはエラー応答のいずれかを返す必要があることを示しています。クライアントは、すべてのリクエストに、攻撃者がサーバーから古い応答を再生することにより、中間の男として行動するのを防ぐために、すべての要求に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を含めることなく、cachedResponseフラグをfalseに設定してはなりません。このようなリクエストを受信するサーバーは、InvalidRequestエラー応答を返す必要があります。
The requestNonce item, if present, MUST be an OCTET STRING that was generated exclusively for this request.
RequestNonceアイテムは、存在する場合は、このリクエストのみで生成されたOctet文字列でなければなりません。
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サーバーのIDを示すために使用され、応答がデジタル的に署名されている場合、クライアントが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アイテムは、存在しないか、protectResponseがtrueに設定されていることに存在します。
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拡張機能のいずれかでrepondernameで指定された名前を含む証明書または（b）または（b）返品を含む証明書に対応する秘密キーを使用して、応答にデジタル的に署名する必要があります。サーバーが指定された名前を主張する証明書を所有していないことを示すエラー。
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.
重要なアイテムはブール値です。各拡張機能は、クリティカル（真の値を持つ）または非批判（falsの値を持つ）のいずれかとして指定されます。デフォルトでは、拡張機能は非クリティカルです。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アイテムには、オクテット文字列が含まれています。Octet文字列内には拡張値があります。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アイテムには、サーバーが応答メッセージに署名するためにどのアルゴリズムを使用するかを示すアルゴリズムIdentidifierが含まれています。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アイテムは、存在しないか、protectResponseがtrueに設定されていることに存在します。
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アイテムは、サーバーの検証ポリシー応答メッセージの署名Generationアイテムに指定された署名アルゴリズムの1つを指定する必要があります。
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アイテムが存在し、サーバーの検証ポリシー応答メッセージの署名項目に含まれるアルゴリズムを指定する場合、サーバーは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アイテムが存在しないか、存在しているが、サーバーによってサポートされていないアルゴリズムを指定している場合、サーバーの検証ポリシー応答メッセージの署名項目で指定されているように、サーバーのデフォルトの署名アルゴリズムを使用してサーバーに応答に署名する必要があります。
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アイテムには、サーバーがどのハッシュアルゴリズムを使用するかを示すオブジェクト識別子が含まれています。応答のリクエストハッシュアイテムのハッシュ値を計算します。FullRequestInResponseがTRUEに設定されている場合、SCVPクライアントはこのアイテムを含めるべきではありません。含まれている場合、Hashalgアイテムは、サーバーの検証ポリシー応答メッセージのハッシュゴリズム項目で指定されたハッシュアルゴリズムの1つを指定する必要があります。
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サーバーは、このアイテムを含むリクエストを処理できる必要があります。サーバーがこのメッセージへの応答をリクエストハッシュを含む応答を返している場合、次のとおりです。
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アイテムに含まれるアルゴリズムを指定する場合、サーバーはHashalgで指定されたアルゴリズムを使用してRequestHashを計算する必要があります。
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. それ以外の場合、ハッシュハルグアイテムが存在しないか、存在しているが、サーバーによってサポートされていないアルゴリズムを指定している場合、サーバーは、サーバーの検証ポリシー応答メッセージのハッシュハルゴリズム項目で指定されているサーバーのデフォルトハッシュアルゴリズムを使用してリクエストハッシュを計算する必要があります。
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）が含まれている場合、デジタル署名ビットセット、非repudiationビットセット、または両方のビットセットのいずれかが必要です。
If the certificate used to validate an AuthenticatedData validation request includes the key usage extension, it MUST have the key agreement bit set.
認証されたData検証要求を検証するために使用される証明書にキー使用拡張機能が含まれている場合、キー契約ビットが設定されている必要があります。
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、ayextededededededeyusage 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. falseに設定されたResponseを保護するリクエストに対する成功応答。これらの応答は、サーバーによって保護されるべきではありません。
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. falseに設定されたResponseを保護する要求に対するエラー応答。これらの応答は、サーバーによって保護されるべきではありません。
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が有効な場合、認証されたData要求に対するエラー応答。サーバーはこれらの応答を保護する必要があります。
7. All other error responses MUST NOT be protected by the server.
7. 他のすべてのエラー応答は、サーバーによって保護されてはなりません。
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 }
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または認証されたdataのいずれかにカプセル化されたcVResponseで構成され、ContentInfoでカプセル化されます。つまり、SignedDataまたはAuthenticatedDataのいずれかのcontaturatedContentInfoフィールドは、ID-CT-SCVP-CertValResponseの値を持つecontentTypeフィールドと、derエンコードされたcvResponseを含むecontentフィールドで構成されています。
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内のCRLSフィールドで1つ以上のCRLを提供する場合があります。SigneDataのSignerinFosフィールドには、Signerinfoが1つだけ含まれている必要があります。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.
認証されたDataの受信フィールドには、リクエストを送信したクライアントの情報を含む正確な1つのRecipientIntIntInfoを含める必要があります。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、生成、およびRespondestatusアイテムが含まれている必要があります。cVResponseには、repvalidationPolicy、requestRef、requestorref、requestorname、ReplyObjects、Respnonce、serverContextInfo、およびcvResponsexensionsアイテムも含まれます。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またはcVResponsexentionsアイテムを含むcVResponseを構築できる場合があります。適合SCVPサーバーは、残りのオプションアイテムのいずれかとcVresponseを構築できる必要があります。SCVPクライアントの適合は、次のオプションの項目を使用してcVResponseを処理できる必要があります：respalidationPolicy、requestRef、requestorname、ReplyObjects、およびrespnonce。
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またはcvResponsexensionsアイテムを含むcVResponseを処理できる必要があります。適合クライアントは、cvresponsexensionsアイテムに重要な拡張機能が存在するかどうかを判断できる必要があります。
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.
生成されたアイテムは、SCVPサーバーが応答を生成した日時を示しています。生産項目は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].
Restupdestatusアイテムは、その要求についてSCVPクライアントにステータス情報を提供します。Respondestatusアイテムには、数値ステータスコードと、[utf8]で定義されたUTF-8変換形式でエンコードされた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:
RestonseStatusアイテムは、次の構文を備えたRestonseStatusタイプを使用します。
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サーバーは、policyを阻害するための要求された値をサポートしていません。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:
RespalidationPolicyアイテムには、完全な検証ポリシーへの参照または、リクエストを検証するためにサーバーが使用する価値による完全なポリシーが含まれています。成功応答に存在する必要があり、エラー応答に存在してはなりません。参照または価値でポリシーを返すかの選択は、リクエストのResponsevalidationPolbyRefアイテムによって制御されます。結果の検証ポリシーは、以下の連合です。
1. Values from the request.
1. リクエストからの値。
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:
respalidationPolicyの構文は次のとおりです。
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.
検証ポリティ項目は、セクション3.2.4で定義されています。ResponseValidationPolbyRefがリクエストでfalsに設定されている場合、ValidationPolicyアイテムのすべてのアイテムを入力する必要があります。ResponseValidationPolbyRefがTrueに設定されている場合、ValidationPolicyアイテムのオプションアイテムは、リクエストの値が参照される検証ポリシーとは値と異なるアイテムに対してだけ入力する必要があります。
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のハッシュです。CVRequestのハッシュを計算するために使用される一方向ハッシュ関数は、セクション3.9で指定されているとおりです。RequestHashアイテムは2つの目的を果たします。まず、クライアントがリクエストが悪意を持って変更されていないことを判断することができます。第二に、Connectionless Protocolsを使用するときに、クライアントが応答を要求に関連付けることができます。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) リクエストの要求項目でクライアントによって主張された身元、
(2) an authenticated identity for the client from a certificate or other credential used to authenticate the request, or
(2) リクエストを認証するために使用される証明書またはその他の資格からクライアントのための認証されたIDまたは
(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アイテムには、CERT、ReplyStatus、ReplyValtime、ReplyChecks、ReplyWantBacksアイテムが含まれている必要があります。Certreplyアイテムには、検証エラー、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は、リクエストの最初の証明書に対応する必要があります。
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アイテムは、特定の証明書のリクエストについてステータス情報をクライアントに提供します。RespondestatusアイテムはReplyStatusアイテムとは異なることに注意してください。Respondestatusアイテムは要求全体のステータスですが、ReplyStatusアイテムは個々のクエリアイテムのステータスです。
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障害：すべてのチェックが正常に実行されました。ただし、1つ以上の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つ以上の証明書の前に検証時間の前に有効な認証パスが見つかったことをクライアントに伝えるために使用されます。。
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の情報が正しかった時間を示しています。ReplyValimeアイテムは、一般化されたタイプのタイプを使用して、UTCの日付と時刻を表します。セクション3.2.7の一般化時間のエンコーディングルールを使用する必要があります。
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.
リクエスト内で、オプションの検証タイムアイテムは、SCVPクライアントがサーバーにチェックを実行することを望んでいる日付と時刻を示します。検証時間が存在しない場合、サーバーは、サーバーがリクエストを処理する日時をクライアントに提供するかのように応答する必要があります。
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.
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:
AC発行者認定パスのステータス値は、単純な検証処理とともに信頼できるルートに構築されます{ID-STC 5}は、次のいずれかです。
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発行者認定パスビルディングの信頼ルートへの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アイテムのオブジェクト識別子（OID）とOctet文字列が含まれています。Octet文字列内には要求された値があります。リクエストのWantbackアイテムのOIDは、対応する返信値を識別するために使用されます。ReplyWantBacksアイテムのOIDSは、リクエストのWantbackアイテムのOIDと一致する必要があります。非誤差の応答の場合、ReplyWantBacksには、リクエストで指定されたWantBackごとに1つのReplyWantBackを含める必要があります（ID-SWB-PKC-CERTおよびID-SWB-AC-CERTを除き、要求された情報が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}には、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}のオクテット文字列値には、再巻き戻し型タイプが含まれています。Revinfowantbackタイプは、regocationInfosタイプのシーケンスであり、オプションのcertBundleです。RegocationInfosタイプの構文とセマンティクスについては、セクション3.2.9で説明しています。取消情報を検証するために必要な証明書がID-SWB-PKC-BEST-CERT-PATHまたはID-SWB-PKC-ALL-CERT-PATHS 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].
公開キー情報のオクテット文字列値{ID-SWB 4}には、件名PublicKeyInfoタイプが含まれています。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.
リクエストの証明書を確認するために使用されるAC発行者認証パスのOctet文字列値{ID-SWB 5}には、CertBundleタイプが含まれています。証明書型の構文とセマンティクスは、セクション3.2.8で説明されています。このcertbundleには、AC発行者証明書から始まり、Trust Anchorが発行した証明書で終了するパス内のすべての証明書が含まれています。
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 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.
AC発行者認証パスの取り消しステータスの証明のオクテット文字列値{ID-SWB 6}には、RevinFowantbackタイプが含まれています。Revinfowantbackタイプは、regocationInfosタイプのシーケンスであり、オプションのcertBundleです。RegocationInfosタイプの構文とセマンティクスについては、セクション3.2.9で説明しています。ID-AA-Cert-Path Wantbackで取り消し情報を検証するために必要な証明書が必要な場合は、CertBundleを含める必要があります。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.
属性証明書の取り消しステータスの証明のオクテット文字列値{ID-SWB 7}には、RevinFowantBackタイプが含まれています。Revinfowantbackタイプは、regocationInfosタイプのシーケンスであり、オプションのcertBundleです。RegocationInfosタイプの構文とセマンティクスについては、セクション3.2.9で説明しています。ID-SWB-AA-Cert-Path 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文字列値{id-swb 12}には、以下に定義されているように、asn.1タイプのcertbundlesが含まれています。証明書型の構文とセマンティクスは、セクション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}には、asn.1タイプのscvpresponsesが含まれています。SCVPサーバーがこの応答を生成するときに他のSCVPサーバーから取得した情報を使用した場合、SCVPresponsはそれらのサーバーから受信した各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.
パスのターゲット証明書の取り消しステータスの証明のオクテット文字列値{ID-SWB-13}には、RevinFowantbackタイプが含まれています。Revinfowantbackタイプは、regocationInfosタイプのシーケンスであり、オプションのcertBundleです。RegocationInfosタイプの構文とセマンティクスについては、セクション3.2.9で説明しています。取消情報を検証するために必要な証明書がID-SWB-PKC-BEST-CERT-PATHまたはID-SWB-PKC-ALL-CERT-PATHS 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 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 14}には、RevinFowantbackタイプが含まれています。Revinfowantbackタイプは、regocationInfosタイプのシーケンスであり、オプションのcertBundleです。RegocationInfosタイプの構文とセマンティクスについては、セクション3.2.9で説明しています。取消情報を検証するために必要な証明書がID-SWB-PKC-BEST-CERT-PATHまたはID-SWB-PKC-ALL-CERT-PATHS 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アイテムは、障害応答にのみ存在する必要があります。存在する場合、検証が失敗した理由を表す1つ以上のOIDを含める必要があります（基本検証アルゴリズムと名前検証アルゴリズムの検証エラーは、セクション3.2.4.2.2および3.2.4.2.4で定義されています）。ReplyStatusが3、5、6、7、または8の場合にのみ、検証エラーのアイテムを含める必要があります。SCVPサーバーは、検証が失敗したすべての理由を指定する必要はありません。SCVPクライアントは、検証エラーに含まれるOIDが認証パスのすべての検証エラーを表していると仮定してはなりません。
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アイテムは、一般化されたタイプのタイプを使用して、UTCの日付と時刻を表します。セクション3.2.7の一般化時間のエンコーディングルールを使用する必要があります。
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の1つと一致する必要があります。
The critical item is a BOOLEAN, and it MUST be set to FALSE.
重要なアイテムはブール値であり、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アイテムには、オクテット文字列が含まれています。Octet文字列内には拡張値があります。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なしでリクエストに対する特定の非キャッシュされた応答を返している場合、サーバーにはメッセージ固有のNONCEを含めることができます。デジタル署名されたメッセージの場合、サーバーは、Respnonceアイテムの値として、リクエストのSignerinfo内のSignedattrsのメッセージDigest属性の値を使用できます。
The requestNonce item uses the OCTET STRING type.
RequestNonceアイテムは、Octet文字列タイプを使用します。
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.
コンテキスト情報はクライアントにとって不透明ですが、異なる認証パスが返されることを保証する情報をサーバーに提供します（別の認定パスが見つかった場合）。コンテキスト情報は、サーバーの状態を示すことができます。または、すでにクライアントに返されている認証パスのハッシュシーケンスを含めることができます。プロトコルは、このアイテムの構造や要件を決定しません。ただし、実装者は、構造を選択する前に、このドキュメントのセキュリティに関する考慮事項セクションを確認する必要があります。
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.
存在する場合、cvResponsextensionsアイテムには、応答を拡張する拡張機能のシーケンスが含まれています。この仕様では、拡張機能を定義しません。この施設は、将来の仕様がSCVPを拡張することを可能にするために提供されています。拡張機能の構文は[PKIX-1]からインポートされます。cvResponsextensionsアイテムには、存在する場合、拡張アイテムのシーケンスが含まれています。それぞれには、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.
重要なアイテムはブール値です。各拡張機能は、クリティカル（真の値を持つ）または非批判（falsの値を持つ）のいずれかとして指定されます。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アイテムには、オクテット文字列が含まれています。Octet文字列内には拡張値があります。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.
リクエストでrequestortextアイテムをサポートするクライアントの実装を適合させる（セクション3.10を参照）は、このアイテムを含む応答を処理できる必要があります。適合サーバーは、応答で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つのメカニズムがあります。1つは、特定のSCVPサーバーキーに関するクライアントの知識に基づいており、もう1つは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応答の検証に使用される公開キーの暗号化ハッシュを保存できます。あるいは、クライアントは、認証されたData応答で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証明書を検証できないため、SCVPサーバー[RQMTS]に委任されたパス検証要求を作成している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で定義されている検証アルゴリズムを使用する必要があります。SCVPクライアントは、[PKIX-1]のセクション6.2で指定されているように、パス内の証明書の数を制限したり、初期名の制約を確立したりするなど、アルゴリズムに追加の制限を課す場合があります。
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.
証明書が検証ポリシーの応答に署名するために使用され、署名Data検証応答にキー使用拡張機能（[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.
認証されたData検証応答の証明書に主要な使用法拡張機能が含まれている場合、キー契約ビットが設定されている必要があります。
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）が含まれている場合、ayextedededkeyusage 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クライアントは、ValpolRequestアイテムを使用して、SCVPサーバーがサポートする検証ポリシーのリストを含むSCVPサーバーのポリシーと構成情報に関する情報を要求します。ValpolRequestがMIMEボディの部分にカプセル化されている場合、アプリケーション/SCVP-VP-Request Mime Bodyの部分に携帯する必要があります。
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 }
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を含める必要がありますが、サーバーは要求のnonceを含めてはならないキャッシュされた応答を返す場合があります。
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に固有のものではない可能性があるため、複数のValpolRequestに応答してサーバーによって再利用される場合があります。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.
応答は、SignedDataにカプセル化されたValpolResponseで構成され、ContentInfoでカプセル化されています。つまり、signedDataのcapsulatedContentINFOフィールドは、ID-CT-SCVP-ValpolResponse（1.2.840.113549.1.16.16.16.16.13）の値を持つecontentTypeフィールドで構成されています。SCVPサーバーには、SignedData内の証明書フィールドに独自の証明書を含める必要があり、SignedDataのSignerinFosフィールドには、Signerinfoが1つだけ含まれている必要があります。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 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.
ServerConfigurationIDアイテムは、ValidationPolicies、ValidationalG、AuthPolicies、DefaultPolicyValues、およびClockSkewで表されるように、サーバー構成のバージョンを一意に表す整数です。これらの値のいずれかが変更された場合、サーバーは新しいServerConfigurationIDを使用して新しいValpolResponseを作成する必要があります。構成が変更されていない場合、サーバーは複数のValpolResponseメッセージでServerConfigurationIDを再利用できます。ただし、サーバーが以前の構成に戻る場合、サーバーも構成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.
一般化された時間の値は、グリニッジ平均時間（Zulu）で表現し、セクション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.
NextUpDateの一般化された時間値は、セクション3.2.7で指定されているグリニッジ平均時間（ZULU）で表現する必要があります。
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.
recocationInfotypesアイテムにより、サーバーは処理が可能な取り消し情報のソースを示すことができます。recocationInfotysビット文字列の各ビットについて、サーバーは、対応する撤回情報タイプを処理でき、できない場合はゼロにビットを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で定義されているRespalidationPolicyが含まれています。検証policyアイテムのすべてのオプションアイテムに入力する必要があります。リクエストがデフォルトの検証ポリシーを参照し、クライアントがリクエスト内の他の値を提供してデフォルト値をオーバーライドしない場合、サーバーはこれらのデフォルト値を使用します。
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フィールドに関連付けられたエンコードルールを使用して、アルゴリズムIdentifierとして指定されています。サポートされているアルゴリズムは[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など）を含めることにより、サーバーは、その非対称アルゴリズムの秘密鍵と対応する認定公開キーを備えており、指定されたハッシュアルゴリズムをサポートしていると述べています。リストが注文されます。最初のデジタル署名アルゴリズムは、サーバーのデフォルトアルゴリズムです。デフォルトのアルゴリズムは、クライアントが別のアルゴリズムを指定しない限り、署名されたメッセージを保護するためにサーバーによって使用されます。
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メッセージに署名できないサーバーの場合、署名創造アイテムは空のシーケンスとしてエンコードされます。
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フィールドに関連付けられたエンコードルールを使用して、アルゴリズムIdentifierとして指定されています。サポートされているアルゴリズムは[pkix-alg]および[pkix-alg2]で定義されていますが、他の署名アルゴリズムもサポートされる場合があります。
For servers that do not verify signatures on CVRequest messages, the signatureVerification item is encoded as an empty sequence.
CVRequestメッセージの署名を検証しないサーバーの場合、署名verificationアイテムは空のシーケンスとしてエンコードされます。
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アイテムは、1つ以上のキー契約のパブリックキーと関連するパラメーターのシーケンスです。これは、クライアントがサーバーに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には、アルゴリズム識別子とサーバーの公開キーが含まれています。SCVPリクエストの認証Dataの主要な契約モードをサポートするSCVPサーバーは、[pkix-alg]で指定されているように、serverpublickeysおよびdiffie-hellmanキー契約アルゴリズムをサポートする必要があります。ServerPublickeysをサポートするSCVPサーバーは、[IKE]で定義されているように、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.
マカルゴリズム項目は、サーバーが主要な契約アルゴリズムの結果としてクライアントが使用することをサーバーが期待する対称アルゴリズムを指定します。主要な導入関数（KDF）は、主要な一致結果から対称的なキー材料を導出するものであり、マカルゴリズムによって暗示される場合があります。あるいは、KDFは、オプションのKDFアイテムを使用して明示的に指定される場合があります。
The clockSkew item is the number of minutes the server will allow for clock skew. The default value is 10 minutes.
ClockSkewアイテムは、サーバーがクロックスキューに許可する分数数です。デフォルト値は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アイテムが含まれている場合、サーバーで生成されたリクエストには、この値から構築されたrequestorrefアイテムと、SCVPサーバーの識別子を含む追加の一般名を含める必要があります。中継されるリクエストにrequestorrefアイテムが含まれていない場合、サーバーで生成されたリクエストには、SCVPサーバーの識別子を含む一般名を含む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アイテムで独自の識別子を発見した場合、エラーで応答する必要があり、Respondestatusアイテムのステータスコードを40に設定する必要があります。
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で定義されています。SCVPASN.1モジュールが続きます。
SCVP
SCVP
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(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 }
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 }
AttributeCertificate
FROM PKIXAttributeCertificate -- RFC 3281
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(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 }
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) } ;
-- 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
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サーバーが信頼するトラストアンカーと同様に、少なくとも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応答を使用して証明書の有効性を決定する場合、クライアントは応答でデジタル署名またはMacを検証して、予想されるSCVPサーバーが生成されることを確認する必要があります。クライアントが応答についてデジタル署名またはMacをチェックしない場合、中間の攻撃は、クライアントを欺いてサーバーからの修正された応答またはクライアントが尋ねなかった質問に対する応答を信じることができます。
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以外の値でユーザーPolicySetにリクエストに浸透しているが、requeseExplicitPolicyフラグを設定しない場合、サーバーは指定されたポリシーを満たさないパスの肯定的な回答を返すことができます。一般に、クライアントがanyPolicy以外の値を持つリクエストでユーザーPolicySetに入力する場合、requesExplicitPolicyフラグも設定する必要があります。これにより、すべての有効なパスが要求されたポリシーの少なくとも1つを満たすことが保証されます。
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では、証明書の歴史的検証は、検証時間で指定された時点で証明書の既知のステータスを返します。これは、デューデリジェンスを示すために使用される場合がありますが、必ずしも最も完全な情報を提供するわけではありません。証明書は、検証時間で指定された時間の後に取り消された可能性がありますが、取り消し通知は、検証時間の前にある無効性の日付を指定する場合があります。SCVPサーバーは、利用可能な最新の情報が証明書をその時点で信頼してはならないことを示しているにもかかわらず、肯定的な対応を提供します。SCVPクライアントは、このリスクを軽減するために、実際の関心時間よりも遅く検証時間を指定することを希望する場合があります。
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）を使用して通信されます。オブジェクトは、IANAによってPKIXワーキンググループに委任されたアークで定義されています。このドキュメントには、付録Aの4つのMIMEタイプの登録も含まれています。このドキュメントまたは予想される更新には、IANAによるさらなるアクションは必要ありません。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[stdwords] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラオンライン証明書ステータスプロトコル」、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.、Polk、W.、Ford、W。、およびD. Solo、「インターネット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] Farrell、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.、Polk、W。、およびR. Housley、「インターネットのアルゴリズムと識別子X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3279、2002年4月。
[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、「インターネットで使用するRSA暗号化の追加アルゴリズムと識別子X.509公開鍵インフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」RFC 4055、2005年6月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF8] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS] Hoffman、P.、ed。、「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.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1証明書処理」、RFC 3850、2004年7月。
[IKE] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKE] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-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. Kojo、「よりモジュール式指数（MODP）Internet Key Exchange（IKE）のDiffie-Hellmanグループ」、RFC 3526、2003年5月。
[RQMTS] Pinkas, D. and R. Housley, "Delegated Path Validation and Delegated Path Discovery Protocol Requirements", RFC 3379, September 2002.
[RQMTS] Pinkas、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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
ポール・ホフマン・フィリップ・ハラム・ベーカー・マイク・マイヤーズ・フランク・バリフィ・アミヤ・タルワルカル・ジョン・ティレンズピーター・シルベスター・ヤリー・ザンバソウ・ショーン・P・ターナー・ウェン・チェン・王フランシス・デュポン・デイブ・エングベルグ・ファイサル・マクソード
Thanks also to working group chair Steve Kent for his support and help.
また、彼のサポートと助けをしてくれたワーキンググループチェアのスティーブケントにも感謝します。
Four MIME media type registrations are provided in this appendix.
この付録には、4つのMIMEメディアタイプの登録が提供されています。
To: ietf-types@iana.org
Subject: Registration of MIME media type application/scvp-cv-request
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: scvp-cv-request
MIMEサブタイプ名：SCVP-CV-Request
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
Person & email address to contact for further information:
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>
Change controller: IESG
Change Controller：IESG
To: ietf-types@iana.org
Subject: Registration of MIME media type application/scvp-cv-response
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
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
Person & email address to contact for further information:
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>
Change controller: IESG
Change Controller：IESG
To: ietf-types@iana.org
Subject: Registration of MIME media type application/scvp-vp-request
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: scvp-vp-request
MIMEサブタイプ名：SCVP-VP-Request
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
Person & email address to contact for further information:
Ambarish Malpani <ambarish@yahoo.com>
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: None
使用に関する制限：なし
Author: Ambarish Malpani <ambarish@yahoo.com>
Change controller: IESG
Change Controller：IESG
To: ietf-types@iana.org
Subject: Registration of MIME media type application/scvp-vp-response
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
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
Person & email address to contact for further information:
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>
Change controller: IESG
Change Controller：IESG
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.
HTTPを使用して相互運用するSCVPクライアントとサーバーのために、次のルールが適用されます。
- 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.
- サーバーは、Cookie、Basic Authentication、または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メソッド用であることに注意してください。明らかに、投稿に適用されるルールのみがこの仕様に関連しています。
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".
コンテンツタイプのヘッダーには、値「Application/SCVP-CV-Request」が必要です。
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エンコードのバイナリ値です。
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応答は、適切なHTTPヘッダーで構成されており、セクション4で説明されているように、CMSボディに包まれたCVResponseのBERエンコードのバイナリ値が続きます。
The Content-Type header MUST have the value "application/scvp-cv-response".
コンテンツタイプのヘッダーには、値「アプリケーション/SCVP-CV応答」が必要です。
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".
コンテンツタイプのヘッダーには、値「Application/SCVP-VP-Request」が必要です。
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エンコードのバイナリ値です。
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".
HTTPベースのSCVPポリシー応答は、適切なHTTPヘッダーで構成されており、セクション6で説明されているように、CMSボディに包まれたValpolresponseのDerエンコードのバイナリ値が続きます。/SCVP-VP応答 "。
Authors' Addresses
著者のアドレス
Trevor Freeman Microsoft Corporation, One Microsoft Way Redmond, WA 98052 USA. EMail: trevorf@microsoft.com
Trevor Freeman Microsoft Corporation、ワンMicrosoft Way Redmond、WA 98052 USA。メール：trevorf@microsoft.com
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USAメール：housley@vigilsec.com
Ambarish Malpani Malpani Consulting Services EMail: ambarish@yahoo.com
Ambarish Malpani Malpani Consulting Servicesメール：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
David Cooper National Institute of Standards and Technology Drive、Mail Stop 8930 Gaithersburg、MD 20899-8930メール：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
Tim Polk National Institute of Standards and Technology Drive、Mail Stop 8930 Gaithersburg、MD 20899-8930メール：wpolk@nist.gov
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。