RFC5055 日本語訳
5055 Server-Based Certificate Validation Protocol (SCVP). T. Freeman,R. Housley, A. Malpani, D. Cooper, W. Polk. December 2007. (Format: TXT=198764 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループT.フリーマン要求をネットワークでつないでください: 5055年のマイクロソフトCorpカテゴリ: 標準化過程R.Housley不寝番セキュリティA.Malpani Malpaniコンサルタント業務D.桶屋W.ポークNIST2007年12月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
ベースのServer Certificate Validationプロトコル(SCVP)でクライアントは証明経路工事と証明経路合法化をサーバへ代表として派遣することができます。合法化方針によると、経路工事か合法化(例えば、経路の証明書のいずれも取り消されないのを確実にする)が実行されます。(それは、1人以上の信頼アンカーを含みます)。 それはクライアント実装の簡素化と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
1. 序論…4 1.1. 用語…4 1.2. SCVP概要…5 1.3. SCVP要件…5 1.4. 合法化方針…6 1.5. 合法化アルゴリズム…7 1.6. 合法化要件…8 2. 概要について議定書の中で述べてください…9 3. 合法化要求…9 3.1cvRequestVersion…12 3.2質問…12 3.2.1queriedCerts…13 3.2.2チェック…15
Freeman, et al. Standards Track [Page 1] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[1ページ]。
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
3.2.3. wantBack…16 3.2.4validationPolicy…19 3.2.4.1validationPolRef…20 3.2.4.1.1. デフォルト合法化方針…21 3.2.4.2validationAlg…22 3.2.4.2.1. 基本的な合法化アルゴリズム…22 3.2.4.2.2. 基本的な合法化アルゴリズム誤り…23 3.2.4.2.3. 合法化をアルゴリズムと命名してください…24 3.2.4.2.4. アルゴリズム誤りと合法化を命名してください…25 3.2.4.3userPolicySet…26 3.2.4.4inhibitPolicyMapping…26 3.2.4.5requireExplicitPolicy…27 3.2.4.6inhibitAnyPolicy…27 3.2.4.7trustAnchors…27 3.2.4.8keyUsages…28 3.2.4.9extendedKeyUsages…28 3.2.4.10specifiedKeyUsages…29 3.2.5responseFlags…30 3.2.5.1fullRequestInResponse…30 3.2.5.2responseValidationPolByRef…30 3.2.5.3protectResponse…31 3.2.5.4cachedResponse…31 3.2.6serverContextInfo…32 3.2.7validationTime…32 3.2.8intermediateCerts…33 3.2.9revInfos…34 3.2.10producedAt…35 3.2.11queryExtensions…35 3.2.11.1extnID…35 3.2 .11 .2 重要…35 3.2.11.3extnValue…36 3.3requestorRef…36 3.4requestNonce…36 3.5requestorName…37 3.6responderName…37 3.7requestExtensions…38 3.7.1extnID…38 3.7 .2 重要…38 3.7.3extnValue…38 3.8signatureAlg…38 3.9hashAlg…39 3.10. requestorText…39 3.11. SCVPは認証を要求します…40 4. 合法化応答…40 4.1cvResponseVersion…43 4.2serverConfigurationID…43
Freeman, et al. Standards Track [Page 2] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[2ページ]。
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
4.3. producedAt…44 4.4responseStatus…44 4.5respValidationPolicy…46 4.6requestRef…47 4.6.1requestHash…47 4.6 .2 最もfullRequest…48 4.7requestorRef…48 4.8requestorName…48 4.9replyObjects…49 4.9.1本命…50 4.9.2replyStatus…50 4.9.3replyValTime…51 4.9.4replyChecks…51 4.9.5replyWantBacks…53 4.9.6validationErrors…56 4.9.7nextUpdate…56 4.9.8certReplyExtensions…56 4.10. respNonce…57 4.11. serverContextInfo…57 4.12. cvResponseExtensions…58 4.13. requestorText…58 4.14. SCVP応答合法化…59 4.14.1. 簡単な主要な合法化…59 4.14.2. SCVPサーバ証明書合法化…59 5. サーバ方針要求…60 5.1vpRequestVersion…60 5.2requestNonce…60 6. 合法化方針応答…61 6.1vpResponseVersion…62 6.2maxCVRequestVersion…62 6.3maxVPRequestVersion…62 6.4serverConfigurationID…62 6.5thisUpdate…63 6.6のnextUpdateとrequestNonce…63 6.7supportedChecks…63 6.8supportedWantBacks…64 6.9validationPolicies…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サーバリレー…67
Freeman, et al. Standards Track [Page 3] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[3ページ]。
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
8. SCVP ASN.1モジュール…68 9. セキュリティ問題…76 10. IANA問題…78 11. 参照…78 11.1. 標準の参照…78 11.2. 有益な参照…79 12. 承認…80 付録A.MIMEメディアは登録証明書をタイプします…81 A.1scvp-cvアプリケーション/要求…81 A.2scvp-cvアプリケーション/応答…82 A.3scvp-vpアプリケーション/要求…83 A.4scvp-vpアプリケーション/応答…84 HTTPの上の付録B.SCVP…85 B.1。 SCVP要求…85 B.2。 SCVP応答…85 B.3。 SCVP方針要求…86 B.4。 SCVP方針応答…86
1. Introduction
1. 序論
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).
最初のクラスのアプリケーションはちょうど2つのものを必要とします: 公開鍵が証明書と確認で指定されたアイデンティティであるかもしれませんが、本来の目的に使用されて、公開鍵が属す確認。 そのようなクライアントは証明経路工事と合法化をSCVPサーバへ完全に代表として派遣することができます。これはしばしば代表として派遣された経路合法化(DPV)と呼ばれます。
The second class of applications can perform certification path validation, but they lack a reliable or efficient method of constructing a valid certification path. Such clients delegate certification path construction to the SCVP server, but not validation of the returned certification path. This is often referred to as delegated path discovery (DPD).
アプリケーションの二等は証明経路合法化を実行できますが、それらは有効な証明経路を構成する信頼できるか効率的なメソッドを欠いています。 そのようなクライアントは返された証明経路の合法化ではなく、SCVPサーバへの証明経路工事を代表として派遣します。 これはしばしば代表として派遣された経路発見(DPD)と呼ばれます。
1.1. Terminology
1.1. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [STDWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[STDWORDS]で説明されるように本書では解釈されることであるべきですか?
Freeman, et al. Standards Track [Page 4] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[4ページ]。
1.2. SCVP Overview
1.2. SCVP概要
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サーバは証明経路をクライアントに提供できます。 また、彼らはクライアントが証明経路を有効にするために必要とするCertificate Revocation Lists(CRLs)とOnline Certificate Statusプロトコル(OCSP)応答などの取消し情報がSCVPサーバで組み立てたクライアントを提供できます。中間的証明書を見つけて、ダウンロードするのに必要であるプロトコル、CRLs、および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. クライアントは合法化方針の管理を集結したがっている組織か共同体にいます。 これらの方針は、特定の信頼アンカーが使用されていることになっていると決めるかもしれません、そして、それをチェックする方針のタイプは証明経路合法化の間、実行されることになっています。
1.3. SCVP Requirements
1.3. SCVP要件
SCVP meets the mandatory requirements documented in [RQMTS] for DPV and DPD.
SCVPはDPVとDPDのために[RQMTS]に記録された義務的な必要条件を満たします。
Freeman, et al. Standards Track [Page 5] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[5ページ]。
Note that RFC 3379 states the following requirement:
RFC3379が以下の要件を述べることに注意してください:
The DPD response MUST indicate one of the following status
alternatives:
DPD応答は以下の状態代替手段の1つを示さなければなりません:
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) 経路発見方針によると、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]の意図を伴うconformantであることを決定しました。
1.4. Validation Policies
1.4. 合法化方針
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.
合法化方針(RFC3379[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要求は、単に有効にされるべき証明書、参照をつけられた合法化方針、および要求のためのどんなラン・タイム・パラメータも含む必要があります。
Freeman, et al. Standards Track [Page 6] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[6ページ]。
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人以上の信頼アンカー(値か参照による)の仕様をサポートします。 クライアントが特定の認証局(カリフォルニア)の発案である証明経路を要求するところでは、独身の信頼アンカーは指定されます。 クライアントが、数個のCAsのいずれかと共に始まる経路を受け入れても構わないと思っているところでは、1セットの信頼アンカーは指定されます。
The basic certification path processing algorithm also supports the following parameters, which are defined in [PKIX-1], Section 4:
また、基本的な証明経路処理アルゴリズムは以下のパラメタにセクション4をサポートします:(パラメタは[PKIX-1]で定義されます)。
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.
公認された公開鍵が使用されるかもしれない他のアプリケーション明確な目標。
1.5. Validation Algorithm
1.5. 合法化アルゴリズム
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
合法化アルゴリズムは、クライアントとサーバの間で申し合わせて断固として、OIDとして表されます。 アルゴリズムはサーバによって実行される、証明書が有効であるかどうか決定する照合を定義します。 合法化アルゴリズム
Freeman, et al. Standards Track [Page 7] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[7ページ]。
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.
合法化方針にはパラメタの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.
本書では定義されたものに加えて、基本的な合法化アルゴリズムでカバーされなかった決められた一定の要求を満たすためにアプリケーション特有の合法化アルゴリズムを定義できます。 ここに記録された合法化アルゴリズムはアプリケーションさらに特有の合法化アルゴリズムの開発のためのガイドとして勤めるべきです。例えば、新しいアプリケーション特有の合法化アルゴリズムは拡大という証明書の対象の代替名で特定の名前フォームを存在に要求するかもしれません。
1.6. Validation Requirements
1.6. 合法化要件
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. 完全なCRLs(または、完全なAuthority Revocation Lists)。
2. OCSP responses, using [OCSP];
2. [OCSP]を使用するOCSP応答。
3. delta CRLs; and
3. デルタCRLs。 そして
4. indirect CRLs.
4. 間接的なCRLs。
Freeman, et al. Standards Track [Page 8] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[8ページ]。
2. Protocol Overview
2. プロトコル概要
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サーバは、ただ一つの応答を作成して、それをクライアントに送ります。 HTTP[HTTP]の上にSCVPの典型的な使用があると予想されますが、また、デジタルに署名しているオブジェクトを輸送できるメールかいかなる他のプロトコルと共にもそれを使用できます。 付録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の種類を登録します、そして、Appendix BはHTTPとのこれらのMIMEの種類の使用について説明します。
3. Validation Request
3. 合法化要求
An SCVP client request to the server MUST be a single CVRequest item. When a CVRequest is encapsulated in a MIME body part, application/scvp-cv-request MUST be used. There are two forms of SCVP request: unprotected and protected. A protected request is used to authenticate the client to the server or to provide anonymous client integrity over the request-response pair. The protection is provided by a digital signature or message authentication code (MAC). In the later case, the MAC key is derived using a key agreement algorithm, such as Diffie-Hellman. If the client's public key is contained in a certificate, then it may be used to authenticate the client. More commonly, the client's key agreement public key will be ephemeral, supporting anonymous client integrity.
サーバへのSCVPクライアント要求はただ一つのCVRequestの品目であるに違いありません。 CVRequestがMIME身体の部分でカプセル化されるとき、scvp-cvアプリケーション/要求を使用しなければなりません。 SCVP要求の2つのフォームがあります: 保護がなく保護されています。 保護された要求は、サーバにクライアントを認証するか、または要求応答組の上に匿名のクライアント保全を提供するのに使用されます。 デジタル署名かメッセージ確認コード(MAC)で保護を提供します。 後の場合では、MACキーは、ディフィー-ヘルマンなどの主要な協定アルゴリズムを使用することで引き出されます。 クライアントの公開鍵が証明書に含まれているなら、それは、クライアントを認証するのに使用されるかもしれません。 より一般的に、匿名のクライアント保全をサポートして、クライアントの主要な協定公開鍵ははかなくなるでしょう。
A server MAY require all requests to be protected, and a server MAY discard all unprotected requests. Alternatively, a server MAY choose to process unprotected requests.
サーバは保護されるというすべての要求を必要とするかもしれません、そして、サーバはすべての保護のない要求を捨てるかもしれません。 あるいはまた、サーバは、保護のない要求を処理するのを選ぶかもしれません。
The unprotected request consists of a CVRequest encapsulated in a Cryptographic Message Syntax (CMS) ContentInfo [CMS]. An overview of this structure is provided below and is only intended as
保護のない要求はCryptographic Message Syntax(CMS)ContentInfo[CMS]でカプセル化されたCVRequestから成ります。 構造が以下に提供されて、意図するだけであるこの概要
Freeman, et al. Standards Track [Page 9] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[9ページ]。
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.
説明に役立つ。 決定的なASN.1は[CMS]で見つけられます。 多くの詳細は示されませんが、SCVPがCMSを利用する方法は明確に例証されます。
ContentInfo {
contentType id-ct-scvp-certValRequest,
-- (1.2.840.113549.1.9.16.1.10)
content CVRequest }
ContentInfocontentType、イドct scvp-certValRequest、--、(1.2.840.113549.1.9.16.1.10)内容CVRequest
The protected request consists of a CVRequest encapsulated in either a SignedData or AuthenticatedData, which is in turn encapsulated in a ContentInfo. That is, the EncapsulatedContentInfo field of either SignedData or AuthenticatedData consists of an eContentType field with a value of id-ct-scvp-certValRequest and an eContent field that contains a Distinguished Encoding Rules (DER)-encoded CVRequest. SignedData is used when the request is digitally signed. AuthenticatedData is used with a message authentication code (MAC).
保護された要求はContentInfoで順番にカプセル化されるSignedDataかAuthenticatedDataのどちらかでカプセル化されたCVRequestから成ります。 すなわち、SignedDataかAuthenticatedDataが値でeContentType分野から成るどちらかのEncapsulatedContentInfo分野、イドct scvp-certValRequest、そして、Distinguished Encoding Rules(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クライアントとサーバSHOULDはMACによって保護された要求と応答のためにAuthenticatedDataをサポートします。
If the client uses SignedData, it MUST have a public key that has been bound to a subject identity by a certificate that conforms to the PKIX profile [PKIX-1], and that certificate MUST be suitable for signing the SCVP request. That is:
クライアントがSignedDataを使用するなら、それには、対象のアイデンティティに縛られた公開鍵がPKIXプロフィール[PKIX-1]に一致している証明書でなければなりません、そして、その証明書はSCVP要求に署名するのに適当であるに違いありません。 それは以下の通りです。
1. If the key usage extension is present, either the digital
signature or the non-repudiation bit MUST be asserted.
1. 主要な用法拡大が存在しているなら、デジタル署名か非拒否ビットのどちらかについて断言しなければなりません。
2. If the extended key usage extension is present, it MUST contain
either the SCVP client OID (see Section 3.11), the
anyExtendedKeyUsage OID, or another OID acceptable to the SCVP
server.
2. 拡張主要な用法拡大が存在しているなら、それはSCVPサーバに許容できるSCVPクライアントOID(セクション3.11を見る)、anyExtendedKeyUsage OID、または別の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の証明書に明白な参照をつけなければなりません。 クライアントSHOULDは要求に証明書を含んでいますが、要求のサイズを減少させるために証明書を省略するかもしれません。 クライアントはSCVPサーバで証明書の合法化を支援するという要求で他の証明書を入れるかもしれません。SignedDataのsignerInfos分野はちょうど1SignerInfoを含まなければなりません。 SignedDataはunsignedAttrs分野を含んではいけません。
Freeman, et al. Standards Track [Page 10] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[10ページ]。
The client MUST put its key agreement public key, or an unambiguous reference to a certificate that contains its key agreement public key, in the AuthenticatedData that encapsulates the request. If an ephemeral key agreement key pair is used, then the ephemeral key agreement public key is carried in the originatorKey field of KeyAgreeRecipientInfo, which requires the client to obtain the server's key agreement public key before computing the message authentication code (MAC). An SCVP server's key agreement key is included in its validation policy response message (see Section 6). The recipientInfos field of AuthenticatedData MUST include exactly one RecipientInfo, which contains information for the SCVP server. The AuthenticatedData MUST NOT include the unauthAttrs field.
クライアントは主要な協定公開鍵を含む証明書に主要な協定公開鍵、または明白な参照を置かなければなりません、要求をカプセル化するAuthenticatedDataで。 はかない主要な協定主要な組が使用されているなら、はかない主要な協定公開鍵はKeyAgreeRecipientInfoのoriginatorKey分野で運ばれます。(KeyAgreeRecipientInfoは、メッセージ確認コード(MAC)を計算する前にクライアントがサーバの主要な協定公開鍵を得るのを必要とします)。 SCVPサーバの主要な協定キーは合法化方針応答メッセージに含まれています(セクション6を見てください)。 AuthenticatedDataのrecipientInfos分野はちょうど1RecipientInfoを含まなければなりません。(RecipientInfoはSCVPサーバのための情報を含みます)。AuthenticatedDataはunauthAttrs分野を含んではいけません。
The syntax and semantics for SignedData, AuthenticatedData, and ContentInfo are defined in [CMS]. The syntax and semantics for CVRequest are defined below. The CVRequest item contains the client request. The CVRequest contains the cvRequestVersion and query items; the CVRequest MAY also contain the requestorRef, requestNonce, requestorName, responderName, requestExtensions, signatureAlg, and hashAlg items.
SignedData、AuthenticatedData、およびContentInfoのための構文と意味論は[CMS]で定義されます。 CVRequestのための構文と意味論は以下で定義されます。 CVRequestの品目はクライアント要求を含んでいます。 CVRequestはcvRequestVersionと質問項目を含んでいます。 また、CVRequestはrequestorRef、requestNonce、requestorName、responderName、requestExtensions、signatureAlg、およびhashAlgの品目を含むかもしれません。
The CVRequest MUST have the following syntax:
CVRequestには、以下の構文がなければなりません:
CVRequest ::= SEQUENCE {
cvRequestVersion INTEGER DEFAULT 1,
query Query,
requestorRef [0] GeneralNames OPTIONAL,
requestNonce [1] OCTET STRING OPTIONAL,
requestorName [2] GeneralName OPTIONAL,
responderName [3] GeneralName OPTIONAL,
requestExtensions [4] Extensions OPTIONAL,
signatureAlg [5] AlgorithmIdentifier OPTIONAL,
hashAlg [6] OBJECT IDENTIFIER OPTIONAL,
requestorText [7] UTF8String (SIZE (1..256)) OPTIONAL }
CVRequest:、:= 系列cvRequestVersion INTEGER DEFAULT1、Queryについて質問してください、requestorRef[0]GeneralNames OPTIONAL、requestNonce[1]OCTET STRING OPTIONAL、requestorName[2]GeneralName OPTIONAL、responderName[3]GeneralName OPTIONAL、requestExtensions[4]拡大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と質問で要求を構成できなければなりません。 従っているクライアントMUST DERは保護されたものと対応する応答メッセージにおける明白なハッシュベースの参照箇所を容易にする同様に保護のないメッセージでCVRequestをコード化します。 新鮮な応答(例えば反射攻撃から守るか、または情報を確実にするのが最新である)の作成を主張するSCVPクライアントはrequestNonceをサポートしなければなりません。 残っているアイテムのサポートはクライアント実装で任意です。
Conforming servers MUST be able to parse CVRequests that contain any or all of the optional items.
サーバを従わせると、任意の項目のいずれかすべてを含むCVRequestsは分析できなければなりません。
Freeman, et al. Standards Track [Page 11] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[11ページ]。
Each of the items within the CVRequest is described in the following sections.
CVRequestの中のそれぞれの項目は以下のセクションで説明されます。
3.1. cvRequestVersion
3.1. cvRequestVersion
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はこの値を処理できなければなりません。
3.2. query
3.2. 質問
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-西暦]。 質問はqueriedCertsの品目を1つが項目、および1つのvalidationPolicyの品目をチェックするのと同じくらいよく含まなければなりません。 また、質問はwantBack、responseFlags、serverContextInfo、validationTime、intermediateCerts、revInfos、producedAt、およびqueryExtensionsの品目を含むかもしれません。
A Query MUST have the following syntax:
Queryには、以下の構文がなければなりません:
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 }
以下について質問してください:= 系列チェックCertChecks--注意: [0]が使用しなかったタグ--queriedCerts CertReferences、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]拡大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
queriedCertsの品目における証明書参照のリストはクライアントが情報が欲しい証明書をサーバに言います。 チェック項目はクライアント必需品が実行した照合を指定します。 wantBackの品目はクライアントが、サーバに応答で返して欲しいオブジェクトを指定します。 validationPolicyの品目がクライアントが欲しい合法化方針を指定する、サーバ
Freeman, et al. Standards Track [Page 12] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[12ページ]。
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.
使うために。 responseFlagsの品目で、クライアントは応答のためのオプション機能を要求できます。 serverContextInfoの品目は、前の要求応答からの追加情報が望まれているとサーバに言います。 validationTimeの品目は、チェックを実行するように日時に比例してクライアントがサーバが欲しい言います。 intermediateCertsとrevInfosの品目はクライアント要求に文脈を提供します。 queryExtensionsの品目は質問構文の今後の拡張に備えます。 以下のセクションでそれぞれのこれらの項目の構文と意味論について議論します。
Conforming clients MUST be able to construct a Query with a queriedCerts item that specifies at least one certificate, checks, and validationPolicy. Conforming SCVP clients MAY support specification of multiple certificates and MAY support the optional items in the Query structure.
クライアントを従わせると、少なくとも1通の証明書、チェック、およびvalidationPolicyを指定するqueriedCertsの品目でQueryを組み立てることができなければなりません。 SCVPクライアントを従わせると、複数の証明書の仕様がサポートされて、任意の項目はQuery構造で支えられるかもしれません。
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.
サーバを従わせると、任意の項目のいずれも含むQueryは処理できなければならなくて、複数の証明書を指定するQueryは処理できなければなりません。
3.2.1. queriedCerts
3.2.1. queriedCerts
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通以上の証明書のSEQUENCEです。それはそれぞれ要求の対象です。 指定された証明書は、公開鍵証明書か属性証明書のどちらかです。 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 }
CertReferences:、:= 選択PKCReferenceのpkcRefs[0]系列サイズ(1..MAX)、ACReferenceのacRefs[1]系列サイズ(1..MAX)
Freeman, et al. Standards Track [Page 13] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[13ページ]。
PKCReference ::= CHOICE {
cert [0] Certificate,
pkcRef [1] SCVPCertID }
PKCReference:、:= 選択本命[0]証明書、pkcRef[1]SCVPCertID
ACReference ::= CHOICE {
attrCert [2] AttributeCertificate,
acRef [3] SCVPCertID }
ACReference:、:= 選択attrCert[2]AttributeCertificate、acRef[3]SCVPCertID
SCVPCertID ::= SEQUENCE {
certHash OCTET STRING,
issuerSerial SCVPIssuerSerial,
hashAlgorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 } }
SCVPCertID:、:= 系列certHash OCTET STRING、issuerSerial SCVPIssuerSerial、hashAlgorithm AlgorithmIdentifier DEFAULTアルゴリズムsha-1
The ASN.1 definition of Certificate is imported from [PKIX-1] and the definition of AttributeCertificate is imported from [PKIX-AC].
CertificateのASN.1定義は[PKIX-1]からインポートされます、そして、AttributeCertificateの定義は[PKIX-西暦]からインポートされます。
When creating a SCVPCertID, the certHash is computed over the entire DER-encoded certificate including the signature. The hash algorithm used to compute certHash is specified in hashAlgorithm. The hash algorithm used to compute certHash SHOULD be one of the hash algorithms specified in the hashAlgorithms item of the server's validation policy response message.
SCVPCertIDを作成するとき、certHashは署名を含む全体のDERによってコード化された証明書に関して計算されます。 certHashを計算するのに使用されるハッシュアルゴリズムはhashAlgorithmで指定されます。 ハッシュアルゴリズムはハッシュの1つがサーバの合法化方針応答メッセージのhashAlgorithmsの品目で指定されたアルゴリズムであったなら以前はよくcertHash SHOULDを計算していました。
When encoding SCVPIssuerSerial, serialNumber is the serial number that uniquely identifies the certificate. For public key certificates, the issuer MUST contain only the issuer name from the certificate encoded in the directoryName choice of GeneralNames. For attribute certificates, the issuer MUST contain the issuer name field from the attribute certificate.
SCVPIssuerSerialをコード化するとき、serialNumberは唯一証明書を特定する通し番号です。 公開鍵証明書に関しては、発行人はGeneralNamesのdirectoryName選択でコード化された証明書からの発行人名だけを含まなければなりません。 属性証明書に関しては、発行人は属性証明書からの発行人名前欄を含まなければなりません。
Conforming clients MUST be able to reference a certificate by direct inclusion. Clients SHOULD be able to specify a certificate using the SCVPCertID. Conforming clients MAY be able to reference multiple certificates and MAY be able to reference both public key and attribute certificates.
クライアントを従わせるのはダイレクト包含で証明書に参照をつけることができなければなりません。 クライアントSHOULD、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 Server実装を従わせると、複数の証明書があるCertReferencesを処理できなければなりません。 SCVPサーバ実装を従わせると、公開鍵か属性証明書のどちらかを含むCertReferencesは分析できなければなりません。 SCVPサーバ実装を従わせると、本命とPKCReferenceでのpkcRef選択の両方を分析できなければなりません。 属性証明書を処理するSCVPサーバ実装を従わせると、attrCertとACReferenceでのacRef選択の両方を分析できなければなりません。
Freeman, et al. Standards Track [Page 14] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[14ページ]。
3.2.2. checks
3.2.2. チェック
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の品目の証明書に実行して欲しい照合について説明します。 チェック項目はオブジェクト識別子(OIDs)の系列を含んでいます。 各OIDは、クライアントが、サーバがどんな照合を実行すると予想するかをSCVPサーバに言います。 要求で指定された各チェックのために、SCVPサーバは、要求されたチェックを実行しなければならないか、または誤りを返さなければなりません。 サーバは、追加チェックを実行するのを選ぶかもしれません(例えば有効にされた証明経路を造るように頼まれるだけであるサーバは、また、取消し状態チェックを実行するのを選ぶかもしれません)、サーバは、応答では追加チェックが実行されたのを示すことができませんが、誤り応答に関するケースを除いて。
The checks item uses the CertChecks type, which has the following syntax:
チェック項目はCertChecksタイプを使用します:(タイプは以下の構文を持っています)。
CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
CertChecks:、:= オブジェクト識別子の系列サイズ(1..MAX)
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]);
- イドstcはpkc経路を造ります: 将来の証明経路を信頼アンカーに造ってください([PKIX-1]のセクション6.1で定義されるように)。
- id-stc-build-valid-pkc-path: Build a validated certification path
to a trust anchor (revocation checking not required);
- イドstcは有効なpkc経路を造ります: 有効にされた証明経路を信頼アンカーに造ってください(取消しの照合は必要ではありません)。
- id-stc-build-status-checked-pkc-path: Build a validated
certification path to a trust anchor and perform revocation status
checks on the certification path.
- stcが状態を築き上げるイドはpkc経路をチェックしました: 有効にされた証明経路を信頼アンカーに造ってください、そして、証明経路に取消し状態チェックを実行してください。
Conforming SCVP server implementations that support delegated path discovery (DPD) as defined in [RQMTS] MUST support the id-stc-build- pkc-path check. Conforming SCVP server implementations that support delegated path validation (DPV) as defined in [RQMTS] MUST support the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc- path checks.
[RQMTS]で定義されるように代表として派遣された経路発見が(DPD)であるとサポートするSCVPサーバ実装を従わせると、イド-stc pkc-経路を造っているチェックはサポートしなければなりません。 [RQMTS]で定義されるように代表として派遣された経路合法化が(DPV)であるとサポートするSCVPサーバ実装を従わせると、イドstcが有効なpkc経路を造っていてイド-stc状態を築き上げてチェックのpkc-経路のチェックはサポートしなければなりません。
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;
- イドstcはaa経路を造ります: Attribute Certificate(西暦)発行人のために将来の証明経路を信頼アンカーに造ってください。
- id-stc-build-valid-aa-path: Build a validated certification path
to a trust anchor for the AC issuer;
- イドstcは有効なaa経路を造ります: 交流発行人のために有効にされた証明経路を信頼アンカーに造ってください。
Freeman, et al. Standards Track [Page 15] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[15ページ]。
- 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;
- stcが状態を築き上げるイドはaa経路をチェックしました: 交流発行人のために有効にされた証明経路を信頼アンカーに造ってください、そして、交流発行人のために証明経路に取消し状態チェックを実行してください。
- 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.
- イドstc状態は、acをチェックして、状態チェックのaa経路を造ります: 交流発行人のために有効にされた証明経路を信頼アンカーに造ってください、そして、交流発行人のための証明経路と同様に西暦に取消し状態チェックを実行してください。
Conforming SCVP server implementations MAY support the attribute certificates checks.
SCVPサーバ実装を従わせるのは、属性証明書がチェックであるとサポートするかもしれません。
For these purposes, the following OIDs are defined:
これらの目的のために、以下のOIDsは定義されます:
id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 }
イド-stc OBJECT IDENTIFIER:、:= iso(1)、組織(3)dod(6)インターネット(1)セキュリティ(5)が特定されたメカニズム(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 }
イドstc体格pkc経路OBJECT IDENTIFIER:、:= イド-stc1のイドstc体格有効なpkc経路OBJECT IDENTIFIER:、:= イド-stc2のイドstc体格状態チェックのpkc経路OBJECT IDENTIFIER:、:= イド-stc3イドstc体格aa経路OBJECT IDENTIFIER:、:= イド-stc4のイドstc体格有効なaa経路OBJECT IDENTIFIER:、:= イド-stc5のイドstc体格状態チェックのaa経路OBJECT IDENTIFIER:、:= イド-stc6のイドのstcの状態のチェックacと体格状態チェックのaa経路OBJECT IDENTIFIER:、:= イド-stc7
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つの主張はサポートしなければなりません。 クライアントを従わせると、複数のチェックの主張はサポートするかもしれません。 クライアントを従わせると、このセクションで定義されたチェックのすべてがサポートする必要はありません。
3.2.3. wantBack
3.2.3. wantBack
The optional wantBack item describes any information the SCVP client wants from the SCVP server for the certificate(s) in the queriedCerts item in addition to the results of the checks specified in the checks item. If present, the wantBack item MUST contain a sequence of object identifiers (OIDs). Each OID tells the SCVP server what the client wants to know about the queriedCerts item. For each type of information specified in the request, the server MUST return information regarding its finding (in a successful response).
任意のwantBackの品目はSCVPクライアントがチェック項目で指定されたチェックの結果に加えたqueriedCertsの品目の証明書のためにSCVPサーバから欲しいどんな情報についても説明します。 存在しているなら、wantBackの品目はオブジェクト識別子(OIDs)の系列を含まなければなりません。 各OIDは、クライアントがqueriedCertsの品目に関して何を知りたがっているかをSCVPサーバに言います。 要求で指定された各情報の種類のために、サーバは調査結果(うまくいっている応答における)の情報を返さなければなりません。
Freeman, et al. Standards Track [Page 16] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[16ページ]。
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
WantBack:、:= オブジェクト識別子の系列サイズ(1..MAX)
For public key certificates, the following wantBacks are defined in this document:
公開鍵証明書に関しては、以下のwantBacksは本書では定義されます:
- id-swb-pkc-cert: The certificate that was the subject of the
request;
- イドswb-pkc本命: 要求の対象であった証明書。
- id-swb-pkc-best-cert-path: The certification path built for the
certificate including the certificate that was validated;
- イドのswb-pkcの最も良い本命道: 有効にされた証明書を含む証明書のために造られた証明経路。
- id-swb-pkc-revocation-info: Proof of revocation status for each
certificate in the certification path;
- イドswb-pkc取消しインフォメーション: 証明経路の各証明書のための取消し状態の証拠。
- id-swb-pkc-public-key-info: The public key from the certificate
that was the subject of the request;
- イドswb-pkc公開鍵インフォメーション: 要求の対象であった証明書からの公開鍵。
- id-swb-pkc-all-cert-paths: A set of certification paths for the
certificate that was the subject of the request;
- イドswb-pkcオール本命道: 要求の対象であった証明書のための1セットの証明経路。
- id-swb-pkc-ee-revocation-info: Proof of revocation status for the
end entity certificate in the certification path; and
- イドswb-pkc-ee取消しインフォメーション: 証明経路の終わりの実体証明書のための取消し状態の証拠。 そして
- id-swb-pkc-CAs-revocation-info: Proof of revocation status for
each CA certificate in the certification path.
- イドswb-pkc-CAs取消しインフォメーション: 証明経路のそれぞれのカリフォルニア証明書のための取消し状態の証拠。
Freeman, et al. Standards Track [Page 17] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[17ページ]。
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サーバ実装が、イドswb- pkc本命とイドswb-pkc公開鍵インフォメーションがwantBacksであるとサポートしなければなりません。 [RQMTS]で定義されるように代表として派遣された経路発見が(DPD)であるとサポートするSCVPサーバ実装を従わせるのは、イドのswb-pkcの最も良い本命道とイドswb-pkc取消しインフォメーションがwantBacksであるとサポートしなければなりません。
SCVP provides two methods for a client to obtain multiple certification paths for a certificate. The client could use serverContextInfo to request one path at a time (see Section 3.2.6). After obtaining each path, the client could submit the serverContextInfo from the previous request to obtain another path until either the client found a suitable path or the server indicated (by not returning a serverContextInfo) that no more paths were available. Alternatively, the client could send a single request with an id-swb-pkc-all-cert-paths wantBack, in which case the server would return all of the available paths in a single response.
SCVPはクライアントが複数の証明経路を証明書に得る2つのメソッドを提供します。 クライアントは、一度に1つの経路を要求するのにserverContextInfoを使用できました(セクション3.2.6を見てください)。 各経路を得た後に、クライアントはクライアントが適当な経路を見つけたか、またはサーバが、それ以上の経路が利用可能でないことを示すまで(serverContextInfoを返さないことによって)別の経路を得るという前の要求からserverContextInfoを提出できました。 あるいはまた、クライアントはイドswb-pkcオール本命道のwantBackとのただ一つの要求を送ることができました、その場合、サーバがただ一つの応答における利用可能な経路のすべてを返すでしょう。
The server may, at its discretion, limit the number of paths that it returns in response to the id-swb-pkc-all-cert-paths. When the request includes an id-swb-pkc-all-cert-paths wantBack, the response SHOULD NOT include a serverContextInfo.
サーバは自己判断で、それがイドswb-pkcオール本命道に対応して返すパスの数を制限するかもしれません。 要求がイドswb-pkcオール本命道のwantBackを含んでいるとき、応答SHOULD NOTはserverContextInfoを含んでいます。
For attribute certificates, the following wantBacks are defined in this document:
属性証明書に関しては、以下のwantBacksは本書では定義されます:
- id-swb-ac-cert: The attribute certificate that was the subject of
the request;
- イドswb-ac本命: 要求の対象であった属性証明書。
- id-swb-aa-cert-path: The certification path built for the AC
issuer certificate;
- イドswb-aa本命道: 交流発行人証明書のために造られた証明経路。
- id-swb-ac-revocation-info: Proof of revocation status for each
certificate in the AC issuer certification path; and
- イドswb-ac取消しインフォメーション: 交流発行人証明経路の各証明書のための取消し状態の証拠。 そして
- id-swb-aa-revocation-info: Proof of revocation status for the
attribute certificate.
- イドswb-aa取消しインフォメーション: 属性証明書のための取消し状態の証拠。
Conforming SCVP server implementations MAY support the attribute certificate wantBacks.
SCVPサーバ実装を従わせるのは、属性証明書がwantBacksであるとサポートするかもしれません。
The following wantBack can be used for either public key or attribute certificates:
公開鍵か属性証明書のどちらかに以下のwantBackを使用できます:
- id-swb-relayed-responses: Any SCVP responses received by the
server that were used to generate the response to this query.
- イドswbは応答をリレーしました: どんなSCVP応答もこの質問への応答を生成するのに使用されたサーバによって受信されました。
Conforming SCVP servers MAY support the id-swb-relayed-responses wantBack.
SCVPサーバを従わせると、イドswbが応答をリレーしているwantBackはサポートするかもしれません。
Freeman, et al. Standards Track [Page 18] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[18ページ]。
For these purposes, the following OIDs are defined:
これらの目的のために、以下のOIDsは定義されます:
id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 }
イド-swb OBJECT IDENTIFIER:、:= iso(1)、組織(3)dod(6)インターネット(1)セキュリティ(5)が特定されたメカニズム(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}
イドのswb-pkcの最も良い本命道のOBJECT IDENTIFIER:、:= イド-swb1、イドswb-pkc取消しインフォメーションOBJECT IDENTIFIER:、:= イド-swb2、イドswb-pkc公開鍵インフォメーションOBJECT IDENTIFIER:、:= イド-swb4イドswb-aa本命道のOBJECT IDENTIFIER:、:= イド-swb5、イドswb-aa取消しインフォメーションOBJECT IDENTIFIER:、:= イド-swb6、イドswb-ac取消しインフォメーションOBJECT IDENTIFIER:、:= イド-swb7のイドのswbリレーされた応答OBJECT IDENTIFIER:、:= イド-swb9、イドswb-pkc本命OBJECT IDENTIFIER:、:= イド-swb10、イドswb-ac本命OBJECT IDENTIFIER:、:= イド-swb11イドswb-pkcオール本命道のOBJECT IDENTIFIER:、:= イド-swb12、イドswb-pkc-ee取消しインフォメーションOBJECT IDENTIFIER:、:= イド-swb13、イドswb-pkc-CAs取消しインフォメーションOBJECT IDENTIFIER:、:= イド-swb14
Other specifications may define additional wantBacks.
他の仕様は追加wantBacksを定義するかもしれません。
Conforming client implementations that support delegated path validation (DPV) as defined in [RQMTS] SHOULD support assertion of at least one wantBack. Conforming client implementations that support delegated path discovery (DPD) as defined in [RQMTS] MUST support assertion of at least one wantBack. Conforming clients MAY support assertion of multiple wantBacks. Conforming clients need not support all of the wantBacks defined in this section.
クライアント実装を従わせて、そのサポートは少なくとも1wantBackの[RQMTS]SHOULDサポート主張で定義されるように経路合法化(DPV)を代表として派遣しました。 [RQMTS]で定義されるように代表として派遣された経路発見が(DPD)であるとサポートするクライアント実装を従わせると、少なくとも1wantBackの主張はサポートしなければなりません。 クライアントを従わせると、複数のwantBacksの主張はサポートするかもしれません。 クライアントを従わせると、このセクションで定義されたwantBacksのすべてがサポートする必要はありません。
3.2.4. validationPolicy
3.2.4. validationPolicy
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つ以上のパラメタに非デフォルト値を使用したいと思うなら、クライアントは方針といかなるこの項目における要求を終了するのに必要なパラメタにも参照を供給します。 要求に何か要求で参照をつけられる方針とどんな供給されたパラメタ値との闘争もあれば、サーバは誤り応答を返さなければなりません。
Freeman, et al. Standards Track [Page 19] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[19ページ]。
The syntax of the validationPolicy item is:
validationPolicyの品目の構文は以下の通りです。
ValidationPolicy ::= SEQUENCE {
validationPolRef ValidationPolRef,
validationAlg [0] ValidationAlg OPTIONAL,
userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT
IDENTIFIER OPTIONAL,
inhibitPolicyMapping [2] BOOLEAN OPTIONAL,
requireExplicitPolicy [3] BOOLEAN OPTIONAL,
inhibitAnyPolicy [4] BOOLEAN OPTIONAL,
trustAnchors [5] TrustAnchors OPTIONAL,
keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL,
extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL,
specifiedKeyUsages [8] SEQUENCE OF KeyPurposeId OPTIONAL }
ValidationPolicy:、:= 系列validationPolRef ValidationPolRef、KeyPurposeId任意の任意のKeyPurposeId specifiedKeyUsages[8]系列の任意のKeyUsage extendedKeyUsages[7]系列のオブジェクトの識別子の任意の、そして、[2]のinhibitPolicyMappingの論理演算子の任意の、そして、requireExplicitPolicy[3]論理演算子任意のinhibitAnyPolicy[4]論理演算子任意の、そして、trustAnchors[5]TrustAnchors任意のkeyUsages[6]系列の任意のvalidationAlg[0]ValidationAlg userPolicySet[1]系列サイズ(1..MAX)
The validationPolRef item is required, but the remaining items are optional. The optional items are used to provide validation policy parameters. When the client uses the validation policy's default values for all parameters, all of the optional items are absent.
validationPolRefの品目が必要ですが、残っているアイテムは任意です。 任意の項目は、合法化方針パラメタを提供するのに使用されます。 クライアントがすべてのパラメタに合法化方針のデフォルト値を使用するとき、任意の項目のすべてが休んでいます。
At a minimum, conforming SCVP client implementations MUST support the validationPolRef item. Conforming client implementations MAY support any or all of the optional items in ValidationPolicy.
最小限では、SCVPクライアント実装を従わせると、validationPolRefの品目はサポートしなければなりません。 クライアント実装を従わせると、ValidationPolicyの任意の項目のいずれかすべてがサポートするかもしれません。
Conforming SCVP servers MUST support processing of a ValidationPolicy that contains any or all of the optional items.
SCVPサーバを従わせると、いずれも含むValidationPolicyの処理か任意の項目のすべてがサポートしなければなりません。
The validationAlg item specifies the validation algorithm. The userPolicySet item provides an acceptable set of certificate policies. The inhibitPolicyMapping item inhibits certificate policy mapping during certification path validation. The requireExplicitPolicy item requires at least one valid certificate policy in the certificate policies extension. The inhibitAnyPolicy item indicates whether the anyPolicy certificate policy OID is processed or ignored when evaluating certificate policy. The trustAnchors item indicates the trust anchors that are acceptable to the client. The keyUsages item indicates the technical usage of the public key that is to be confirmed by the server as acceptable. The extendedKeyUsages item indicates the application-specific usage of the public key that is to be confirmed by the server as acceptable. The syntax and semantics of each of these items are discussed in the following sections.
validationAlgの品目は合法化アルゴリズムを指定します。 userPolicySetの品目は許容できるセットの証明書方針を提供します。 inhibitPolicyMappingの品目は証明経路合法化の間、証明書方針マッピングを禁止します。 requireExplicitPolicyの品目は証明書方針拡張子で少なくとも1つの有効な証明書方針を必要とします。 inhibitAnyPolicyの品目は、証明書方針を評価するとき、anyPolicy証明書方針OIDが処理されるか、または無視されるかを示します。 trustAnchorsの品目はクライアントにとって、許容できる信頼アンカーを示します。 keyUsagesの品目は許容できるとしてサーバによって確認されることになっている公開鍵の技術的な用法を示します。 extendedKeyUsagesの品目は許容できるとしてサーバによって確認されることになっている公開鍵のアプリケーション特有の用法を示します。 以下のセクションでそれぞれのこれらの項目の構文と意味論について議論します。
3.2.4.1. validationPolRef
3.2.4.1. validationPolRef
The reference to the validation policy is an OID that the client and server have agreed represents a particular validation policy.
合法化方針の参照はクライアントとサーバが特定の合法化方針を表すのに同意したOIDです。
Freeman, et al. Standards Track [Page 20] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[20ページ]。
The syntax of the validationPolRef item is:
validationPolRefの品目の構文は以下の通りです。
ValidationPolRef::= SEQUENCE {
valPolId OBJECT IDENTIFIER,
valPolParams ANY DEFINED BY valPolId OPTIONAL }
ValidationPolRef:、:= 系列valPolIdオブジェクト識別子、valPolIdによって少しも任意の状態で定義されたvalPolParams
Where a validation policy supports additional policy-specific parameter settings, these values are specified using the valPolParams item. The syntax and semantics of the parameters structure are defined by the object identifier encoded as the valPolId. Where a validation policy has no parameters, such as the default validation policy (see Section 3.2.4.1.1), this item MUST be omitted.
合法化方針が追加方針特有のパラメタ設定をサポートするところでは、これらの値は、valPolParamsの品目を使用することで指定されます。 パラメタ構造の構文と意味論はvalPolIdとしてコード化されたオブジェクト識別子によって定義されます。 セクション3.2を見てください。合法化方針にはデフォルト合法化方針などのパラメタが全くない、(.4 .1 .1、)この項目を省略しなければなりません。
Parameters specified in this item are independent of the validation algorithm and the validation algorithm's parameters (see Section 3.2.4.2). For example, a server may support a validation policy where it validates a certificate using the name validation algorithm and also makes a determination regarding the creditworthiness of the subject. In this case, the validation policy parameters could be used to specify the value of the transaction. The validation algorithm parameters are used to specify the application identifier and name for the name validation algorithm.
セクション3.2を見てください。この項目で指定されたパラメタが合法化アルゴリズムと合法化アルゴリズムのパラメタから独立している、(.4 .2)。 例えば、サーバはそれが名前合法化アルゴリズムを使用することで証明書を有効にして、また当社の信用価値に関して決断をする合法化方針をサポートするかもしれません。 この場合、合法化方針パラメタは、取引価格を指定するのに使用されるかもしれません。 合法化アルゴリズムパラメタは、名前合法化アルゴリズムにアプリケーション識別子と名前を指定するのに使用されます。
Conforming SCVP client implementations MUST support specification of a validation policy. Conforming SCVP client implementations MAY be able to specify parameters for a validation policy. Conforming SCVP server implementations MUST be able to process valPolId and MAY be able to process valPolParams.
SCVPクライアント実装を従わせると、合法化方針の仕様はサポートしなければなりません。 SCVPクライアント実装を従わせるのは合法化方針のためにパラメータを指定できるかもしれません。 SCVPサーバ実装を従わせると、valPolIdを処理できなければならなくて、valPolParamsを処理できるかもしれません。
3.2.4.1.1. Default Validation Policy
3.2.4.1.1. デフォルト合法化方針
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 }
イド-svp OBJECT IDENTIFIER:、:= iso(1)、組織(3)dod(6)インターネット(1)セキュリティ(5)が特定されたメカニズム(5)pkix(7)19
id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }
イド-svp-defaultValPolicyオブジェクト識別子:、:= イド-svp1
Freeman, et al. Standards Track [Page 21] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[21ページ]。
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を見てください。デフォルト合法化方針がデフォルト合法化アルゴリズムとして基本的な合法化アルゴリズムを使用しなければならない、(セクション3.2.4を見てください、.2、.1)、合法化方針パラメタを全く持っていない、(.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サーバは、地方のセキュリティ必要条件を満たすのにデフォルト方針を使用することで誤り応答をすべての要求に送るために構成されるかもしれません。
3.2.4.2. validationAlg
3.2.4.2. validationAlg
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 }
ValidationAlg:、:= 系列valAlgId OBJECT IDENTIFIER、パラメタいずれも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クライアントは基本的な合法化アルゴリズムをサポートしなければなりません、そして、SHOULDは名前合法化アルゴリズムをサポートします。 使用のための他のドキュメントで特定のアプリケーションで他の合法化アルゴリズムを指定できます。 SCVPクライアントとサーバは、どんなそのような合法化もアルゴリズムであるとサポートするかもしれません。
3.2.4.2.1. Basic Validation Algorithm
3.2.4.2.1. 基本的な合法化アルゴリズム
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
クライアントはSCVPの基本的な合法化アルゴリズムか別のアルゴリズムの使用を要求できます。 アイデンティティ証明書に関しては、基本的な合法化アルゴリズムは[PKIX-1]のセクション6で定義されるように証明経路合法化アルゴリズムを実装しなければなりません。 属性証明書に関しては、基本的な合法化アルゴリズムは[PKIX-西暦]のセクション5で定義されるように証明経路合法化を実装しなければなりません。 他の合法化アルゴリズムはそれらの上と、そして、基本的のそれらの上で機能を実装するかもしれません。
Freeman, et al. Standards Track [Page 22] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[22ページ]。
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:
しかし、アルゴリズム、合法化アルゴリズムは基本的な合法化アルゴリズムによる対応することの結果を生成しなければなりません。 すなわち、基本的なアルゴリズムによる合法化要件のいずれもどんな新たに定義された合法化アルゴリズムからも省略されないかもしれません。しかしながら、他の合法化アルゴリズムは基本的な合法化アルゴリズムを使用することで有効な経路を拒絶するかもしれません。 基本的な合法化アルゴリズムを特定するオブジェクト識別子は以下の通りです。
id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 }
イド-svp-basicValAlgオブジェクト識別子:、:= イド-svp3
When id-svp-basicValAlg appears in valAlgId, the parameters item MUST be absent.
イド-svp-basicValAlgがvalAlgIdに現れるとき、パラメタ項目は欠けているに違いありません。
3.2.4.2.2. Basic Validation Algorithm Errors
3.2.4.2.2. 基本的な合法化アルゴリズム誤り
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.
以下の誤りは応答におけるvalidationErrorsの品目での包含のための基本的な合法化アルゴリズムのために定義されます(セクション4.9.6を見てください)。 すべての合法化アルゴリズムが基本的な合法化アルゴリズムの機能性を実装しなければならないので、いかなる他の合法化アルゴリズムでもこれらの誤りを使用できます。
id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg
イド-bvae OBJECT IDENTIFIER:、:= イド-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 }
bvaeが吐き出したイドOBJECT IDENTIFIER:、:= イドがまだ有効でない状態でbvaeされていた状態で1をイドでbvaeする、OBJECT IDENTIFIER:、:= イド-bvae2、イド-bvae-wrongTrustAnchor OBJECT IDENTIFIER:、:= イド-bvae3、イド-bvae-noValidCertPath OBJECT IDENTIFIER:、:= bvaeが取り消したイド-bvae4イドOBJECT IDENTIFIER:、:= イド-bvae5、イド-bvae-invalidKeyPurpose OBJECT IDENTIFIER:、:= イド-bvae9、イド-bvae-invalidKeyUsage OBJECT IDENTIFIER:、:= イド-bvae10、イド-bvae-invalidCertPolicy OBJECT IDENTIFIER:、:= イド-bvae11
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).
bvaeが吐き出したイド値は、要求のために費やされた合法化時間がnotAfter時間より遅く終わりの証明書にあったことを意味します(証明書は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.
イドbvaeなまだ有効でない値は、要求のために費やされた合法化時間がnotBefore時の前に終わりの証明書にあったことを意味します。
The id-bvae-wrongTrustAnchor value means that a certification path could not be constructed for the client-specified trust anchor(s), but a path exists for one of the trust anchors specified in the server's default validation policy.
イド-bvae-wrongTrustAnchor値は、クライアントによって指定された信頼アンカーのために証明経路を構成できなかったことを意味しますが、経路はサーバのデフォルト合法化方針で指定された信頼アンカーのひとりのために存在しています。
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.
イド-bvae-noValidCertPath値は、サーバが要望に応じた信頼アンカーと目標証明書の間の中間的証明書の系列を構成できなかったことを意味します。
Freeman, et al. Standards Track [Page 23] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[23ページ]。
The id-bvae-revoked value means that the end certificate has been revoked.
イド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.
イド-bvae-invalidKeyPurpose値は、拡大[PKIX-1]、.13が)結局証明するセクション4.2.1がそうしない拡張主要な用法が合法化方針を満たすことを意味します。
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.
イド-bvae-invalidKeyUsage値は、拡大[PKIX-1]、.3が)結局証明するセクション4.2.1がそうしないkeyUsageが合法化方針を満たすことを意味します。 例えば、証明書におけるkeyUsage拡張子はkeyEnciphermentビットだけについて断言するかもしれませんが、合法化方針は、keyUsagesの品目でdigitalSignatureが必要であると指定します。
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).
イド-bvae-invalidCertPolicy値は、経路がユーザ方針セットで指定された方針のどれかの下で有効でないことを意味します、そして、明白な方針が必要です。 すなわち、有効な_方針_木はNULLです、そして、明白な_政策変数はゼロ([PKIX-1]、セクション6.1.5)です。
3.2.4.2.3. Name Validation Algorithm
3.2.4.2.3. 名前合法化アルゴリズム
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 }
イド-svp-nameValAlgオブジェクト識別子:、:= イド-svp2
When the id-svp-nameValAlg appears as a valAlgId, the parameters MUST use the NameValidationAlgParms syntax:
イド-svp-nameValAlgがvalAlgIdとして現れるとき、パラメタはNameValidationAlgParms構文を使用しなければなりません:
NameValidationAlgParms ::= SEQUENCE {
nameCompAlgId OBJECT IDENTIFIER,
validationNames GeneralNames }
NameValidationAlgParms:、:= 系列nameCompAlgIdオブジェクト識別子、validationNames GeneralNames
GeneralNames is defined in [PKIX-1].
GeneralNamesは[PKIX-1]で定義されます。
If more than one name is supplied in the validationNames value, all names MUST be of the same type. The certificate must contain a matching name for each of the names supplied in validationNames according to the name matching rules associated with the nameCompAlgId. This specification defines three sets of name matching rules.
validationNames値で1つ以上の名前を提供するなら、同じタイプにはすべての名前があるに違いありません。 証明書はnameCompAlgIdに関連している規則に合っている名前に応じてvalidationNamesで提供されたそれぞれの名前のための合っている名前を含まなければなりません。 この仕様は3セットの名前マッチング規則を定義します。
Freeman, et al. Standards Track [Page 24] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[24ページ]。
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がイド-nva-dnCompAlgであるなら、要求で供給されたGeneralNamesはdirectoryNameであるに違いありません、そして、使用されるべき合っている規則は[PKIX-1]で定義されます。 証明書は対象の分野かdirectoryNameのどちらかにsubjectAltName拡張子で合っている名前を保管しなければなりません。 この仕様は以下のイド-nva-dnCompAlgのためにOIDを定義します:
id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 }
イド-nva-dnCompAlgオブジェクト識別子:、:= イド-svp4
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がイド-kp-serverAuth[PKIX-1]であるなら、要求で供給されたGeneralNamesはdNSNameであるに違いありません、そして、使用されるべき合っている規則は[PKIX-1]で定義されます。
If a subjectAltName extension is present and includes one or more names of type dNSName, a match in any one of the set is considered acceptable. If the subjectAltName extension is omitted, or does not include any names of type dNSName, the (most specific) Common Name field in the subject field of the certificate MUST be used.
subjectAltName拡張子が存在していて、タイプdNSNameという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はbar.foo.a. comではなく、foo.a. comに合っています。
If the nameCompAlgId supplied in the request is id-kp-mailProtection [PKIX-1], then GeneralNames supplied in the request MUST be an rfc822Name, and the matching rules are defined in [SMIME-CERT].
要求で供給されたnameCompAlgIdがイド-kp-mailProtection[PKIX-1]であるなら、要求で供給されたGeneralNamesはrfc822Nameであるに違いありません、そして、合っている規則は[SMIME-CERT]で定義されます。
Conforming SCVP servers MUST support the name validation algorithm and the matching rules associated with id-nva-dnCompAlg, id-kp- serverAuth, and id-kp-mailProtection. SCVP servers MAY support other name matching rules.
SCVPサーバを従わせると、イド-nva-dnCompAlg、イド-kp- serverAuth、およびイド-kp-mailProtectionに関連している名前合法化アルゴリズムと合っている規則はサポートされなければなりません。 SCVPサーバは、他の名前が合っている規則であるとサポートするかもしれません。
3.2.4.2.4. Name Validation Algorithm Errors
3.2.4.2.4. 名前合法化アルゴリズム誤り
The following errors are defined for the name validation algorithm:
以下の誤りは名前合法化アルゴリズムのために定義されます:
id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg
イド-nvae OBJECT IDENTIFIER:、:= イド-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 }
イドnvae名前ミスマッチOBJECT IDENTIFIER:、:= nvaeノーが命名するイド-nvae1イドOBJECT IDENTIFIER:、:= イドが未知のalg OBJECT IDENTIFIERをnvaeしていた状態で2をイドでnvaeする、:、:= イド-nvae3イドnvae悪名OBJECT IDENTIFIER:、:= nvaeの悪い名がタイプするイド-nvae4イドOBJECT IDENTIFIER:、:= イド-nvae5のイドのnvae複雑な名のOBJECT IDENTIFIER:、:= イド-nvae6
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
イドnvae名前ミスマッチ値が、クライアントがサーバが認識した要求を名前に供給したことを意味して、サーバは、証明書で対応する名前がタイプであることがわかりますが、aを見つけることができませんでした。
Freeman, et al. Standards Track [Page 25] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[25ページ]。
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.
供給という名前に合ってください。 例えば、クライアントは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.
nvaeノー、が命名するイド値は、クライアントがサーバが認識した要求を名前に供給したことを意味しますが、サーバは証明書のタイプという対応する名前を見つけることができませんでした。 例えば、クライアントは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.
イドのnvaeの未知のalg値は、クライアントがサーバが認識しないnameCompAlgIdを供給したことを意味します。
The id-nvae-bad-name value means the client supplied either an empty or malformed name in the request.
クライアントが提供した値が要求における空の、または、奇形の名前を意味するイドnvae悪名。
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.
イドのnvaeの悪い名前タイプ値はアプリケーション識別子のための不適当な名前タイプに提供されたクライアントを意味します。 例えば、クライアントはイド-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.
イドnvaeが名前が複雑であった値は、クライアントが異なったタイプの要求における複数の名前を提供したことを意味します。
3.2.4.3. userPolicySet
3.2.4.3. userPolicySet
The userPolicySet item specifies a list of certificate policy identifiers that the SCVP server MUST use when constructing and validating a certification path. The userPolicySet item specifies the user-initial-policy-set as defined in Section 6 of [PKIX-1]. A userPolicySet containing the anyPolicy OID indicates a user-initial- policy-set of any-policy.
userPolicySetの品目は証明経路を組み立てて、有効にするときSCVPサーバが使用しなければならない証明書方針識別子のリストを指定します。 userPolicySetの品目は[PKIX-1]のセクション6で定義されるようにユーザの初期の方針セットを指定します。 anyPolicy OIDを含むuserPolicySetがユーザ初期に方針に設定されていた状態でaを示す、いくらか、-、方針
SCVP clients SHOULD support the userPolicySet item in requests, and SCVP servers MUST support the userPolicySet item in requests.
SCVPクライアントSHOULDは要求でuserPolicySetの品目をサポートします、そして、SCVPサーバは要求でuserPolicySetの品目をサポートしなければなりません。
3.2.4.4. inhibitPolicyMapping
3.2.4.4. inhibitPolicyMapping
The inhibitPolicyMapping item specifies an input to the certification path validation algorithm, and it controls whether policy mapping is allowed during certification path validation (see [PKIX-1], Section 6.1.1). If the client wants the server to inhibit policy mapping, inhibitPolicyMapping is set to TRUE in the request. SCVP clients MAY support inhibiting policy mapping. SCVP servers SHOULD support inhibiting policy mapping.
inhibitPolicyMappingの品目は証明経路合法化アルゴリズムに入力を指定します、そして、それは方針マッピングが証明経路合法化の間、許容されているかどうかを([PKIX-1]、セクション6.1.1を見てください)制御します。 クライアントが、サーバに方針マッピングを禁止して欲しいなら、inhibitPolicyMappingは要求でTRUEに用意ができています。 SCVPクライアントは、禁止が方針マッピングであるとサポートするかもしれません。 SCVPサーバSHOULDは、禁止が方針マッピングであるとサポートします。
Freeman, et al. Standards Track [Page 26] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[26ページ]。
3.2.4.5. requireExplicitPolicy
3.2.4.5. requireExplicitPolicy
The requireExplicitPolicy item specifies an input to the certification path validation algorithm, and it controls whether there must be at least one valid policy in the certificate policies extension (see [PKIX-1], Section 6.1.1). If the client wants the server to require at least one policy, requireExplicitPolicy is set to TRUE in the request.
requireExplicitPolicyの品目は証明経路合法化アルゴリズムに入力を指定します、そして、それは証明書方針拡張子には少なくとも1つの有効な方針があるに違いないかを([PKIX-1]、セクション6.1.1を見てください)制御します。 クライアントが、サーバに少なくとも1つの方針を必要として欲しいなら、requireExplicitPolicyは要求でTRUEに用意ができています。
SCVP clients MAY support requiring explicit policies. SCVP servers SHOULD support requiring explicit policies.
SCVPクライアントは、必要さが明白な方針であるとサポートするかもしれません。 SCVPサーバSHOULDは、必要さが明白な方針であるとサポートします。
3.2.4.6. inhibitAnyPolicy
3.2.4.6. inhibitAnyPolicy
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サーバSHOULDは、無視がanyPolicy OIDであるとサポートします。
3.2.4.7. trustAnchors
3.2.4.7. trustAnchors
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]に関する必要条件を満たすどんなカリフォルニア証明書も提供できます。 これらの必要条件を満たさない信頼アンカーを供給するなら、サーバは誤り応答を返さなければなりません。
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
TrustAnchors:、:= PKCReferenceの系列サイズ(1..MAX)
Freeman, et al. Standards Track [Page 27] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[27ページ]。
SCVP servers MUST support trustAnchors. SCVP clients SHOULD support trustAnchors.
SCVPサーバはtrustAnchorsをサポートしなければなりません。 SCVPクライアントSHOULDはtrustAnchorsをサポートします。
3.2.4.8. keyUsages
3.2.4.8. keyUsages
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つのkeyUsage値を提供します、そして、デジタル署名がある1つはセットしました、そして、非拒否があるもう片方がセットしました。 主要な用法拡大が証明書から欠けるなら、すべての用法に良いと証明書を考えなければなりません、そして、したがって、SCVP要求におけるどんなパターンも合うでしょう。
SCVP clients SHOULD support keyUsages, and SCVP servers MUST support keyUsages.
SCVPクライアントSHOULDはkeyUsagesをサポートします、そして、SCVPサーバはkeyUsagesをサポートしなければなりません。
3.2.4.9. extendedKeyUsages
3.2.4.9. extendedKeyUsages
The extended key usage extension ([PKIX-1], Section 4.2.1.13) defines more specific technical purposes, in addition to, or in place of, the purposes indicated in the key usage extension, for which the certified public key may be used. If the client 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]、.13が)より特定の技術的な目的、目的か主要な用法拡大で示された目的定義するセクション4.2.1。(公認された公開鍵はその.1に使用されるかもしれません)。 クライアントが拡張主要な用法拡大で特定の値(または、値)と一致した証明書を受け入れるなら、それは、[PKIX-1]で定義されているとして同じ意味論を使用することで適切な用法を伝えることができます。
Freeman, et al. Standards Track [Page 28] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[28ページ]。
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)サーバの文脈の証明書を入手したなら、それは、証明書がイド-kp-serverAuthオブジェクト識別子で拡張主要な用法構造を含むことによってこの用法と一致していると確認できます。
If the extension is absent, or is present and asserts the anyExtendedKeyUsage OID, then all usages specified in the request are a match. If the extension is present and does not assert the anyExtendedKeyUsage OID, all usages in the request MUST be present in the certificate. The certificate extension may contain more usages than requested.
拡大が休むか、存在していて、またはanyExtendedKeyUsage OIDについて断言するなら、要求で指定されたすべての用法がマッチです。 拡大が存在していて、anyExtendedKeyUsage OIDについて断言しないなら、要求におけるすべての用法が証明書に存在していなければなりません。 証明書拡張子は要求されているより多くの用法を含むかもしれません。
Where the client does not require any particular extended key usage, the client can specify an empty SEQUENCE. This may be used to override extended key usage requirements imposed in the validation policy specified by valPolId.
クライアントが少しの特定の拡張主要な用法も必要としないところでは、クライアントは空のSEQUENCEを指定できます。 これは、valPolIdによって指定された合法化方針で課された拡張主要な用法要件に優越するのに使用されるかもしれません。
SCVP clients SHOULD support extendedKeyUsages, and SCVP servers MUST support extendedKeyUsages.
SCVPクライアントSHOULDはextendedKeyUsagesをサポートします、そして、SCVPサーバはextendedKeyUsagesをサポートしなければなりません。
3.2.4.10. specifiedKeyUsages
3.2.4.10. specifiedKeyUsages
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]、.13が)目的か、より特定の技術的な目的か主要な用法拡大で示された目的に代わって定義するセクション4.2.1。(公認された公開鍵はその.1に使用されるかもしれません)。 クライアントが、特定の値(または、値)が拡張主要な用法拡大に現れるのを必要とするなら、それは、[PKIX-1]の定義されるのと同じ意味論を使用することで必要な用法を指定できます。 例えば、クライアントがTLSサーバの文脈の証明書を入手するなら、それは、サーバ証明書がイド-kp-serverAuthオブジェクト識別子がある拡張主要な用法構造を含んでいるのを必要とするでしょうに。 この場合、クライアントは、要求でspecifiedKeyUsagesの品目を入れて、イド-kp-serverAuthオブジェクト識別子について断言するでしょう。
If one or more specified usages are included in the request, the certificate MUST contain the extended key usage extension, and all usages specified in the request MUST be present in the certificate extension. The certificate extension may contain more usages than specified in the request. Specified key usages are not satisfied by the presence of the anyExtendedKeyUsage OID.
1つ以上の指定された用法が要求に含まれているなら、証明書は拡張主要な用法拡大を含まなければなりません、そして、要求で指定されたすべての用法が証明書拡張子で存在していなければなりません。 証明書拡張子は要求で指定されるより多くの用法を含むかもしれません。 指定された主要な用法はanyExtendedKeyUsage OIDの存在によって満たされていません。
Where the client does not require any particular extended key usage, the client can specify an empty SEQUENCE. This may be used to override specified key usage requirements imposed in the validation policy specified by valPolId.
クライアントが少しの特定の拡張主要な用法も必要としないところでは、クライアントは空のSEQUENCEを指定できます。 これは、valPolIdによって指定された合法化方針で課された指定された主要な用法要件に優越するのに使用されるかもしれません。
Freeman, et al. Standards Track [Page 29] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[29ページ]。
SCVP clients SHOULD support specifiedKeyUsages, and SCVP servers MUST support specifiedKeyUsages.
SCVPクライアントSHOULDはspecifiedKeyUsagesをサポートします、そして、SCVPサーバはspecifiedKeyUsagesをサポートしなければなりません。
3.2.5. responseFlags
3.2.5. responseFlags
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 }
ResponseFlags:、:= 系列誤って、responseValidationPolByRef[1]ブールの本当のfullRequestInResponseのデフォルト本当の、そして、protectResponse[2]ブールのデフォルトcachedResponse[3][0]論理演算子デフォルト論理演算子は本当にデフォルトとします。
Each of the response flags is described in the following sections.
それぞれの応答旗は以下のセクションで説明されます。
3.2.5.1. fullRequestInResponse
3.2.5.1. fullRequestInResponse
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サーバSHOULDは、帰りが完全な要求であるとサポートします。
3.2.5.2. responseValidationPolByRef
3.2.5.2. responseValidationPolByRef
The responseValidationPolByRef item controls whether the response includes just a reference to the policy or a reference to the policy plus all the parameters by value of the policy used to process the request. The response MUST contain a reference to the validation policy. If the client wants the validation policy parameters to be included by value also, then responseValidationPolByRef is set to FALSE. The main reason a client would request the server to include validation policy to be included by value is to archive the request- response exchange in a single object. That is, the client wants to archive the CVResponse and have it include every aspect of the validation policy.
応答が方針の値でまさしく方針の指示するものか方針とすべてのパラメタの指示するものを含んでいるか否かに関係なく、responseValidationPolByRef項目コントロールは以前はよく要求を処理していました。 応答は合法化方針の参照を含まなければなりません。 クライアントが値でも合法化方針パラメタを含んで欲しいなら、responseValidationPolByRefはFALSEに用意ができています。 クライアントが、値によって含まれるように合法化方針を含めるようサーバに要求するだろう主な理由は単一のオブジェクトの要求応答交換を格納することです。 すなわち、クライアントは、それにCVResponseを格納して、合法化方針のあらゆる局面を含ませたがっています。
Freeman, et al. Standards Track [Page 30] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[30ページ]。
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サーバSHOULDは、値で帰りが合法化方針であるとサポートします。
3.2.5.3. protectResponse
3.2.5.3. protectResponse
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がSHOULDがサポートするサーバであるとサポートしなければなりません。 ローカルの方針に基づいて、この値がFALSEに設定されるなら、保護されたか保護のない応答を返すためにサーバを構成できます。 サーバがローカルの方針に基づいて保護された応答を返すことができないなら、この値がTRUEに設定されるなら、サーバは誤りを返さなければなりません。
3.2.5.4. cachedResponse
3.2.5.4. cachedResponse
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を入れなければなりません。
Freeman, et al. Standards Track [Page 31] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[31ページ]。
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に用意ができているところにさえ新鮮な応答を提供するのを選ぶかもしれません。
3.2.6. serverContextInfo
3.2.6. serverContextInfo
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サーバによる前の要求応答交換からの文脈を含んでいます。それは、サーバが同じ証明書のために1つ以上の証明経路をクライアントに返すのを許容します。 例えば、次に、サーバが証明書のために特定の証明経路を構成しますが、クライアントが、それが容認できないのがわかるなら、クライアントはserverContextInfoと共に同じ質問を最初の応答からサーバに送り返すことができます、そして、サーバは異なった証明経路を提供できるでしょう(別の1つを見つけることができるなら)。
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:
SCVPクライアントにとって、serverContextInfoの内容は不明瞭です。 すなわち、クライアントは、サーバによって異なった証明経路を得るというその後の要求に提供された値を返すのが必要であることを知っているだけです。 その後の質問が、以下を除いて、前の質問と同じである必要に注意してください:
- 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サーバがSHOULDサポートserverContextInfoであるとサポートするかもしれません。
3.2.7. validationTime
3.2.7. validationTime
The optional validationTime item, if present, tells the date and time relative to which the SCVP client wants the server to perform the checks. If the validationTime is not present, the server MUST perform the validation using the date and time at which the server processes the request. If the validationTime is present, it MUST be encoded as GeneralizedTime. The validationTime provided MUST be a retrospective time since the server can only perform a validity check using the current time (default) or previous time. A server can ignore the validationTime provided in the request if the time is within the clock skew of the server's current time.
存在しているなら、任意のvalidationTimeの品目は、チェックを実行するように日時に比例してSCVPクライアントがサーバが欲しい言います。 validationTimeが存在していないなら、サーバが要求を処理する日時を使用して、サーバは合法化を実行しなければなりません。 validationTimeが存在しているなら、GeneralizedTimeとしてそれをコード化しなければなりません。 validationTimeは、サーバが働くことができるだけであって以来の回顧展時間がバリディティチェックであったに違いないなら現在の時間(デフォルト)か前の時間を使用することで提供しました。 サーバはサーバの現在の時間の時計斜行の中に時間があるなら要求に提供されたvalidationTimeを無視できます。
Freeman, et al. Standards Track [Page 32] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[32ページ]。
The revocation status information is obtained with respect to the validation time. When specifying a validation time other than the current time, the validation time should not necessarily be identical to the time when the private key was used. The validation time specified by the client may be adjusted to compensate for:
合法化時間に関して取消し状態情報を得ます。 現在の時間以外の合法化時間を指定するとき、合法化時間は必ず秘密鍵が使用された時と同じであるべきであるというわけではありません。 クライアントによって指定された合法化時間は、以下を代償するように調整されるかもしれません。
1) time for the end-entity to realize that its private key has been,
or could possibly be, compromised, and/or
そして/または1) 終わり実体が換金される秘密鍵が持っている時間はあるか、または感染されて、あるかもしれない。
2) time for the end-entity to report the key compromise, and/or
そして/または2)終わり実体が主要な感染を報告する時間。
3) time for the revocation authority to process the revocation
request from the end-entity, and/or
そして/または3)終わり実体から取消し要求を処理する取消し権威のための時間。
4) time for the revocation authority to update and distribute the
revocation status information.
4)取消し状態情報をアップデートして、分配する取消し権威のための時間。
GeneralizedTime values MUST be expressed in Universal Coordinated Time (UTC) (which is also known as Greenwich Mean Time and Zulu time) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds.
GeneralizedTime値は、Universal Coordinated Time(UTC)(また、グリニッジ標準時とズールー族の時間として知られている)に表さなければならなくて、秒を含まなければなりません(すなわち、回はYYYYMMDDHHMMSSZです)、秒数がゼロでさえあるときに。 GeneralizedTime値は断片的な秒を含んではいけません。
The information in the corresponding CertReply item in the response MUST be formatted as if the server created the response at the time indicated in the validationTime. However, if the server does not have appropriate historical information, the server MUST return an error response.
まるでvalidationTimeで示されるときサーバが応答を作成するかのように応答における対応するCertReplyの品目の情報をフォーマットしなければなりません。 しかしながら、サーバに適切な歴史に関する知識がないなら、サーバは誤り応答を返さなければなりません。
SCVP servers MUST apply a clock skew to the validation time to allow for minor time synchronization errors. The default value is 10 minutes. If the server uses a value other than the default, it MUST include the clock skew value in the validation policy response.
SCVPサーバは小さい方の時間同期化誤りを考慮する合法化時間に時計斜行を適用しなければなりません。 デフォルト値は10分です。 サーバがデフォルト以外の値を使用するなら、それは合法化方針応答に時計斜行価値を含まなければなりません。
SCVP clients MAY support validationTime other than the current time. SCVP servers MUST support using its current time, and SHOULD support the client setting the validationTime in the request.
SCVPクライアントは現在の時間以外のvalidationTimeをサポートするかもしれません。 SCVPサーバは、使用が現在の時間であるとサポートしなければなりません、そして、SHOULDは要求にvalidationTimeをはめ込んでいるクライアントをサポートします。
3.2.8. intermediateCerts
3.2.8. intermediateCerts
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
任意のintermediateCertsの品目は、SCVPサーバが有効な証明経路を作成するのを助けるかもしれません。 存在しているとき、intermediateCertsの品目は証明経路を形成するときサーバが使用するかもしれない証明書を提供します。 証明経路を造るとき、サーバがいかなる他の証明書に加えたintermediateCertsの品目のサーバが使用できる証明書を使用するかもしれない、アクセサリー そして存在しているとき、intermediateCertsの品目が少なくとも1通の証明書を含まなければならない。
Freeman, et al. Standards Track [Page 33] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[33ページ]。
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.
CertBundleとしてintermediateCertsの品目を構造化しなければなりません。 まさしく彼らがこの項目に存在しているので、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
CertBundle:、:= 証明書の系列サイズ(1..MAX)
SCVP clients SHOULD support intermediateCerts, and SCVP servers MUST support intermediateCerts.
SCVPクライアントSHOULDはintermediateCertsをサポートします、そして、SCVPサーバはintermediateCertsをサポートしなければなりません。
3.2.9. revInfos
3.2.9. revInfos
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などの取消し情報、証明経路を有効にするときSCVPサーバが使用するかもしれないデルタCRLs[PKIX-1]、および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.
クライアントSHOULD、CRLsとデルタCRLsを切り離すことによって、SCVPサーバに丁重にしてください。 しかしながら、2が一般的な構文を共有するので、彼らが通常のCRLsとしてSCVPクライアントによって特定されても、SCVPサーバSHOULDはデルタCRLsを受け入れます。
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、デルタCRLs、およびOCSP応答を提供できます。 必要であるなら、将来、追加取消し情報タイプのために追加オブジェクト識別子を割り当てることができます。
The revInfos item uses the RevocationInfos type, which has the following syntax:
revInfosの品目はRevocationInfosタイプを使用します:(タイプは以下の構文を持っています)。
RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo
RevocationInfos:、:= RevocationInfoの系列サイズ(1..MAX)
RevocationInfo ::= CHOICE {
crl [0] CertificateList,
delta-crl [1] CertificateList,
ocsp [2] OCSPResponse,
other [3] OtherRevInfo }
RevocationInfo:、:= 選択crl[0]CertificateList、デルタ-crl[1]CertificateList、ocsp[2]OCSPResponse、他の[3]OtherRevInfo
Freeman, et al. Standards Track [Page 34] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[34ページ]。
OtherRevInfo ::= SEQUENCE {
riType OBJECT IDENTIFIER,
riValue ANY DEFINED BY riType }
OtherRevInfo:、:= 系列riTypeオブジェクト識別子、riTypeによって少しも定義されたriValue
3.2.10. producedAt
3.2.10. producedAt
The client MAY allow the server to use a cached SCVP response. When doing so, the client MAY use the producedAt item to express requirements on the freshness of the cached response. The producedAt item tells the earliest date and time at which an acceptable cached response could have been produced. The producedAt item represents the date and time in UTC, using the GeneralizedTime type. The value in the producedAt item is independent of the validation time.
クライアントはサーバにキャッシュされたSCVP応答を使用させるかもしれません。 そうするとき、クライアントは、キャッシュされた応答の新しさに関する要件を言い表すのにproducedAtの品目を使用するかもしれません。 producedAtの品目は日時を許容できるキャッシュされた応答が起こされたかもしれない最も前半言います。 GeneralizedTimeタイプを使用して、producedAtの品目はUTCに日時を表します。 producedAtの品目の値は合法化時間から独立しています。
GeneralizedTime value MUST be expressed in UTC, as defined in Section 3.2.7.
セクション3.2.7で定義されるようにUTCでGeneralizedTime値を言い表さなければなりません。
SCVP clients MAY support using producedAt values in the request. SCVP servers MAY support the producedAt values in the request. SCVP servers that support cached responses SHOULD support the producedAt value in requests.
SCVPクライアントは、使用が要求でproducedAt値であるとサポートするかもしれません。 SCVPサーバは要求におけるproducedAt値をサポートするかもしれません。 キャッシュされた応答がSHOULDであるとサポートするSCVPサーバは、producedAtが要求で値であるとサポートします。
3.2.11. queryExtensions
3.2.11. queryExtensions
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を広げるのを許容するために施設を提供します。 Extensionsのための構文は[PKIX-1]からインポートされます。 存在しているとき、queryExtensionsの品目はExtensionの品目の系列を含まなければなりません、そして、それぞれの拡大はextnIDを含まなければなりません、重要です、そして、extnValueの品目 それぞれのこれらが以下のセクションで説明されます。
3.2.11.1. extnID
3.2.11.1. extnID
The extnID item is an identifier for the extension. It contains the object identifier that names the extension.
extnIDの品目は拡大のための識別子です。 それは拡大を命名するオブジェクト識別子を含んでいます。
3.2.11.2. critical
3.2.11.2. 重要です。
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.
緊要補給品はaブールです。 各拡大は重要(TRUEの値がある)か非臨界(FALSEの値がある)として指定されます。 デフォルトで、拡大は非臨界です。 認識しない重要な拡大に遭遇するなら、SCVPサーバは質問を拒絶しなければなりません。 しかしながら、非臨界拡大をそれが認識されないなら無視されるかもしれませんが、それが認識されるなら、処理しなければなりません。
Freeman, et al. Standards Track [Page 35] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[35ページ]。
3.2.11.3. extnValue
3.2.11.3. extnValue
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 STRINGを含んでいます。 中では、OCTET STRINGが拡大値です。 ASN.1タイプは関連extnIDオブジェクト識別子によって特定された各拡大に指定されます。
3.3. requestorRef
3.3. requestorRef
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はSEQUENCEとしてコード化されますが、オーダーは全く含意されません。 requestorRefの品目は、いくつかの構成でループを検出するのに使用されます。 requestorRefの値と使用はセクション7で説明されます。
Conforming SCVP clients MAY support specification of the requestorRef value. Conforming SCVP server implementations MUST process the requestorRef value if present. If the SCVP client includes a requestorRef value in the request, then the SCVP server MUST return the same value in a non-cached response. The SCVP server MAY omit the requestorRef value from cached SCVP responses.
SCVPクライアントを従わせると、requestorRef価値の仕様はサポートするかもしれません。 SCVPサーバ実装を従わせると、存在しているなら、requestorRef値は処理されなければなりません。 SCVPクライアントが要求でrequestorRef値を入れるなら、SCVPサーバは非キャッシュされた応答で同じ値を返さなければなりません。 SCVPサーバはキャッシュされたSCVP応答からrequestorRef値を省略するかもしれません。
The requestorRef item MUST be a sequence of GeneralName. No provisions are made to ensure uniqueness of the requestorRef GeneralName values.
requestorRefの品目はGeneralNameの系列であるに違いありません。 条項は全くrequestorRef GeneralName値のユニークさを確実にさせられません。
3.4. requestNonce
3.4. requestNonce
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サーバSHOULDが非キャッシュされた応答を返す優先を言い表しています。 サーバが非キャッシュされた応答を返すなら、respNonceの品目として応答における要求からのrequestNonceの値を含まなければなりません。 しかしながら、サーバはrespNonceを持ってはいけないキャッシュされた応答を返すかもしれません。
SCVP clients that insist on creation of a fresh response (e.g., to protect against a replay attack or ensure information is up to date) MUST support requestNonce. Conforming SCVP server implementations MUST process the requestNonce value if present.
新鮮な応答(例えば反射攻撃から守るか、または情報を確実にするのが最新である)の作成を主張するSCVPクライアントはrequestNonceをサポートしなければなりません。 SCVPサーバ実装を従わせると、存在しているなら、requestNonce値は処理されなければなりません。
If the client includes a requestNonce and also sets the cachedResponse flag to FALSE as described in Section 3.2.5.4, the client is indicating that the SCVP server MUST return either a non- cached response including the respNonce or an error response. The client SHOULD include a requestNonce item in every request to prevent
クライアントがrequestNonceを入れて、また、セクション3.2.5で説明されるようにcachedResponse旗をFALSEに設定するなら、.4、クライアントは、SCVPサーバがrespNonceを含む非キャッシュされた応答か誤り応答のどちらかを返さなければならないのを示しています。 クライアントSHOULDは防ぐあらゆる要求にrequestNonceの品目を含んでいます。
Freeman, et al. Standards Track [Page 36] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[36ページ]。
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値のSHOULDが変えるサーバから古い応答を再演することによって機能するのからの攻撃者はクライアントで発信しました。
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に設定してはいけません。 SHOULDがinvalidRequest誤り応答を返すそのような要求を受け取るサーバ。
The requestNonce item, if present, MUST be an OCTET STRING that was generated exclusively for this request.
存在しているなら、requestNonceの品目はこの要求のための排他的に生成されたOCTET STRINGでなければなりません。
3.5. requestorName
3.5. requestorName
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サーバはこの項目を含んでいる要求を処理できなければなりません。
3.6. responderName
3.6. responderName
The optional responderName item is used by the client to indicate the identity of the SCVP server that the client expects to sign the SCVP response if the response is digitally signed. The responderName item SHOULD only be included if:
応答がデジタルに署名されるなら、任意のresponderNameの品目は、クライアントがSCVP応答に署名すると予想するSCVPサーバのアイデンティティを示すのにクライアントによって使用されます。 responderNameの品目SHOULDだけ、含められてください、:
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サーバはこの項目の値を無視するかもしれません。 どちらの対象の分野にもresponderNameで指定された名前を含んでいる証明書に対応する秘密鍵を使用することでSCVP応答がSHOULDであると署名するために1つ以上の秘密鍵を(a) デジタルに維持するSCVPサーバが応答に署名するか、またはsubjectAltName拡大か(b)はサーバには指定された名前について断言する証明書がないのを示す誤りを返します。
Freeman, et al. Standards Track [Page 37] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[37ページ]。
3.7. requestExtensions
3.7. requestExtensions
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.
OPTIONAL requestExtensionsの品目は拡大を含んでいます。 存在しているなら、系列における各拡大は要求を広げています。 この仕様は少しの拡大も定義しません。 将来の仕様がSCVPを広げるのを許容するために施設を提供します。 Extensionsのための構文は[PKIX-1]からインポートされます。 存在しているとき、requestExtensionsの品目はExtensionの品目の系列を含まなければなりません、そして、それぞれの拡大はextnIDを含まなければなりません、重要です、そして、extnValueの品目 それぞれのこれらが以下のセクションで説明されます。
3.7.1. extnID
3.7.1. extnID
The extnID item is an identifier for the extension. It contains the object identifier that names the extension.
extnIDの品目は拡大のための識別子です。 それは拡大を命名するオブジェクト識別子を含んでいます。
3.7.2. critical
3.7.2. 重要です。
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.
緊要補給品はaブールです。 各拡大は重要(TRUEの値がある)か非臨界(FALSEの値がある)として指定されます。 デフォルトで、拡大は非臨界です。 認識しない重要な拡大に遭遇するなら、SCVPサーバは質問を拒絶しなければなりません。 非臨界拡大をそれが認識されないなら無視されるかもしれませんが、それが認識されるなら、処理しなければなりません。
3.7.3. extnValue
3.7.3. extnValue
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 STRINGを含んでいます。 中では、OCTET STRINGが拡大値です。 ASN.1タイプは関連extnIDオブジェクト識別子によって特定された各拡大に指定されます。
3.8. signatureAlg
3.8. signatureAlg
The signatureAlg item contains an AlgorithmIdentifier indicating which algorithm the server should use to sign the response message. The signatureAlg item SHOULD only be included if:
signatureAlgの品目はサーバが応答メッセージに署名するのにどのアルゴリズムを使用するべきであるかを示すAlgorithmIdentifierを含んでいます。 signatureAlgの品目SHOULDだけ、含められてください、:
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の品目SHOULDはサーバの合法化方針応答メッセージのsignatureGenerationの品目で指定された署名アルゴリズムの1つを指定します。
Freeman, et al. Standards Track [Page 38] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[38ページ]。
SCVP servers MUST be able to process requests that include this item. If the server is returning a digitally signed response to this message, then:
SCVPサーバはこの項目を含んでいる要求を処理できなければなりません。 次に、サーバがこのメッセージへのデジタルに署名している応答を返しているなら:
1. If the signatureAlg item is present and specifies an algorithm
that is included in the signatureGeneration item of the server's
validation policy response message, the server MUST sign the
response using the signature algorithm specified in signatureAlg.
1. signatureAlgの品目が存在していて、サーバの合法化方針応答メッセージのsignatureGenerationの品目に含まれているアルゴリズムを指定するなら、signatureAlgで指定された署名アルゴリズムを使用して、サーバは応答に署名しなければなりません。
2. Otherwise, if the signatureAlg item is absent or is present but
specifies an algorithm that is not supported by the server, the
server MUST sign the response using the server's default signature
algorithm as specified in the signatureGeneration item of the
server's validation policy response message.
2. さもなければ、signatureAlgの品目が休むか、存在していますが、またはサーバによってサポートされないアルゴリズムを指定するなら、サーバの合法化方針応答メッセージのsignatureGenerationの品目の指定されるとしてのサーバのデフォルト署名アルゴリズムを使用して、サーバは応答に署名しなければなりません。
3.9. hashAlg
3.9. hashAlg
The hashAlg item contains an object identifier indicating which hash algorithm the server should use to compute the hash value for the requestHash item in the response. SCVP clients SHOULD NOT include this item if fullRequestInResponse is set to TRUE. If included, the hashAlg item SHOULD specify one of the hash algorithms specified in the hashAlgorithms item of the server's validation policy response message.
hashAlgの品目はサーバがrequestHashの品目のために応答でハッシュ値を計算するのにどのハッシュアルゴリズムを使用するべきであるかを示すオブジェクト識別子を含んでいます。 fullRequestInResponseがTRUEに用意ができているなら、SCVPクライアントSHOULD NOTはこの項目を含んでいます。 含まれているなら、hashAlgの品目SHOULDはサーバの合法化方針応答メッセージのhashAlgorithmsの品目で指定されたハッシュアルゴリズムの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サーバはこの項目を含んでいる要求を処理できなければなりません。 サーバが次にrequestHashを含んでいるこのメッセージへの応答を返しているなら:
1. If the hashAlg item is present and specifies an algorithm that is
included in the hashAlgorithms item of the server's validation
policy response message, the server MUST use the algorithm
specified in hashAlg to compute the requestHash.
1. hashAlgの品目が存在していて、サーバの合法化方針応答メッセージのhashAlgorithmsの品目に含まれているアルゴリズムを指定するなら、サーバはrequestHashを計算するためにhashAlgで指定されたアルゴリズムを使用しなければなりません。
2. Otherwise, if the hashAlg item is absent or is present but
specifies an algorithm that is not supported by the server, the
server MUST compute the requestHash using the server's default
hash algorithm as specified in the hashAlgorithms item of the
server's validation policy response message.
2. さもなければ、hashAlgの品目が休むか、存在していますが、またはサーバによってサポートされないアルゴリズムを指定するなら、サーバの合法化方針応答メッセージのhashAlgorithmsの品目の指定されるとしてのサーバのデフォルトハッシュアルゴリズムを使用して、サーバはrequestHashを計算しなければなりません。
3.10. requestorText
3.10. requestorText
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の品目を使用するかもしれません。 例えば、この分野は要求の自然か理由について説明するかもしれません。
Freeman, et al. Standards Track [Page 39] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[39ページ]。
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を見てください)。
3.11. SCVP Request Authentication
3.11. SCVPは認証を要求します。
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サーバSHOULDは[PKIX-1]のセクション6で定義された合法化アルゴリズムを使用します。
If the certificate used to validate a SignedData validation request includes the key usage extension ([PKIX-1], Section 4.2.1.3), it MUST have either the digital signature bit set, the non-repudiation bit set, or both bits set.
証明書が以前はよくSignedDataを有効にしていたなら、合法化要求は主要な用法拡大[PKIX-1]を含んでいます、セクション4.2。.1 .3) それにはデジタル署名ビットが設定するどちらかがなければならない、非拒否ビットがセットしたか、またはさもなければ、両方のビットはセットしました。
If the certificate used to validate an AuthenticatedData validation request includes the key usage extension, it MUST have the key agreement bit set.
AuthenticatedData合法化要求を有効にするのに使用される証明書が主要な用法拡大を含んでいるなら、それで、主要な協定ビットを設定しなければなりません。
If the certificate used on a validation request contains the extended key usage extension ([PKIX-1], Section 4.2.1.13), the server SHALL verify that it contains the SCVP client OID, the anyExtendedKeyUsage OID, or another OID acceptable to the server. The SCVP client OID is defined as follows:
合法化要求のときに使用された証明書が広げることを含むなら、用法拡大[PKIX-1]を合わせてください、セクション4.2。サーバSHALLは、サーバに許容できるSCVPクライアントOID、anyExtendedKeyUsage OID、または別のOIDを含むことを確かめます。.1 .13) SCVPクライアントOIDは以下の通り定義されます:
id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 }
イド-kp OBJECT IDENTIFIER:、:= iso(1)、組織(3)dod(6)インターネット(1)セキュリティ(5)が特定されたメカニズム(5)pkix(7)3
id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 }
イド-kp-scvpClientオブジェクト識別子:、:= イド-kp16
If a protected request fails to meet the validation policy of the server, it MUST be treated as an unauthenticated request.
保護された要求がサーバの合法化方針を満たさないなら、非認証された要求としてそれを扱わなければなりません。
4. Validation Response
4. 合法化応答
An SCVP server response to the client MUST be a single CVResponse item. When a CVResponse is encapsulated in a MIME body part, application/scvp-cv-response MUST be used.
クライアントへのSCVPサーバ応答はただ一つのCVResponseの品目であるに違いありません。 CVResponseがMIME身体の部分でカプセル化されるとき、scvp-cvアプリケーション/応答を使用しなければなりません。
There are a number of forms of an SCVP response:
SCVP応答の多くのフォームがあります:
1. A success response to a request that has protectResponse set to
FALSE. These responses SHOULD NOT be protected by the server.
1. protectResponseを持っている要求への成功応答はFALSEにセットしました。 これらの応答SHOULD NOT、サーバで、保護されてください。
Freeman, et al. Standards Track [Page 40] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[40ページ]。
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などの保護された輸送を変更しました。 これらの応答SHOULD NOT、サーバで、保護されてください。
4. An error response to a request that has protectResponse set to
FALSE. These responses SHOULD NOT be protected by the server.
4. protectResponseを持っている要求への誤り応答はFALSEにセットしました。 これらの応答SHOULD NOT、サーバで、保護されてください。
5. An error response to an authenticated request. The server SHOULD
protect these responses.
5. 認証された要求への誤り応答。 サーバSHOULDはこれらの応答を保護します。
6. An error response to an AuthenticatedData request where MAC is
valid. The server MUST protect these responses.
6. MACが有効であるAuthenticatedData要求への誤り応答。 サーバはこれらの応答を保護しなければなりません。
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とSHOULDサポートAuthenticatedDataをサポートしなければなりません。 どのタイプが使用されているかは、ローカルの方針の問題です。 保護された応答が必要であるところでは、SCVPサーバはSignedDataかAuthenticatedDataを使用しなければなりません、トランザクションが保護された輸送(例えば、TLS)を使用することで実行されても。
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 }
ContentInfocontentType、イドct scvp-certValResponse、--、(1.2.840.113549.1.9.16.1.11)内容CVResponse
Freeman, et al. Standards Track [Page 41] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[41ページ]。
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.
保護された応答はContentInfoで順番にカプセル化されるSignedDataかAuthenticatedDataのどちらかでカプセル化されたCVResponseから成ります。 すなわち、SignedDataかAuthenticatedDataが値でeContentType分野から成るどちらかのEncapsulatedContentInfo分野、イドct scvp-certValResponse、そして、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分野に1CRLsを提供するかもしれません。 SignedDataのsignerInfos分野はちょうど1SignerInfoを含まなければなりません。 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分野はcontent typeを含まなければなりません、そして、メッセージダイジェスト属性は[CMS]、およびそれで署名証明書が[ESS]で定義されるように結果と考えるSHOULDインクルードを定義しました。 署名証明書属性の中では、証明書識別子の系列で特定された最初の証明書はSCVPサーバの証明書であるに違いありません。署名証明書属性での他の証明書識別子の包含はOPTIONALです。 署名証明書での方針の包含はOPTIONALです。
The recipientInfos field of AuthenticatedData MUST include exactly one RecipientInfo, which contains information for the client that sent the request. The AuthenticatedData MUST NOT include the unauthAttrs field.
AuthenticatedDataのrecipientInfos分野はちょうど1RecipientInfoを含まなければなりません。(RecipientInfoは要求を送ったクライアントへの情報を含みます)。 AuthenticatedDataはunauthAttrs分野を含んではいけません。
The CVResponse item contains the server's response. The CVResponse MUST contain the cvResponseVersion, serverConfigurationID, producedAt, and responseStatus items. The CVResponse MAY also contain the respValidationPolicy, requestRef, requestorRef, requestorName, replyObjects, respNonce, serverContextInfo, and cvResponseExtensions items. The replyObjects item MUST contain exactly one CertReply item for each certificate requested. The requestorRef item MUST be included if the request included a requestorRef item and a non-cached response is provided. The respNonce item MUST be included if the request included a requestNonce item and a non-cached response is provided.
CVResponseの品目はサーバの応答を含んでいます。 CVResponseはcvResponseVersionを含まなければなりません、また、responseStatusの品目 serverConfigurationID、producedAt、およびCVResponseはrespValidationPolicy、requestRef、requestorRef、requestorName、replyObjects、respNonce、serverContextInfo、およびcvResponseExtensionsの品目を含むかもしれません。replyObjectsの品目はちょうど各証明書のためのCertReplyの品目が要求した1つを含まなければなりません。 要求がrequestorRefの品目を含んでいたなら、requestorRefの品目を含まなければなりません、そして、非キャッシュされた応答を提供します。 要求がrequestNonceの品目を含んでいたなら、respNonceの品目を含まなければなりません、そして、非キャッシュされた応答を提供します。
Freeman, et al. Standards Track [Page 42] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[42ページ]。
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 }
CVResponse:、:= 系列{ cvResponseVersion整数、serverConfigurationID整数、responseStatus ResponseStatusの、そして、respValidationPolicy0のRespValidationPolicyの任意の、そして、requestRef1RequestReference任意のrequestorRef2GeneralNames任意のproducedAt GeneralizedTime; requestorName3のGeneralNamesの任意の、そして、replyObjects4ReplyObjects任意のrespNonce5の八重奏のストリングの任意の、そして、serverContextInfo6八重奏ストリング任意のcvResponseExtensions7拡張子任意のrequestorText8UTF8String(サイズ(1 .256))任意です; }
Conforming SCVP servers MAY be capable of constructing a CVResponse that includes the serverContextInfo or cvResponseExtensions items. Conforming SCVP servers MUST be capable of constructing a CVResponse with any of the remaining optional items. Conforming SCVP clients MUST be capable of processing a CVResponse with the following optional items: respValidationPolicy, requestRef, requestorName, replyObjects, and respNonce.
SCVPサーバを従わせると、serverContextInfoかcvResponseExtensionsの品目を含んでいるCVResponseは組み立てることができるかもしれません。SCVPサーバを従わせると、残っている任意の項目のどれかがあるCVResponseは組み立てることができなければなりません。SCVPクライアントを従わせると、以下の任意の項目があるCVResponseを処理できなければなりません: respValidationPolicy、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かcvResponseExtensionsの品目を含んでいるCVResponseは処理できなければなりません。クライアントを従わせるのは、重要な拡大がcvResponseExtensionsの品目に存在しているかどうか決定できなければなりません。
4.1. cvResponseVersion
4.1. cvResponseVersion
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に合わなければなりません。 サーバが合っているバージョン番号で応答を生成することができないなら、サーバはサーバがバージョン番号としてサポートする中で最も大きいバージョン番号を示す誤り応答を返さなければなりません。
4.2. serverConfigurationID
4.2. serverConfigurationID
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を見てください。
Freeman, et al. Standards Track [Page 43] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[43ページ]。
4.3. producedAt
4.3. producedAt
The producedAt item tells the date and time at which the SCVP server generated the response. The producedAt item MUST be expressed in UTC, and it MUST be interpreted as defined in Section 3.2.7. This value is independent of the validation time.
producedAtの品目はSCVPサーバが応答を生成した日時を言います。 UTCでproducedAtの品目を言い表さなければなりません、そして、セクション3.2.7で定義されているとそれを解釈しなければなりません。 この値は合法化時間から独立しています。
4.4. responseStatus
4.4. responseStatus
The responseStatus item gives status information to the SCVP client about its request. The responseStatus item has a numeric status code and an optional string that is a sequence of characters from the ISO/IEC 10646-1 character set encoded with the UTF-8 transformation format defined in [UTF8].
responseStatusの品目は要求に関して状態情報をSCVPクライアントに教えます。 responseStatusの品目には、数値ステータスコードとUTF-8変換書式が[UTF8]で定義されている状態でコード化されたISO/IEC10646-1文字集合からのキャラクタの系列である任意のストリングがあります。
The string MAY be used to transmit status information. The client MAY choose to display the string to a human user. However, because there is often no way to know the languages understood by a human user, the string may be of little or no assistance.
ストリングは、状態情報を伝えるのに使用されるかもしれません。 クライアントは、人間のユーザにストリングを表示するのを選ぶかもしれません。 しかしながら、人間のユーザに解釈された言語を知る方法が全くしばしばあるというわけではないので、ストリングはまず役に立たないかもしれません。
The responseStatus item uses the ResponseStatus type, which has the following syntax:
responseStatusの品目はResponseStatusタイプを使用します:(タイプは以下の構文を持っています)。
ResponseStatus ::= SEQUENCE {
statusCode CVStatusCode DEFAULT okay,
errorMessage UTF8String OPTIONAL }
ResponseStatus:、:= 系列statusCode CVStatusCode DEFAULT承認、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),
CVStatusCode:、:= ENUMERATED、(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)
Freeman, et al. Standards Track [Page 44] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[44ページ]。
unrecognizedValAlg (51),
fullRequestInResponseUnsupported (52),
fullPolResponseUnsupported (53),
inhibitPolicyMappingUnsupported (54),
requireExplicitPolicyUnsupported (55),
inhibitAnyPolicyUnsupported (56),
validationTimeUnsupported (57),
unrecognizedCritQueryExt (63),
unrecognizedCritRequestExt (64) }
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 サーバは、帰りが応答で完全な要求であるとサポートしません。
Freeman, et al. Standards Track [Page 45] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[45ページ]。
53 The server does not support returning the full validation policy
by value in the response.
54 The server does not support the requested value for inhibit
policy mapping.
55 The server does not support the requested value for require
explicit policy.
56 The server does not support the requested value for inhibit
anyPolicy.
57 The server only validates requests using current time.
63 The query item in the request contains a critical extension whose
OID is not recognized.
64 The request contains a critical request extension whose OID is
not recognized.
53 サーバは、応答における値で帰りが完全な合法化方針であるとサポートしません。 サーバが要求された値をサポートしない54は方針マッピングを禁止します。 サーバが要求された値をサポートしない55は明白な方針を必要とします。 サーバが要求された値をサポートしない56はanyPolicyを禁止します。 57 サーバは、現在の時間を使用することで要求を有効にするだけです。 63 要求における質問項目はOIDが認識されない重要な拡大を含んでいます。 64 要求はOIDが認識されない重要な要求拡張子を含んでいます。
Status codes 0-9 are reserved for codes that indicate the request was processed by the server and therefore MUST be sent in a success response. Status codes 10 and above indicate an error and MUST therefore be sent in an error response.
ステータスコード0-9は要求をサーバによって処理されて、したがって、成功応答で送らなければならないのを示すコードのために予約されます。 より多くのステータスコード10を誤りを示して、したがって、誤り応答で送らなければなりません。
4.5. respValidationPolicy
4.5. respValidationPolicy
The respValidationPolicy item contains either a reference to the full validation policy or the full policy by value used by the server to validate the request. It MUST be present in success responses and MUST NOT be present in error responses. The choice between returning the policy by reference or by value is controlled by the responseValidationPolByRef item in the request. The resultant validation policy is the union of the following:
respValidationPolicyの品目はサーバによって使用される、要求を有効にする値で完全な合法化方針の参照か完全担保保険証券のどちらかを含みます。 それは、成功応答で存在していなければならなくて、現在の間違った応答であるはずがありません。 参照か値で方針を返すことの選択は要求でresponseValidationPolByRefの品目によって制御されます。 結果の合法化方針は以下の組合です:
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:
RespValidationPolicy構文は以下の通りです。
RespValidationPolicy ::= ValidationPolicy
RespValidationPolicy:、:= ValidationPolicy
The validationPolicy item is defined in Section 3.2.4. When responseValidationPolByRef is set to FALSE in the request, all items in the validationPolicy item MUST be populated. When responseValidationPolByRef is set to TRUE, OPTIONAL items in the validationPolicy item only need to be populated for items for which the value in the request differs from the value from the referenced validation policy.
validationPolicyの品目はセクション3.2.4で定義されます。 responseValidationPolByRefが要求でFALSEに用意ができているとき、validationPolicyの品目のすべての項目に居住しなければなりません。 responseValidationPolByRefがTRUEに用意ができているとき、validationPolicyの品目のOPTIONALの品目は、要求における値が参照をつけられた合法化方針からの値と異なっている項目のために居住される必要があるだけです。
Freeman, et al. Standards Track [Page 46] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[46ページ]。
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サーバ実装を従わせると、参照で方針を断言できなければならなくて、任意の項目を含むことができなければなりません。
4.6. requestRef
4.6. requestRef
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.
SCVPクライアントはrequestRefの品目でサーバからこの応答に対応する要求を特定できます。それは、要求から要求のハッシュか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 }
RequestReference:、:= 選択requestHash[0]HashValue--、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をサポートするかもしれません。 requestHashを使用するサーバがサポートしなければならないSCVP、およびそれら、SHOULDは、使用がfullRequestであるとサポートします。
4.6.1. requestHash
4.6.1. requestHash
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つの目的に役立ちます。 まず最初に、それで、クライアントは、要求が陰湿に変更されなかったと決心できます。 コネクションレスプロトコルを使用するとき、2番目に、それで、クライアントは応答を要求に関連づけることができます。 requestNonceは合っている要求と応答に代替のメカニズムを提供します。
Freeman, et al. Standards Track [Page 47] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[47ページ]。
The requestHash item uses the HashValue type, which has the following syntax:
requestHashの品目はHashValueタイプを使用します:(タイプは以下の構文を持っています)。
HashValue ::= SEQUENCE {
algorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 },
value OCTET STRING }
HashValue:、:= 系列アルゴリズムAlgorithmIdentifier DEFAULTアルゴリズムsha-1、値のOCTET STRING
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
sha-1 OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)oiw(14) secsig(3)アルゴリズム(2)26
The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It is repeated here for convenience.
SHA-1のためのアルゴリズム識別子は[PKIX-ALG]からインポートされます。 それは便宜のためにここで繰り返されます。
4.6.2. fullRequest
4.6.2. 最もfullRequest
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で説明されます。
4.7. requestorRef
4.7. requestorRef
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サーバは同じ値を返さなければなりません。
4.8. requestorName
4.8. requestorName
The optional requestorName item is used by the server to return one or more identities associated with the client in the response.
任意のrequestorNameの品目はサーバによって使用されて、応答でクライアントに関連している1つ以上のアイデンティティを返します。
The SCVP server MAY choose to include any or all of the following:
SCVPサーバは、以下のいずれかすべてを含んでいるのを選ぶかもしれません:
(1) the identity asserted by the client in the requestorName item of
the request,
(1) 要求のrequestorNameの品目のクライアントによって断言されたアイデンティティ
(2) an authenticated identity for the client from a certificate or
other credential used to authenticate the request, or
または(2) 証明書か他の資格証明書からのクライアントのための認証されたアイデンティティが以前はよく要求を認証していた。
(3) a client identifier from an out-of-band mechanism.
(3) バンドで出ているメカニズムからのクライアント識別子。
Alternatively, the SCVP server MAY omit this item.
あるいはまた、SCVPサーバはこの項目を省略するかもしれません。
Freeman, et al. Standards Track [Page 48] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[48ページ]。
In the case of non-cached responses to authenticated requests, the SCVP server SHOULD return a requestor name.
認証された要求への非キャッシュされた応答の場合では、SCVPサーバSHOULDは要請者名を返します。
SCVP servers that support authenticated requests SHOULD support this item.
認証された要求がSHOULDであるとサポートする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クライアントはこの項目を含んでいる応答を処理できなければなりません、項目値がどんな方法でも処理に影響を与えないかもしれませんが。
4.9. replyObjects
4.9. replyObjects
The replyObjects item returns requested objects to the SCVP client, each of which tells the client about a single certificate from the request. The replyObjects item MUST be present in the response, unless the response is reporting an error. The CertReply item MUST contain cert, replyStatus, replyValTime, replyChecks, and replyWantBacks items, and the CertReply item MAY contain the validationErrors, nextUpdate, and certReplyExtensions items.
replyObjects項目リターンはSCVPクライアントへのオブジェクトを要求しました。それはただ一つの証明書に関するクライアントとそれぞれ要求を見分けます。 応答が誤りを報告していない場合、replyObjectsの品目は応答で存在していなければなりません。 CertReplyの品目は本命、replyStatus、replyValTime、replyChecks、およびreplyWantBacksの品目を含まなければなりません、そして、CertReplyの品目はvalidationErrors、nextUpdate、およびcertReplyExtensionsの品目を含むかもしれません。
A success response MUST contain one CertReply for each certificate specified in the queriedCerts item in the request. The order is important. The first CertReply in the sequence MUST correspond to the first certificate in the request, the second CertReply in the sequence MUST correspond to the second certificate in the request, and so on.
成功応答は要求にqueriedCertsの品目で指定された各証明書あたり1CertReplyを含まなければなりません。 オーダーは重要です。 系列における最初のCertReplyは要求における最初の証明書に対応しなければなりません、系列のCertReplyが要求、などに2番目の証明書に対応しなければならない秒に。
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
ReplyObjects:、:= CertReplyの系列サイズ(1..MAX)
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 }
CertReply:、:= 系列本命CertReference、replyStatus ReplyStatus DEFAULT成功、replyValTime GeneralizedTime、replyChecks ReplyChecks replyWantBacks ReplyWantBacks、validationErrors[0]SEQUENCE SIZE(1..MAX)OF OBJECT IDENTIFIER OPTIONAL nextUpdate[1]GeneralizedTime OPTIONAL、certReplyExtensions[2]拡大OPTIONAL
Freeman, et al. Standards Track [Page 49] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[49ページ]。
4.9.1. cert
4.9.1. 本命
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.
本命項目はクライアントが情報を要求している証明書の証明書か参照のどちらかを含んでいます。 証明書が要求における参照で指定されて、要求がイドswb-pkc本命かイドswb-aa本命wantBackのどちらかを含んで、サーバが参照をつけられた証明書を入手できたなら、この項目は証明書を含まなければなりません。 さもなければ、この項目は要求におけるqueriedCertsの品目で使用されたのと同じ値を含まなければなりません。
CertReference has the following syntax:
CertReferenceには、以下の構文があります:
CertReference ::= CHOICE {
pkc PKCReference,
ac ACReference }
CertReference:、:= 選択pkc PKCReference、ac ACReference
4.9.2. replyStatus
4.9.2. replyStatus
The replyStatus item gives status information to the client about the request for the specific certificate. Note that the responseStatus item is different from the replyStatus item. The responseStatus item is the status of the whole request, while the replyStatus item is the status for the individual query item.
replyStatusの品目は特定の証明書に関する要求に関して状態情報をクライアントに教えます。 responseStatusの品目がreplyStatusの品目と異なっていることに注意してください。 responseStatusの品目は全体の要求の状態です、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) }
ReplyStatus:、:= 列挙されます。成功(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失敗: 証明経路を全く構成できませんでした。
Freeman, et al. Standards Track [Page 50] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[50ページ]。
6 Failure: the constructed certification path is not valid with
respect to the validation policy.
7 Failure: the constructed certification path is not valid with
respect to the validation policy, but a query at a later time may
be successful.
8 Failure: all checks were performed successfully; however, one or
more of the wantBacks could not be satisfied.
6失敗: 組み立てられた証明経路は合法化方針に関して有効ではありません。 7失敗: 組み立てられた証明経路は合法化方針に関して有効ではありませんが、質問は後でうまくいっているかもしれません。 8失敗: すべてのチェックが首尾よく実行されました。 しかしながら、wantBacksの1つ以上は満足することができませんでした。
Codes 1 and 2 are used to tell the client that the request was properly formed, but the certificate in question was not. This is especially useful to clients that do not parse certificates.
コード1と2は要求が適切に形成されたとクライアントに言うのに使用されましたが、問題の証明書は使用されたというわけではありません。 これは特に証明書を分析しないクライアントの役に立ちます。
Code 7 is used to tell the client that a valid certification path was found with the exception that a certificate in the path is on hold, current revocation information is unavailable, or the validation time precedes the notBefore time in one or more certificates in the path.
コード7は、経路の証明書が保留されているか、現在の取消し情報が入手できないか、または合法化時間が経路の1通以上の証明書でnotBefore時間に先行すると有効な証明経路が例外で見つけられたクライアントに言うのに使用されます。
For codes 1, 2, 3, and 4, the replyChecks and replyWantBacks items are not populated (i.e., they MUST be an empty sequence). For codes 5, 6, 7, and 8, replyChecks MUST include an entry corresponding to each check in the request; the replyWantBacks item is not populated.
コード1、2、3、および4において、replyChecksとreplyWantBacksの品目は居住されません(すなわち、それらは空の系列であるに違いありません)。 コード5、6、7、および8のために、replyChecksはそれぞれ要求を預けるために対応するエントリーを含まなければなりません。 replyWantBacksの品目は居住されません。
4.9.3. replyValTime
4.9.3. replyValTime
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の情報が正しかった時を言います。 GeneralizedTimeタイプを使用して、replyValTimeの品目はUTCに日時を表します。 セクション3.2.7におけるGeneralizedTimeのための符号化規則を使用しなければなりません。
Within the request, the optional validationTime item tells the date and time relative to which the SCVP client wants the server to perform the checks. If the validationTime is not present, the server MUST respond as if the client provided the date and time at which the server processes the request.
要求の中では、任意のvalidationTimeの品目は、チェックを実行するように日時に比例してSCVPクライアントがサーバが欲しい言います。 validationTimeが存在していないなら、まるでクライアントがサーバが要求を処理する日時を提供するかのようにサーバは反応しなければなりません。
The information in the CertReply item MUST be formatted as if the server created this portion of the response at the time indicated in the validationTime item of the query. However, if the server does not have appropriate historical information, the server MAY either return an error or return information for a later time.
まるで質問のvalidationTimeの品目で示されるときサーバが応答のこの部分を作成するかのようにCertReplyの品目の情報をフォーマットしなければなりません。 しかしながら、サーバに適切な歴史に関する知識がないなら、サーバは、誤りを返すか、または後の時間情報を返すかもしれません。
4.9.4. replyChecks
4.9.4. replyChecks
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
replyChecksの品目は質問にチェック項目への応答を含んでいます。 replyChecksの品目は質問と整数からのオブジェクト識別子(OID)を含んでいます。 整数の値は、要求されたチェックがうまくいったかどうかを示します。 質問のチェック項目のOIDsは、対応するreplyChecksを特定するのに使用されます。
Freeman, et al. Standards Track [Page 51] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[51ページ]。
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の品目のOIDは要求におけるチェック項目で指定された各OIDに合わなければなりません。 誤り応答の場合では、サーバは、さらに誤りについて説明するために応答における追加チェックを含むかもしれません。 クライアントは応答に含まれていたどんな認識されていないReplyCheckも無視しなければなりません。
The replyChecks item uses the ReplyChecks type, which has the following syntax:
replyChecksの品目はReplyChecksタイプを使用します:(タイプは以下の構文を持っています)。
ReplyChecks ::= SEQUENCE OF ReplyCheck
ReplyChecks:、:= ReplyCheckの系列
ReplyCheck ::= SEQUENCE {
check OBJECT IDENTIFIER,
status INTEGER DEFAULT 0 }
ReplyCheck:、:= 系列OBJECT IDENTIFIER、状態INTEGER DEFAULT0をチェックしてください。
The status value for public key certification path building to a
trusted root, { id-stc 1 }, can be one of the following:
信じられた根への公開鍵証明経路ビルへの状態値(イド-stc1)は以下の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:
簡単な合法化処理に伴う信じられた根への公開鍵証明経路ビルへの状態値(イド-stc2)は以下の1つであるかもしれません:
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:
完全な状態の照合に伴う信じられた根への公開鍵証明経路ビルへの状態値(イド-stc3)は以下の1つであるかもしれません:
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通以上の証明書のための取消し情報のためのソースの場所を見つけることができなかったことを意味しません。
Freeman, et al. Standards Track [Page 52] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[52ページ]。
The status value for AC issuer certification path building to a
trusted root, { id-stc 4 }, can be one of the following:
信じられた根への交流発行人証明経路ビルへの状態値(イド-stc4)は以下の1つであるかもしれません:
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:
簡単な合法化処理に伴う信じられた根への交流発行人証明経路ビルへの状態値(イド-stc5)は以下の1つであるかもしれません:
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:
完全な状態の照合に伴う信じられた根への交流発行人証明経路ビルへの状態値(イド-stc6)は以下の1つであるかもしれません:
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:
完全な状態の照合に伴う信じられた根まで建てられる交流発行人証明経路と同様に西暦の取消し状態の照合のための状態値(イド-stc7)は以下の1つであるかもしれません:
0: Valid
1: Not valid
2: Revocation off-line
3: Revocation unavailable
4: No known source for revocation information
0: 有効な1: 有効な2でない: 取消しオフライン3: 取消し入手できない4: 取消し情報のための知られているソースがありません。
4.9.5. replyWantBacks
4.9.5. replyWantBacks
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の品目は要求とOCTET STRINGのwantBackの品目からのオブジェクト識別子(OID)を含んでいます。 中では、OCTET STRINGが要求された値です。 要求におけるwantBackの品目のOIDsは、対応する回答値を特定するのに使用されます。 replyWantBacksの品目のOIDsは要求でwantBackの品目でOIDsに合わなければなりません。 非誤り応答のために、replyWantBacksはちょうど要求(求められた情報が本命項目に含まれているところでイドswb-pkc本命とイドswb-ac本命を除く)で指定された各wantBackあたり1ReplyWantBackを含まなければなりません。
Freeman, et al. Standards Track [Page 53] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[53ページ]。
The replyWantBacks item uses the ReplyWantBacks type, which has the following syntax:
replyWantBacksの品目はReplyWantBacksタイプを使用します:(タイプは以下の構文を持っています)。
ReplyWantBacks ::= SEQUENCE OF ReplyWantBack
ReplyWantBacks:、:= ReplyWantBackの系列
ReplyWantBack::= SEQUENCE {
wb OBJECT IDENTIFIER,
value OCTET STRING }
ReplyWantBack:、:= 系列wb OBJECT IDENTIFIER、値の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.
要求における証明書について確かめるのに使用される証明経路へのOCTET STRING値(イド-swb1)はCertBundleタイプを含んでいます。 CertBundleタイプの構文と意味論はセクション3.2.8で説明されます。 このCertBundleは経路にすべての証明書を含んでいます、証明書が信頼アンカーによって発行されている状態で終わりの証明書と結末から始まって。
The OCTET STRING value for the proof of revocation status,
{ id-swb 2 }, contains the RevInfoWantBack type. The RevInfoWantBack
type is a SEQUENCE of the RevocationInfos type and an optional
CertBundle. The syntax and semantics of the RevocationInfos type are
described in Section 3.2.9. The CertBundle MUST be included if any
certificates required to validate the revocation information were not
returned in the id-swb-pkc-best-cert-path or
id-swb-pkc-all-cert-paths wantBack. The CertBundle MUST include all
such certificates, but there are no ordering requirements.
取消し状態の証拠のためのOCTET STRING値(イド-swb2)はRevInfoWantBackタイプを含んでいます。 RevInfoWantBackタイプは、RevocationInfosタイプのSEQUENCEと任意のCertBundleです。 RevocationInfosタイプの構文と意味論はセクション3.2.9で説明されます。 取消し情報を有効にするのに必要である証明書がイドのswb-pkcの最も良い本命道かイドswb-pkcオール本命道のwantBackで返されなかったなら、CertBundleを含まなければなりません。 CertBundleはそのようなすべての証明書を含まなければなりませんが、注文要件が全くありません。
RevInfoWantBack ::= SEQUENCE {
revocationInfo RevocationInfos,
extraCerts CertBundle OPTIONAL }
RevInfoWantBack:、:= 系列revocationInfo RevocationInfosで、extraCerts CertBundle任意です。
The OCTET STRING value for the public key information, { id-swb 4 },
contains the SubjectPublicKeyInfo type. The syntax and semantics of
the SubjectPublicKeyInfo type are described in [PKIX-1].
公開鍵情報のためのOCTET STRING値(イド-swb4)はSubjectPublicKeyInfoタイプを含んでいます。 SubjectPublicKeyInfoタイプの構文と意味論は[PKIX-1]で説明されます。
The OCTET STRING value for the AC issuer certification path used to
verify the certificate in the request, { id-swb 5 }, contains the
CertBundle type. The syntax and semantics of the CertBundle type are
described in Section 3.2.8. This CertBundle includes all the
certificates in the path, beginning with the AC issuer certificate
and ending with the certificate issued by the trust anchor.
要求における証明書について確かめるのに使用される交流発行人証明経路へのOCTET STRING値(イド-swb5)はCertBundleタイプを含んでいます。 CertBundleタイプの構文と意味論はセクション3.2.8で説明されます。 このCertBundleは経路にすべての証明書を含んでいます、交流発行人証明書で始まって、証明書が信頼アンカーによって発行されている状態で終わって。
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
交流発行人証明経路の取消し状態の証拠のためのOCTET STRING値(イド-swb6)はRevInfoWantBackタイプを含んでいます。 RevInfoWantBackタイプは、RevocationInfosタイプのSEQUENCEと任意のCertBundleです。 RevocationInfosタイプの構文と意味論はセクション3.2.9で説明されます。 CertBundle
Freeman, et al. Standards Track [Page 54] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[54ページ]。
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.
取消し情報を有効にするのに必要である証明書がイドaa本命道のwantBackで返されなかったなら、含めなければならなくなってください。 CertBundleはそのようなすべての証明書を含まなければなりませんが、注文要件が全くありません。
The OCTET STRING value for the proof of revocation status of the
attribute certificate, { id-swb 7 }, contains the RevInfoWantBack
type. The RevInfoWantBack type is a SEQUENCE of the RevocationInfos
type and an optional CertBundle. The syntax and semantics of the
RevocationInfos type are described in Section 3.2.9. The CertBundle
MUST be included if any certificates required to validate the
revocation information were not returned in the id-swb-aa-cert-path
wantBack. The CertBundle MUST include all such certificates, but
there are no ordering requirements.
属性証明書の取消し状態の証拠のためのOCTET STRING値(イド-swb7)はRevInfoWantBackタイプを含んでいます。 RevInfoWantBackタイプは、RevocationInfosタイプのSEQUENCEと任意のCertBundleです。 RevocationInfosタイプの構文と意味論はセクション3.2.9で説明されます。 取消し情報を有効にするのに必要である証明書がイドswb-aa本命道のwantBackで返されなかったなら、CertBundleを含まなければなりません。 CertBundleはそのようなすべての証明書を含まなければなりませんが、注文要件が全くありません。
The OCTET STRING value for returning all paths, { id-swb 12 },
contains an ASN.1 type CertBundles, as defined below. The syntax and
semantics of the CertBundle type are described in Section 3.2.8.
Each CertBundle includes all the certificates in one path, starting
with the end certificate and ending with the certificate issued by
the trust anchor.
すべての経路を返すためのOCTET STRING値(イド-swb12)は以下で定義されるようにASN.1タイプCertBundlesを含んでいます。 CertBundleタイプの構文と意味論はセクション3.2.8で説明されます。 各CertBundleは1つの経路にすべての証明書を含んでいます、証明書が信頼アンカーによって発行されている状態で終わりの証明書と結末から始まって。
CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle
CertBundles:、:= CertBundleの系列サイズ(1..MAX)
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.
リレーされた応答のためのOCTET STRING値(イド-swb9)は以下で定義されるようにASN.1タイプSCVPResponsesを含んでいます。 SCVPサーバがこの応答を生成するとき他のSCVPサーバから得られた情報を使用したなら、SCVPResponsesはそれらのサーバから受けられたそれぞれのSCVP応答を含まなければなりません。 SCVPサーバが応答を生成するとき他のSCVPサーバから得られた情報を使用しなかったなら、SCVPResponsesは空の系列であるに違いありません。
SCVPResponses ::= SEQUENCE OF ContentInfo
SCVPResponses:、:= ContentInfoの系列
The OCTET STRING value for the proof of revocation status of the
path's target certificate, { id-swb-13 }, contains the
RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the
RevocationInfos type and an optional CertBundle. The syntax and
semantics of the RevocationInfos type are described in Section 3.2.9.
The CertBundle MUST be included if any certificates required to
validate the revocation information were not returned in the id-swb-
pkc-best-cert-path or id-swb-pkc-all-cert-paths wantBack. The
CertBundle MUST include all such certificates, but there are no
ordering requirements.
経路の目標証明書の取消し状態の証拠のためのOCTET STRING値(イド-swb-13)はRevInfoWantBackタイプを含んでいます。 RevInfoWantBackタイプは、RevocationInfosタイプのSEQUENCEと任意のCertBundleです。 RevocationInfosタイプの構文と意味論はセクション3.2.9で説明されます。 取消し情報を有効にするのに必要である証明書がイドのswb- pkcの最も良い本命道かイドswb-pkcオール本命道のwantBackで返されなかったなら、CertBundleを含まなければなりません。 CertBundleはそのようなすべての証明書を含まなければなりませんが、注文要件が全くありません。
The OCTET STRING value for the proof of revocation status of the
intermediate certificates in the path, { id-swb 14 }, contains the
RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the
経路の中間的証明書の取消し状態の証拠のためのOCTET STRING値(イド-swb14)はRevInfoWantBackタイプを含んでいます。 RevInfoWantBackタイプはSEQUENCEです。
Freeman, et al. Standards Track [Page 55] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[55ページ]。
RevocationInfos type and an optional CertBundle. The syntax and semantics of the RevocationInfos type are described in Section 3.2.9. The CertBundle MUST be included if any certificates required to validate the revocation information were not returned in the id-swb- pkc-best-cert-path or id-swb-pkc-all-cert-paths wantBack. The CertBundle MUST include all such certificates, but there are no ordering requirements.
RevocationInfosタイプと任意のCertBundle。 RevocationInfosタイプの構文と意味論はセクション3.2.9で説明されます。 取消し情報を有効にするのに必要である証明書がイドのswb- pkcの最も良い本命道かイドswb-pkcオール本命道のwantBackで返されなかったなら、CertBundleを含まなければなりません。 CertBundleはそのようなすべての証明書を含まなければなりませんが、注文要件が全くありません。
4.9.6. validationErrors
4.9.6. validationErrors
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の品目は失敗応答で存在しているだけでよいです。 そして、存在しているなら、合法化が失敗した理由を表す1OIDsを含まなければならない、(基本的な合法化アルゴリズムと名前合法化アルゴリズムのための合法化誤りがセクション3.2.4で定義される、.2、.2、3.2 .4 .2 .4)。 validationErrorsの品目SHOULD、replyStatusが3、5、6、7、または8歳であるときには、単に含められてください。 SCVPサーバは、合法化が失敗した理由のすべてを指定するのに必要ではありません。 SCVPクライアントは、validationErrorsに含まれていたOIDsが証明経路のための合法化誤りのすべてを表すと仮定してはいけません。
4.9.7. nextUpdate
4.9.7. nextUpdate
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.
項目が利用可能になるように証明書の正当性の情報をリフレッシュするとサーバがaを予想する時に言うnextUpdate。 証明書取消し状態情報が利用可能でないか、または証明書が吊しているなら、nextUpdateの品目は特におもしろいです。 GeneralizedTimeタイプを使用して、nextUpdateの品目はUTCに日時を表します。 セクション3.2.7におけるGeneralizedTimeのための符号化規則を使用しなければなりません。
4.9.8. certReplyExtensions
4.9.8. certReplyExtensions
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]で定義されたExtensionsタイプを使用します。 要求におけるqueryExtensionsの品目のオブジェクト識別子(OIDs)は、対応する回答値を特定するのに使用されます。 存在しているとき、certReplyExtensionsの品目はExtensionの品目の系列を含んでいます。それはそれぞれ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の品目でOIDsの1つを合わせなければなりません。
The critical item is a BOOLEAN, and it MUST be set to FALSE.
緊要補給品はaブールです、そして、FALSEにそれを設定しなければなりません。
Freeman, et al. Standards Track [Page 56] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[56ページ]。
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 STRINGを含んでいます。 中では、OCTET STRINGが拡大値です。 ASN.1タイプは関連extnIDオブジェクト識別子によって特定された各拡大に指定されます。
4.10. respNonce
4.10. respNonce
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.
サーバが一回だけなしで要求への特定の非キャッシュされた応答を返しているなら、サーバはメッセージの特定の一回だけを含むかもしれません。 デジタルに署名しているメッセージのために、サーバは値としてrespNonceの品目で要求のSignerInfoの中でsignedAttrsのメッセージダイジェスト属性の値を使用するかもしれません。
The requestNonce item uses the OCTET STRING type.
requestNonceの品目はOCTET STRINGタイプを使用します。
Conforming client implementations MUST be able to process a response that includes this item. Conforming servers MUST support respNonce.
クライアント実装を従わせると、この項目を含んでいる応答は処理できなければなりません。 サーバを従わせると、respNonceはサポートしなければなりません。
4.11. serverContextInfo
4.11. serverContextInfo
The serverContextInfo item in a response is a mechanism for the server to pass some opaque context information to the client. If the client does not like the certification path returned, it can make a new query and pass along this context information.
応答におけるserverContextInfoの品目はサーバが何らかの不透明な文脈情報をクライアントに渡すメカニズムです。 クライアントが、証明経路が返されるのが好きでないなら、それは、新しい質問をして、この文脈情報を伝えることができます。
Section 3.2.6 contains information about the client's usage of this item.
セクション3.2 .6 クライアントのこの項目の使用法の情報を含んでいます。
The context information is opaque to the client, but it provides information to the server that ensures that a different certification path will be returned (if another one can be found). The context information could indicate the state of the server, or it could contain a sequence of hashes of certification paths that have already been returned to the client. The protocol does not dictate any structure or requirements for this item. However, implementers should review the Security Considerations section of this document before selecting a structure.
クライアントにとって、文脈情報は不明瞭ですが、それは異なった証明経路が返されるのを確実にするサーバに情報を提供します(別の1つを見つけることができるなら)。 文脈情報がサーバの事情を示すかもしれませんか、またはそれは既にクライアントに返された証明経路のハッシュの系列を含むかもしれません。 プロトコルはこの項目のためのどんな構造や要件も決めません。 しかしながら、構造を選択する前に、implementersはこのドキュメントのSecurity Considerations部を見直すはずです。
Freeman, et al. Standards Track [Page 57] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[57ページ]。
Servers that are incapable of returning additional paths MUST NOT include the serverContextInfo item in the response.
戻っている追加経路の不可能なサーバは応答にserverContextInfoの品目を含んではいけません。
4.12. cvResponseExtensions
4.12. cvResponseExtensions
If present, the cvResponseExtensions item contains a sequence of extensions that extend the response. This specification does not define any extensions. The facility is provided to allow future specifications to extend SCVP. The syntax for Extensions is imported from [PKIX-1]. The cvResponseExtensions item, when present, contains a sequence of Extension items, each of which contains an extnID item, a critical item, and an extnValue item.
存在しているなら、cvResponseExtensionsの品目は応答を広げる拡大の系列を含んでいます。 この仕様は少しの拡大も定義しません。 将来の仕様がSCVPを広げるのを許容するために施設を提供します。 Extensionsのための構文は[PKIX-1]からインポートされます。 存在しているとき、cvResponseExtensionsの品目はExtensionの品目の系列を含んでいます。それはそれぞれ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.
緊要補給品はaブールです。 各拡大は重要(TRUEの値がある)か非臨界(FALSEの値がある)として指定されます。 認識しない重要な拡大に遭遇するなら、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 STRINGを含んでいます。 中では、OCTET STRINGが拡大値です。 ASN.1タイプは関連extnIDオブジェクト識別子によって特定された各拡大に指定されます。
4.13. requestorText
4.13. requestorText
The requestorText item contains a text field supplied by the client.
requestorTextの品目はクライアントによって提供されたテキストフィールドを含んでいます。
If the client includes a requestorText value in the request and the server is generating a specific non-cached response to the request, then the server MUST return the same value in the response.
クライアントが要求でrequestorText値を入れて、サーバが要求への特定の非キャッシュされた応答を生成しているなら、サーバは応答における同じ値を返さなければなりません。
If the server is using a cached response to the request, then it MUST omit the requestorText item.
サーバが要求へのキャッシュされた応答を使用しているなら、それはrequestorTextの品目を省略しなければなりません。
The requestNonce item uses the UTF8 string type.
requestNonceの品目はUTF8ストリングタイプを使用します。
Conforming client implementations that support the requestorText item in requests (see Section 3.10) MUST be able to process a response that includes this item. Conforming servers MUST support requestorText in responses.
要求(セクション3.10を見る)でrequestorTextの品目をサポートするクライアント実装を従わせると、この項目を含んでいる応答は処理できなければなりません。 サーバを従わせると、requestorTextは応答でサポートしなければなりません。
Freeman, et al. Standards Track [Page 58] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[58ページ]。
4.14. SCVP Response Validation
4.14. SCVP応答合法化
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応答を保護するのに使用される秘密鍵に対応する証明書にはSCVP応答の合法化のための2つのメカニズム、特定のSCVPサーバキーに関するクライアントの知識に基づいた1つ、および合法化に基づくもう片方があります。
4.14.1. Simple Key Validation
4.14.1. 簡単な主要な合法化
The simple key validation method is where the SCVP client has a local policy of one or more SCVP server keys that directly identify the set of valid SCVP servers. Mechanisms for storage of server keys or identifiers are a local matter. For example, a client could store cryptographic hashes of public keys used to verify SignedData responses. Alternatively, a client could store shared symmetric keys used to verify MACs in AuthenticatedData responses.
簡単な主要な合法化メソッドはSCVPクライアントが直接有効なSCVPサーバのセットを特定する1個以上のSCVPサーバキーのローカルの方針を持っているところです。 サーバキーか識別子のストレージのためのメカニズムは地域にかかわる事柄です。 例えば、クライアントはSignedData応答について確かめるのに使用される公開鍵の暗号のハッシュを保存できました。 あるいはまた、クライアントはAuthenticatedData応答でMACsについて確かめるのに使用される共有された対称鍵を保存できました。
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サーバへの要求にしているSCVPクライアントは簡単な主要な合法化を使用しなければなりません[RQMTS]。 SignedDataかAuthenticatedDataを使用するかどうかが、これらのクライアントがいるローカルの方針の問題です。 簡単な主要な合法化は他の理由に他のSCVPクライアントによって使用されるかもしれません。
4.14.2. SCVP Server Certificate Validation
4.14.2. 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クライアントSHOULDは[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.
証明書が、以前はよく合法化が方針応答とSignedData合法化であると署名していたなら、応答は主要な用法拡大[PKIX-1]を含んでいます、セクション4.2。.1 .3) それにはデジタル署名ビットが設定するどちらかがなければならない、非拒否ビットがセットしたか、またはさもなければ、両方のビットはセットしました。
If the certificate for AuthenticatedData validation responses contains the key usage extension, it MUST have the key agreement bit set.
AuthenticatedData合法化応答のための証明書が主要な用法拡大を含んでいるなら、それで、主要な協定ビットを設定しなければなりません。
Freeman, et al. Standards Track [Page 59] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[59ページ]。
If the certificate used on a validation policy response or a validation response contains the extended key usage extension ([PKIX-1], Section 4.2.1.13), it MUST contain either the anyExtendedKeyUsage OID or the following OID:
合法化方針応答か合法化応答のときに使用された証明書が広げることを含むなら、用法拡大[PKIX-1]を合わせてください、セクション4.2。.1 .13) それはanyExtendedKeyUsage OIDかOIDのどちらかを以下の含まなければなりません:
id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 }
イド-kp-scvpServerオブジェクト識別子:、:= イド-kp15
5. Server Policy Request
5. サーバ方針要求
An SCVP client uses the ValPolRequest item to request information about an SCVP server's policies and configuration information, including the list of validation policies supported by the SCVP server. When a ValPolRequest is encapsulated in a MIME body part, it MUST be carried in an application/scvp-vp-request MIME body part.
SCVPクライアントはSCVPサーバの方針と設定情報の情報を要求するのにValPolRequestの品目を使用します、SCVPサーバによってサポートされた合法化方針のリストを含んでいて。ValPolRequestがMIME身体の部分でカプセル化されるとき、scvp-vpアプリケーション/要求MIME身体の部分でそれを運ばなければなりません。
The request consists of a ValPolRequest encapsulated in a ContentInfo. The client does not sign the request.
要求はContentInfoでカプセル化されたValPolRequestから成ります。 クライアントは要求に署名しません。
ContentInfo {
contentType id-ct-scvp-valPolRequest,
-- (1.2.840.113549.1.9.16.1.12)
content ValPolRequest }
ContentInfocontentType、イドct scvp-valPolRequest、--、(1.2.840.113549.1.9.16.1.12)内容ValPolRequest
The ValPolRequest type has the following syntax:
ValPolRequestタイプには、以下の構文があります:
ValPolRequest ::= SEQUENCE {
vpRequestVersion INTEGER DEFAULT 1,
requestNonce OCTET STRING }
ValPolRequest:、:= 系列vpRequestVersion整数デフォルト1、requestNonce八重奏ストリング
Conforming SCVP server implementations MUST recognize and process the server policy request. Conforming clients SHOULD support the server policy request.
SCVPサーバ実装を従わせるのは、サーバ方針要求を認識して、処理しなければなりません。 従っているクライアントSHOULDはサーバ方針要求をサポートします。
5.1. vpRequestVersion
5.1. vpRequestVersion
The syntax and semantics of vpRequestVersion are the same as cvRequestVersion as described in Section 3.1.
vpRequestVersionの構文と意味論はセクション3.1で説明されるcvRequestVersionと同じです。
5.2. requestNonce
5.2. requestNonce
The requestNonce item contains a request identifier generated by the SCVP client. If the server returns a specific response, it MUST include the requestNonce from the request in the response, but the server MAY return a cached response, which MUST NOT include a requestNonce.
requestNonceの品目はSCVPクライアントによって生成された要求識別子を含んでいます。 サーバが特定の応答を返しますが、応答における要求からのrequestNonceを含まなければなりませんが、サーバがキャッシュされた応答(requestNonceを含んではいけない)を返すかもしれないなら。
Freeman, et al. Standards Track [Page 60] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[60ページ]。
6. Validation Policy Response
6. 合法化方針応答
In response to a ValPolRequest, the SCVP server provides a ValPolResponse. The ValPolResponse may not be unique to any ValPolRequest, so may be reused by the server in response to multiple ValPolRequests. The ValPolResponse also has an indication of how frequently the ValPolResponse may be reissued. The server MUST sign the response using its digital signature certificate. When a ValPolResponse is encapsulated in a MIME body part, it MUST be carried in an application/scvp-vp-response MIME body part.
ValPolRequestに対応して、SCVPサーバはValPolResponseを提供します。 ValPolResponseは、どんなValPolRequestにもユニークでないかもしれないので、サーバによって複数のValPolRequestsに対応して再利用されるかもしれません。 また、ValPolResponseには、ValPolResponseがどれくらい頻繁に再発行されるかもしれないかしるしがあります。 デジタル署名証明書を使用して、サーバは応答に署名しなければなりません。 ValPolResponseがMIME身体の部分でカプセル化されるとき、scvp-vpアプリケーション/応答MIME身体の部分でそれを運ばなければなりません。
The response consists of a ValPolResponse encapsulated in a SignedData, which is in turn encapsulated in a ContentInfo. That is, the EncapsulatedContentInfo field of SignedData consists of an eContentType field with a value of id-ct-scvp-valPolResponse (1.2.840.113549.1.9.16.1.13) and an eContent field that contains a DER-encoded ValPolResponse. The SCVP server MUST include its own certificate in the certificates field within SignedData, and the signerInfos field of SignedData MUST include exactly one SignerInfo. The SignedData MUST NOT include the unsignedAttrs field.
応答はContentInfoで順番にカプセル化されるSignedDataでカプセル化されたValPolResponseから成ります。 すなわち、SignedDataのEncapsulatedContentInfo分野がa値でeContentType分野から成る、イドct scvp-valPolResponse、(1.2 .840 .113549 .1 .9 .16 .1 .13) そして、DERによってコード化されたValPolResponseを含むeContent分野。 SCVPサーバはSignedDataの中の証明書分野にそれ自身の証明書を含まなければなりません、そして、SignedDataのsignerInfos分野はちょうど1SignerInfoを含まなければなりません。 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 }
ValPolResponse:、:= 系列{ vpResponseVersion整数、maxCVRequestVersion整数、maxVPRequestVersion整数、thisUpdate GeneralizedTimeの、そして、nextUpdate GeneralizedTime任意のserverConfigurationID整数、supportedChecks CertChecks、supportedWantBacks WantBack、オブジェクト識別子のvalidationPolicies系列、オブジェクト識別子のvalidationAlgs系列、AuthPolicy、responseTypes ResponseTypesのauthPolicies系列; defaultPolicyValues RespValidationPolicy、revocationInfoTypes RevocationInfoTypes、AlgorithmIdentifierのsignatureGeneration系列、AlgorithmIdentifierのsignatureVerification系列、オブジェクト識別子のhashAlgorithms系列サイズ(1..MAX)、KeyAgreePublicKey任意のclockSkew整数デフォルト10の、そして、requestNonce八重奏ストリング任意のserverPublicKeys系列; }
Freeman, et al. Standards Track [Page 61] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[61ページ]。
ResponseTypes ::= ENUMERATED {
cached-only (0),
non-cached-only (1),
cached-and-non-cached (2) }
ResponseTypes:、:= 列挙されます。キャッシュされて唯一の(0)、非キャッシュされる、唯一、キャッシュされて非キャッシュされた(1)、(2)
RevocationInfoTypes ::= BIT STRING {
fullCRLs (0),
deltaCRLs (1),
indirectCRLs (2),
oCSPResponses (3) }
RevocationInfoTypes:、:= ビット列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サーバは、キャッシュされた方針応答をサポートしなければならなくて、方針要求への特定の応答をサポートするかもしれません。
6.1. vpResponseVersion
6.1. vpResponseVersion
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を返さなければなりません。
6.2. maxCVRequestVersion
6.2. maxCVRequestVersion
The maxCVRequestVersion item defines the maximum version number for CV requests that the server supports.
maxCVRequestVersionの品目はサーバがサポートするCV要求の最大のバージョン番号を定義します。
6.3. maxVPRequestVersion
6.3. maxVPRequestVersion
The maxVPRequestVersion item defines the maximum version number for VP requests that the server supports.
maxVPRequestVersionの品目はサーバがサポートするVP要求の最大のバージョン番号を定義します。
6.4. serverConfigurationID
6.4. serverConfigurationID
The serverConfigurationID item is an integer that uniquely represents the version of the server configuration as represented by the validationPolicies, validationAlgs, authPolicies, defaultPolicyValues, and clockSkew. If any of these values change, the server MUST create a new ValPolResponse with a new serverConfigurationID. If the configuration has not changed, then the server may reuse serverConfigurationID across multiple
serverConfigurationIDの品目はvalidationPolicies、validationAlgs、authPolicies、defaultPolicyValues、およびclockSkewによって表されるように唯一サーバ構成のバージョンを表す整数です。 これらの値のどれかが変化するなら、サーバは新しいserverConfigurationIDと共に新しいValPolResponseを作成しなければなりません。 構成が変化していないなら、サーバは倍数の向こう側にserverConfigurationIDを再利用するかもしれません。
Freeman, et al. Standards Track [Page 62] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[62ページ]。
ValPolResponse messages. However, if the server reverts to an earlier configuration, the server MUST NOT revert the configuration ID as well, but MUST select another unique value.
ValPolResponseメッセージ。 しかしながら、サーバが以前の構成に戻るなら、サーバは、また、構成IDを振り向けてはいけませんが、別のユニークな値を選択しなければなりません。
6.5. thisUpdate
6.5. thisUpdate
This item indicates the signing date and time of this policy response.
この項目はこの方針応答の署名日付と時間を示します。
GeneralizedTime values MUST be expressed in Greenwich Mean Time (Zulu) and interpreted as defined in Section 3.2.7.
GeneralizedTime値をグリニッジ標準時(ズールー族)に言い表されて、セクション3.2.7で定義されていると解釈しなければなりません。
6.6. nextUpdate and requestNonce
6.6. nextUpdateとrequestNonce
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の品目は、要求に提供された一回だけを返すことによって、特定の要求への応答をリンクします。
If the nextUpdate item is omitted, it indicates a non-cached response generated in response to a specific request (i.e., the ValPolResponse is bound to a specific request). If this item is omitted, the requestNonce item MUST be present and MUST include the requestNonce value from the request.
nextUpdateの品目が省略されるなら、それは特定の要求に対応して生成された非キャッシュされた応答を示します(すなわち、ValPolResponseは特定の要求に縛られます)。 この項目が省略されるなら、requestNonceの品目は、存在していなければならなくて、要求からのrequestNonce値を含まなければなりません。
If the nextUpdate item is present, it indicates a cached response that is not bound to a specific request. An SCVP server MUST periodically generate a new response as defined by the next update time, but MAY use the same ValPolResponse to respond to multiple requests. The requestNonce is omitted if the nextUpdate item is present.
nextUpdateの品目が存在しているなら、それは特定の要求に縛られないキャッシュされた応答を示します。 SCVPサーバは、次のアップデート時間までに定義されるように定期的に新しい応答を生成しなければなりませんが、複数の要求に応じるのに同じValPolResponseを使用するかもしれません。 nextUpdateの品目が存在しているなら、requestNonceは省略されます。
It is a matter of local server policy to return a cached or non- cached specific response.
キャッシュされたか非キャッシュされた特定の応答を返すのは、ローカルサーバ方針の問題です。
GeneralizedTime values in nextUpdate MUST be expressed in Greenwich Mean Time (Zulu) as specified in Section 3.2.7.
セクション3.2.7における指定されるとしてのグリニッジ標準時(ズールー族)にnextUpdateのGeneralizedTime値を言い表さなければなりません。
6.7. supportedChecks
6.7. supportedChecks
The supportedChecks item contains a sequence of object identifiers representing the checks supported by the server.
supportedChecksの品目はサーバで後押しされているチェックを表すオブジェクト識別子の系列を含んでいます。
Freeman, et al. Standards Track [Page 63] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[63ページ]。
6.8. supportedWantBacks
6.8. supportedWantBacks
The supportedWantBacks item contains a sequence of object identifiers representing the wantBacks supported by the server.
supportedWantBacksの品目はサーバによってサポートされたwantBacksを表すオブジェクト識別子の系列を含んでいます。
6.9. validationPolicies
6.9. validationPolicies
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の品目はサーバによってサポートされた合法化方針を表すオブジェクト識別子の系列を含んでいます。サーバがデフォルト合法化方針を使用することで要求を処理したがっているかどうかと、それが処理しないかどうかが、ローカルの方針の問題である、次に、それはこのリストにイド-svp-defaultValPolicyを含んではいけません。
6.10. validationAlgs
6.10. validationAlgs
The validationAlgs item contains a sequence of OIDs. Each OID identifies a validation algorithm supported by the server.
validationAlgsの品目はOIDsの系列を含んでいます。 各OIDはサーバによってサポートされた合法化アルゴリズムを特定します。
6.11. authPolicies
6.11. authPolicies
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
AuthPolicy:、:= オブジェクト識別子
6.12. responseTypes
6.12. responseTypes
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の品目で、サーバはそれがサポートする応答タイプの範囲を発行できます。 キャッシュされて、サーバが返すだけである手段だけが要求への応答をキャッシュしました。 非キャッシュされる、すなわち、要請者の一回だけを含んでいて、サーバが要求への特定の応答を返すことを意味するだけです。 要求によって、サーバサポートがともにキャッシュした手段と非キャッシュされた応答の両方が、タイプして、キャッシュされたか非キャッシュされた応答を返すでしょう。
6.13. revocationInfoTypes
6.13. revocationInfoTypes
The revocationInfoTypes item allows the server to indicate the sources of revocation information that it is capable of processing. For each bit in the RevocationInfoTypes BIT STRING, the server MUST set the bit to one if it is capable of processing the corresponding revocation information type and to zero if it cannot.
revocationInfoTypesの品目で、サーバはそれが処理ができるという取消し情報の源を示すことができます。 RevocationInfoTypes BIT STRINGの各ビットのために、それは処理が対応する取消し情報タイプとゼロにできて、設定できないなら、サーバは1つにビットを設定しなければなりません。
Freeman, et al. Standards Track [Page 64] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[64ページ]。
6.14. defaultPolicyValues
6.14. defaultPolicyValues
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.
これはサーバによって使用されるデフォルト合法化方針です。それはRespValidationPolicyを含んでいます。(RespValidationPolicyはセクション4.5で定義されます)。 validationPolicyの品目のすべてのOPTIONALの品目に居住しなければなりません。 デフォルト合法化方針とクライアントがする要求参照が要求における他の値を供給することによってデフォルト値を無効にしないとき、サーバはこれらのデフォルト値を使用するでしょう。
This allows the client to optimize the request by omitting parameters that match the server default values.
これで、クライアントは、サーバデフォルト値に合っているパラメタを省略することによって、要求を最適化できます。
6.15. signatureGeneration
6.15. signatureGeneration
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サーバによってサポートされたデジタル署名アルゴリズムのセットを指定します。 それぞれのデジタル署名アルゴリズムはAlgorithmIdentifierとして指定されます、公開鍵証明書[PKIX-1]のsignatureAlgorithm分野に関連している符号化規則を使用して。 サポートしているアルゴリズムは[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にメッセージに署名することができないサーバにおいて、signatureGenerationの品目は空の系列としてコード化されます。
6.16. signatureVerification
6.16. signatureVerification
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サーバが確かめることができるデジタル署名アルゴリズムのセットを指定します。それぞれのデジタル署名アルゴリズムはAlgorithmIdentifierとして指定されます、公開鍵証明書[PKIX-1]のsignatureAlgorithm分野に関連している符号化規則を使用して。 サポートしているアルゴリズムは[PKIX-ALG]と[PKIX-ALG2]で定義されますが、また、他の署名アルゴリズムはサポートされるかもしれません。
For servers that do not verify signatures on CVRequest messages, the signatureVerification item is encoded as an empty sequence.
CVRequestメッセージで署名について確かめないサーバにおいて、signatureVerificationの品目は空の系列としてコード化されます。
Freeman, et al. Standards Track [Page 65] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[65ページ]。
6.17. hashAlgorithms
6.17. hashAlgorithms
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のためのオブジェクト識別子を指定します。 また、他のハッシュアルゴリズムはサポートされるかもしれません。
6.18. serverPublicKeys
6.18. serverPublicKeys
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がサーバに要求するクライアントによって使用されます。KeyAgreePublicKeyタイプにはserverPublicKeys系列の各個条があります:
KeyAgreePublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING,
macAlgorithm AlgorithmIdentifier,
kDF AlgorithmIdentifier OPTIONAL }
KeyAgreePublicKey:、:= 系列アルゴリズム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はアルゴリズム識別子とサーバの公開鍵を含んでいます。 要求がserverPublicKeysをサポートしなければならないSCVPのためにAuthenticatedDataの主要な協定モードをサポートするSCVPサーバと[PKIX-ALG]の指定されるとしてのディフィー-ヘルマンの主要な協定アルゴリズム。 serverPublicKeysをサポートするSCVPサーバは[IKE]で定義されるように1024年のビットのModular Exponential(MODP)グループキー(グループ2)を支えなければなりません。 serverPublicKeysをサポートするSCVPサーバは、他のディフィー-ヘルマングループ[イケ-GROUPS]、および他の主要な協定がアルゴリズムであるとサポートするかもしれません。
The macAlgorithm item specifies the symmetric algorithm the server expects the client to use with the result of the key agreement algorithm. A key derivation function (KDF), which derives symmetric key material from the key agreement result, may be implied by the macAlgorithm. Alternatively, the KDF may be explicitly specified using the optional kDF item.
macAlgorithmの品目は主要な協定アルゴリズムの結果と共に使用するサーバがクライアントを予想する左右対称のアルゴリズムを指定します。 主要な派生機能(KDF)がmacAlgorithmによって含意されるかもしれません。 あるいはまた、KDFは、任意のkDFの品目を使用することで明らかに指定されるかもしれません。
6.19. clockSkew
6.19. clockSkew
The clockSkew item is the number of minutes the server will allow for clock skew. The default value is 10 minutes.
clockSkewの品目はサーバが時計斜行のために許容する数分の数です。 デフォルト値は10分です。
Freeman, et al. Standards Track [Page 66] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[66ページ]。
7. SCVP Server Relay
7. SCVPサーバリレー
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サーバに関する識別子を含む追加GeneralNameを含まなければなりません。リレーされるという要求がrequestorRefの品目を含んでいないなら、サーバで発生している要求はSCVPサーバに関する識別子を含むGeneralNameを含んでいるrequestorRefの品目を含まなければなりません。
To prevent false loop detection, servers should use identifiers that are unique within their network of cooperating SCVP servers. SCVP servers that support relay SHOULD populate this item with the DNS name of the server or the distinguished name in the server's certificate. SCVP servers MAY choose other procedures for generating identifiers that are unique within their community.
誤った輪の検出を防ぐために、サーバはそれらの協力関係を持っているSCVPサーバのネットワークの中でユニークな識別子を使用するべきです。 サーバのDNS名か分類名がサーバの証明書にある状態で、リレーSHOULDをサポートするSCVPサーバがこの項目に居住します。 SCVPサーバはそれらの共同体の中でユニークな識別子を生成するための他の手順を選ぶかもしれません。
When an SCVP server receives a request that contains a requestorRef item, the server MUST check the sequence of names in the requestorRef item for its own identifier. If the server discovers its own identifier in the requestorRef item, it MUST respond with an error, setting the statusCode in the responseStatus item to 40.
SCVPサーバがrequestorRefの品目を含む要求を受け取るとき、サーバはそれ自身の識別子がないかどうかrequestorRefの品目の名前の系列をチェックしなければなりません。 サーバがrequestorRefの品目のそれ自身の識別子を発見するなら、誤りで応じなければなりません、40へのresponseStatusの品目にstatusCodeをはめ込んで。
When an SCVP server generates a non-cached response to a relayed request, the server MUST include the requestorRef item from the request in the response.
SCVPサーバがリレーされた要求への非キャッシュされた応答を発生させるとき、サーバは応答における要求からのrequestorRefの品目を含まなければなりません。
Freeman, et al. Standards Track [Page 67] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[67ページ]。
8. SCVP ASN.1 Module
8. SCVP ASN.1モジュール
This section defines the syntax for SCVP request-response pairs. The semantics for the messages are defined in Sections 3, 4, 5, and 6. The SCVP ASN.1 module follows.
このセクションは構文をSCVP要求応答組定義します。 メッセージのための意味論はセクション3、4、5、および6で定義されます。 SCVP ASN.1モジュールは従います。
SCVP
SCVP
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 21 }
iso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)21
DEFINITIONS IMPLICIT TAGS ::= BEGIN
定義、内在しているタグ:、:= 始まってください。
IMPORTS
輸入
AlgorithmIdentifier, Attribute, Certificate, Extensions,
-- Import UTF8String if required by compiler
-- UTF8String, -- CertificateList, CertificateSerialNumber
FROM PKIX1Explicit88 -- RFC 3280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 18 }
AlgorithmIdentifier、Attribute、Certificate、Extensions--コンパイラ--UTF8String--CertificateList、必要なら、RFC3280年までにCertificateSerialNumber FROM PKIX1Explicit88--輸入UTF8Stringiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)18
GeneralNames, GeneralName, KeyUsage, KeyPurposeId
FROM PKIX1Implicit88 -- RFC 3280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 19 }
GeneralNames、GeneralName、KeyUsage、RFC PKIX1Implicit88からのKeyPurposeId--3280iso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)19
AttributeCertificate
FROM PKIXAttributeCertificate -- RFC 3281
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 12 }
PKIXAttributeCertificateからのAttributeCertificate--RFC3281iso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)12
OCSPResponse
FROM OCSP -- RFC 2560
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 14 }
OCSPからのOCSPResponse--RFC2560iso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(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) } ;
RFC ContentInfo FROM CryptographicMessageSyntax2004--3852、iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm-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 }
イドct OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9)イド-smime(16)1をメンバーと同じくらい具体化させます。
Freeman, et al. Standards Track [Page 68] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[68ページ]。
id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 }
イドct scvp-certValRequest、物の識別子:、:= イドct10
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 }
CVRequest:、:= 系列cvRequestVersion INTEGER DEFAULT1、Queryについて質問してください、requestorRef[0]GeneralNames OPTIONAL、requestNonce[1]OCTET STRING OPTIONAL、requestorName[2]GeneralName OPTIONAL、responderName[3]GeneralName OPTIONAL、requestExtensions[4]拡大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 }
以下について質問してください:= 系列queriedCerts CertReferences、チェック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]拡大OPTIONAL
CertReferences ::= CHOICE {
pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference,
acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference }
CertReferences:、:= 選択PKCReferenceのpkcRefs[0]系列サイズ(1..MAX)、ACReferenceのacRefs[1]系列サイズ(1..MAX)
CertReference::= CHOICE {
pkc PKCReference,
ac ACReference }
CertReference:、:= 選択pkc PKCReference、ac ACReference
PKCReference ::= CHOICE {
cert [0] Certificate,
pkcRef [1] SCVPCertID }
PKCReference:、:= 選択本命[0]証明書、pkcRef[1]SCVPCertID
ACReference ::= CHOICE {
attrCert [2] AttributeCertificate,
acRef [3] SCVPCertID }
ACReference:、:= 選択attrCert[2]AttributeCertificate、acRef[3]SCVPCertID
SCVPCertID ::= SEQUENCE {
certHash OCTET STRING,
issuerSerial SCVPIssuerSerial,
hashAlgorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 } }
SCVPCertID:、:= 系列certHash OCTET STRING、issuerSerial SCVPIssuerSerial、hashAlgorithm AlgorithmIdentifier DEFAULTアルゴリズムsha-1
Freeman, et al. Standards Track [Page 69] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[69ページ]。
SCVPIssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
SCVPIssuerSerial:、:= 系列発行人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 }
ValidationPolicy:、:= 系列validationPolRef ValidationPolRef、KeyPurposeId任意の任意のKeyPurposeId specifiedKeyUsages[8]系列の任意のKeyUsage extendedKeyUsages[7]系列の物の識別子の任意の、そして、[2]のinhibitPolicyMappingの論理演算子の任意の、そして、requireExplicitPolicy[3]論理演算子任意のinhibitAnyPolicy[4]論理演算子任意の、そして、trustAnchors[5]TrustAnchors任意のkeyUsages[6]系列の任意のvalidationAlg[0]ValidationAlg userPolicySet[1]系列サイズ(1..MAX)
CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
CertChecks:、:= 物の識別子の系列サイズ(1..MAX)
WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
WantBack:、:= 物の識別子の系列サイズ(1..MAX)
ValidationPolRef ::= SEQUENCE {
valPolId OBJECT IDENTIFIER,
valPolParams ANY DEFINED BY valPolId OPTIONAL }
ValidationPolRef:、:= 系列valPolId物の識別子、valPolIdによって少しも任意の状態で定義されたvalPolParams
ValidationAlg ::= SEQUENCE {
valAlgId OBJECT IDENTIFIER,
parameters ANY DEFINED BY valAlgId OPTIONAL }
ValidationAlg:、:= 系列valAlgId OBJECT IDENTIFIER、パラメタいずれもDEFINED BY valAlgId OPTIONAL
NameValidationAlgParms ::= SEQUENCE {
nameCompAlgId OBJECT IDENTIFIER,
validationNames GeneralNames }
NameValidationAlgParms:、:= 系列nameCompAlgId物の識別子、validationNames GeneralNames
TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference
TrustAnchors:、:= PKCReferenceの系列サイズ(1..MAX)
KeyAgreePublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING,
macAlgorithm AlgorithmIdentifier,
kDF AlgorithmIdentifier OPTIONAL }
KeyAgreePublicKey:、:= 系列アルゴリズム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 }
ResponseFlags:、:= 系列誤って、responseValidationPolByRef[1]ブールの本当のfullRequestInResponseのデフォルト本当の、そして、protectResponse[2]ブールのデフォルトcachedResponse[3][0]論理演算子デフォルト論理演算子は本当にデフォルトとします。
Freeman, et al. Standards Track [Page 70] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[70ページ]。
CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate
CertBundle:、:= 証明書の系列サイズ(1..MAX)
RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo
RevocationInfos:、:= RevocationInfoの系列サイズ(1..MAX)
RevocationInfo ::= CHOICE {
crl [0] CertificateList,
delta-crl [1] CertificateList,
ocsp [2] OCSPResponse,
other [3] OtherRevInfo }
RevocationInfo:、:= 選択crl[0]CertificateList、デルタ-crl[1]CertificateList、ocsp[2]OCSPResponse、他の[3]OtherRevInfo
OtherRevInfo ::= SEQUENCE {
riType OBJECT IDENTIFIER,
riValue ANY DEFINED BY riType }
OtherRevInfo:、:= 系列riType物の識別子、riTypeによって少しも定義されたriValue
-- SCVP Certificate Validation Response
-- SCVP証明書合法化応答
id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 }
イドct scvp-certValResponse、物の識別子:、:= イドct11
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 }
CVResponse:、:= 系列{ cvResponseVersion整数、serverConfigurationID整数、responseStatus ResponseStatusの、そして、respValidationPolicy0のRespValidationPolicyの任意の、そして、requestRef1RequestReference任意のrequestorRef2GeneralNames任意のproducedAt GeneralizedTime; requestorName3のGeneralNamesの任意の、そして、replyObjects4ReplyObjects任意のrespNonce5の八重奏のストリングの任意の、そして、serverContextInfo6八重奏ストリング任意のcvResponseExtensions7拡張子任意のrequestorText8UTF8String(サイズ(1 .256))任意です; }
ResponseStatus ::= SEQUENCE {
statusCode CVStatusCode DEFAULT okay,
errorMessage UTF8String OPTIONAL }
ResponseStatus:、:= 系列statusCode CVStatusCode DEFAULT承認、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),
CVStatusCode:、:= ENUMERATED、(0)を承認してください、skipUnrecognizedItems(1)、tooBusy(10)、invalidRequest(11)、internalError(12)、badStructure(20)、unsupportedVersion(21)、abortUnrecognizedItems(22)、unrecognizedSigKey(23)、badSignatureOrMAC(24)
Freeman, et al. Standards Track [Page 71] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[71ページ]。
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) }
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
RespValidationPolicy:、:= ValidationPolicy
RequestReference ::= CHOICE {
requestHash [0] HashValue, -- hash of CVRequest
fullRequest [1] CVRequest }
RequestReference:、:= 選択requestHash[0]HashValue--、CVRequest fullRequest[1]CVRequestの細切れ肉料理
HashValue ::= SEQUENCE {
algorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 },
value OCTET STRING }
HashValue:、:= 系列アルゴリズムAlgorithmIdentifier DEFAULTアルゴリズムsha-1、値のOCTET STRING
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
sha-1 OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)oiw(14) secsig(3)アルゴリズム(2)26
ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply
ReplyObjects:、:= CertReplyの系列サイズ(1..MAX)
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 }
CertReply:、:= 系列本命CertReference、replyStatus ReplyStatus DEFAULT成功、replyValTime GeneralizedTime、replyChecks ReplyChecks replyWantBacks ReplyWantBacks、validationErrors[0]SEQUENCE SIZE(1..MAX)OF OBJECT IDENTIFIER OPTIONAL nextUpdate[1]GeneralizedTime OPTIONAL、certReplyExtensions[2]拡大OPTIONAL
Freeman, et al. Standards Track [Page 72] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[72ページ]。
ReplyStatus ::= ENUMERATED {
success (0),
malformedPKC (1),
malformedAC (2),
unavailableValidationTime (3),
referenceCertHashFail (4),
certPathConstructFail (5),
certPathNotValid (6),
certPathNotValidNow (7),
wantBackUnsatisfied (8) }
ReplyStatus:、:= 列挙されます。成功(0)、malformedPKC(1)、malformedAC(2)、unavailableValidationTime(3)、referenceCertHashFail(4)、certPathConstructFail(5)、certPathNotValid(6)、certPathNotValidNow(7)、wantBackUnsatisfied(8)
ReplyChecks ::= SEQUENCE OF ReplyCheck
ReplyChecks:、:= ReplyCheckの系列
ReplyCheck ::= SEQUENCE {
check OBJECT IDENTIFIER,
status INTEGER DEFAULT 0 }
ReplyCheck:、:= 系列OBJECT IDENTIFIER、状態INTEGER DEFAULT0をチェックしてください。
ReplyWantBacks ::= SEQUENCE OF ReplyWantBack
ReplyWantBacks:、:= ReplyWantBackの系列
ReplyWantBack::= SEQUENCE {
wb OBJECT IDENTIFIER,
value OCTET STRING }
ReplyWantBack:、:= 系列wb OBJECT IDENTIFIER、値のOCTET STRING
CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle
CertBundles:、:= CertBundleの系列サイズ(1..MAX)
RevInfoWantBack ::= SEQUENCE {
revocationInfo RevocationInfos,
extraCerts CertBundle OPTIONAL }
RevInfoWantBack:、:= 系列revocationInfo RevocationInfosで、extraCerts CertBundle任意です。
SCVPResponses ::= SEQUENCE OF ContentInfo
SCVPResponses:、:= ContentInfoの系列
-- SCVP Validation Policies Request
-- 方針が要求するSCVP合法化
id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 }
イドct scvp-valPolRequest、物の識別子:、:= イドct12
ValPolRequest ::= SEQUENCE {
vpRequestVersion INTEGER DEFAULT 1,
requestNonce OCTET STRING }
ValPolRequest:、:= 系列vpRequestVersion整数デフォルト1、requestNonce八重奏ストリング
-- SCVP Validation Policies Response
-- SCVP合法化方針応答
id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 }
イドct scvp-valPolResponse、物の識別子:、:= イドct13
ValPolResponse ::= SEQUENCE {
vpResponseVersion INTEGER,
maxCVRequestVersion INTEGER,
maxVPRequestVersion INTEGER,
serverConfigurationID INTEGER,
ValPolResponse:、:= 系列、vpResponseVersion整数、maxCVRequestVersion整数、maxVPRequestVersion整数、serverConfigurationID整数
Freeman, et al. Standards Track [Page 73] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[73ページ]。
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 }
thisUpdate GeneralizedTimeで、nextUpdate GeneralizedTime任意である、supportedChecks CertChecks、supportedWantBacks WantBack、物の識別子のvalidationPolicies系列、物の識別子のvalidationAlgs系列、AuthPolicy、responseTypes ResponseTypes、defaultPolicyValues RespValidationPolicyのauthPolicies系列; revocationInfoTypes RevocationInfoTypes、AlgorithmIdentifierのsignatureGeneration系列、AlgorithmIdentifierのsignatureVerification系列、物の識別子のhashAlgorithms系列サイズ(1..MAX)、KeyAgreePublicKey任意のclockSkew整数デフォルト10の、そして、requestNonce八重奏ストリング任意のserverPublicKeys系列
ResponseTypes ::= ENUMERATED {
cached-only (0),
non-cached-only (1),
cached-and-non-cached (2) }
ResponseTypes:、:= 列挙されます。キャッシュされて唯一の(0)、非キャッシュされる、唯一、キャッシュされて非キャッシュされた(1)、(2)
RevocationInfoTypes ::= BIT STRING {
fullCRLs (0),
deltaCRLs (1),
indirectCRLs (2),
oCSPResponses (3) }
RevocationInfoTypes:、:= ビット列fullCRLs(0)、deltaCRLs(1)、indirectCRLs(2)、oCSPResponses(3)
AuthPolicy ::= OBJECT IDENTIFIER
AuthPolicy:、:= 物の識別子
-- SCVP Check Identifiers
-- SCVPは識別子をチェックします。
id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 }
イド-stc OBJECT IDENTIFIER:、:= iso(1)、組織(3)dod(6)インターネット(1)セキュリティ(5)が特定されたメカニズム(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 }
イドstc体格pkc経路OBJECT IDENTIFIER:、:= イド-stc1のイドstc体格有効なpkc経路OBJECT IDENTIFIER:、:= イド-stc2のイドstc体格状態チェックのpkc経路OBJECT IDENTIFIER:、:= イド-stc3イドstc体格aa経路OBJECT IDENTIFIER:、:= イド-stc4のイドstc体格有効なaa経路OBJECT IDENTIFIER:、:= イド-stc5のイドstc体格状態チェックのaa経路OBJECT IDENTIFIER:、:= イド-stc6のイドのstcの状態のチェックacと体格状態チェックのaa経路OBJECT IDENTIFIER:、:= イド-stc7
Freeman, et al. Standards Track [Page 74] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[74ページ]。
-- SCVP WantBack Identifiers
-- SCVP WantBack識別子
id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 }
イド-swb OBJECT IDENTIFIER:、:= iso(1)、組織(3)dod(6)インターネット(1)セキュリティ(5)が特定されたメカニズム(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}
イドのswb-pkcの最も良い本命道のOBJECT IDENTIFIER:、:= イド-swb1、イドswb-pkc取消しインフォメーションOBJECT IDENTIFIER:、:= イド-swb2、イドswb-pkc公開鍵インフォメーションOBJECT IDENTIFIER:、:= イド-swb4イドswb-aa本命道のOBJECT IDENTIFIER:、:= イド-swb5、イドswb-aa取消しインフォメーションOBJECT IDENTIFIER:、:= イド-swb6、イドswb-ac取消しインフォメーションOBJECT IDENTIFIER:、:= イド-swb7のイドのswbリレーされた応答OBJECT IDENTIFIER:、:= イド-swb9、イドswb-pkc本命OBJECT IDENTIFIER:、:= イド-swb10、イドswb-ac本命OBJECT IDENTIFIER:、:= イド-swb11イドswb-pkcオール本命道のOBJECT IDENTIFIER:、:= イド-swb12、イドswb-pkc-ee取消しインフォメーションOBJECT IDENTIFIER:、:= イド-swb13、イドswb-pkc-CAs取消しインフォメーションOBJECT IDENTIFIER:、:= イド-swb14
-- 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 }
イド-svp OBJECT IDENTIFIER:、:= iso(1)、組織(3)dod(6)インターネット(1)セキュリティ(5)が特定されたメカニズム(5)pkix(7)19
id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }
イド-svp-defaultValPolicyオブジェクト識別子:、:= イド-svp1
-- SCVP Basic Validation Algorithm Identifier
-- SCVPの基本の合法化アルゴリズム識別子
id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 }
イド-svp-basicValAlgオブジェクト識別子:、:= イド-svp3
-- SCVP Basic Validation Algorithm Errors
-- SCVPの基本的な合法化アルゴリズム誤り
id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg
イド-bvae OBJECT IDENTIFIER:、:= イド-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 }
bvaeが吐き出したイドOBJECT IDENTIFIER:、:= イドがまだ有効でない状態でbvaeされていた状態で1をイドでbvaeする、OBJECT IDENTIFIER:、:= イド-bvae2、イド-bvae-wrongTrustAnchor OBJECT IDENTIFIER:、:= イド-bvae3、イド-bvae-noValidCertPath OBJECT IDENTIFIER:、:= bvaeが取り消したイド-bvae4イドOBJECT IDENTIFIER:、:= イド-bvae5、イド-bvae-invalidKeyPurpose OBJECT IDENTIFIER:、:= イド-bvae9、イド-bvae-invalidKeyUsage OBJECT IDENTIFIER:、:= イド-bvae10、イド-bvae-invalidCertPolicy OBJECT IDENTIFIER:、:= イド-bvae11
-- SCVP Name Validation Algorithm Identifier
-- SCVP名前合法化アルゴリズム識別子
id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 }
イド-svp-nameValAlgオブジェクト識別子:、:= イド-svp2
Freeman, et al. Standards Track [Page 75] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[75ページ]。
-- SCVP Name Validation Algorithm DN comparison algorithm
-- SCVP Name Validation Algorithm DN比較アルゴリズム
id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 }
イド-nva-dnCompAlgオブジェクト識別子:、:= イド-svp4
-- SCVP Name Validation Algorithm Errors
-- SCVP名前合法化アルゴリズム誤り
id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg
イド-nvae OBJECT IDENTIFIER:、:= イド-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 }
イドnvae名前ミスマッチOBJECT IDENTIFIER:、:= nvaeノーが命名するイド-nvae1イドOBJECT IDENTIFIER:、:= イドが未知のalg OBJECT IDENTIFIERをnvaeしていた状態で2をイドでnvaeする、:、:= イド-nvae3イドnvae悪名OBJECT IDENTIFIER:、:= nvaeの悪い名がタイプするイド-nvae4イドOBJECT IDENTIFIER:、:= イド-nvae5のイドのnvae複雑な名のOBJECT IDENTIFIER:、:= イド-nvae6
-- 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 }
イド-kp OBJECT IDENTIFIER:、:= iso(1)、組織(3)dod(6)インターネット(1)セキュリティ(5)が特定されたメカニズム(5)pkix(7)3
id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 }
イド-kp-scvpServerオブジェクト識別子:、:= イド-kp15
id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 }
イド-kp-scvpClientオブジェクト識別子:、:= イド-kp16
END
終わり
9. Security Considerations
9. セキュリティ問題
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].
Cryptographic Message Syntaxメッセージ・フォーマットに特定のセキュリティ問題に関しては、[CMS]を見てください。 PKI証明経路合法化のプロセスに特定のセキュリティ問題に関しては、[PKIX-1]を見てください。
A client that trusts a server's response for validation of a certificate inherently trusts that server as much as it would trust its own validation software. This means that if an attacker compromises a trusted SCVP server, the attacker can change the validation processing for every client that relies on that server. Thus, an SCVP server must be protected at least as well as the trust anchors that the SCVP server trusts.
それ自身の合法化ソフトウェアを信じるほど本来証明書の合法化のためのサーバの応答を信じるクライアントはそのサーバを信じます。 これは、攻撃者が信じられたSCVPサーバに感染するなら、攻撃者がそのサーバを当てにするすべてのクライアントのために合法化処理を変えることができることを意味します。その結果、少なくともSCVPサーバが信じる信頼アンカーと同様にSCVPサーバを保護しなければなりません。
Clients MUST verify that the response matches their original request. Clients need to ensure that the server has performed the appropriate checks for the correct certificates under the requested validation policy for the specified validation time, and that the response includes the requested wantBacks and meets the client's freshness requirements.
クライアントは、応答が彼らのオリジナルの要求に合っていることを確かめなければなりません。 クライアントは、応答がサーバが指定された合法化時間の要求された合法化方針の下で正しい証明書のための適切なチェックを実行して、要求されたwantBacksを含んで、クライアントの新しさ必要条件を満たすのを保証する必要があります。
Freeman, et al. Standards Track [Page 76] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[76ページ]。
When the SCVP response is used to determine the validity of a certificate, the client MUST validate the digital signature or MAC on the response to ensure that the expected SCVP server generated it. If the client does not check the digital signature or MAC on the response, a man-in-the-middle attack could fool the client into believing modified responses from the server or responses to questions the client did not ask.
SCVP応答が応答のときに証明書の正当性を決定するのに使用されるとき、クライアントは、予想されたSCVPサーバがそれを生成したのを保証するためにデジタルの署名かMACを有効にしなければなりません。 クライアントがチェックしないなら、デジタル署名か応答でのMAC、介入者攻撃が、クライアントが尋ねなかったという質問へのサーバか応答からクライアントが変更された応答を信じているようにだますかもしれません。
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の品目を使用するなら、implementersはサーバに多くの状態が情報であることを保たせるように攻撃者がひところ多くの要求を送るところでサービス不能攻撃に対する穏当な処置を取らなければなりません。
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などの保護された輸送を使用することによって、保全を確実にすることができます。 それは、個別に要求と応答メッセージを保護するのにMACsかデジタル署名を使用することによって、保全を確実にすることができます。
If an SCVP client populates the userPolicySet in a request with a value other than anyPolicy, but does not set the requireExplicitPolicy flag, the server may return an affirmative answer for paths that do not satisfy any of the specified policies. In general, when a client populates the userPolicySet in a request with a value other than anyPolicy, the requireExplicitPolicy flag should also be set. This guarantees that all valid paths satisfy at least one of the requested policies.
SCVPクライアントが要求でanyPolicy以外の値でuserPolicySetに居住しますが、requireExplicitPolicy旗を設定しないなら、サーバは特約保険証券のいずれも満たさない経路のための肯定的な返答を返すかもしれません。 また、一般に、クライアントが要求でanyPolicy以外の値でuserPolicySetに居住するとき、requireExplicitPolicy旗は設定されるべきです。 これは、すべての有効な経路が少なくとも要求された方針の1つを満たすのを保証します。
Freeman, et al. Standards Track [Page 77] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[77ページ]。
In SCVP, historical validation of a certificate returns the known status of the certificate at the time specified in validationTime. This may be used to demonstrate due diligence, but does not necessarily provide the most complete information. A certificate may have been revoked after the time specified in validationTime, but the revocation notice may specify an invalidity date that precedes the validationTime. The SCVP server would provide an affirmative response even though the most current information available indicates the certificate should not be trusted at that time. SCVP clients may wish to specify a validationTime later than the actual time of interest to mitigate this risk.
SCVPでは、validationTimeで指定されるとき、証明書の歴史的な合法化は証明書の知られている状態を返します。 これは、適切な注意を示すのに使用されるかもしれませんが、必ず最も完全な情報を提供するというわけではありません。 時間がvalidationTimeで指定した後に証明書は取り消されたかもしれませんが、取消し通知はvalidationTimeに先行する無効日付を指定するかもしれません。 利用可能な最も現在の情報は、証明書がその時信じられるべきでないのを示しますが、SCVPサーバは肯定的な応答を提供するでしょう。 SCVPクライアントはこの危険を緩和するために興味がある実際の時間より遅く、validationTimeを指定したがっているかもしれません。
10. IANA Considerations
10. IANA問題
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要求と応答の詳細は、オブジェクト識別子(OIDs)を使用することで伝えられます。 オブジェクトはIANAによってPKIX作業部会へ代表として派遣されたアークで定義されます。 また、このドキュメントはAppendix A.の4つのMIMEの種類登録証明書を含んでいます。IANAによるさらなるどんな動作もこのドキュメントかどんな予期されたアップデートにも必要ではありません。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
C. Adams, "X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP", RFC 2560,
June 1999.
[OCSP] マイアーズ、M.、Ankney、R.、Malpani、A.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、1999年6月。
[PKIX-1] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[PKIX-1] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[PKIX-AC] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[PKIX-西暦] ファレルとS.とR.Housley、「承認のためのインターネット属性証明書プロフィール」、RFC3281、2002年4月。
Freeman, et al. Standards Track [Page 78] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[78ページ]。
[PKIX-ALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3279, April 2002.
[PKIX-ALG] Bassham、L.、ポーク、W.、およびR.Housley、「インターネットX.509公開鍵暗号基盤証明書と証明書取消しのためのアルゴリズムと識別子は(CRL)プロフィールをリストアップします」、RFC3279、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、および「中のインターネットX.509公開鍵暗号基盤CertificateとCertificate Revocation List(CRL)が輪郭を描く使用のためのRSA Cryptographyのための追加AlgorithmsとIdentifiers」、RFC4055(2005年6月)
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[UTF8]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[ESS] Hoffman, P., Ed., "Enhanced Security Services for
S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、エド、「S/MIMEのための警備の強化サービス」、RFC2634、6月1999日
[SMIME-CERT] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Certificate Handling",
RFC 3850, July 2004.
[SMIME-本命]Ramsdell、B.、エド「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1証明書は扱う」RFC3850、2004年7月。
[IKE] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[IKE] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
11.2. Informative References
11.2. 有益な参照
[IKE-GROUPS] Kivinen, T. and M. Kojo, "More Modular Exponential
(MODP) Diffie-Hellman groups for Internet Key Exchange
(IKE)", RFC 3526, May 2003.
[イケ-GROUPS]Kivinen、T.、およびM.Kojo、「より多くのModular Exponential(MODP)ディフィー-ヘルマンはインターネット・キー・エクスチェンジ(IKE)のために分類します」、RFC3526、2003年5月。
[RQMTS] Pinkas, D. and R. Housley, "Delegated Path Validation
and Delegated Path Discovery Protocol Requirements",
RFC 3379, September 2002.
[RQMTS]ピンカス、D.、R.Housley、および「代表として派遣された経路合法化と代表として派遣された経路発見プロトコル要件」、2002年9月のRFC3379。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
[TLS] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
Freeman, et al. Standards Track [Page 79] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[79ページ]。
12. Acknowledgments
12. 承認
The lively debate in the PKIX Working Group has made a significant impact on this protocol. Special thanks to the following for their contributions to this document and diligence in greatly improving it.
PKIX作業部会における活発な討論はこのプロトコルで重要な影響を与えました。 このドキュメントへの彼らの貢献とそれを大いに改良することにおける勤勉さのための以下のおかげで、特別です。
Paul Hoffman Phillip Hallam-Baker Mike Myers Frank Balluffi Ameya Talwalkar John Thielens Peter Sylvester Yuriy Dzambasow Sean P. Turner Wen-Cheng Wang Francis Dupont Dave Engberg Faisal Maqsood
ポールホフマンフィリップハラム-ベイカーマイクマイアーズフランクBalluffi Ameya TalwalkarジョンThielensピーターシルベスターユーリーDzambasowショーンP.ターナーWenチェンワングフランシスデュポンデーヴEngberg Faisal Maqsood
Thanks also to working group chair Steve Kent for his support and help.
また、彼のサポートのためのワーキンググループ議長のスティーブ・ケントをありがとうございます、助けてください。
Freeman, et al. Standards Track [Page 80] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[80ページ]。
Appendix A. MIME Media Type Registrations
付録A.MIMEメディアは登録証明書をタイプします。
Four MIME media type registrations are provided in this appendix.
4つのMIMEメディアタイプ登録証明書をこの付録に提供します。
A.1. application/scvp-cv-request
A.1scvp-cvアプリケーション/要求
To: ietf-types@iana.org Subject: Registration of MIME media type application/scvp-cv-request
To: ietf-types@iana.org Subject: MIMEメディアの登録はscvp-cvアプリケーション/要求をタイプします。
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: scvp-cv-request
MIME「副-タイプ」は以下を命名します。 scvp-cv-要求
Required parameters: None
必要なパラメタ: なし
Optional parameters: None
任意のパラメタ: なし
Encoding considerations: Binary
問題をコード化します: バイナリー
Security considerations: Carries a request for information. This request may optionally be cryptographically protected.
セキュリティ問題: 情報に関する要求を運びます。 この要求は任意に暗号で保護されるかもしれません。
Interoperability considerations: None
相互運用性問題: なし
Published specification: RFC 5055
広められた仕様: RFC5055
Applications that use this media type: SCVP clients sending certificate validation requests
このメディアタイプを使用するアプリケーション: 証明書合法化要求を送るSCVPクライアント
Additional information:
追加情報:
Magic number(s): None
File extension(s): .SCQ
Macintosh File Type Code(s): None
マジックナンバー(s): なにも、File拡張子: .SCQマッキントッシュファイルタイプは(s)をコード化します: なし
Person & email address to contact for further information: Ambarish Malpani <ambarish@yahoo.com>
詳細のために連絡する人とEメールアドレス: Ambarish Malpani <ambarish@yahoo.com 、gt。
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>
以下を書いてください。 Ambarish Malpani <ambarish@yahoo.com 、gt。
Change controller: IESG
コントローラを変えてください: IESG
Freeman, et al. Standards Track [Page 81] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[81ページ]。
A.2. application/scvp-cv-response
A.2scvp-cvアプリケーション/応答
To: ietf-types@iana.org Subject: Registration of MIME media type application/scvp-cv-response
To: ietf-types@iana.org Subject: MIMEメディアの登録はscvp-cvアプリケーション/応答をタイプします。
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
広められた仕様: RFC5055
Applications that use this media type: SCVP servers responding to certificate validation requests
このメディアタイプを使用するアプリケーション: 合法化要求を証明するために反応するSCVPサーバ
Additional information:
追加情報:
Magic number(s): None
File extension(s): .SCS
Macintosh File Type Code(s): none
マジックナンバー(s): なにも、File拡張子: .SCSマッキントッシュファイルタイプは(s)をコード化します: なし
Person & email address to contact for further information: Ambarish Malpani <ambarish@yahoo.com>
詳細のために連絡する人とEメールアドレス: Ambarish Malpani <ambarish@yahoo.com 、gt。
Intended usage: COMMON Restrictions on usage: This media type can be used with any protocol that can transport digitally signed objects.
意図している用法: 用法のCOMMON Restrictions: デジタルに署名しているオブジェクトを輸送できるどんなプロトコルと共にもこのメディアタイプを使用できます。
Author: Ambarish Malpani <ambarish@yahoo.com>
以下を書いてください。 Ambarish Malpani <ambarish@yahoo.com 、gt。
Change controller: IESG
コントローラを変えてください: IESG
Freeman, et al. Standards Track [Page 82] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[82ページ]。
A.3. application/scvp-vp-request
A.3scvp-vpアプリケーション/要求
To: ietf-types@iana.org Subject: Registration of MIME media type application/scvp-vp-request
To: ietf-types@iana.org Subject: MIMEメディアの登録はscvp-vpアプリケーション/要求をタイプします。
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: scvp-vp-request
MIME「副-タイプ」は以下を命名します。 scvp-vp-要求
Required parameters: None
必要なパラメタ: なし
Optional parameters: None
任意のパラメタ: なし
Encoding considerations: Binary
問題をコード化します: バイナリー
Security considerations: Carries a request for information.
セキュリティ問題: 情報に関する要求を運びます。
Interoperability considerations: None
相互運用性問題: なし
Published specification: RFC 5055
広められた仕様: RFC5055
Applications that use this media type: SCVP clients sending validation policy requests
このメディアタイプを使用するアプリケーション: 合法化方針要求を送るSCVPクライアント
Additional information:
追加情報:
Magic number(s): None
File extension(s): .SPQ
Macintosh File Type Code(s): none
マジックナンバー(s): なにも、File拡張子: .SPQマッキントッシュファイルタイプは(s)をコード化します: なし
Person & email address to contact for further information: Ambarish Malpani <ambarish@yahoo.com>
詳細のために連絡する人とEメールアドレス: Ambarish Malpani <ambarish@yahoo.com 、gt。
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage: None
用法における制限: なし
Author: Ambarish Malpani <ambarish@yahoo.com>
以下を書いてください。 Ambarish Malpani <ambarish@yahoo.com 、gt。
Change controller: IESG
コントローラを変えてください: IESG
Freeman, et al. Standards Track [Page 83] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[83ページ]。
A.4. application/scvp-vp-response
A.4scvp-vpアプリケーション/応答
To: ietf-types@iana.org Subject: Registration of MIME media type application/scvp-vp-response
To: ietf-types@iana.org Subject: MIMEメディアの登録はscvp-vpアプリケーション/応答をタイプします。
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
広められた仕様: RFC5055
Applications that use this media type: SCVP servers responding to validation policy requests
このメディアタイプを使用するアプリケーション: 合法化方針要求に応じるSCVPサーバ
Additional information:
追加情報:
Magic number(s): None
File extension(s): .SPP
Macintosh File Type Code(s): none
マジックナンバー(s): なにも、File拡張子: .SPPマッキントッシュファイルタイプは(s)をコード化します: なし
Person & email address to contact for further information: Ambarish Malpani <ambarish@yahoo.com>
詳細のために連絡する人とEメールアドレス: Ambarish Malpani <ambarish@yahoo.com 、gt。
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>
以下を書いてください。 Ambarish Malpani <ambarish@yahoo.com 、gt。
Change controller: IESG
コントローラを変えてください: IESG
Freeman, et al. Standards Track [Page 84] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[84ページ]。
Appendix B. SCVP over HTTP
HTTPの上の付録B.SCVP
This appendix describes the formatting and transportation conventions for the SCVP request and response when carried by HTTP.
HTTPによって運ばれると、この付録はSCVP要求と応答のために形式と輸送コンベンションについて説明します。
In order for SCVP clients and servers using HTTP to interoperate, the following rules apply.
SCVPクライアントの注文と共同利用するのにHTTPを使用するサーバでは、以下の規則は適用されます。
- Clients MUST use the POST method to submit their requests.
- クライアントは彼らの要求を提出するポストメソッドを使用しなければなりません。
- 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.
- クライアントは、TLS1.0以降を使用することで要求をHTTPSに送るのを試みるかもしれません、サーバがTLSをサポートするのに必要ではありませんが。
- Servers MUST NOT assume client support for any type of HTTP
authentication such as cookies, Basic authentication, or Digest
authentication.
- サーバはHTTP認証のクッキー、Basic認証、またはDigest認証などのどんなタイプのクライアントサポートも仮定してはいけません。
- 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]における他の規則と制限に従うと予想されます。 それらの規則のいくつかがポスト以外のHTTPメソッドのためのものであることに注意してください。 この仕様において、ポストに適用される規則だけが関連しています。
B.1. SCVP Request
B.1。 SCVP要求
An SCVP request using the POST method is constructed as follows:
ポストメソッドを使用するSCVP要求は以下の通り構成されます:
The Content-Type header MUST have the value "application/scvp-cv- request".
コンテントタイプヘッダーには、「アプリケーション/scvp-cvは要求する」値がなければなりません。
The body of the message is the binary value of the DER encoding of the CVRequest, wrapped in a CMS body as described in Section 3.
メッセージ欄はセクション3で説明されるようにCMSボディーで包装されたCVRequestのDERコード化の2進の値です。
B.2. SCVP Response
B.2。 SCVP応答
An HTTP-based SCVP response is composed of the appropriate HTTP headers, followed by the binary value of the BER encoding of the CVResponse, wrapped in a CMS body as described in Section 4.
HTTPベースのSCVP応答はセクション4で説明されるようにCMSボディーで包装されたCVResponseのBERコード化の2進の値があとに続いた適切なHTTPヘッダで構成されます。
The Content-Type header MUST have the value "application/scvp-cv- response".
コンテントタイプヘッダーには、値がなければなりません。「アプリケーション/scvp-cv応答。」
Freeman, et al. Standards Track [Page 85] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[85ページ]。
B.3. SCVP Policy Request
B.3。 SCVP方針要求
An SCVP request using the POST method is constructed as follows:
ポストメソッドを使用するSCVP要求は以下の通り構成されます:
The Content-Type header MUST have the value "application/scvp-vp-
request".
コンテントタイプヘッダーには、「アプリケーション/scvp-vpは要求する」値がなければなりません。
The body of the message is the binary value of the BER encoding of the ValPolRequest, wrapped in a CMS body as described in Section 5.
メッセージ欄はセクション5で説明されるようにCMSボディーで包装されたValPolRequestのBERコード化の2進の値です。
B.4. SCVP Policy Response
B.4。 SCVP方針応答
An HTTP-based SCVP policy response is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the ValPolResponse, wrapped in a CMS body as described in Section 6. The Content-Type header MUST have the value "application/scvp-vp- response".
HTTPベースのSCVP方針応答はセクション6で説明されるようにCMSボディーで包装されたValPolResponseのDERコード化の2進の値があとに続いた適切なHTTPヘッダで構成されます。 コンテントタイプヘッダーには、値がなければなりません。「アプリケーション/scvp-vp応答。」
Freeman, et al. Standards Track [Page 86] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[86ページ]。
Authors' Addresses
作者のアドレス
Trevor Freeman Microsoft Corporation, One Microsoft Way Redmond, WA 98052 USA. EMail: trevorf@microsoft.com
トレバーフリーマンマイクロソフト社、1つのマイクロソフト道、ワシントン98052レッドモンド(米国)。 メール: trevorf@microsoft.com
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
ラッセルHousley不寝番セキュリティ、LLC918春の小山Driveヴァージニア20170ハーンドン(米国)メール: housley@vigilsec.com
Ambarish Malpani Malpani Consulting Services EMail: ambarish@yahoo.com
Ambarish Malpani Malpaniコンサルタント業務はメールされます: ambarish@yahoo.com
David Cooper National Institute of Standards and Technology 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 EMail: david.cooper@nist.gov
デヴィッド桶屋米国商務省標準技術局100事務局Drive、8930年のメール停止ゲイザースバーグ、MD20899-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
ティムポーク米国商務省標準技術局100事務局Drive、8930年のメール停止ゲイザースバーグ、MD20899-8930メール: wpolk@nist.gov
Freeman, et al. Standards Track [Page 87] RFC 5055 SCVP December 2007
フリーマン、他 規格はSCVP2007年12月にRFC5055を追跡します[87ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Freeman, et al. Standards Track [Page 88]
フリーマン、他 標準化過程[88ページ]
一覧
スポンサーリンク
