RFC2797 日本語訳
2797 Certificate Management Messages over CMS. M. Myers, X. Liu, J.Schaad, J. Weinstein. April 2000. (Format: TXT=103357 bytes) (Obsoleted by RFC5272) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Myers
Request for Comments: 2797 VeriSign
Category: Standards Track X. Liu
Cisco
J. Schaad
Microsoft
J. Weinstein
April 2000
コメントを求めるワーキンググループM.マイアーズの要求をネットワークでつないでください: 2797年のベリサインカテゴリ: 標準化過程X.リュウコクチマスJ.SchaadマイクロソフトJ.ワインスタイン2000年4月
Certificate Management Messages over CMS
cmの上の証明書管理メッセージ
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document defines a Certificate Management protocol using CMS (CMC). This protocol addresses two immediate needs within the Internet PKI community:
このドキュメントは、CMS(CMC)を使用することでCertificate Managementプロトコルを定義します。 このプロトコルはインターネットPKI共同体の中の2つの即座の必要性を扱います:
1. The need for an interface to public key certification products and
services based on [CMS] and [PKCS10], and
2. The need in [SMIMEV3] for a certificate enrollment protocol for
DSA-signed certificates with Diffie-Hellman public keys.
1. 公開鍵証明製品とサービスへのインタフェースの必要性は[CMS]、[PKCS10]、および2を基礎づけました。 [SMIMEV3]のディフィー-ヘルマン公開鍵があるDSA-署名入りの証書のための証明書登録プロトコルの必要性。
A small number of additional services are defined to supplement the core certificate request service.
少ない数の追加サービスが、コア証明書要求サービスを補うために定義されます。
Throughout this specification the term CMS is used to refer to both [CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers to this specification.
この仕様中では、CMSという用語は、[CMS]と[PKCS7]の両方について言及するのに使用されます。 signedDataとenvelopedDataの両方に関しては、CMSはPKCS7のスーパーセットです。 一般に、PKCS7の使用は本書ではPKCS7構文のスーパーセットを提供するCryptographic Message Syntax[CMS]に並べられます。 CMCという用語はこの仕様を示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Myers, et al. Standards Track [Page 1] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[1ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
1. Protocol Requirements
1. プロトコル要件
- The protocol is to be based as much as possible on the existing
CMS, PKCS#10 and CRMF specifications.
- The protocol must support the current industry practice of a
PKCS#10 request followed by a PKCS#7 response as a subset of the
protocol.
- The protocol needs to easily support the multi-key enrollment
protocols required by S/MIME and other groups.
- The protocol must supply a way of doing all operations in a
single-round trip. When this is not possible the number of round
trips is to be minimized.
- The protocol will be designed such that all key generation can
occur on the client.
- The mandatory algorithms must superset the required algorithms for
S/MIME.
- The protocol will contain POP methods. Optional provisions for
multiple-round trip POP will be made if necessary.
- The protocol will support deferred and pending responses to
certificate request for cases where external procedures are
required to issue a certificate.
- The protocol needs to support arbitrary chains of local
registration authorities as intermediaries between certificate
requesters and issuers.
- プロトコルは既存のCMS、PKCS#10、およびCRMF仕様にできるだけ基づくことです。 - プロトコルは、現在の産業がPKCS#7応答がプロトコルの部分集合としてあとに続いたPKCS#10要求の習慣であるとサポートしなければなりません。 - プロトコルは、マルチ主要な登録がS/MIMEと他のグループによって必要とされたプロトコルであると容易にサポートする必要があります。 - プロトコルは単発旅行におけるすべての操作をする方法を供給しなければなりません。 これが可能でないときに、周遊旅行の数は最小にされることです。 - プロトコルは、すべてのキー生成がクライアントの上に起こることができるように、設計されるでしょう。 - 義務的なアルゴリズム必須スーパーセット、S/MIMEのための必要なアルゴリズム。 - プロトコルはPOPメソッドを含むでしょう。 必要なら、複数の周遊旅行POPのための任意の条項は作られるでしょう。 - プロトコルは、外部手続きが証明書を下付するのに必要であるケースを求める要求を証明するために延期されて未定の応答をサポートするでしょう。 - プロトコルは、証明書リクエスタと発行人の間の仲介者として地方の登録局の任意のチェーンを支える必要があります。
2. Protocol Overview
2. プロトコル概要
An enrollment transaction in this specification is generally composed of a single round trip of messages. In the simplest case an enrollment request is sent from the client to the server and an enrollment response is then returned from the server to the client. In some more complicated cases, such as delayed certificate issuance and polling for responses, more than one round trip is required.
一般に、この仕様による登録トランザクションはメッセージの単発旅行で構成されます。 最も簡単な場合では、登録要求をクライアントからサーバに送ります、そして、次に、サーバからクライアントまで登録応答を返します。 応答のための遅れた証明書発行や世論調査などのそれ以上の複雑な場合では、1つ以上の周遊旅行が必要です。
This specification supports two different request messages and two different response messages.
この仕様は2つの異なった要求メッセージと2つの異なった応答メッセージをサポートします。
Public key certification requests can be based on either the PKCS10 or CRMF object. The two different request messages are (a) the bare PKCS10 (in the event that no other services are needed), and (b) the PKCS10 or CRMF message wrapped in a CMS encapsulation as part of a PKIData object.
公開鍵証明要求はPKCS10かCRMFオブジェクトに基づくことができます。 2つの異なった要求メッセージがそうです。(a) (b) PKIDataオブジェクトの一部としてCMSカプセル化で包装されたむき出しのPKCS10(他のサービスは全く必要でない場合)と、PKCS10かCRMFメッセージ。
Public key certification responses are based on the CMS signedData object. The response may be either (a) a degenerate CMS signedData object (in the event no other services are needed), or (b) a ResponseBody object wrapped in a CMS signedData object.
公開鍵証明応答はCMS signedDataオブジェクトに基づいています。 応答は、ResponseBodyオブジェクトがCMS signedDataオブジェクトで身を包ませた(a) 堕落したCMS signedDataオブジェクト(イベントでは、他のサービスは全く必要でない)か(b)のどちらかであるかもしれません。
Myers, et al. Standards Track [Page 2] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[2ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
No special services are provided for doing either renewal (new certificates with the same key) or re-keying (new certificates on new keys) of clients. Instead a renewal/re-key message looks the same as any enrollment message, with the identity proof being supplied by existing certificates from the CA.
特殊業務は、全くクライアントを更新(同じキーがある新しい証明書)か再の合わせのどちらかであること(新しいキーの上の新しい証明書)をしながら、備えられません。 代わりに、再更新/主要なメッセージはどんな登録メッセージとも同じに見えます、既存の証明書からカリフォルニアからアイデンティティ証拠を供給していて。
A provision exists for Local Registration Authorities (LRAs) to participate in the protocol by taking client enrollment messages, wrapping them in a second layer of enrollment message with additional requirements or statements from the LRA and then passing this new expanded request on to the Certification Authority.
クライアント登録伝言を受け取ることによってLocal Registration Authorities(LRAs)がプロトコルに参加するように、支給は存在しています、2番目の層に関する登録メッセージでLRAからの追加要件か声明でそれらを包装して、次に、この新しい拡張要求に認証局に合格して。
This specification makes no assumptions about the underlying transport mechanism. The use of CMS is not meant to imply an email- based transport.
この仕様は基本的な移送機構に関する仮定を全くしません。 CMSの使用は、メールが輸送を基礎づけたのを含意することになっていません。
Optional services available through this specification are transaction management, replay detection (through nonces), deferred certificate issuance, certificate revocation requests and certificate/CRL retrieval.
この仕様で利用可能な任意のサービスは延期されたトランザクション管理、再生検出(一回だけを通した)、証明書発行、証明書取消し要求、および証明書/CRL検索です。
2.1 Terminology
2.1 用語
There are several different terms, abbreviations and acronyms used in this document that we define here for convenience and consistency of usage:
本書では使用される私たちが用法の便宜と一貫性のためにここで定義するいくつかの異なった用語、略語、および頭文字語があります:
"End-Entity" (EE) refers to the entity that owns a key pair and for
whom a certificate is issued.
"LRA" or "RA" refers to a (Local) Registration Authority. A
registration authority acts as an intermediary between an End-
Entity and a Certification Authority. Multiple RAs can exist
between the End-Entity and the Certification Authority.
"CA" refers to a Certification Authority. A Certification Authority
is the entity that performs the actual issuance of a certificate.
"Client" refers to an entity that creates a PKI request. In this
document both RAs and End-Entities can be clients.
"Server" refers to the entities that process PKI requests and create
PKI responses. CAs and RAs can be servers in this document.
"PKCS#10" refers the Public Key Cryptography Standard #10. This is
one of a set of standards defined by RSA Laboratories in the
1980s. PKCS#10 defines a Certificate Request Message syntax.
"CRMF" refers to the Certificate Request Message Format RFC [CRMF].
We are using certificate request message format defined in this
document as part of our management protocol.
"CMS" refers to the Cryptographic Message Syntax RFC [CMS]. This
document provides for basic cryptographic services including
encryption and signing with and without key management.
「終わり実体」(EE)は主要な組を所有して、証明書が発行される実体について言及します。 "LRA"か"RA"が(地方)の登録局を示します。 登録局はEnd実体と認証局の間の仲介者として機能します。 複数のRAsがEnd-実体と認証局の間に存在できます。 「カリフォルニア」は認証局を示します。 認証局は証明書の実際の発行を実行する実体です。 「クライアント」はPKI要求を作成する実体を示します。 本書ではRAsとEnd-実体の両方がクライアントであるかもしれません。 「サーバ」はPKI要求を処理して、PKI応答を作成する実体を示します。 CAsとRAsは本書ではサーバであるかもしれません。 「PKCS#10インチは公開鍵暗号規格#10を参照します。」 これは1980年代にRSA研究所によって定義された1セットの規格の1つです。 PKCS#10はCertificate Request Message構文を定義します。 "CRMF"はCertificate Request Message Format RFC[CRMF]を示します。 私たちは本書では私たちの管理プロトコルの一部と定義された証明書要求メッセージ書式を使用しています。 「CMS」はCryptographic Message Syntax RFC[CMS]を示します。 このドキュメントはかぎ管理のあるなしにかかわらず暗号化を含んで、署名する基本的な暗号のサービスに備えます。
Myers, et al. Standards Track [Page 3] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[3ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
"POP" is an acronym for "Proof of Possession". POP refers to a value
that can be used to prove that the private key corresponding to a
public key is in the possession and can be used by an end-entity.
"Transport wrapper" refers to the outermost CMS wrapping layer.
「POP」は「所有物の証拠」のための頭文字語です。 POPは公開鍵に対応する秘密鍵が所有物にあると立証するのに使用できて、終わり実体で使用できる値について言及します。 「輸送ラッパー」は一番はずれのCMSラッピング層を示します。
2.2 Protocol Flow Charts
2.2 プロトコルフローチャート
Figure 1 shows the Simple Enrollment Request and Response messages. The contents of these messages are detailed in Sections 4.1 and 4.3 below.
図1はSimple Enrollment RequestとResponseにメッセージを示しています。 これらのメッセージの内容は以下のセクション4.1と4.3で詳細です。
Simple PKI Request Simple PKI Response
------------------------- --------------------------
簡単なPKIは簡単なPKI応答を要求します。------------------------- --------------------------
+----------+ +------------------+
| PKCS #10 | | CMS "certs-only" |
+----------+--------------+ | message |
| | +------------------+------+
| Certificate Request | | |
| | | CMS Signed Data, |
| Subject Name | | no signerInfo |
| Subject Public Key Info | | |
| (K_PUB) | | signedData contains one |
| Attributes | | or more certificates in |
| | | the "certificates" |
+-----------+-------------+ | portion of the |
| signed with | | signedData. |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
+-------------+ | is empty. |
| |
+--------------+----------+
| unsigned |
+----------+
+----------+ +------------------+ | PKCS#10| | cm、「本命専用」| +----------+--------------+ | メッセージ| | | +------------------+------+ | 証明書要求| | | | | | cmはデータに署名しました。| | 対象の名前| | signerInfoがありません。| | 対象の公開鍵インフォメーション| | | | (K_パブ) | | signedDataは1つを含んでいます。| | 属性| | または、以上はコネを証明します。| | | | 「証明書」| +-----------+-------------+ | 分配します。| | 契約されます。| | signedData。 | | マッチング| | | | K_PRIV| | encapsulatedContentInfo| +-------------+ | 空になってください。 | | | +--------------+----------+ | 未署名| +----------+
Figure 1: Simple PKI Request and Response Messages
図1: 簡単なPKI要求と応答メッセージ
Myers, et al. Standards Track [Page 4] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[4ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
Full PKI Request Full PKI Response
----------------------- ------------------------
完全なPKIは完全なPKI応答を要求します。----------------------- ------------------------
+----------------+ +----------------+
| CMS signedData | | CMS signedData |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData object | | ResponseBody object |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment attribute>* | | <enrollment attribute>* |
| <certification request>*| | <CMS object>* |
| <CMS objects>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certificate requests | | as part of the response |
| are CRMF or PKCS#10 | | are included in the |
| objects. Attributes are | | "certificates" portion |
| (OID, ANY defined by | | of the signedData. |
| OID) pairs. | | Relevant CA certs and |
| | | CRLs can be included as |
+-------+-----------------+ | well. |
| signed (keypair | | |
| used may be pre-| +---------+---------------+
| existing or | | signed by the |
| identified in | | CA or an LRA |
| the request) | +---------------+
+-----------------+
+----------------+ +----------------+ | cm signedData| | cm signedData| | オブジェクト| | オブジェクト| +----------------+--------+ +----------------+--------+ | | | | | PKIDataオブジェクト| | ResponseBodyオブジェクト| | | | | | 以下の系列 | | 以下の系列 | | <登録属性>*| | <登録属性>*| | <証明要求>*| | <CMSオブジェクト>*| | <CMSオブジェクト>*| | <他のメッセージ>*| | <他のメッセージ>*| | | | | | どこ、ゼロか*=以上| | どこ、ゼロか*=以上| | | | | | 証明書が発行したすべて| | 証明書要求| | 応答の一部として| | CRMFかPKCSが#10ですか?| | 含まれています。| | オブジェクト。 属性はそうです。| | 「証明書」部分| | (少しも定義されたOID| | signedDataについて。 | | OID) 組。 | | そして関連カリフォルニア本命。| | | | CRLsを含むことができます。| +-------+-----------------+ | さて。 | | signed (keypair | | | | used may be pre-| +---------+---------------+ | existing or | | signed by the | | identified in | | CA or an LRA | | the request) | +---------------+ +-----------------+
Figure 2: Full PKI Request and Response Messages
図2: 完全なPKI要求と応答メッセージ
Figure 2 shows the Full Enrollment Request and Response messages. The contents of these messages are detailed in Sections 4.2 and 4.4 below.
図2はFull Enrollment RequestとResponseにメッセージを示しています。 これらのメッセージの内容は以下のセクション4.2と4.4で詳細です。
3. Protocol Elements
3. プロトコル要素
This section covers each of the different elements that may be used to construct enrollment request and enrollment response messages. Section 4 will cover how to build the enrollment request and response messages.
このセクションは登録要求と登録応答メッセージを構成するのに使用されるかもしれないそれぞれの異なった要素をカバーします。 セクション4はどう登録要求と応答メッセージを組み込むかをカバーするでしょう。
Myers, et al. Standards Track [Page 5] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[5ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
3.1 PKIData Object
3.1 PKIDataは反対します。
The new content object PKIData has been defined for this protocol. This new object is used as the body of the full PKI request message. The new body is identified by:
新しい満足しているオブジェクトPKIDataはこのプロトコルのために定義されました。 この新しいオブジェクトは完全なPKI要求メッセージのボディーとして使用されます。 新しいボディーは以下によって特定されます。
id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
イド-cct-PKIDataオブジェクト識別子:、:= イド-cct2
The ASN.1 structure corresponding to this new content type is:
この新しいcontent typeに対応するASN.1構造は以下の通りです。
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
PKIData:、:= 系列TaggedAttributeのcontrolSequence系列サイズ(0..MAX)、TaggedRequestのreqSequence系列サイズ(0..MAX)、TaggedContentInfoのcmsSequence系列サイズ(0..MAX)、OtherMsgのotherMsgSequence系列サイズ(0..MAX)
-- controlSequence consists of a sequence of control attributes. The control attributes defined in this document are found in section 5. As control sequences are defined by OIDs, other parties can define additional control attributes. Unrecognized OIDs MUST result in no part of the request being successfully processed.
-- controlSequenceはコントロール属性の系列から成ります。 本書では定義されたコントロール属性はセクション5で見つけられます。 コントロールと、系列はOIDsによって定義されて、相手は追加コントロール属性を定義できます。 認識されていないOIDsは首尾よく処理される要求の一部を全くもたらしてはいけません。
-- reqSequence consists of a sequence of certificate requests. The certificate requests can be either a CertificateRequest (PKCS10 request) or a CertReqMsg. Details on each of these request types are found in sections 3.3.1 and 3.3.2 respectively.
-- reqSequenceは証明書要求の系列から成ります。 証明書要求は、CertificateRequest(PKCS10要求)かCertReqMsgのどちらかであるかもしれません。 要求タイプがあるというそれぞれのこれらに関する詳細はセクション3.3.1と3.3でそれぞれ.2を設立します。
-- cmsSequence consists of a sequence of [CMS] message objects. This protocol only uses EnvelopedData, SignedData and EncryptedData. See section 3.6 for more details.
-- cmsSequenceは[CMS]メッセージオブジェクトの系列から成ります。 このプロトコルはEnvelopedData、SignedData、およびEncryptedDataを使用するだけです。 その他の詳細に関してセクション3.6を見てください。
-- otherMsgSequence allows for other arbitrary data items to be
placed into the enrollment protocol. The {OID, any} pair of values
allows for arbitrary definition of material. Data objects are placed
here while control objects are placed in the controlSequence field.
See section 3.7 for more details.
-- otherMsgSequenceは、他の任意のデータ項目が登録プロトコルに置かれるのを許容します。 OID、いくらか、値の組は材料の勝手な定義を考慮します。 コントロールオブジェクトはcontrolSequence分野に置かれますが、データ・オブジェクトはここに置かれます。 その他の詳細に関してセクション3.7を見てください。
3.2 ResponseBody Object
3.2 ResponseBodyは反対します。
The new content object ResponseBody has been defined for this protocol. This new object is used as the body of the full PKI response message. The new body is identified by:
新しい満足しているオブジェクトResponseBodyはこのプロトコルのために定義されました。 この新しいオブジェクトは完全なPKI応答メッセージの本論として使用されます。 新しいボディーは以下によって特定されます。
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
イド-cct-PKIResponseオブジェクト識別子:、:= イド-cct3
Myers, et al. Standards Track [Page 6] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[6ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
The ASN.1 structure corresponding to this body content type is:
このボディーcontent typeに対応するASN.1構造は以下の通りです。
ResponseBody ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
ResponseBody:、:= 系列TaggedAttributeのcontrolSequence系列サイズ(0..MAX)、TaggedContentInfoのcmsSequence系列サイズ(0..MAX)、OtherMsgのotherMsgSequence系列サイズ(0..MAX)
-- controlSequence consists of a sequence of control attributes. The control attributes defined in this document are found in section 3.5. Other parties can define additional control attributes.
-- controlSequenceはコントロール属性の系列から成ります。 本書では定義されたコントロール属性はセクション3.5で見つけられます。 相手は追加コントロール属性を定義できます。
-- cmsSequence consists of a sequence of [CMS] message objects. This protocol only uses EnvelopedData, SignedData and EncryptedData. See section 3.6 for more details.
-- cmsSequenceは[CMS]メッセージオブジェクトの系列から成ります。 このプロトコルはEnvelopedData、SignedData、およびEncryptedDataを使用するだけです。 その他の詳細に関してセクション3.6を見てください。
-- otherMsgSequence allows for other arbitrary items to be placed
into the enrollment protocol. The {OID, any} pair of values allows
for arbitrary definition of material. Data objects are placed here
while control objects are placed in the controlSequence field. See
section 3.7 for more details.
-- otherMsgSequenceは、他の任意の商品が登録プロトコルに置かれるのを許容します。 OID、いくらか、値の組は材料の勝手な定義を考慮します。 コントロールオブジェクトはcontrolSequence分野に置かれますが、データ・オブジェクトはここに置かれます。 その他の詳細に関してセクション3.7を見てください。
3.3 Certification Requests (PKCS10/CRMF)
3.3 証明要求(PKCS10/CRMF)
Certification Requests are based on either PKCS10 or CRMF messages. Section 3.3.1 specifies mandatory and optional requirements for clients and servers dealing with PKCS10 request messages. Section 3.3.2 specifies mandatory and optional requirements for clients and servers dealing with CRMF request messages.
証明RequestsはPKCS10かCRMFメッセージのどちらかに基づいています。 セクション3.3 .1 義務的でクライアントにとって、任意の要件とPKCS10要求メッセージに対処するサーバを指定します。 セクション3.3 .2 義務的でクライアントにとって、任意の要件とCRMF要求メッセージに対処するサーバを指定します。
3.3.1 PKCS10 Request Body
3.3.1 PKCS10はボディーを要求します。
Servers MUST be able to understand and process PKCS10 request bodies. Clients MUST produce a PKCS10 request body when using the Simple Enrollment Request message. Clients MAY produce a PKCS10 request body when using the Full Enrollment Request message.
サーバは分かることができなければなりません、そして、プロセスPKCS10はボディーを要求します。 Simple Enrollment Requestメッセージを使用するとき、クライアントはPKCS10要求ボディーを生産しなければなりません。 Full Enrollment Requestメッセージを使用するとき、クライアントはPKCS10要求ボディーを生産するかもしれません。
When producing a PKCS10 request body, clients MUST produce a PKCS10 message body containing a subject name and public key. Some certification products are operated using a central repository of information to assign subject names upon receipt of a public key for certification. To accommodate this mode of operation, the subject name in a CertificationRequest MAY be NULL, but MUST be present. CAs that receive a CertificationRequest with a NULL subject name MAY reject such requests. If rejected and a response is returned, the CA MUST respond with the failInfo attribute of badRequest.
PKCS10要求ボディーを生産するとき、クライアントは対象の名前と公開鍵を含むPKCS10メッセージボディーを生産しなければなりません。 いくつかの証明製品が、証明のための公開鍵を受け取り次第対象の名前を割り当てるのに情報の中央倉庫を使用することで操作されます。 この運転モードに対応するために、CertificationRequestの対象の名前は、NULLであるかもしれませんが、存在していなければなりません。 NULLの対象の名でCertificationRequestを受けるCAsはそのような要求を拒絶するかもしれません。 拒絶されるのとa応答を返すなら、カリフォルニアはbadRequestのfailInfo属性で応じなければなりません。
Myers, et al. Standards Track [Page 7] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[7ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
The client MAY incorporate one or more standard X.509 v3 extensions in any PKCS10 request as an ExtensionReq attribute. An ExtensionReq attribute is defined as
クライアントはExtensionReq属性としてどんなPKCS10要求でも1つ以上の標準のX.509 v3拡張子を取り入れるかもしれません。 ExtensionReq属性は定義されます。
ExtensionReq ::= SEQUENCE OF Extension
ExtensionReq:、:= 拡大の系列
where Extension is imported from [PKIXCERT] and ExtensionReq is
identified by {pkcs-9 14}.
Extensionがどこで[PKIXCERT]とExtensionReqからインポートされるかはpkcs-9 14によって特定されます。
Servers MUST be able to process all extensions defined in [PKIXCERT]. Servers are not required to be able to process other V3 X.509 extensions transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all client-requested extensions into a certificate. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example changing key usage from key exchange to signing.) If a certification request is denied due to the inability to handle a requested extension and a response is returned, the server MUST respond with the failInfo attribute of unsupportedExt.
サーバは[PKIXCERT]で定義されたすべての拡大を処理できなければなりません。 サーバはこのプロトコルを使用することで伝えられた他のV3 X.509拡張子を処理できるように必要ではありません、そして、それらは他の、そして、個人的な拡大を処理する必要はないことができます。 サーバは、すべてのクライアントによって要求された拡大を証明書に入れるのに必要ではありません。 サーバがクライアントによって要求された拡大を変更することが許可されています。 サーバは、クライアントによって要求された拡大の当初の意図を無効にするために拡大を変更してはいけません。 (例えば、主要な用法を主要な交換から署名に変えます。) 要求された拡大を扱うことができないことのため証明要求を否定して、応答を返すなら、サーバはunsupportedExtのfailInfo属性で反応しなければなりません。
3.3.2 CRMF Request Body
3.3.2 CRMFはボディーを要求します。
Servers MUST be able to understand and process CRMF request body. Clients MAY produce a CRMF message body when using the Full Enrollment Request message.
サーバは分かることができなければなりません、そして、プロセスCRMFはボディーを要求します。 Full Enrollment Requestメッセージを使用するとき、クライアントはCRMFメッセージボディーを生産するかもしれません。
This memo imposes the following additional changes on the construction and processing of CRMF messages:
このメモはCRMFメッセージの工事と処理に以下の付加的な変化を課します:
- When CRMF message bodies are used in the Full Enrollment Request
message, each CRMF message MUST include both the subject and
publicKey fields in the CertTemplate. As in the case of PKCS10
requests, the subject may be encoded as NULL, but MUST be present.
- In general, when both CRMF and CMC controls exist with equivalent
functionality, the CMC control SHOULD be used. The CMC control
MUST override any CRMF control.
- The regInfo field MUST NOT be used on a CRMF message. Equivalent
functionality is provided in the regInfo control attribute
(section 5.12).
- The indirect method of proving POP is not supported in this
protocol. One of the other methods (including the direct method
described in this document) MUST be used instead if POP is
desired. The value of encrCert in SubsequentMessage MUST NOT be
used.
- CRMFメッセージボディーがFull Enrollment Requestメッセージで使用されるとき、それぞれのCRMFメッセージはCertTemplateの対象とpublicKey分野の両方を含まなければなりません。 PKCS10要求に関するケースのように、対象は、NULLとしてコード化されるかもしれませんが、存在していなければなりません。 - 一般に、CRMFとCMCコントロールの両方が同等な機能性で存在するときのCMCはSHOULDを制御します。使用されます。 CMCコントロールはどんなCRMFコントロールもくつがえさなければなりません。 - CRMFメッセージでregInfo分野を使用してはいけません。 regInfoコントロール属性(セクション5.12)に同等な機能性を提供します。 - POPを立証する間接的なメソッドはこのプロトコルでサポートされません。 POPが望まれているなら、代わりに他のメソッド(本書では説明されたダイレクトメソッドを含んでいる)の1つを使用しなければなりません。 SubsequentMessageのencrCertの値を使用してはいけません。
Myers, et al. Standards Track [Page 8] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[8ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
- Since the subject and publicKeyValues are always present, the
POPOSigningKeyInput MUST NOT be used when computing the value for
POPSigningKey.
- 対象とpublicKeyValuesがいつも存在しているので、POPSigningKeyのために値を計算するとき、POPOSigningKeyInputを使用してはいけません。
A server is not required to use all of the values suggested by the client in the certificate template. Servers MUST be able to process all extensions defined in [PXIXCERT]. Servers are not required to be able to process other V3 X.509 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example change key usage from key exchange to signing.) If a certificate request is denied due to the inability to handle a requested extension, the server MUST respond with a failInfo attribute of unsupportedExt.
サーバは、証明書テンプレートでクライアントによって提案された値のすべてを使用するのに必要ではありません。 サーバは[PXIXCERT]で定義されたすべての拡大を処理できなければなりません。 サーバはこのプロトコルを使用することで伝えられた他のV3 X.509拡張子を処理できるように必要ではありません、そして、それらは他の、そして、個人的な拡大を処理する必要はないことができます。 サーバがクライアントによって要求された拡大を変更することが許可されています。 サーバは、クライアントによって要求された拡大の当初の意図を無効にするために拡大を変更してはいけません。 (例えば、主要な用法を主要な交換から署名に変えてください。) 証明書要求が要求された拡大を扱うことができないことのため否定されるなら、サーバはunsupportedExtのfailInfo属性で反応しなければなりません。
3.3.3 Production of Diffie-Hellman Public Key Certification Requests
3.3.3 ディフィー-ヘルマンの公開鍵証明要求の生産
Part of a certification request is a signature over the request; Diffie-Hellman is a key agreement algorithm and cannot be used to directly produce the required signature object. [DH-POP] provides two ways to produce the necessary signature value. This document also defines a signature algorithm that does not provide a POP value, but can be used to produce the necessary signature value.
証明要求の一部が要求の上の署名です。 ディフィー-ヘルマンは、主要な協定アルゴリズムであり、直接必要な署名オブジェクトを作り出すのに使用できません。 [DH-POP]は必要な署名値を生産する2つの方法を提供します。 また、このドキュメントはPOP値を提供しませんが、必要な署名値を生産するのに使用できる署名アルゴリズムを定義します。
3.3.3.1 No-Signature Signature Mechanism
3.3.3.1 署名がない署名メカニズム
Key management (encryption/decryption) private keys cannot always be used to produce some type of signature value as they can be in a decrypt only device. Certification requests require that the signature field be populated. This section provides a signature algorithm specifically for that purposes. The following object identifier and signature value are used to identify this signature type:
それらがaでデバイスだけを解読することであることができるので、タイプの署名価値を生産するのにいつもかぎ管理(暗号化/復号化)秘密鍵を使用できるというわけではありません。 証明要求は、署名分野が居住されるのを必要とします。 このセクションは特にその目的に署名アルゴリズムを提供します。 以下のオブジェクト識別子と署名値はこの署名タイプを特定するのに使用されます:
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
イド-alg-noSignatureオブジェクト識別子:、:= イド-pkixイド-alg(6)2
NoSignatureValue ::= OCTET STRING
NoSignatureValue:、:= 八重奏ストリング
The parameters for id-alg-noSignature MUST be present and MUST be encoded as NULL. NoSignatureValue contains the hash of the certification request. It is important to realize that there is no security associated with this signature type. If this signature type is on a certification request and the Certification Authority policy requires proof-of-possession of the private key, the POP mechanism defined in section 5.7 MUST be used.
イド-alg-noSignatureのためのパラメタを存在していなければならなくて、NULLとしてコード化しなければなりません。 NoSignatureValueは証明要求のハッシュを含んでいます。 この署名タイプに関連しているどんなセキュリティもないとわかるのは重要です。 証明要求にはこの署名タイプがあって、認証局方針が秘密鍵所有物の証拠を必要とするなら、セクション5.7で定義されたPOPメカニズムを使用しなければなりません。
Myers, et al. Standards Track [Page 9] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[9ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
3.3.3.2 Diffie-Hellman POP Signature
3.3.3.2 ディフィー-ヘルマンの大衆的なSignature
CMC compliant implementations MUST support section 5 of [DH-POP].
CMC対応することの実装は[DH-POP]のセクション5をサポートしなければなりません。
3.3.3.3 Diffie-Hellman MAC signature
3.3.3.3 ディフィー-ヘルマンのMAC署名
CMC compliant implementations MAY support section 4 of [DH-POP].
CMC対応することの実装は[DH-POP]のセクション4をサポートするかもしれません。
3.4 Body Part Identifiers
3.4 ボディー部分識別子
Each element of a PKIData or PKIResponse message has an associated body part identifier. The Body Part Identifier is a 4-octet integer encoded in the certReqIds field for CertReqMsg objects (in a TaggedRequest) or in the bodyPartId field of the other objects. The Body Part Identifier MUST be unique within a single PKIData or PKIResponse object. Body Part Identifiers can be duplicated in different layers (for example a CMC message embedded within another). The Body Part Id of zero is reserved to designate the current PKIData object. This value is used in control attributes such as the Add Extensions Control in the pkiDataReference field to refer to a request in the current PKIData object.
PKIDataかPKIResponseメッセージの各要素には、関連ボディー部分識別子があります。 Body Part IdentifierはCertReqMsgオブジェクト(TaggedRequestの)のためのcertReqIds分野か他のオブジェクトのbodyPartId分野でコード化された4八重奏の整数です。 Body Part Identifierは独身のPKIDataかPKIResponseオブジェクトの中にユニークであるに違いありません。 異なった層(例えば別のものの中で埋め込まれたCMCメッセージ)でボディーPart Identifiersをコピーできます。 ゼロのBody Part Idは、現在のPKIDataオブジェクトを指定するために予約されます。 この値は、現在のPKIDataオブジェクトでの要求を示すのにpkiDataReference分野のAdd Extensions Controlなどのコントロール属性に使用されます。
Some control attribute, such as the CMC Status Info attribute, will also use Body Part Identifiers to refer to elements in the previous message. This allows an error to be explicit about the attribute or request to which the error applies.
また、CMC Status Info属性などの何らかのコントロール属性が、前のメッセージの要素を示すのにBody Part Identifiersを使用するでしょう。 これは、誤りが誤りが適用される属性か要求に関して明白であることを許容します。
3.5 Control Attributes
3.5 コントロール属性
The overall control flow of how a message is processed in this document is based on the control attributes. Each control attribute consists of an object identifier and a value based on the object identifier.
メッセージがどう処理されるかに関する総括経営流動は本書ではコントロール属性に基づいています。 それぞれのコントロール属性はオブジェクト識別子に基づくオブジェクト識別子と価値から成ります。
Servers MUST fail the processing of an entire PKIData message if any included control attribute is not recognized. The response MUST be the error badRequest and bodyList MUST contain the bodyPartID of the invalid or unrecognized control attribute.
何か含まれているコントロール属性が認識されないなら、サーバは全体のPKIDataメッセージの処理に失敗しなければなりません。 応答は誤りbadRequestであるに違いありません、そして、bodyListは無効の、または、認識されていないコントロール属性のbodyPartIDを含まなければなりません。
The syntax of a control attribute is
コントロール属性の構文はそうです。
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartId,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
TaggedAttribute:、:= 系列bodyPartID BodyPartId、attrTypeオブジェクト識別子、AttributeValueのattrValuesセット
Myers, et al. Standards Track [Page 10] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[10ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
-- bodyPartId is a unique integer that is used to reference this
control attribute. The id of 0 is reserved for use as the
reference to the current PKIData object.
-- bodyPartIdはこのコントロールが結果と考える参照に使用されるユニークな整数です。 0のイドは使用のために現在のPKIDataオブジェクトの参照として予約されます。
-- attrType is the OID defining the associated data in attrValues
-- attrTypeはattrValuesの関連データを定義するOIDです。
-- attrValues contains the set of data values used in processing
the control attribute.
-- attrValuesはコントロール属性を処理する際に使用されるデータ値のセットを含んでいます。
The set of control attributes that are defined by this memo are found in section 5.
このメモで定義されるコントロール属性のセットはセクション5で見つけられます。
3.6 Content Info objects
3.6 満足しているInfoオブジェクト
The cmsSequence field of the PKIRequest and PKIResponse messages contains zero or more tagged content info objects. The syntax for this structure is
PKIRequestとPKIResponseメッセージのcmsSequence分野はゼロか、よりタグ付けをされた満足しているインフォメーションオブジェクトを含んでいます。 この構造への構文はそうです。
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartId,
contentInfo ContentInfo
}
TaggedContentInfo:、:= 系列bodyPartID BodyPartId、contentInfo ContentInfo
-- bodyPartId is a unique integer that is used to reference this
content info object. The id of 0 is reserved for use as the
reference to the current PKIData object.
-- bodyPartIdはユニークな整数です、すなわち、参照に使用されて、この満足しているインフォメーションが反対します。 0のイドは使用のために現在のPKIDataオブジェクトの参照として予約されます。
-- contentInfo contains a ContentInfo object (defined in [CMS]).
The three contents used in this location are SignedData,
EnvelopedData and Data.
-- contentInfoはContentInfoオブジェクト([CMS]では、定義される)を含んでいます。 コンテンツがこの位置で使用した3は、SignedDataと、EnvelopedDataとDataです。
EnvelopedData provides for shrouding of data. Data allows for general transport of unstructured data.
EnvelopedDataはデータを覆い隠すことに備えます。 データは不統一なデータの一般的な輸送を考慮します。
The SignedData object from [CMS] is also used in this specification to provide for authentication as well as serving as the general transport wrapper of requests and responses.
[CMS]からのSignedDataオブジェクトは、また、認証に備えるのにこの仕様で使用されて、要求と応答の一般的な輸送ラッパーとして機能しています。
3.6.1 Signed Data
3.6.1 署名しているデータ
The signedData object is used in two different locations when constructing enrollment messages. The signedData object is used as a wrapper for a PKIData as part of the enrollment request message. The signedData object is also used as the outer part of an enrollment response message.
登録メッセージを構成するとき、signedDataオブジェクトは2つの別の場所で使用されます。 signedDataオブジェクトは登録要求メッセージの一部としてのPKIDataにラッパーとして使用されます。 また、signedDataオブジェクトは登録応答メッセージの外側の部分として使用されます。
Myers, et al. Standards Track [Page 11] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[11ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
For the enrollment response the signedData wrapper allows the server to sign the returning data, if any exists, and to carry the certificates and CRLs for the enrollment request. If no data is being returned beyond the certificates, no signerInfo objects are placed in the signedData object.
いずれか存在しているならサーバがsignedDataラッパーで戻っているデータに署名することができる登録応答、登録要求のために証明書とCRLsを運ぶために。 証明書を超えてデータを全く返していないなら、signerInfoオブジェクトを全くsignedDataオブジェクトに置きません。
3.6.2 Enveloped Data
3.6.2 おおわれたデータ
EnvelopedData is the primary method of providing confidentiality for sensitive information in this protocol. The protocol currently uses EnvelopedData to provide encryption of an entire request (see section 4.5). The envelopedData object would also be used to wrap private key material for key archival.
EnvelopedDataはこのプロトコルで秘密性を機密情報に提供するプライマリメソッドです。 プロトコルは、現在、全体の要求の暗号化を提供するのにEnvelopedDataを使用します(セクション4.5を見てください)。 また、envelopedDataオブジェクトは、キーのために記録保管所で秘密鍵の材料を包装するのに使用されるでしょう。
Servers MUST implement envelopedData according to [CMS]. There is an ambiguity (about encrypting content types other than id-data) in the PKCS7 specification that has lead to non-interoperability.
[CMS]に従って、サーバはenvelopedDataを実装しなければなりません。 非相互運用性にリードを持っているPKCS7仕様にはあいまいさ(イドデータ以外のcontent typeを暗号化することに関する)があります。
3.7 Other Message Bodies
3.7 他のメッセージ本体
The other message body portion of the message allows for arbitrary data objects to be carried as part of a message. This is intended to contain data that is not already wrapped in a CMS contentInfo object. The data is ignored unless a control attribute references the data by bodyPartId.
メッセージのもう片方のメッセージボディー部分は、任意のデータ・オブジェクトがメッセージの一部として運ばれるのを許容します。 これがCMS contentInfoオブジェクトで既に身を包まれないデータを含むことを意図します。 コントロール属性がbodyPartIdでデータに参照をつけない場合、データは無視されます。
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
OtherMsg:、:= 系列bodyPartID BodyPartID、otherMsgValueがotherMsgTypeで少しも定義したotherMsgTypeオブジェクト識別子
-- bodyPartID contains the unique id of this object
-- bodyPartIDはこのオブジェクトのユニークなイドを含んでいます。
-- otherMsgType contains the OID defining both the usage of this body part and the syntax of the value associated with this body part
-- otherMsgTypeはこの身体の部分の使用法とこの身体の部分に関連している価値の構文の両方を定義するOIDを含んでいます。
-- otherMsgValue contains the data associated with the message body part.
-- otherMsgValueはメッセージ身体の部分に関連しているデータを含んでいます。
4. PKI Messages
4. PKIメッセージ
This section discusses the details of putting together the different enrollment request and response messages.
このセクションは異なった登録要求と応答メッセージをまとめる詳細について論じます。
Myers, et al. Standards Track [Page 12] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[12ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
4.1 Simple Enrollment Request
4.1 簡単な登録要求
The simplest form of an enrollment request is a plain PKCS10 message. If this form of enrollment request is used for a private key that is capable of generating a signature, the PKCS10 MUST be signed with that private key. If this form of the enrollment request is used for a D-H key, then the D-H POP mechanism described in [DH-POP] MUST be used.
登録要求の最も簡単なフォームは明瞭なPKCS10メッセージです。 この形式の登録要求が使用されているなら、署名、PKCS10 MUSTを生成することができる秘密鍵には、その秘密鍵を契約されてください。 登録要求のこのフォームがD-Hキーに使用されるなら、[DH-POP]で説明されたD-H POPメカニズムを使用しなければなりません。
Servers MUST support the Simple Enrollment Request message. If the Simple Enrollment Request message is used, servers MUST return the Simple Enrollment Response message (see Section 4.3) if the enrollment request is granted. If the enrollment request fails, the Full Enrollment Response MAY be returned or no response MAY be returned.
サーバはSimple Enrollment Requestメッセージをサポートしなければなりません。 Simple Enrollment Requestメッセージが使用されているなら、登録要求が承諾されるなら、サーバはSimple Enrollment Responseメッセージ(セクション4.3を見る)を返さなければなりません。 登録要求が失敗するなら、Full Enrollment Responseを返すかもしれませんか、または応答を全く返さないかもしれません。
Many advanced services specified in this memo are not supported by the Simple Enrollment Request message.
このメモで指定された多くの高度なサービスはSimple Enrollment Requestメッセージで後押しされていません。
4.2 Full PKI Request
4.2 完全なPKI要求
The Full Enrollment Request provides the most functionality and flexibility. Clients SHOULD use the Full Enrollment Request message when enrolling. Servers MUST support the Full Enrollment Request message. An enrollment response (full or simple as appropriate) MUST be returned to all Full Enrollment Requests.
Full Enrollment Requestは最も多くの機能性と柔軟性を提供します。 登録するとき、クライアントSHOULDはFull Enrollment Requestメッセージを使用します。 サーバはFull Enrollment Requestメッセージをサポートしなければなりません。 登録応答、(完全であるか簡単である、適切である、)、すべてのFull Enrollment Requestsに返さなければなりません。
The Full Enrollment Request message consists of a PKIData object wrapped in a signedData CMS object. The objects in the PKIData are ordered as follows:
Full Enrollment RequestメッセージはsignedData CMSオブジェクトで身を包まれたPKIDataオブジェクトから成ります。 以下の通りPKIDataのオブジェクトを注文します:
1. All Control Attributes, 2. All certification requests, 3. All CMS objects, 4. All other messages.
1. すべてが属性、2を制御します。 すべての証明要求、3。 すべてのCMSオブジェクト、4。 他のすべてのメッセージ。
Each element in a Full Enrollment Request is identified by a Body Part Identifier. If duplicate ids are found, the server MUST return the error badRequest with a bodyPartID of 0.
Full Enrollment Requestの各要素はBody Part Identifierによって特定されます。 写しイドが見つけられるなら、サーバは0のbodyPartIDと誤りbadRequestを返さなければなりません。
The signedData object wrapping the PKIData may be signed either by
the private key material of the signature certification request, or
by a previously certified signature key. If the private key of a
signature certification request is being used, then:
a) the certification request containing the corresponding public key
MUST include a Subject Key Identifier extension request,
b) the subjectKeyIdentifier form of signerInfo MUST be used, and
PKIDataを包装するsignedDataオブジェクトは署名証明要求の秘密鍵の材料、または以前に公認された署名キーによって署名されるかもしれません。 次に、署名証明要求の秘密鍵が使用されているなら: そしてa) 対応する公開鍵を含む証明要求がSubject Key Identifier拡大要求を含まなければならなくて、b) signerInfoのsubjectKeyIdentifierフォームを使用しなければならない。
Myers, et al. Standards Track [Page 13] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[13ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
c) the value of the subjectKeyIdentifier form of signerInfo MUST be
the Subject Key Identifier specified in the corresponding
certification request.
c) signerInfoのsubjectKeyIdentifierフォームの値は対応する証明要求で指定されたSubject Key Identifierでなければなりません。
(The subjectKeyIdentifier form of signerInfo is used here because no certificates have yet been issued for the signing key.) If the request key is used for signing, there MUST be only one signerInfo object in the signedData object.
(signerInfoのsubjectKeyIdentifierフォームは署名キーのためにまだ証明書を全く発行していないので、ここで使用されます。) 要求キーが署名に使用されるなら、1個のsignerInfoオブジェクトしかsignedDataオブジェクトにないに違いありません。
When creating a message to renew a certificate, the following should be taken into consideration:
証明書を更新するメッセージを作成するとき、以下は考慮に入れられるべきです:
1. The identification and identityProof control statements are not
required. The same information is provided by the use of an
existing certificate from the CA when signing the enrollment
message.
2. CAs and LRAs may impose additional restrictions on the signing
certificate used. They may require that the most recently issued
signing certificate for an entity be used.
3. A renewal message may occur either by creating a new set of keys,
or by re-using an existing set of keys. Some CAs may prevent re-
use of keys by policy. In this case the CA MUST return NOKEYREUSE
as the failure code.
1. 識別とidentityProof規制声明は必要ではありません。 登録メッセージに署名するとき、カリフォルニアから既存の証明書の使用で同じ情報を提供します。 2. CAsとLRAsは追加制限を使用される署名証明書に課すかもしれません。 彼らは、実体のための最も最近発行された署名証明書が使用されるのを必要とするかもしれません。 3. 更新メッセージは、新しいセットのキーを作成するか、または既存のセットのキーを再使用することによって、現れるかもしれません。 いくつかのCAsがキーの方針による再使用を防ぐかもしれません。 この場合、カリフォルニアは失敗コードとしてNOKEYREUSEを返さなければなりません。
4.3 Simple Enrollment Response
4.3 簡単な登録応答
Servers SHOULD use the simple enrollment response message whenever possible. Clients MUST be able to process the simple enrollment response message. The simple enrollment response message consists of a signedData object with no signerInfo objects on it. The certificates requested are returned in the certificate bag of the signedData object.
可能であるときはいつも、サーバSHOULDは簡単な登録応答メッセージを使用します。 クライアントは簡単な登録応答メッセージを処理できなければなりません。 簡単な登録応答メッセージはそれのsignerInfoオブジェクトなしでsignedDataオブジェクトから成ります。 signedDataオブジェクトの証明書バッグで要求された証明書を返します。
Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete chains to one or more self-signed certificates, not just the newly issued certificate(s). The server MAY additionally return CRLs in the CRL bag. Servers MAY include the self-signed certificates. Clients MUST NOT implicitly trust included self-signed certificate(s) merely due to its presence in the certificate bag. In the event clients receive a new self-signed certificate from the server, clients SHOULD provide a mechanism to enable the user to explicitly trust the certificate.
クライアントは、証明書が順不同であると仮定してはいけません。 サーバSHOULDは新譜の証明書だけではなく、1つ以上の自己署名入りの証書に完全なチェーンを形成するのに必要であるすべての中間的証明書を含んでいます。 サーバはCRLバッグでさらに、CRLsを返すかもしれません。 サーバは自己署名入りの証書を含むかもしれません。 クライアントは単に存在のため証明書バッグでそれとなく含まれている自己署名入りの証書を信じてはいけません。 イベントクライアントでは、サーバから新しい自己署名入りの証書を受け取ってください、とクライアントSHOULDはユーザが明らかに証明書を信じるのを可能にするためにメカニズムを前提とします。
Myers, et al. Standards Track [Page 14] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[14ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
4.4 Full PKI Response
4.4 完全なPKI応答
Servers MUST return full PKI response messages if a) a full PKI request message failed or b) additional services other than returning certificates are required. Servers MAY return full PKI responses with failure information for simple PKI requests. Following section 4.3 above, servers returning only certificates and a success status to the client SHOULD use the simple PKI response message.
a) 完全なPKI要求メッセージが失敗したか、または戻っている証明書以外のb)追加サービスが必要であるなら、サーバは完全なPKI応答メッセージを返さなければなりません。 サーバは簡単なPKI要求のための失敗情報がある完全なPKI応答を返すかもしれません。 以下の章4.3 上では、証明書と成功状態だけをクライアントSHOULDに返すサーバが簡単なPKI応答メッセージを使用します。
Clients MUST be able to process a full PKI response message.
クライアントは完全なPKI応答メッセージを処理できなければなりません。
The full enrollment response message consists of a signedData object encapsulating a responseBody object. In a responseBody object all Control Attributes MUST precede all CMS objects. The certificates granted in an enrollment response are returned in the certificates field of the immediately encapsulating signedData object.
完全な登録応答メッセージはresponseBodyオブジェクトをカプセルに入れるsignedDataオブジェクトから成ります。 responseBodyオブジェクトでは、すべてのControl AttributesがすべてのCMSオブジェクトに先行しなければなりません。 すぐに要約のsignedDataオブジェクトの証明書分野で登録応答で与えられた証明書を返します。
Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete chains one ore more self-signed certificates, not just the newly issued certificate(s). The server MAY additionally return CRLs in the CRL bag. Servers MAY include the self-signed certificates. Clients MUST NOT implicitly trust included self-signed certificate(s) merely due to its presence in the certificate bag. In the event clients receive a new self-signed certificate from the server, clients SHOULD provide a mechanism to enable the user to explicitly trust the certificate.
クライアントは、証明書が順不同であると仮定してはいけません。 サーバSHOULDは新譜の証明書だけではなく、証明書であると自己に署名されて、完全なチェーン1鉱石をさらに形成するのに必要であるすべての中間的証明書を含んでいます。 サーバはCRLバッグでさらに、CRLsを返すかもしれません。 サーバは自己署名入りの証書を含むかもしれません。 クライアントは単に存在のため証明書バッグでそれとなく含まれている自己署名入りの証書を信じてはいけません。 イベントクライアントでは、サーバから新しい自己署名入りの証書を受け取ってください、とクライアントSHOULDはユーザが明らかに証明書を信じるのを可能にするためにメカニズムを前提とします。
4.5 Application of Encryption to a PKI Message
4.5 PKIメッセージへの暗号化の応用
There are occasions where a PKI request or response message must be encrypted in order to prevent any information about the enrollment from being accessible to unauthorized entities. This section describes the means used to encrypt a PKI message. This section is not applicable to a simple enrollment message.
時が、登録のどんな情報も権限のない実体にアクセス可能であることを防ぐためにPKI要求か応答メッセージを暗号化しなければならないところにあります。 このセクションはPKIメッセージを暗号化するのに使用される手段を説明します。 このセクションは簡単な登録メッセージに適切ではありません。
Confidentiality is provided by wrapping the PKI message (a signedData object) in a CMS EnvelopedData object. The nested content type in the EnvelopedData is id-signedData. Note that this is different from S/MIME where there is a MIME layer placed between the encrypted and signed data objects. It is recommended that if an enveloped data layer is applied to a PKI message, a second signing layer be placed outside of the enveloped data layer. The following figure shows how this nesting would be done:
CMS EnvelopedDataオブジェクトでPKIメッセージ(signedDataオブジェクト)に身を包ませることによって、秘密性を提供します。 EnvelopedDataの入れ子にされたcontent typeはイド-signedDataです。 これが暗号化されて署名しているデータ・オブジェクトの間に置かれたMIME層があるS/MIMEと異なっていることに注意してください。 おおわれたデータ層がPKIメッセージに適用されるなら、それはそれに推薦されます、1秒がおおわれたデータの置かれた外部が層であったなら層に署名して。 以下の図は、この巣篭もりがどのように完了しているかを示します:
Myers, et al. Standards Track [Page 15] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[15ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
Normal Option 1 Option 2
------ -------- --------
SignedData EnvelopedData SignedData
PKIData SignedData EnvelopedData
PKIData SignedData
PKIData
通常のオプション1オプション2------ -------- -------- SignedData EnvelopedData SignedData PKIData SignedData EnvelopedData PKIData SignedData PKIData
Options 1 and 2 provide the benefit of preventing leakage of sensitive data by encrypting the information. LRAs can remove the enveloped data wrapping, and replace or forward without further processing. Section 6 contains more information about LRA processing.
オプション1と2は情報を暗号化することによって極秘データの漏出を防ぐ利益を提供します。 LRAsがおおわれたデータを取り除くことができる、包装して、取り替えるか、進めるさらなる処理なしで。 セクション6はLRA処理に関する詳しい情報を含みます。
PKI Messages MAY be encrypted or transmitted in the clear. Servers MUST provided support for all three versions.
PKI Messagesは明確で暗号化されるか、または伝えられるかもしれません。 サーバはすべての3つのバージョンのサポートであるならそうしなければなりません。
Alternatively, an authenticated, secure channel could exist between the parties requiring encryption. Clients and servers MAY use such channels instead of the technique described above to provide secure, private communication of PKI request and response messages.
あるいはまた、認証されて、安全なチャンネルは暗号化を必要とするパーティーの間に存在できました。 クライアントとサーバはPKI要求と応答メッセージの安全で、個人的なコミュニケーションを提供するために上で説明されたテクニックの代わりにそのようなチャンネルを使用するかもしれません。
5. Control Attributes
5. コントロール属性
Control attributes are carried as part of both PKI requests and responses. Each control attribute is encoded as a unique Object Identifier followed by that data for the control attribute. The encoding of the data is based on the control attribute object identifier. Processing systems would first detect the OID and process the corresponding attribute value prior to processing the message body.
コントロール属性はPKI要求と応答の両方の一部として運ばれます。 ユニークなObject Identifierがコントロール属性のためのそのデータで続いて、それぞれのコントロール属性はコード化されます。 データのコード化はコントロール属性オブジェクト識別子に基づいています。 メッセージ本体を処理する前に、処理システムは、最初に、OIDを検出して、対応する属性値を処理するでしょう。
The following table lists the names, OID and syntactic structure for each of the control attributes documented in this memo.
以下のテーブルはこのメモに記録されたそれぞれのコントロール属性のために名前、OID、および統語構造を記載します。
Myers, et al. Standards Track [Page 16] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[16ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
Control Attribute OID Syntax ----------------- ---------- -------------- cMCStatusInfo id-cmc 1 CMCStatusInfo identification id-cmc 2 UTF8String identityProof id-cmc 3 OCTET STRING dataReturn id-cmc 4 OCTET STRING transactionId id-cmc 5 INTEGER senderNonce id-cmc 6 OCTET STRING recipientNonce id-cmc 7 OCTET STRING addExtensions id-cmc 8 AddExtensions encryptedPOP id-cmc 9 EncryptedPOP decryptedPOP id-cmc 10 DecryptedPOP lraPOPWitness id-cmc 11 LraPOPWitness getCert id-cmc 15 GetCert getCRL id-cmc 16 GetCRL revokeRequest id-cmc 17 RevokeRequest regInfo id-cmc 18 OCTET STRING responseInfo id-cmc 19 OCTET STRING QueryPending id-cmc 21 OCTET STRING idPOPLinkRandom id-cmc 22 OCTET STRING idPOPLinkWitness id-cmc 23 OCTET STRING idConfirmCertAcceptance id-cmc 24 CMCCertId
規制属性OID構文----------------- ---------- -------------- 1CMCStatusInfoのcMCStatusInfoイド-cmc識別イド-cmc2UTF8String identityProofイド-cmc3OCTET STRING dataReturnイド-cmc4OCTET STRING transactionIdイド-cmc5INTEGER senderNonceイド-cmc6OCTET STRING recipientNonceイド-cmc7OCTET STRING addExtensionsイド-cmc8AddExtensions encryptedPOPイド-cmc9EncryptedPOP decryptedPOPイド-cmc10DecryptedPOP; lraPOPWitnessイド-cmc11LraPOPWitness getCertイド-cmc15GetCert getCRLイド-cmc16GetCRL revokeRequestイド-cmc17RevokeRequest regInfoイド-cmc18OCTET STRING responseInfoイド-cmc19OCTET STRING QueryPendingイド-cmc21OCTET STRING idPOPLinkRandomイド-cmc22OCTET STRING idPOPLinkWitnessイド-cmc23OCTET STRING idConfirmCertAcceptanceイド-cmc24CMCCertId
5.1 CMC Status Info Control Attribute
5.1 CMC状態インフォメーションコントロール属性
The CMC status info control is used in full PKI Response messages to return information on a client request. Servers MAY emit multiple CMC status info controls referring to a single body part. Clients MUST be able to deal with multiple CMC status info controls in a response message. This statement uses the following ASN.1 definition:
CMC状態インフォメーションコントロールはクライアント要求の情報を返す完全なPKI Responseメッセージで使用されます。 サーバはただ一つの身体の部分について言及する複数のCMC状態インフォメーションコントロールを放つかもしれません。 クライアントは応答メッセージにおける複数のCMC状態インフォメーションコントロールに対処できなければなりません。 この声明は以下のASN.1定義を使用します:
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
CMCStatusInfo:、:= 系列cMCStatus CMCStatus、BodyPartIDのbodyList系列サイズ(1..MAX)、任意のstatusString UTF8String otherInfo選択、failInfo CMCFailInfo、pendInfo PendInfo、任意
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
PendInfo:、:= 系列pendToken八重奏ストリング、pendTime GeneralizedTime
Myers, et al. Standards Track [Page 17] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[17ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
-- cMCStatus is described in section 5.1.1
-- cMCStatusはセクション5.1.1で説明されます。
-- bodyList contains the list of body parts in the request message
to which this status information applies. If an error is being
returned for a simple enrollment message, body list will contain a
single integer of value '1'.
-- bodyListはこの状態情報が適用される要求メッセージに身体の部分のリストを含んでいます。 誤りが簡単な登録メッセージのために返されると、ボディーリストは価値'1'のただ一つの整数を含むでしょう。
-- statusString contains a string with additional description
information. This string is human readable.
-- statusStringは追加記述情報があるストリングを含んでいます。 このストリングは読み込み可能な状態で人間です。
-- failInfo is described in section 5.1.2. It provides a detailed
error on what the failure was. This choice is present only if
cMCStatus is failed.
-- failInfoはセクション5.1.2で説明されます。 それは失敗が何であったかに関して詳細な誤りを提供します。 cMCStatusが失敗されている場合にだけ、この選択は存在しています。
-- pendToken is the token to be used in the queryPending control
attribute.
-- pendTokenはqueryPendingコントロール属性に使用されるべきトークンです。
-- pendTime contains the suggested time the server wants to be
queried about the status of the request.
-- pendTimeはサーバを要求の状態に関して質問されたい提案された時を含んでいます。
If the cMCStatus field is success, the CMC Status Info Control MAY be omitted unless it is only item in the response message. If no status exists for a certificate request or other item requiring processing, then the value of success is to be assumed.
CMC Status Info ControlはcMCStatus分野が成功であり、それが項目であるだけではないなら応答メッセージで省略されるかもしれません。 状態が全く処理するのを必要とする証明書要求か他の項目のために存在していないなら、成功の値は想定されることです。
5.1.1 CMCStatus values
5.1.1 CMCStatus値
CMCStatus is a field in the CMCStatusInfo structure. This field contains a code representing the success or failure of a specific operation. CMCStatus has the ASN.1 structure of:
CMCStatusはCMCStatusInfo構造の分野です。 この分野は特定の操作の成否を表すコードを含んでいます。 CMCStatusには、以下のASN.1構造があります。
CMCStatus ::= INTEGER {
success (0),
-- request was granted
-- reserved (1),
-- not used, defined where the original structure was defined
failed (2),
-- you don't get what you want, more information elsewhere in
the message
pending (3),
-- the request body part has not yet been processed,
-- requester is responsible to poll back on this
-- pending may only be return for certificate request
operations.
noSupport (4),
-- the requested operation is not supported
confirmRequired (5)
CMCStatus:、:= INTEGER、要求が承諾されたという成功(0)は(1)を予約しました--使用されていなくて、元の構造が失敗されていた状態で定義されたところで定義されて、あなたは欲しいものを得ません、(3)までメッセージのほかの場所の詳しい情報--要求身体の部分はまだ処理されていません--リクエスタがこれで投票するのにおいて原因となるという未定の(2)は証明書要求操作noSupport(4)のためのリターンであるにすぎないかもしれません--要求された操作はconfirmRequiredであるとサポートされません。(5)
Myers, et al. Standards Track [Page 18] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[18ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
-- conformation using the idConfirmCertAcceptance control is
required
-- before use of certificate
}
-- idConfirmCertAcceptanceコントロールを使用する組織が証明書の使用の前に必要です。
5.1.2 CMCFailInfo
5.1.2 CMCFailInfo
CMCFailInfo conveys information relevant to the interpretation of a failure condition. The CMCFailInfo has the following ASN.1 structure:
CMCFailInfoは失敗状態の解釈に関連している情報を伝えます。 CMCFailInfoには、以下のASN.1構造があります:
CMCFailInfo ::= INTEGER {
badAlg (0)
-- Unrecognized or unsupported algorithm
badMessageCheck (1)
-- integrity check failed
badRequest (2)
-- transaction not permitted or supported
badTime (3)
-- Message time field was not sufficiently close to the system
time
badCertId (4)
-- No certificate could be identified matching the provided
criteria
unsuportedExt (5)
-- A requested X.509 extension is not supported by the
recipient CA.
mustArchiveKeys (6)
-- Private key material must be supplied
badIdentity (7)
-- Identification Attribute failed to verify
popRequired (8)
-- Server requires a POP proof before issuing certificate
popFailed (9)
-- POP processing failed
noKeyReuse (10)
-- Server policy does not allow key re-use
internalCAError (11)
tryLater (12)
}
CMCFailInfo:、:= 整数{ badAlg(0)--認識されていないかサポートされないアルゴリズムbadMessageCheck(1)--保全チェックはbadRequest(2)に失敗しました--トランザクションは、badTimeが(3)であると許可もしませんでしたし、サポートもしませんでした--メッセージ時間分野がシステム時間badCertId(4)の十分近くにありませんでした--提供された評価基準unsuportedExt(5)を合わせながら、証明書を全く特定できませんでした; 要求されたX.509拡張子はカリフォルニア受取人mustArchiveKeys(6)によってサポートされません--badIdentity(7)を秘密鍵の材料に供給しなければなりません--識別AttributeはpopRequired(8)について確かめませんでした--証明書popFailed(9)を発行します--POP処理の失敗したnoKeyReuse(10)--サーバ方針が主要な再使用internalCAError(11)tryLater(12)を許容しない前にサーバはPOP証拠を必要とします; }
Additional failure reasons MAY be defined for closed environments with a need.
追加失敗理由は閉じている環境のために必要性をもって定義されるかもしれません。
Myers, et al. Standards Track [Page 19] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[19ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
5.2 Identification and IdentityProof Control Attributes
5.2 識別とIdentityProofコントロール属性
Some CAs and LRAs require that a proof of identity be included in a certification request. Many different ways of doing this exist with different degrees of security and reliability. Most people are familiar with the request of a bank to provide your mother's maiden name as a form of identity proof.
いくつかのCAsとLRAsが、身元の証拠が証明要求に含まれているのを必要とします。 これをする多くの異なった方法が異なった度合いのセキュリティと信頼性で存在しています。 ほとんどの人々が銀行がアイデンティティ証拠のフォームとしてあなたの母親の旧姓を提供するという要求に詳しいです。
CMC provides one method of proving the client's identity based on a shared secret between the certificate requestor and the verifying authority. If clients support full request messages, clients MUST implement this method of identity proof. Servers MUST provide this method and MAY also have a bilateral method of similar strength available.
CMCは共有秘密キーに基づくクライアントのアイデンティティを立証する1つのメソッドを証明書要請者と検証権威の間に提供します。 クライアントが完全な要求メッセージをサポートするなら、クライアントはアイデンティティ証拠のこのメソッドを実装しなければなりません。 サーバは、このメソッドを提供しなければならなくて、また、有効な同様の強さの双方のメソッドを持っているかもしれません。
The CMC method starts with an out-of-band transfer of a token (the shared secret). The distribution of this token is beyond the scope of this document. The client then uses this token for an identity proof as follows:
CMCメソッドはトークン(共有秘密キー)のバンドで出かけている転送から始まります。 このトークンの分配はこのドキュメントの範囲を超えています。 次に、クライアントは以下のアイデンティティ証拠にこのトークンを使用します:
1. The reqSequence field of the PKIData object (encoded exactly as it
appears in the request message including the sequence type and
length) is the value to be validated.
2. A SHA1 hash of the token is computed.
3. An HMAC-SHA1 value is then computed over the value produced in
Step 1, as described in [HMAC], using the hash of the token from
Step 2 as the shared secret value.
4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the
value of the identityProof attribute.
1. PKIDataオブジェクト(ちょうど系列タイプと長さを含んでいて、要求メッセージに現れるように、コード化される)のreqSequence分野は有効にされるべき値です。 2. トークンのSHA1ハッシュは計算されます。 3. 次に、HMAC-SHA1値はStep1の生産物価値に関して計算されます、[HMAC]で説明されるように、共有秘密キー値としてStep2からトークンのハッシュを使用して。 4. そして、Step3からの160ビットのHMAC-SHA1結果はidentityProof属性の値としてコード化されます。
When the server verifies the identityProof attribute, it computes the HMAC-SHA1 value in the same way and compares it to the identityProof attribute contained in the enrollment request.
サーバがidentityProof属性について確かめるとき、それは、同様に、HMAC-SHA1値を計算して、登録要求に含まれたidentityProof属性とそれを比較します。
If a server fails the verification of an identityProof attribute and the server returns a response message, the failInfo attribute MUST be present in the response and MUST have a value of badIdentity.
サーバがidentityProof属性の検証に失敗して、サーバが応答メッセージを返すなら、failInfo属性は、応答で存在していなければならなくて、badIdentityの値を持たなければなりません。
Optionally, servers MAY require the inclusion of the unprotected identification attribute with an identification attribute. The identification attribute is intended to contain either a text string or a numeric quantity, such as a random number, which assists the server in locating the shared secret needed to validate the contents of the identityProof attribute. Numeric values MUST be converted to text string representations prior to encoding as UTF8-STRINGs in this attribute. If the identification control attribute is included in
任意に、サーバは識別属性で保護のない識別属性の包含を必要とするかもしれません。 識別属性はテキスト文字列か数値量のどちらかを含むつもりです、乱数のように。(それは、identityProof属性のコンテンツを有効にするのに必要である共有秘密キーの場所を見つけるのにサーバを助けます)。 数値はUTF8-STRINGsとしてのコード化の前にこの属性でテキスト文字列表現に転向しているに違いありません。 識別コントロール属性が中に含まれているなら
Myers, et al. Standards Track [Page 20] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[20ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
the message, the derivation of the shared secret in step 2 is altered so that the hash of the concatenation of the token and the identity value are hashed rather than just the token.
メッセージ、ステップ2における、共有秘密キーの派生が変更されるので、トークンの連結のハッシュとアイデンティティ値はまさしくトークンよりむしろ論じ尽くされます。
5.2.1 Hardware Shared Secret Token Generation
5.2.1ハードウェア共有秘密キートークン世代
The shared secret between the end-entity and the identity verify is sometimes transferred using a hardware device that generates a series of tokens based on some shared secret value. The user can therefore prove their identity by transferring this token in plain text along with a name string. The above protocol can be used with a hardware shared-secret token generation device by the following modifications:
何らかの共有秘密キー価値に基づく一連のトークンを生成するハードウェアデバイスを使用することで時々移されます終わり実体とアイデンティティの間の共有秘密キーが、確かめる。 したがって、ユーザは、名前ストリングに伴うプレーンテキストのこのトークンを移すことによって、彼らのアイデンティティを立証できます。 ハードウェア共有秘密キートークン世代デバイスと共に以下の変更で上のプロトコルを使用できます:
1. The identification attribute MUST be included and MUST contain the
hardware-generated token.
2. The shared secret value used above is the same hardware-generated
token.
3. All certification requests MUST have a subject name and the
subject name MUST contain the fields required to identify the
holder of the hardware token device.
1. 識別属性は、含まなければならなくて、ハードウェアで発生しているトークンを含まなければなりません。 2. 上で使用された共有秘密キー値は同じハードウェアで発生しているトークンです。 3. すべての証明要求には、対象の名前がなければなりません、そして、対象の名前はハードウェアトークンデバイスの所有者を特定するのに必要である分野を含まなければなりません。
5.3 Linking Identity and POP Information
5.3 アイデンティティと大衆的な情報をリンクすること。
In a PKI Full Request message identity information about the creator/author of the message is carried in the signature of the CMS SignedData object containing all of the certificate requests. Proof-of-possession information for key pairs requesting certification, however, is carried separately for each PKCS#10 or CRMF message. (For keys capable of generating a digital signature, the POP is provided by the signature on the PKCS#10 or CRMF request. For encryption-only keys the controls described in Section 5.7 below are used.) In order to prevent substitution-style attacks we must guarantee that the same entity generated both the POP and proof-of- identity information.
メッセージのクリエイター/作者のPKI Full Requestメッセージアイデンティティ情報では、CMS SignedDataオブジェクトの署名では、証明書要求のすべてを含んでいて、運ばれます。 しかしながら、証明を要求する主要な組所有物の証拠情報はそれぞれのPKCS#10かCRMFメッセージのために別々に運ばれます。 (デジタル署名を生成することができるキーにおいて、10かCRMFが要求するPKCS#における署名でPOPを提供します。 暗号化だけキーに関しては、以下のセクション5.7で説明されたコントロールは使用されています。) 私たちが、代替スタイル攻撃を防ぐために同じ実体が、両方がPOPと証拠であると生成したのを保証しなければならない、-、アイデンティティ情報について。
This section describes two mechanisms for linking identity and POP information: witness values cryptographically derived from the shared-secret (Section 5.3.1) and shared-secret/subject DN matching (Section 5.3.2). Clients and servers MUST support the witness value technique. Clients and servers MAY support shared-secret/subject DN matching or other bilateral techniques of similar strength. The idea behind both mechanisms is to force the client to sign some data into each certificate request that can be directly associated with the shared-secret; this will defeat attempts to include certificate requests from different entities in a single Full PKI Request message.
このセクションはアイデンティティとPOP情報をリンクするために2つのメカニズムについて説明します: 目撃者値は共有秘密キー(セクション5.3.1)と共有秘密キー/対象DNからマッチングを暗号で引き出しました(セクション5.3.2)。 クライアントとサーバは、目撃者値がテクニックであるとサポートしなければなりません。 クライアントとサーバは、共有秘密キー/対象が同様の強さのDNの合わせているか他の双方のテクニックであるとサポートするかもしれません。 両方のメカニズムの後ろの考えはクライアントを直接共有秘密キーに関連づけることができるそれぞれの証明書要求にいくつかのデータを署名させることです。 これはただ一つのFull PKI Requestメッセージの異なった実体からの証明書要求を含む試みを破るでしょう。
Myers, et al. Standards Track [Page 21] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[21ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
5.3.1 Witness values derived from the shared-secret
5.3.1 共有秘密キーから得られた目撃者値
The first technique for doing identity-POP linking works by forcing the client to include a piece of information cryptographically- derived from the shared-secret token as a signed extension within each certificate request (PKCS#10 or CRMF) message. This technique is useful if null subject DNs are used (because, for example, the server can generate the subject DN for the certificate based only on the shared secret). Processing begins when the client receives the shared-secret token out-of-band from the server. The client then computes the following values:
クライアントに署名している拡大としてそれぞれの証明書要求(PKCS#の10かCRMF)メッセージの中で共有秘密キートークンから暗号で得られた1つの情報を入れさせることによって、アイデンティティPOPリンクをするための最初のテクニックは利きます。 ヌル対象のDNsが使用されているなら(例えば、サーバが証明書のためのDNが共有秘密キーだけに基礎づけた対象を生成することができるので)、このテクニックは役に立ちます。 クライアントがバンドの外でサーバから共有秘密キートークンを受けるとき、処理は始まります。次に、クライアントは以下の値を計算します:
1. The client generates a random byte-string, R, which SHOULD be at
least 512 bits in length.
2. A SHA1 hash of the token is computed.
3. An HMAC-SHA1 value is then computed over the random value produced
in Step 1, as described in [HMAC], using the hash of the token
from Step 2 as the shared secret.
4. The random value produced in Step 1 is encoded as the value of an
idPOPLinkRandom control attribute. This control attribute MUST be
included in the Full PKI Request message.
5. The 160-bit HMAC-SHA1 result from Step 3 is encoded as the value
of an idPOPLinkWitness extension to the certificate request.
a. For CRMF, idPOPLinkWitness is included in the controls section
of the CertRequest structure.
b. For PKCS#10, idPOPLinkWitness is included in the attributes
section of the CertificationRequest structure.
1. クライアントは、中の少なくとも512ビットが長さであったなら無作為のバイトストリング、RがどのSHOULDであるかと生成します。 2. トークンのSHA1ハッシュは計算されます。 3. 次に、HMAC-SHA1値はStep1の無作為の生産物価値に関して計算されます、[HMAC]で説明されるように、共有秘密キーとしてStep2からトークンのハッシュを使用して。 4. Step1の無作為の生産物価値はidPOPLinkRandomコントロール属性の値としてコード化されます。 Full PKI Requestメッセージにこのコントロール属性を含まなければなりません。 5. Step3からの160ビットのHMAC-SHA1結果はidPOPLinkWitness拡張子の値として証明書要求にコード化されます。. a。 CRMFに関しては、含まれていたidPOPLinkWitnessはCertRequestの規制部で. bを構造化します。 PKCS#10において、idPOPLinkWitnessはCertificationRequest構造の属性部に含まれています。
Upon receipt, servers MUST verify that each certificate request contains a copy of the idPOPLinkWitness and that its value was derived in the specified manner from the shared secret and the random string included in the idPOPLinkRandom control attribute.
領収書では、サーバは値がそれぞれの証明書要求がidPOPLinkWitnessのコピーを含んでいて、共有秘密キーから指定された方法で引き出されて、idPOPLinkRandomコントロール属性に無作為のストリングを含んでいたことであることを確かめなければなりません。
5.3.2 Shared-secret/subject DN matching
5.3.2 共有秘密キー/対象DNマッチング
The second technique for doing identity-POP linking is to link a particular subject distinguished name (subject DN) to the shared- secrets that are distributed out-of-band and to require that clients using the shared-secret to prove identity include that exact subject DN in every certificate request. It is expected that many client- server connections using shared-secret based proof-of-identity will use this mechanism. (It is common not to omit the subject DN information from the certificate request messages.)
アイデンティティPOPリンクをするための2番目のテクニックは、特定の対象の分類名(対象のDN)をバンドの外で分配される共有された秘密にリンクして、アイデンティティを立証するのに共有秘密キーを使用しているクライアントがあらゆる証明書要求でその正確な対象DNを入れるのが必要であることです。 身元の共有されて秘密のベースの証拠を使用している多くのクライアントサーバ接続がこのメカニズムを使用すると予想されます。 (証明書要求メッセージからの対象のDN情報を省略しないのは一般的です。)
When the shared secret is generated and transferred out-of-band to initiate the registration process (Section 5.2), a particular subject DN is also associated with the shared secret and communicated to the client. (The subject DN generated MUST be unique per entity in
登録手続(セクション5.2)に着手するためにバンドの外に共有秘密キーを生成して、移すとき、特定の対象のDNをまた、共有秘密キーに関連づけて、クライアントに伝えます。 (DNが生成した対象は中の実体単位でユニークであるに違いありません。
Myers, et al. Standards Track [Page 22] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[22ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
accordance with CA policy; a null subject DN cannot be used. A common practice could be to place the identification value as part of the subject DN.) When the client generates the Full PKI Request message, it MUST use these two pieces of information as follows:
カリフォルニア方針がある一致。 ヌル対象のDNを使用できません。 一般的な習慣は対象のDNの一部として識別値を置くことになっているかもしれません。) クライアントがFull PKI Requestメッセージを生成すると、以下の2つの情報を使用しなければなりません:
1. The client MUST include the specific subject DN that it received
along with the shared secret as the subject name in every
certificate request (PKCS#10 and/or CRMF) in the Full PKI Request.
The subject names in the requests MUST NOT be null.
2. The client MUST include the identityProof control attribute
(Section 5.2), derived from the shared secret, in the Full PKI
Request.
1. クライアントはFull PKI Requestでのあらゆる証明書要求(PKCS#の10、そして/または、CRMF)でそれが共有秘密キーと共に対象の名前として受けた特定の対象のDNを入れなければなりません。 要求における対象の名前はヌルであるはずがありません。 2. クライアントはFull PKI Requestで共有秘密キーから得られたidentityProofコントロール属性(セクション5.2)を入れなければなりません。
The server receiving this message MUST (a) validate the identityProof control attribute and then, (b) check that the subject DN included in each certificate request matches that associated with the shared secret. If either of these checks fails the certificate request MUST be rejected.
このメッセージを受け取るサーバはチェックしなければなりません。(a) identityProofコントロール属性を有効にしてください、そして、次に、(b) 各証明書にDNを含んでいる対象が共有秘密キーと交際したマッチを要求するのをチェックしてください。 これらのチェックのどちらかが失敗するなら、証明書要求を拒絶しなければなりません。
5.3.3 Renewal and Re-Key Messages
5.3.3 更新と再主要なメッセージ
In a renewal or re-key message, the subject DN in (a) the certificate referenced by the CMS SignerInfo object, and (b) all certificate requests within the request message MUST match according to the standard name match rules described in [PKIXCERT].
(b) 更新か再主要なメッセージでは、(a) CMS SignerInfoによって参照をつけられた証明書の対象のDNは反対します、そして、マッチという規則が[PKIXCERT]で説明した標準の名前によると、要求メッセージの中のすべての証明書要求が合わなければなりません。
5.4 Data Return Control Attribute
5.4のデータがコントロール属性を返します。
The data return control attribute allows clients to send arbitrary data (usually some type of internal state information) to the server and to have the data returned as part of the enrollment response message. Data placed in a data return statement is considered to be opaque to the server. The same control is used for both requests and responses. If the data return statement appears in an enrollment message, the server MUST return it as part of the enrollment response message.
データリターンコントロール属性で、クライアントに任意のデータ(通常タイプの内部の州の情報)をサーバに送って、登録応答メッセージの一部としてデータを返させます。 データリターン声明に置かれたデータがサーバに不伝導性であると考えられます。同じコントロールは要求と応答の両方に使用されます。 データリターン声明が登録メッセージに現れるなら、サーバは登録応答メッセージの一部としてそれを返さなければなりません。
In the event that the information in the data return statement needs to be confidential, it is expected that the client would apply some type of encryption to the contained data, but the details of this are outside the scope of this specification.
データリターン声明の情報が、秘密である必要がある場合、クライアントがタイプの暗号化を含まれたデータに適用すると予想されますが、この仕様の範囲の外にこの詳細があります。
An example of using this feature is for a client to place an identifier marking the exact source of the private key material. This might be the identifier of a hardware device containing the private key.
この特徴を使用する例はクライアントが識別子を置いて、秘密鍵の材料の正確な源を示すことです。 これは秘密鍵を含むハードウェアデバイスに関する識別子であるかもしれません。
Myers, et al. Standards Track [Page 23] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[23ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
5.5 Add Extensions Control Attribute
5.5は、拡大コントロールが結果と考えると言い足します。
The Add Extensions control attribute is used by LRAs in order to specify additional extensions that are to be placed on certificates. This attribute uses the following ASN.1 definition:
Add Extensionsコントロール属性は、証明書に置かれることになっている追加拡大を指定するのにLRAsによって使用されます。 この属性は以下のASN.1定義を使用します:
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
AddExtensions:、:= 系列pkiDataReference BodyPartID certReferences SEQUENCE OF BodyPartID、拡大SEQUENCE OF Extension
-- pkiDataReference field contains the body part id of the
embedded request message.
-- pkiDataReference分野は埋め込まれた要求メッセージのボディー部分イドを含んでいます。
-- certReferences field is a list of references to one or more of
the payloads contained within a PKIData. Each element of the
certReferences sequence MUST be equal to either the bodyPartID of
a TaggedCertificationRequest or the certReqId of the CertRequest
within a CertReqMsg. By definition, the listed extensions are to
be applied to every element referenced in the certReferences
sequence. If a request corresponding to bodyPartID cannot be
found, the error badRequest is returned referencing this control
attribute.
-- certReferences分野はPKIDataの中に含まれたペイロードの1つ以上への参考文献一覧です。 certReferences系列のそれぞれの原理はCertReqMsgの中でTaggedCertificationRequestのbodyPartIDかCertRequestのcertReqIdのどちらかと等しいに違いありません。 定義上、記載された拡大はcertReferences系列で参照をつけられるあらゆる要素に適用されることです。 bodyPartIDに対応する要求を見つけることができないなら、このコントロール属性に参照をつけながら、誤りbadRequestを返します。
-- extensions field contains the sequence of extensions to be
applied to the referenced certificate requests.
-- 拡大分野は参照をつけられた証明書要求に適用されるべき拡大の系列を含んでいます。
Servers MUST be able to process all extensions defined in [PKIXCERT]. Servers are not required to be able to process every V3 X.509 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all LRA-requested extensions into a certificate. Servers are permitted to modify LRA-requested extensions. Servers MUST NOT alter an extension so as to reverse the meaning of a client-requested extension If a certification request is denied due to the inability to handle a requested extension and a response is returned, the server MUST return a failInfo attribute with the value of unsupportedExt.
サーバは[PKIXCERT]で定義されたすべての拡大を処理できなければなりません。 サーバはこのプロトコルを使用することで伝えられたあらゆるV3 X.509拡張子を処理できるように必要ではありません、そして、それらは他の、そして、個人的な拡大を処理する必要はないことができます。 サーバは、すべてのLRAによって要求された拡大を証明書に入れるのに必要ではありません。 サーバがLRAによって要求された拡大を変更することが許可されています。 サーバは証明要求が要求された拡大を扱うことができないことのため否定されるクライアントによって要求された拡大Ifの意味を逆にするために拡大を変更してはいけません、そして、応答を返します、そして、サーバはunsupportedExtの値があるfailInfo属性を返さなければなりません。
If multiple Add Extensions statements exist in an enrollment message, the exact behavior is left up to the certificate issuer policy. However it is recommended that the following policy be used. These rules would be applied to individual extensions within an Add Extensions control attribute (as opposed to an "all or nothing" approach).
複数のAdd Extensions声明が登録メッセージに存在しているなら、正確な振舞いは証明書発行人方針に任せられます。 しかしながら、以下の方針が使用されるのは、お勧めです。 これらの規則はAdd Extensionsコントロール属性(「すべてか何でもない」アプローチと対照的に)の中で個々の拡大に適用されるでしょう。
Myers, et al. Standards Track [Page 24] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[24ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
1. If the conflict is within a single PKIData object, the certificate
request would be rejected with an error of badRequest.
1. 単一のPKIDataオブジェクトの中に闘争があるなら、証明書要求はbadRequestの誤りで拒絶されるでしょう。
2. If the conflict is between different PKIData objects, the
outermost version of the extension would be used (allowing an LRA
to override the extension requested by the end-entyt).
2. 異なったPKIDataオブジェクトの間には、闘争があるなら、拡大の一番はずれのバージョンは使用されるでしょう(LRAが終わり-entytによって要求された拡大をくつがえすのを許容します)。
5.6 Transaction Management Control Attributes
5.6 トランザクション管理コントロール属性
Transactions are identified and tracked using a transaction identifier. If used, clients generate transaction identifiers and retain their value until the server responds with a message that completes the transaction. Servers correspondingly include received transaction identifiers in the response.
トランザクションは、トランザクション識別子を使用することで特定されて、追跡されます。 使用されるなら、サーバが取引を完了するメッセージで反応するまで、クライアントは、トランザクション識別子を生成して、それらの値を保有します。 サーバは応答に受信されたトランザクション識別子を対応する含んでいます。
The transactionId attribute identifies a given transaction. It is used between client and server to manage the state of an operation. Clients MAY include a transactionID attribute in request messages. If the original request contains a transactionID attribute, all subsequent request and response messages MUST include the same transactionID attribute. A server MUST use only transactionIds in the outermost PKIdata object. TransactionIds on inner PKIdata objects are for intermediate entities.
transactionId属性は与えられたトランザクションを特定します。 それは、操作の状態を経営するのにクライアントとサーバの間で使用されます。 クライアントは要求メッセージでtransactionID属性を入れるかもしれません。 オリジナルの要求がtransactionID属性を含んでいるなら、すべてのその後の要求と応答メッセージは同じtransactionID属性を含まなければなりません。 サーバは一番はずれのPKIdataオブジェクトでtransactionIdsだけを使用しなければなりません。 内側のPKIdataオブジェクトの上のTransactionIdsは中間的実体のためのものです。
Replay protection can be supported through the use of sender and recipient nonces. If nonces are used, in the first message of a transaction, no recipientNonce is transmitted; a senderNonce is instantiated by the message originator and retained for later reference. The recipient of a sender nonce reflects this value back to the originator as a recipientNonce and includes it's own senderNonce. Upon receipt by the transaction originator of this message, the originator compares the value of recipientNonce to its retained value. If the values match, the message can be accepted for further security processing. The received value for senderNonce is also retained for inclusion in the next message associated with the same transaction.
送付者と受取人一回だけの使用で反復操作による保護をサポートすることができます。 一回だけがトランザクションの最初のメッセージで使用されるなら、recipientNonceは全く伝えられません。 senderNonceはメッセージ創始者によって例示されて、後の参照のために保有されます。 送付者一回だけの受取人は、recipientNonceとしてこの値を創始者に映し出して、それの自身のsenderNonceを入れます。 このメッセージのトランザクション創始者による領収書では、創始者はrecipientNonceの値を保有された値と比較します。 値が合っているなら、さらなるセキュリティ処理のためにメッセージを受け入れることができます。 また、senderNonceのための容認された値は同じトランザクションに関連している次のメッセージでの包含のために保有されます。
The senderNonce and recipientNonce attribute can be used to provide application-level replay prevention. Clients MAY include a senderNonce in the initial request message. Originating messages include only a value for senderNonce. If a message includes a senderNonce, the response MUST include the transmitted value of the previously received senderNonce as recipientNonce and include new value for senderNonce. A server MUST use only nonces in the outermost PKIdata object. Nonces on inner PKIdata objects are for intermediate entities.
アプリケーションレベル再生防止を提供するのにsenderNonceとrecipientNonce属性を使用できます。 クライアントは初期の要求メッセージでsenderNonceを入れるかもしれません。 起因するメッセージはsenderNonceのための値だけを含んでいます。 メッセージがsenderNonceを含んでいるなら、応答は、recipientNonceとして以前に容認されたsenderNonceの伝えられた値を含んでいて、senderNonceのために新しい値を含まなければなりません。 サーバは一番はずれのPKIdataオブジェクトで一回だけだけを使用しなければなりません。 内側のPKIdataオブジェクトの上の一回だけは中間的実体のためのものです。
Myers, et al. Standards Track [Page 25] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[25ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
5.7 Proof-of-possession (POP) for encryption-only keys
5.7 暗号化だけキーのための所有物の証拠(POP)
Everything described in this section is optional to implement, for both servers and clients. Servers MAY require this POP method be used only if another POP method is unavailable. Servers SHOULD reject all requests contained within a PKIData if any required POP is missing for any element within the PKIData.
このセクションで説明されたすべてが、サーバとクライアントの両方のために実装するために任意です。 サーバはこのPOPメソッドを必要とするかもしれません。別のPOPメソッドが入手できない場合にだけ、使用されます。 サーバSHOULDはPKIDataの中のどんな要素においても、どれか必要なPOPがなくなるならPKIDataの中に含まれたすべての要求を拒絶します。
Many servers require proof that an entity requesting a certificate for a public key actually possesses the corresponding private component of the key pair. For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair. With keys that can only be used for encryption operations, POP MUST be performed by forcing the client to decrypt a value. See Section 5 of [CRMF] for a detailed discussion of POP.
多くのサーバが公開鍵のための証明書を要求する実体が実際に主要な組の対応する個人的なコンポーネントを持っているという証拠を必要とします。 署名キーとして使用できるキーに関しては、証明要求と秘密鍵を契約するのはその主要な組のPOPとして機能します。 暗号化操作に使用できるだけであるキーで、クライアントに値を解読させることによって、POPを実行しなければなりません。 POPの詳細な論議に関して[CRMF]のセクション5を見てください。
By necessity, POP for encryption-only keys cannot be done in one round-trip, since there are four distinct phases:
4つの異なったフェーズがあるので、必要に迫られて、1で往復であることで暗号化だけキーのためのPOPができません:
1. Client tells the server about the public component of a new
encryption key pair.
2. Server sends the client a POP challenge, encrypted with the
presented public encryption key, which the client must decrypt.
3. Client decrypts the POP challenge and sends it back to the server.
4. Server validates the decrypted POP challenge and continues
processing the certificate request.
1. クライアントは新しい暗号化主要な組の公共のコンポーネントに関するサーバを言います。 2. サーバはクライアントが解読しなければならない提示された公共の暗号化キーで暗号化されたPOP挑戦をクライアントに送ります。 3. クライアントは、POPが挑戦であると解読して、それをサーバに送り返します。. 4。 サーバは、解読されたPOP挑戦を有効にして、証明書要求を処理し続けています。
CMC defines two different attributes. The first deals with the encrypted challenge sent from the server to the user in step 2. The second deals with the decrypted challenge sent from the client to the server in step 3.
CMCは2つの異なった属性を定義します。 暗号化された挑戦との最初の取引はステップ2でサーバからユーザまで発信しました。 秒はステップ3でクライアントからサーバに送られた解読された挑戦に対処します。
The encryptedPOP attribute is used to send the encrypted challenge from the server to the client. As such, it is encoded as a tagged attribute within the controlSequence of a ResponseBody. (Note that we assume that the message sent in Step 1 above is an enrollment request and that the response in step 2 is a Full Enrollment Response including a failureInfo specifying that a POP is explicitly required, and providing the POP challenge in the encryptedPOP attribute.)
encryptedPOP属性は、暗号化された挑戦をサーバからクライアントに送るのに使用されます。 そういうものとして、それはタグ付けをされた属性としてResponseBodyのcontrolSequenceの中でコード化されます。 (私たちがStep1で上に送られたメッセージが登録要求であり、ステップ2における応答がPOPが明らかに必要であると指定するfailureInfoを含んで、POP挑戦をencryptedPOP属性に提供するFull Enrollment Responseであると思うことに注意してください。)
EncryptedPOP ::= SEQUENCE {
EncryptedPOP:、:= 系列
request TaggedRequest,
cms contentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
TaggedRequest(cm contentInfo、thePOPAlgID AlgorithmIdentifier、witnessAlgID AlgorithmIdentifier)がOCTET STRINGを目撃するよう要求してください。
Myers, et al. Standards Track [Page 26] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[26ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
}
}
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
DecryptedPOP:、:= 系列bodyPartID BodyPartID、thePOPAlgID AlgorithmIdentifier、thePOP八重奏ストリング
The encrypted POP algorithm works as follows:
暗号化されたPOPアルゴリズムは以下の通り利きます:
1. The server generates a random value y and associates it with the
request.
2. The server returns the encrypted pop with the following fields
set:
a. request is the certificate request in the original request
message (it is included here so the client need not key a copy
of the request),
b. cms is an EnvelopedData object, the content type being id-data
and the content being the value y. If the certificate request
contains a subject key identifier (SKI) extension, then the
recipient identifier SHOULD be the SKI. If the
issuerAndSerialNumber form is used, the IsserName MUST be
encoded as NULL and the SerialNumber as the bodyPartId of the
certificate request,
c. thePOPAlgID contains the algorithm to be used in computing the
return POP value,
d. witnessAlgID contains the hash algorithm used on y to create
the field witness,
e. witness contains the hashed value of y.
3. The client decrypts the cms field to obtain the value y. The
client computes H(y) using the witnessAlgID and compares to the
value of witness. If the values do not compare or the decryption
is not successful, the client MUST abort the enrollment process.
The client aborts the process by sending a request message
containing a CMCStatusInfo control attribute with failInfo value
of popFailed.
4. The client creates the decryptedPOP as part of a new PKIData
message. The fields in the decryptedPOP are:
a. bodyPartID refers to the certificate request in the new
enrollment message,
b. thePOPAlgID is copied from the encryptedPOP,
c. thePOP contains the possession proof. This value is computed
by thePOPAlgID using the value y and request referenced in
(4a).
5. The server then re-computes the value of thePOP from its cached
value of y and the request and compares to the value of thePOP.
If the values do not match, the server MUST NOT issue the
certificate. The server MAY re-issue a new challenge or MAY fail
1. サーバは、無作為の値がyであると生成して、それを要求に関連づけます。 2. 以下がある暗号化されたポップスがさばくサーバリターンはセットしました: a. b.cmによる要求はオリジナルの要求メッセージで証明書要求(それがここで入れられているので、クライアントは要求のコピーを合わせる必要はありません、)であり、EnvelopedDataオブジェクトと、イドデータであるcontent typeと値yである内容です。 要求は証明書であるなら対象の主要な識別子(SKI)拡張子を含んでいて、次に、受取人識別子はSHOULDです。SKIになってください。 issuerAndSerialNumberフォームが使用されているなら、証明書要求のbodyPartIdとしてのNULLとSerialNumberとしてIsserNameをコード化しなければならなくて、c.thePOPAlgIDはリターンPOP価値を計算する際に使用されるべきアルゴリズムを含んでいて、d.witnessAlgIDは分野目撃者を創造するのにyで使用されるハッシュアルゴリズムを含んでいて、e.目撃者はyの論じ尽くされた値を含みます。 3. クライアントは、cmが値yを得る分野であると解読します。 クライアントは、witnessAlgIDを使用することでH(y)を計算して、目撃者の値と比較します。 値が比較されないか、または復号化がうまくいかないなら、クライアントは登録プロセスを中止しなければなりません。 クライアントは、popFailedのfailInfo値でCMCStatusInfoコントロール属性を含む要求メッセージを送ることによって、プロセスを中止します。 4. クライアントは新しいPKIDataメッセージの一部としてdecryptedPOPを作成します。 decryptedPOPの分野は以下の通りです。 a. bodyPartIDは新規加入メッセージにおける証明書要求を示して、b.thePOPAlgIDはencryptedPOPからコピーされて、c.thePOPは所有物証拠を含んでいます。 この値は、中で参照をつけられた値yと要求を使用することでthePOPAlgIDによって計算されます。(4a)。 5. サーバは、次に、yのキャッシュされた値と要求からthePOPの値を再計算して、thePOPの値と比較されます。 値が合っていないなら、サーバは証明書を発行してはいけません。 サーバは、新しい挑戦を再発行するか、または失敗するかもしれません。
Myers, et al. Standards Track [Page 27] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[27ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
the request altogether.
全体で要求。
When defining the algorithms for thePOPAlgID and witnessAlgID care must be taken to ensure that the result of witnessAlgID is not a useful value to shortcut the computation with thePOPAlgID. Clients MUST implement SHA-1 for witnessAlgID. Clients MUST implement HMAC- SHA1 for thePOPAlgID. The value of y is used as the secret value in the HMAC algorithm and the request referenced in (4a) is used as the data. If y is greater than 64 bytes, only the first 64 bytes of y are used as the secret.
witnessAlgIDの結果がa役に立たないのを保証するためにthePOPAlgIDのためにアルゴリズムを定義して、witnessAlgID注意を払わなければならないとき、thePOPAlgIDとの計算を近道に評価してください。 クライアントはwitnessAlgIDのためにSHA-1を実装しなければなりません。 クライアントはthePOPAlgIDのためにHMAC- SHA1を実装しなければなりません。 yの値は秘密の値としてHMACアルゴリズムと中で参照をつけられた要求で使用されます。(4a)はデータとして使用されます。 yが64バイト以上であるなら、最初の64バイトのyだけが秘密として使用されます。
One potential problem with the algorithm above is the amount of state that a CA needs to keep in order to verify the returned POP value. This describes one of many possible ways of addressing the problem by reducing the amount of state kept on the CA to a single (or small set) of values.
上であることのアルゴリズムの1つの潜在的な問題がカリフォルニアが返されたPOP値について確かめるために維持する必要がある状態の量です。 これはカリフォルニアに値のシングル(または、小さいセット)まで維持された状態の量を減少させることによって問題と取り組む多くの可能な方法の1つについて説明します。
1. Server generates random seed x, constant across all requests. (The
value of x would normally be altered on a regular basis and kept
for a short time afterwards.)
2. For certificate request R, server computes y = F(x,R). F can be,
for example, HMAC-SHA1(x,R). All that's important for
statelessness is that y be consistently computable with only known
state constant x and function F, other inputs coming from the cert
request structure. y should not be predictable based on knowledge
of R, thus the use of a OWF like HMAC-SHA1.
1. サーバはすべての要求の向こう側に一定の無作為の種子xを生成します。 (通常、xの値は、定期的に変更されて、その後、短い間保たれるでしょう。) 2. 証明書要求Rのために、サーバはy=F(x、R)を計算します。 例えば、FはHMAC-SHA1であるかもしれません(x、R)。 国がないことに、重要なすべてがyが知られている州の定数xと機能Fだけで一貫して計算できるということである、本命から来る他の入力は構造を要求します。yはその結果、Rに関する知識、HMAC-SHA1のようなOWFの使用に基づいて予測できるべきではありません。
5.8 LRA POP Witnesses Control Attribute
5.8 LRAの大衆的な目撃者は属性を制御します。
In an enrollment scenario involving an LRAs the CA may allow (or require) the LRA to perform the POP protocol with the entity requesting certification. In this case the LRA needs a way to inform the CA it has done the POP. This control attribute has been created to address this issue.
カリフォルニアが許容するかもしれないLRAsにかかわる登録シナリオ、(必要である、)、POPを実行するLRAは証明を要求する実体で議定書を作ります。 この場合、LRAはそれがPOPをしたカリフォルニアに知らせる方法を必要とします。 この問題を扱うためにこのコントロール属性を作成してあります。
The ASN.1 structure for the LRA POP witness is as follows:
LRA POP目撃者のためのASN.1構造は以下の通りです:
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID
}
LraPopWitness:、:= 系列pkiDataBodyid BodyPartID、BodyPartIDのbodyIds系列
-- pkiDataBodyid field contains the body part id of the nested CMS
body object containing the client's full request message.
pkiDataBodyid is set to 0 if the request is in the current
PKIRequest body.
-- pkiDataBodyid分野はクライアントの完全な要求メッセージを含む入れ子にされたCMSボディーオブジェクトのボディー部分イドを含んでいます。要求が現在のPKIRequestボディーにあるなら、pkiDataBodyidは0に用意ができています。
Myers, et al. Standards Track [Page 28] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[28ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
-- bodyIds contains a list of certificate requests for which the
LRA has performed an out-of-band authentication. The method of
authentication could be archival of private key material,
challenge-response or other means.
-- bodyIdsはLRAがバンドで出ている認証を実行した証明書要求のリストを含んでいます。 何らかのチャレンジレスポンスは、認証のメソッドが秘密鍵の材料で記録保管所であるかもしれないことを意味します。
If a certificate server does not allow for an LRA to do the POP verification, it returns an error of POPFAILURE. The CA MUST NOT start a challenge-response to re-verify the POP itself.
証明書サーバが、LRAがPOP検証をするのを許容しないなら、それはPOPFAILUREの誤りを返します。 カリフォルニアは、POP自体について再確かめるためにチャレンジレスポンスを始めてはいけません。
5.9 Get Certificate Control Attribute
5.9は証明書コントロール属性を得ます。
Everything described in this section is optional to implement.
このセクションで説明されたすべてが、実装するために任意です。
The get certificate control attribute is used to retrieve previously issued certificates from a repository of certificates. A Certificate Authority, an LRA or an independent service may provide this repository. The clients expected to use this facility are those operating in a resource-constrained environment. (An example of a resource-constrained client would be a low-end IP router that does not retain its own certificate in non-volatile memory.)
使用される証明書コントロール属性に証明書の倉庫からの以前に発行された証明書を検索させてください。 Certificate Authority、LRAまたは独立しているサービスがこの倉庫を提供するかもしれません。 この施設を使用すると予想されたクライアントはリソースで強制的な環境で作動するものです。 (リソースで強制的なクライアントの例は非揮発性メモリーでそれ自身の証明書を保有しないローエンドIPルータでしょう。)
The get certificate control attribute has the following ASN.1 structure:
以下のASN.1がコントロール属性で構造化する証明書を手に入れてください:
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
GetCert:、:= 系列issuerName GeneralName、serialNumber整数
The service responding to the request will place the requested certificate in the certificates field of a SignedData object. If the get certificate attribute is the only control in a Full PKI Request message, the response would be a Simple Enrollment Response.
要求に応じるサービスはSignedDataオブジェクトの証明書分野に要求された証明書を置くでしょう。 得てください。証明書属性はFull PKI Requestメッセージにおける唯一のコントロール、応答がSimple Enrollment Responseであるだろうということです。
5.10 Get CRL Control Attribute
5.10はCRLコントロール属性を得ます。
Everything described in this section is optional to implement.
このセクションで説明されたすべてが、実装するために任意です。
The get CRL control attribute is used to retrieve CRLs from a repository of CRLs. A Certification Authority, an LRA or an independent service may provide this repository. The clients expected to use this facility are those where a fully deployed directory is either infeasible or undesirable.
使用されるCRLコントロール属性にCRLsの倉庫からCRLsを検索させてください。 認証局、LRAまたは独立しているサービスがこの倉庫を提供するかもしれません。 この施設を使用すると予想されたクライアントは完全に配布しているディレクトリが実行不可能であるか、または望ましくないところのそれらです。
The get CRL control attribute has the following ASN.1 structure:
以下のASN.1構造を属性が持っているCRLコントロールに手に入れてください:
Myers, et al. Standards Track [Page 29] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[29ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
GetCRL:、:= 系列issuerName Name(cRLName GeneralName OPTIONAL、時間GeneralizedTime OPTIONAL)はReasonFlags OPTIONALを推論します。
The fields in a GetCRL have the following meanings:
GetCRLの分野には、以下の意味があります:
-- issuerName is the name of the CRL issuer.
-- issuerNameはCRL発行人の名前です。
-- cRLName may be the value of CRLDistributionPoints in the
subject certificate or equivalent value in the event the
certificate does not contain such a value.
-- cRLNameは対象の証明書か同等な値における、証明書が含まないイベントにおける、CRLDistributionPointsの値がそのような値であったならそうするかもしれません。
-- time is used by the client to specify from among potentially
several issues of CRL that one whose thisUpdate value is less than
but nearest to the specified time. In the absence of a time
component, the CA always returns with the most recent CRL.
-- 時間は、潜在的にCRLのいくつかの問題から指定された時間により少ないのですが、thisUpdate値が最も近いそのものを指定するためにクライアントによって費やされます。 時間コンポーネントがないとき、カリフォルニアはいつも最新のCRLとともに帰ります。
-- reasons is used to specify from among CRLs partitioned by
revocation reason. Implementers should bear in mind that while a
specific revocation request has a single CRLReason code--and
consequently entries in the CRL would have a single CRLReason code
value--a single CRL can aggregate information for one or more
reasonFlags.
-- 理由は、取消し理由によって仕切られたCRLsから指定するのに使用されます。 Implementersは、特定の取消し要求にはただ一つのCRLReasonコードがある間(そして、その結果、CRLのエントリーでは、ただ一つのCRLReasonコード値があるでしょう)独身のCRLが1reasonFlagsのための情報に集めることができるのを覚えておくはずです。
A service responding to the request will place the requested CRL in the crls field of a SignedData object. If the get CRL attribute is the only control in a full enrollment message, the response would be a simple enrollment response.
要求に応じるサービスはSignedDataオブジェクトのcrls分野に要求されたCRLを置くでしょう。 得てください。CRL属性は完全な登録メッセージにおける唯一のコントロール、応答が簡単な登録応答であるだろうということです。
5.11 Revocation Request Control Attribute
5.11 取消し要求コントロール属性
The revocation request control attribute is used to request that a certificate be revoked.
取消し要求コントロール属性は、証明書が取り消されるよう要求するのに使用されます。
The revocation request control attribute has the following ASN.1 syntax:
取消し要求コントロール属性に、以下のASN.1構文があります:
RevRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }
RevRequest:、:= 系列issuerName Name(serialNumber INTEGER)はCRLReasonを推論して、invalidityDate GeneralizedTime OPTIONAL(sharedSecret OCTET STRING OPTIONAL)はUTF8string OPTIONALについて論評します。
Myers, et al. Standards Track [Page 30] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[30ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
-- issuerName contains the issuerName of the certificate to be
revoked.
-- issuerNameは取り消されるべき証明書のissuerNameを含んでいます。
-- serialNumber contains the serial number of the certificate to
be revoked
-- serialNumberは取り消されるべき証明書の通し番号を含んでいます。
-- reason contains the suggested CRLReason code for why the
certificate is being revoked. The CA can use this value at its
discretion in building the CRL.
-- 理由は証明書が取り消されている理由の提案されたCRLReasonコードを含んでいます。 カリフォルニアは自己判断でCRLを造る際にこの値を使用できます。
-- invalidityDate contains the suggested value for the Invalidity
Date CRL Extension. The CA can use this value at its discretion
in building the CRL.
-- invalidityDateはInvalidity Date CRL Extensionのための提案された値を含んでいます。 カリフォルニアは自己判断でCRLを造る際にこの値を使用できます。
-- sharedSecret contains a secret value registered by the EE when
the certificate was obtained to allow for revocation of a
certificate in the event of key loss.
-- sharedSecretは主要な損失の場合、証明書の取消しを考慮するために証明書を入手したときEEが示した秘密の値を含んでいます。
-- comment contains a human readable comment.
-- コメントは人間の読み込み可能なコメントを含んでいます。
For a revocation request to become a reliable object in the event of a dispute, a strong proof of originator authenticity is required. However, in the instance when an end-entity has lost use of its signature private key, it is impossible for the end-entity to produce a digital signature (prior to the certification of a new signature key pair). The RevRequest provides for the optional transmission from the end-entity to the CA of a shared secret that may be used as an alternative authenticator in the instance of loss of use. The acceptability of this practice is a matter of local security policy.
異義が生じた場合には信頼できるオブジェクトになるという取消し要求において、創始者の信憑性の確かな証拠が必要です。 しかしながら、インスタンスでは、終わり実体が署名秘密鍵の使用を失ったとき、終わり実体がデジタル署名(新しい署名主要な組の証明の前の)を起こすのは、不可能です。 RevRequestは任意の終わり実体から代替の固有識別文字として使用の損失のインスタンスに使用されるかもしれない共有秘密キーのカリフォルニアまでのトランスミッションに備えます。 この習慣の受容性はローカルの安全保障政策の問題です。
(Note that in some situations a Registration Authority may be delegated authority to revoke certificates on behalf of some population within its scope control. In these situations the CA would accept the LRA's digital signature on the request to revoke a certificate, independent of whether the end entity still had access to the private component of the key pair.)
(いくつかの状況で、Registration Authorityが範囲制御装置の中の何らかの人口を代表して証明書を取り消す代理権であるかもしれないことに注意してください。 これらの状況で、カリフォルニアは証明書を取り消すという要求のときにLRAのデジタル署名を受け入れるでしょう、終わりの実体がまだ主要な組の個人的なコンポーネントに近づく手段を持っていたかどうかの如何にかかわらず。)
Clients MUST provide the capability to produce a digitally signed revocation request control attribute. Clients SHOULD be capable of producing an unsigned revocation request containing the end-entity's shared secret. If a client provides shared secret based self- revocation, the client MUST be capable of producing a revocation request containing the shared secret. Servers MUST be capable of accepting both forms of revocation requests.
クライアントはデジタルに署名している取消し要求コントロール属性を作り出す能力を提供しなければなりません。 クライアントSHOULD、終わり実体の共有秘密キーを含む未署名の取消し要求は作り出すことができてください。 クライアントが共有された秘密のベースの自己取消しを提供するなら、クライアントは共有秘密キーを含む取消し要求を作り出すことができなければなりません。 サーバは両方の形式の取消し要求を受け入れることができなければなりません。
The structure of an unsigned, shared secret based revocation request is a matter of local implementation. The shared secret does not need to be encrypted when sent in a revocation request. The shared secret
未署名の、そして、共有された秘密のベースの取消し要求の構造は地方の実装の問題です。 取消し要求で送ると、共有秘密キーは暗号化する必要はありません。 共有秘密キー
Myers, et al. Standards Track [Page 31] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[31ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
has a one-time use, that of causing the certificate to be revoked, and public knowledge of the shared secret after the certificate has been revoked is not a problem. Clients need to inform users that the same shared secret SHOULD NOT be used for multiple certificates.
証明書がことになった取り消されているのが、問題であるという後に1回の使用、証明書が取り消されることを引き起こすもの、および共有秘密キーに関する公知を持っています。 クライアントは、同じ共有秘密キーSHOULD NOTが複数の証明書に使用されることをユーザに知らせる必要があります。
A full response message MUST be returned for a revocation request.
取消し要求のために完全な応答メッセージを返さなければなりません。
5.12 Registration and Response Information Control Attributes
5.12 登録と応答情報管理属性
The regInfo control attribute is for clients and LRAs to pass additional information as part a PKI request. The regInfo control attribute uses the ASN.1 structure:
regInfoコントロール属性はクライアントとLRAsがPKI要求に部分としての追加情報に合格することです。 regInfoコントロール属性はASN.1構造を使用します:
RegInfo ::= OCTET STRING
RegInfo:、:= 八重奏ストリング
The content of this data is based on bilateral agreement between the client and server.
このデータの内容はクライアントとサーバの間の二国間条約に基づいています。
If a server (or LRA) needs to return information back to a requestor in response to data submitted in a regInfo attribute, then that data is returned as a responseInfo control attribute. The content of the OCTET STRING for response information is based on bilateral agreement between the client and server.
サーバ(または、LRA)が、regInfo属性で提出されたデータに対応して情報を要請者に返して戻す必要があるなら、responseInfoコントロール属性としてそのデータを返します。 応答情報のためのOCTET STRINGの内容はクライアントとサーバの間の二国間条約に基づいています。
5.13 Query Pending Control Attribute
5.13は未定のコントロール属性について質問します。
In some environments, process requirements for manual intervention or other identity checking can cause a delay in returning the certificate related to a certificate request. The query pending attribute allows for a client to query a server about the state of a pending certificate request. The server returns a token as part of the CMCStatusInfo attribute (in the otherInfo field). The client puts the token into the query pending attribute to identify the correct request to the server. The server can also return a suggested time for the client to query for the state of a pending certificate request.
いくつかの環境で、手動の介入か他のアイデンティティの照合のためのプロセス要件は証明書要求に関連する証明書を返す遅れを引き起こす場合があります。 属性まで質問は、クライアントが未定の証明書要求の状態に関するサーバについて質問するのを許容します。 サーバはCMCStatusInfo属性(otherInfo分野の)の一部としてトークンを返します。 クライアントは、属性まで正しい要求をサーバに特定するために質問にトークンを入れます。また、サーバはクライアントが未定の証明書要求の状態に質問する提案された時間を返すことができます。
The ASN.1 structure used by the query pending control attribute is:
コントロール属性まで質問で使用されるASN.1構造は以下の通りです。
QueryPending ::= OCTET STRING
QueryPending:、:= 八重奏ストリング
If a server returns a pending state (the transaction is still pending), the otherInfo MAY be omitted. If it is not omitted then the same value MUST be returned (the token MUST NOT change during the request).
サーバが未定の状態を返すなら(トランザクションはまだ未定です)、otherInfoは省略されるかもしれません。 それを省略しないなら、同じ値を返さなければなりません(トークンは要求の間、変化してはいけません)。
Myers, et al. Standards Track [Page 32] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[32ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
5.14 Confirm Certificate Acceptance
5.14は証明書承認を確認します。
Some Certification Authorities require that clients give a positive conformation that the certificates issued to it are acceptable. The Confirm Certificate Acceptance control attribute is used for that purpose. If the CMCStatusInfo on a certificate request is confirmRequired, then the client MUST return a Confirm Certificate
クライアントが証明書がそれに発行した積極的な組織を与えるCertification Authoritiesが必要とする或るものは許容できます。 Confirm Certificate Acceptanceコントロール属性はそのために使用されます。 証明書要求でのCMCStatusInfoがconfirmRequiredであるなら、クライアントはConfirm Certificateを返さなければなりません。
Acceptance prior to any usage of the certificate. Clients SHOULD wait for the response from the server that the conformation has been received.
証明書のどんな使用法の前の承認。 組織がサーバですが、受け取って、SHOULDが応答を待つクライアント。
The confirm certificate acceptance structure is:
証明書承認構造は以下の通りであると確認してください。
CMCCertId ::= IssuerSerial
CMCCertId:、:= IssuerSerial
-- CMCCertId contains the issuer and serial number of the
certificate being accepted.
-- CMCCertIdは受け入れられる証明書の発行人と通し番号を含んでいます。
Servers MUST return a full enrollment response for a confirm certificate acceptance control.
サーバはaのための応答が確認する完全な登録に証明書承認コントロールを返さなければなりません。
6. Local Registration Authorities
6. 地方の登録局
This specification permits the use of Local Registration Authorities (LRAs). An LRA sits between the end-entity and the Certification Authority. From the end-entity's perspective, the LRA appears to be the Certification Authority and from the server the LRA appears to be a client. LRAs receive the enrollment messages, perform local processing and then forward onto Certificate Authorities. Some of the types of local processing that an LRA can perform include:
この仕様はLocal Registration Authorities(LRAs)の使用を可能にします。 LRAは終わり実体と認証局の間に座っています。 終わり実体の見解から、LRAは、認証局であるように見えます、そして、サーバから、LRAはクライアントであるように見えます。 LRAsはCertificate Authoritiesに登録メッセージを受け取って、ローカル処理を実行して、次に、フォワードを実行します。 LRAが実行できるローカル処理の何人かのタイプは:
- batching multiple enrollment messages together,
- challenge/response POP proofs,
- addition of private or standardized certificate extensions to all
requests,
- archival of private key material,
- routing of requests to different CAs.
- 一緒にバッチング倍数登録メッセージ--秘密鍵の材料における記録保管所の挑戦/応答POP証拠(すべての要求への個人的であるか標準化された証明書拡張子の追加)--異なったCAsへの要求のルーティング。
When an LRA receives an enrollment message it has three options: it may forward the message without modification, it may add a new wrapping layer to the message, or it may remove one or more existing layers and add a new wrapping layer.
LRAが登録メッセージを受け取るとき、それには、3つのオプションがあります: 変更なしでメッセージを転送するかもしれなくて、新しいラッピング層をメッセージに追加するかもしれないか、それは、1つ以上の既存の層を取り除いて、新しいラッピング層を加えるかもしれません。
When an LRA adds a new wrapping layer to a message it creates a new PKIData object. The new layer contains any control attributes required (for example if the LRA does the POP proof for an encryption key or the addExtension control attribute to modify an enrollment
LRAが新しいラッピング層をメッセージに追加するとき、それは新しいPKIDataオブジェクトを作成します。 新しい層が属性が必要としたコントロールを含んでいる、(例えば、暗号化キーかaddExtensionコントロール属性が登録を変更するように、LRAはPOP証拠をします。
Myers, et al. Standards Track [Page 33] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[33ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
request) and the client enrollment message. The client enrollment message is placed in the cmsSequence if it is a Full Enrollment message and in the reqSequence if it is a Simple Enrollment message. If an LRA is batching multiple client messages together, then each client enrollment message is placed into the appropriate location in the LRA's PKIData object along with all relevant control attributes.
要求) そして、クライアント登録メッセージ。 それがSimple EnrollmentメッセージであるならFull EnrollmentメッセージとreqSequenceにあるなら、クライアント登録メッセージはcmsSequenceに置かれます。 LRAが一緒にバッチング倍数クライアントメッセージであるなら、それぞれのクライアント登録メッセージはすべての関連コントロール属性に伴うLRAのPKIDataオブジェクトの適切な位置に置かれます。
(If multiple LRAs are in the path between the end-entity and the Certification Authority, this will lead to multiple wrapping layers on the message.)
(複数のLRAsが終わり実体と認証局の間の経路にあると、これはメッセージの複数のラッピング層に通じるでしょう。)
In processing an enrollment message, an LRA MUST NOT alter any certificate request body (PKCS #10 or CRMF) as any alteration would invalidate the signature on the request and thus the POP for the private key.
処理では、どんな変更も秘密鍵のためにその結果、要求とPOPの上で署名を無効にするように登録メッセージ、LRA MUST NOTはどんな証明書要求ボディー(PKCS#の10かCRMF)も変更します。
An example of how this would look is illustrated by the following figure:
これがどう見えるだろうかに関する例は以下の図によって例証されます:
SignedData (by LRA)
PKIData
controlSequence
LRA added control statements
reqSequence
Zero or more Simple CertificationRequests from clients
cmsSequence
Zero or more Full PKI messages from clients
SignedData (by client)
PKIData
SignedData(LRAによる)PKIData controlSequence LRAはクライアントSignedData(クライアントによる)PKIDataからクライアントcmsSequence Zeroからの規制声明のreqSequence Zeroか、より多くのSimple CertificationRequestsか、より多くのFull PKIメッセージを加えました。
Under some circumstances an LRA is required to remove wrapping layers. The following sections look at the processing required if encryption layers and signing layers need to be removed.
いくつかの状況で、LRAが、取り外すのに層を包装しながら、必要です。 以下のセクションは暗号化層と署名層が、取り除かれる必要があるなら必要である処理を見ます。
6.1 Encryption Removal
6.1 暗号化取り外し
There are two cases that require an LRA to remove or change encryption in an enrollment message. In the first case the encryption was applied for the purposes of protecting the entire enrollment request from unauthorized entities. If the CA does not have a recipient info entry in the encryption layer, the LRA MUST remove the encryption layer. The LRA MAY add a new encryption layer with or without adding a new signing layer.
登録メッセージにはLRAが暗号化を取り除くか、または変えるのを必要とする2つのケースがあります。 前者の場合暗号化は権限のない実体から全体の登録要求を保護する目的のために適用されました。 カリフォルニアが暗号化層の中に受取人インフォメーションエントリーを持っていないなら、LRA MUSTは暗号化層を取り除きます。 新しい署名層を加えることのあるなしにかかわらずLRA MAYは新しい暗号化層を加えます。
The second change of encryption that may be required is to change the encryption inside of a signing layer. In this case the LRA MUST remove all signing layers containing the encryption. All control statements MUST be merged according to local policy rules as each
必要であるかもしれない暗号化の2番目の変化は署名層の暗号化内部を変えることになっています。 この場合、LRA MUSTは暗号化を含むすべての署名層を取り除きます。 ローカルの政策ルールによると、それぞれとしてすべての規制声明を合併しなければなりません。
Myers, et al. Standards Track [Page 34] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[34ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
signing layer is removed and the resulting merged controls MUST be placed in a new signing layer provided by the LRA. If the signing layer provided by the end-entity needs to be removed to the LRA can remove the layer.
署名層は移されます、そして、LRAによって提供された新しい署名層に結果として起こる合併しているコントロールを置かなければなりません。 署名層が提供されたなら、終わり実体で、LRAに移されるべき必要性は層を取り除くことができます。
6.2 Signature Layer Removal
6.2 署名層の除去
Only two instances exist where an LRA should remove a signature layer on a Full Enrollment message. If an encryption needs to be modified within the message, or if a Certificate Authority will not accept secondary delegation (i.e. multiple LRA signatures). In all other situations LRAs SHOULD NOT remove a signing layer from a message.
2つのインスタンスだけがLRAがFull Enrollmentメッセージで署名層を移すはずであるところに存在しています。 暗号化が、メッセージの中で変更される必要があるか、またはCertificate Authorityがセカンダリ委譲(すなわち、倍数LRA署名)を受け入れないなら。 全部で、他の状況LRAs SHOULDはメッセージから署名層を取り除きません。
If an LRA removes a signing layer from a message, all control statements MUST be merged according to local policy rules. The resulting merged control statements MUST be placed in a new signing layer provided by the LRA.
LRAがメッセージから署名層を取り除くなら、ローカルの政策ルールによると、すべての規制声明を合併しなければなりません。 LRAによって提供された新しい署名層に結果として起こる合併している規制声明を置かなければなりません。
7. Transport Wrapping
7. 輸送ラッピング
Not all methods of transporting data allow for sending unlabeled raw binary data, in may cases standard methods of encoding can be used to greatly ease this issue. These methods normally consist of wrapping some identification of the content around the binary data, possibly applying an encoding to the data and labeling the data. We document for use three different wrapping methods.
ラベルされていない生のバイナリ・データ、コネがそうする発信がコード化の標準方法をケースに入れるので、この問題を大いに緩和するのにデータを輸送するメソッドが許容するというわけではないすべてを使用できます。 通常、これらのメソッドは内容の何らかの識別をバイナリ・データに巻きつけるのから成ります、ことによるとコード化をデータに適用して、データをラベルして。 私たちは使用のために3つの異なったラッピングメソッドを記録します。
-- MIME wrapping is for transports that are natively MIME based such
as HTTP and E-mail.
-- Binary file transport is defined since floppy disk transport is
still very common. File transport can be done either as MIME
wrapped (section 7.1) or bare (section 7.2).
-- Socket based transport uses the raw BER encoded object.
-- MIMEラッピングはHTTPやメールのように基づくネイティブMIMEである輸送のためのものです。 -- フロッピーディスク輸送がまだ非常に一般的であるので、バイナリーファイル輸送は定義されます。 ファイル輸送は、MIMEが(セクション7.1)を包装したのでするか、または(セクション7.2)を剥き出すことができます。 -- 生のBERがコード化したソケットに基づいている輸送用途は反対します。
7.1 MIME Wrapping
7.1 MIMEラッピング
MIME wrapping is defined for those environments that are MIME native. These include E-Mail based protocols as well as HTTP.
MIMEラッピングはMIMEネイティブであるそれらの環境のために定義されます。 これらはHTTPと同様にメールのベースのプロトコルを含んでいます。
The basic mime wrapping in this section is taken from [SMIMEV2] and [SMIMEV3]. Simple enrollment requests are encoded using the application/pkcs10 content type. A file name MUST be included either in a content type or content disposition statement. The extension for the file MUST be ".p10".
[SMIMEV2]と[SMIMEV3]からこのセクションの基本的なパントマイムラッピングを取ります。 簡単な登録要求は、アプリケーション/pkcs10content typeを使用することでコード化されます。 content typeか満足している使途計算書にファイル名を含まなければなりません。 ファイルのための拡大は".p10""であるに違いありません。
Myers, et al. Standards Track [Page 35] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[35ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
Simple enrollment response messages MUST be encoded as content-type application/pkcs7-mime. An smime-type parameter MUST be on the content-type statement with a value of "certs-only." A file name with the ".p7c" extension MUST be specified as part of the content-type or content-disposition.
content type pkcs7アプリケーション/パントマイムとして簡単な登録応答メッセージをコード化しなければなりません。 smime-型引数が「本命専用」の値と共にcontent type声明にあるに違いありません。 content typeか満足している気質の一部として".p7c"拡大を伴うファイル名を指定しなければなりません。
Full enrollment request messages MUST be encoded as content-type application/pkcs7-mime. The smime-type parameter MUST be included with a value of "CMC-enroll". A file name with the ".p7m" extension MUST be specified as part of the content-type or content-disposition statement.
content type pkcs7アプリケーション/パントマイムとして完全な登録要求メッセージをコード化しなければなりません。 「CMC登録してください」の値でsmime-型引数を含まなければなりません。 content typeか満足している使途計算書の一部として".p7m"拡大を伴うファイル名を指定しなければなりません。
Full enrollment response messages MUST be encoded as content-type application/pkcs7-mime. The smime-type parameter MUST be included with a value of "CMC-response." A file name with the ".p7m" extensions MUST be specified as part of the content-type or content- disposition.
content type pkcs7アプリケーション/パントマイムとして完全な登録応答メッセージをコード化しなければなりません。 「CMC-応答」の値でsmime-型引数を含まなければなりません。 content typeか内容気質の一部として".p7m"拡大を伴うファイル名を指定しなければなりません。
MIME TYPE File Extension SMIME-TYPE
MIMEタイプファイル拡張子SMIME-タイプ
application/pkcs10 .p10 N/A (simple PKI request)
アプリケーション/pkcs10 .p10 N/A(簡単なPKI要求)
application/pkcs7-mime .p7m CMC-request (full PKI request)
pkcs7アプリケーション/パントマイム.p7m CMC-要求(完全なPKI要求)
application/pkcs7-mime .p7c certs-only (simple PKI response)
pkcs7-パントマイム.p7cアプリケーション/本命専用(簡単なPKI応答)
application/pkcs7-mime .p7m CMC-response (full PKI response)
pkcs7アプリケーション/パントマイム.p7m CMC-応答(完全なPKI応答)
7.2 File-Based Transport
7.2 ファイルベースの輸送
Enrollment messages and responses may also be transferred between clients and servers using file system-based mechanisms, such as when enrollment is performed for an off-line client. When files are used to transport binary, BER-encoded Full Enrollment Request and Response messages, the following file type extensions SHOULD be used:
また、オフラインクライアントへのシステムベースのメカニズムであって、登録がいつなどように実行されたファイルを使用するかで登録メッセージと応答をクライアントとサーバの間に移すかもしれません。 ファイルが使用されているときには、2進の、そして、BERによってコード化されたFull Enrollment RequestとResponseメッセージ、以下のファイルの種類拡大SHOULDを輸送するのに、使用されてください:
Message Type File Extension
メッセージタイプファイル拡張子
Full PKI Request .crq
完全なPKIは.crqを要求します。
Full PKI Response .crp
完全なPKI応答.crp
Myers, et al. Standards Track [Page 36] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[36ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
7.3 Socket-Based Transport
7.3 ソケットベースの輸送
When enrollment messages and responses are sent over sockets, no wrapping is required. Messages SHOULD be sent in their binary, BER- encoded form.
登録メッセージと応答をソケットの上に送るとき、包装を必要としません。 それらのバイナリーでメッセージSHOULDを送って、BERはフォームをコード化しました。
8. Interoperability
8. 相互運用性
8.1 Mandatory and Optional Algorithms
8.1 義務的で任意のアルゴリズム
CMC clients and servers MUST be capable of producing and processing message signatures using the Digital Signature Algorithm [DSA]. DSA signatures MUST be indicated by the DSA AlgorithmIdentifier value (as specified in section 7.2.2 of [PKIXCERT]). PKI clients and servers SHOULD also be capable of producing and processing RSA signatures (as specified in section 7.2.1 of [PKIXCERT]).
CMCクライアントとサーバは生産とDigital Signature Algorithm[DSA]を使用する処理メッセージ署名ができなければなりません。 DSA AlgorithmIdentifier値でDSA署名を示さなければなりません(.2セクション7.2[PKIXCERT]で指定されるように)。 また、生産できてRSA署名を処理しているPKIクライアントとサーバSHOULD(.1セクション7.2[PKIXCERT]で指定されるように)。
CMC clients and servers MUST be capable of protecting and accessing message encryption keys using the Diffie-Hellman (D-H) key exchange algorithm. D-H/3DES protection MUST be indicated by the D-H AlgorithmIdentifier value specified in [CMS]. PKI clients and servers SHOULD also be capable of producing and processing RSA key transport. When used for PKI messages, RSA key transport MUST be indicated as specified in section 7.2.1 of [PKIXCERT].
ディフィー-ヘルマン(D-H)の主要な交換アルゴリズムを使用することで、メッセージ暗号化キーを保護して、CMCクライアントとサーバはアクセスできなければなりません。 [CMS]で指定されたD-H AlgorithmIdentifier値でD-H/3DES保護を示さなければなりません。 また、生産できてRSAの主要な輸送を処理しているPKIクライアントとサーバSHOULD。 使用されたら、PKIメッセージ、主要な輸送がそうしなければならないRSAに関して.1セクション7.2[PKIXCERT]で指定されるように示されてください。
8.2 Minimum Conformance Requirements
8.2 最小の順応要件
A minimally compliant CMC server:
最少量で対応することのCMCサーバ:
a) MUST accept a Full PKI Request message
i) MUST accept CRMF Request Bodies within a Full PKI Request
ii) MUST accept PKCS#10 Request Bodies within a Full PKI Request
b) MUST accept a Simple Enrollment Request message
c) MUST be able to return a Full PKI Response. (A Full PKI Response
is always a valid response, but for interoperability with
downlevel clients a compliant server SHOULD use the Simple
Enrollment Response whenever possible.)
a) Full PKI Requestメッセージi)を受け入れなければなりません。 Full PKI Request ii)の中のCRMF Request Bodiesは受け入れなければなりません。 Full PKI Request bの中のPKCS#10Request Bodiesが受け入れなければならない、) Simple Enrollment Requestメッセージc)を受け入れなければなりません。 Full PKI Responseを返すことができなければならなくなってください。 (いつもFull PKI Responseは有効回答ですが、downlevelクライアントがいる相互運用性のために、可能であるときはいつも、対応するサーバSHOULDはSimple Enrollment Responseを使用します。)
A minimally-complaint CMC client:
最少量で、-、苦情、CMCクライアント:
a) MAY use either the Simple Enrollment Message or the Full PKI
Request.
i) clients MUST use PKCS#10 with the Simple Enrollment Message
ii) clients MAY use either PKCS#10 or CRMF with the Full PKI
Request
b) MUST understand the Simple Enrollment Response.
c) MUST understand the Full PKI Response.
a) Simple Enrollment MessageかFull PKI Request. iのどちらか) クライアントがそうしなければならない使用がクライアントとPKCS#10かCRMFのどちらかを使用するかもしれないSimple Enrollment Message ii)と共にPKCS#10、を使用しますように、Full PKI Request b) Simple Enrollment Response. cが理解しなければならない、) Full PKI Responseを理解しなければなりません。
Myers, et al. Standards Track [Page 37] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[37ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
9. Security Considerations
9. セキュリティ問題
Initiation of a secure communications channel between an end-entity and a CA or LRA (and, similarly, between an LRA and another LRA or CA) necessarily requires an out-of-band trust initiation mechanism. For example, a secure channel may be constructed between the end- entity and the CA via IPSEC or TLS. Many such schemes exist and the choice of any particular scheme for trust initiation is outside the scope of this document. Implementers of this protocol are strongly encouraged to consider generally accepted principles of secure key management when integrating this capability within an overall security architecture.
そして、終わり実体とカリフォルニアかLRAの間の安全なコミュニケーションチャンネルの開始、(同様と、間、別のLRAとLRAかカリフォルニア) 必ず、バンドで出ている信頼開始メカニズムを必要とします。 例えば、安全なチャンネルはIPSECかTLSを通して終わりの実体とカリフォルニアの間で構成されるかもしれません。 そのような多くの体系が存在しています、そして、このドキュメントの範囲の外に信頼開始のどんな特定の体系の選択もあります。 総合的なセキュリティー体系の中でこの能力を統合するとき、このプロトコルのImplementersが安全なかぎ管理の一般に認められた原則を考えるよう強く奨励されます。
Mechanisms for thwarting replay attacks may be required in particular implementations of this protocol depending on the operational environment. In cases where the CA maintains significant state information, replay attacks may be detectable without the inclusion of the optional nonce mechanisms. Implementers of this protocol need to carefully consider environmental conditions before choosing whether or not to implement the senderNonce and recipientNonce attributes described in section 5.6. Developers of state-constrained PKI clients are strongly encouraged to incorporate the use of these attributes.
反射攻撃を阻むためのメカニズムが運用環境に依存するこのプロトコルの特定の実装で必要であるかもしれません。 カリフォルニアが重要な州の情報を保守する場合では、反射攻撃は任意の一回だけのメカニズムの包含なしで検出可能であるかもしれません。このプロトコルのImplementersは、senderNonceとrecipientNonceがセクション5.6で説明された属性であると実装するかどうかを選ぶ前に慎重に環境条件を考える必要があります。 状態が強制的なPKIクライアントの開発者がこれらの属性の使用を取り入れるよう強く奨励されます。
Under no circumstances should a signing key be archived. Doing so allows the archiving entity to potentially use the key for forging signatures.
署名キーを決して、格納するべきではありません。 そうするのに、格納実体は鍛造物署名に潜在的にキーを使用できます。
Due care must be taken prior to archiving keys. Once a key is given to an archiving entity, the archiving entity could use the keys in a way not conducive to the archiving entity. Users should be made especially aware that proper verification is made of the certificate used to encrypt the private key material.
キーを格納する前に、相当な注意を取らなければなりません。 いったん格納実体にキーを与えると、格納実体はある意味で格納実体に役に立たないキーを使用するかもしれません。 ユーザを秘密鍵の材料を暗号化するのに使用される証明書で適切な検証をするのを特に意識するようにするべきです。
Clients and servers need to do some checks on cryptographic parameters prior to issuing certificates to make sure that weak parameters are not used. A description of the small subgroup attack is provided in [X942]. CMC implementations ought to be aware of this attack when doing parameter validations.
クライアントとサーバは、弱いパラメタが使用されていないのを確実にするために証明書を発行する前に暗号のパラメタのいくつかのチェックをする必要があります。 小さいサブグループ攻撃の記述を[X942]に提供します。 パラメタ合法化をするとき、CMC実装はこの攻撃を意識しているべきです。
Myers, et al. Standards Track [Page 38] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[38ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
10. Acknowledgments
10. 承認
The authors would like to thank Brian LaMacchia for his work in developing and writing up many of the concepts presented in this document. The authors would also like to thank Alex Deacon and Barb Fox for their contributions.
作者は彼の仕事について本書では提示された概念の多くを開発して、詳しく書く際にブライアンLaMacchiaに感謝したがっています。 また、作者は彼らの貢献についてアレックスDeaconとバーブフォックスに感謝したがっています。
11. References
11. 参照
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet
X.509 Certificate Request Message Format", RFC 2511, March
1999.
[CRMF] マイアーズとM.とアダムスとC.と独奏とD.とD.ケンプ、「インターネットX.509証明書要求メッセージ形式」、RFC2511、1999年3月。
[DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4"
[DH]B.Kaliski、「PKCS3:」 ディフィー-ヘルマンKey Agreement v1.4"
[DH-POP] H. Prafullchandra, J. Schaad, "Diffie-Hellman Proof-of-
Possession Algorithms", Work in Progress.
[DHポップス]のH.Prafullchandra、J.Schaad、「ディフィー-ヘルマンProof、-、所有物アルゴリズム、」 仕事進行中です。
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[HMAC] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[PKCS1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC
2313, March 1998.
[PKCS1]Kaliski、B.、「PKCS#1:」 RSA暗号化、バージョン1.5インチ、RFC2313、1998年3月。
[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax v1.5",
RFC 2315, October 1997.
[PKCS7]Kaliski、B.、「PKCS#7:」 暗号のMessage Syntax v1.5"、1997年10月のRFC2315。
[PKCS8] RSA Laboratories, "PKCS#8: Private-Key Information Syntax
Standard, Version 1.2", November 1, 1993.
[PKCS8]RSA研究所、「PKCS#8:」 標準の秘密鍵情報構文バージョン1.2インチと、1993年11月1日。
[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax
v1.5", RFC 2314, October 1997.
[PKCS10]Kaliski、B.、「PKCS#10:」 証明Request Syntax v1.5"、1997年10月のRFC2314。
[PKIXCERT] Housley, R., Ford, W., Polk, W. and D. Solo "Internet
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459, January 1999.
[PKIXCERT] HousleyとR.とフォードとW.とポークとW.と「インターネットX.509公開鍵基盤の証明書とCRLは輪郭を描く」D.独奏、RFC2459、1999年1月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L.
Repka, "S/MIME Version 2 Message Specification", RFC 2311,
March 1998.
[SMIMEV2] DusseとS.とホフマンとP.とRamsdellとB.とLundbladeとL.とL.Repka、「S/MIMEバージョン2メッセージ仕様」、RFC2311、1998年3月。
Myers, et al. Standards Track [Page 39] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[39ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
[SMIMEV3] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[SMIMEV3] Ramsdell、B.、「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。
[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.
[X942] レスコラ、E.、「ディフィー-ヘルマンの主要な協定メソッド」、RFC2631、1999年6月。
12. Authors' Addresses
12. 作者のアドレス
Michael Myers VeriSign Inc. 1350 Charleston Road Mountain View, CA, 94043
マウンテンビュー、マイケルマイアーズベリサイン株式会社1350チャールストンRoadカリフォルニア 94043
Phone: (650) 429-3402 EMail: mmyers@verisign.com
以下に電話をしてください。 (650) 429-3402 メールしてください: mmyers@verisign.com
Xiaoyi Liu Cisco Systems 170 West Tasman Drive San Jose, CA 95134
Xiaoyiリュウシスコシステムズ170の西タスマン・Driveサンノゼ、カリフォルニア 95134
Phone: (480) 526-7430 EMail: xliu@cisco.com
以下に電話をしてください。 (480) 526-7430 メールしてください: xliu@cisco.com
Jim Schaad
ジムSchaad
EMail: jimsch@nwlink.com
メール: jimsch@nwlink.com
Jeff Weinstein
ジェフ・ワインスタイン
EMail: jsw@meer.net
メール: jsw@meer.net
Myers, et al. Standards Track [Page 40] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[40ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
Appendix A ASN.1 Module
付録はASN.1モジュールです。
EnrollmentMessageSyntax
{ iso(1) identified-organization(3) dod(4) internet(1)
security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc(6) }
EnrollmentMessageSyntaxiso(1)の特定された組織(3)dod(4)インターネット(1)セキュリティ(5)mechansims(5) pkix(7)イドモッズ(0)イドモッズcmc(6)
DEFINITIONS IMPLICIT TAGS ::= BEGIN
定義、内在しているタグ:、:= 始まってください。
-- EXPORTS All -- -- The types and values defined in this module are exported for use -- in the other ASN.1 modules. Other applications may use them for -- their own purposes.
-- EXPORTS All----このモジュールで定義されたタイプと値は他のASN.1モジュールにおける使用のためにエクスポートされます。 アプリケーションがそれらを使用するかもしれないもう一方--それら自身の目的。
IMPORTS
輸入
-- Information Directory Framework (X.501)
Name
FROM InformationFramework { joint-iso-itu-t ds(5)
modules(1) informationFramework(1) 3 }
-- InformationFrameworkからの情報ディレクトリフレームワーク(X.501)名共同iso-itu t ds(5)モジュール(1)informationFramework(1)3
-- Directory Authentication Framework (X.509)
AlgorithmIdentifier, AttributeCertificate, Certificate,
CertificateList, CertificateSerialNumber
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 }
-- AuthenticationFrameworkからのAlgorithmIdentifier(AttributeCertificate)が証明するディレクトリ認証フレームワーク(X.509)、CertificateList、CertificateSerialNumber共同iso-itu t ds(5)モジュール(1)authenticationFramework(7)3
-- PKIX Part 1 - Implicit
GeneralName, CRLReason, ReasonFlags
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(2)}
-- PKIX第1部--PKIX1Implicit88からの内在しているGeneralName、CRLReason、ReasonFlagsiso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の内在している88(2)
-- PKIX Part 1 - Explicit
SubjectPublicKeyInfo, Extension
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
-- PKIX第1部--PKIX1Explicit88からの明白なSubjectPublicKeyInfo、拡大iso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の明白な88(1)
-- Cryptographic Message Syntax
ContentInfo, Attribute
FROM CryptographicMessageSyntax { 1 2 840 113549 1 9 16 0 1}
-- CryptographicMessageSyntaxからの暗号のメッセージ構文ContentInfo、属性{ 1 2 840 113549 1 9 16 0 1}
-- CRMF
CertReqMsg
FROM CRMF { 1 3 6 1 5 5 7 0 5 };
-- CRMF1 3 6 1 5 5 7 0 5からのCRMF CertReqMsg。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)
Myers, et al. Standards Track [Page 41] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[41ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls
id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types
イド-cmc OBJECT IDENTIFIER:、:= イド-pkix7--CMCはイド-cct OBJECT IDENTIFIERを制御します:、:= イド-pkix12--CMC content type
-- The following controls have simple type content (usually OCTET
STRING)
-- 以下のコントロールには、簡単なタイプ内容があります。(通常八重奏ストリング)
id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}
id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}
id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}
id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}
id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22)
id-cmc-popLinkWitness OBJECT IDENTIFIER ::= (id-cmc 23)
イドcmc識別OBJECT IDENTIFIER:、:= イド-cmc2イド-cmc-identityProofオブジェクト識別子:、:= イド-cmc3イド-cmc-dataReturnオブジェクト識別子:、:= イド-cmc4イド-cmc-transactionIdオブジェクト識別子:、:= イド-cmc5イド-cmc-senderNonceオブジェクト識別子:、:= イド-cmc6イド-cmc-recipientNonceオブジェクト識別子:、:= イド-cmc7イド-cmc-regInfoオブジェクト識別子:、:= イド-cmc18イド-cmc-responseInfoオブジェクト識別子:、:= イド-cmc19イド-cmc-queryPendingオブジェクト識別子:、:= イド-cmc21イド-cmc-popLinkRandomオブジェクト識別子:、:= イド-cmc22)イド-cmc-popLinkWitnessオブジェクト識別子: : =(イド-cmc23)
-- This is the content type used for a request message in the
protocol
-- これはプロトコルの要求メッセージに使用されるcontent typeです。
id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
イド-cct-PKIDataオブジェクト識別子:、:= イド-cct2
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
PKIData:、:= 系列TaggedAttributeのcontrolSequence系列サイズ(0..MAX)、TaggedRequestのreqSequence系列サイズ(0..MAX)、TaggedContentInfoのcmsSequence系列サイズ(0..MAX)、OtherMsgのotherMsgSequence系列サイズ(0..MAX)
bodyIdMax INTEGER ::= 4294967295
bodyIdMax整数:、:= 4294967295
BodyPartID ::= INTEGER(0..bodyIdMax)
BodyPartID:、:= 整数(0..bodyIdMax)
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartId,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
TaggedAttribute:、:= 系列bodyPartID BodyPartId、attrTypeオブジェクト識別子、AttributeValueのattrValuesセット
AttributeValue ::= ANY
AttributeValue:、:= 少しも
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg
TaggedRequest:、:= CHOICE、tcr[0]TaggedCertificationRequest、crm[1]CertReqMsg
Myers, et al. Standards Track [Page 42] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[42ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
}
}
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
TaggedCertificationRequest:、:= 系列bodyPartID BodyPartID、certificationRequest CertificationRequest
CertificationRequest ::= SEQUENCE {
certificationRequestInfo SEQUENCE {
version INTEGER,
subject Name,
subjectPublicKeyInfo SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING },
attributes [0] IMPLICIT SET OF Attribute },
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
CertificationRequest:、:= 系列certificationRequestInfo SEQUENCE、バージョンINTEGER、Nameをかけてください、subjectPublicKeyInfo SEQUENCE、アルゴリズムAlgorithmIdentifier、subjectPublicKey BIT STRINGが[0] IMPLICIT SET OF Attributeを結果と考える、signatureAlgorithm AlgorithmIdentifier、署名BIT STRING
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartId,
contentInfo ContentInfo
}
TaggedContentInfo:、:= 系列bodyPartID BodyPartId、contentInfo ContentInfo
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
OtherMsg:、:= 系列bodyPartID BodyPartID、otherMsgValueがotherMsgTypeで少しも定義したotherMsgTypeオブジェクト識別子
-- This defines the response message in the protocol
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
-- これはプロトコルイド-cct-PKIResponse OBJECT IDENTIFIERの応答メッセージを定義します:、:= イド-cct3
ResponseBody ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
ResponseBody:、:= 系列TaggedAttributeのcontrolSequence系列サイズ(0..MAX)、TaggedContentInfoのcmsSequence系列サイズ(0..MAX)、OtherMsgのotherMsgSequence系列サイズ(0..MAX)
-- Used to return status state in a response
-- 応答で状態状態を返すために、使用されます。
id-cmc-cMCStatusInfo OBJECT IDENTIFIER ::= {id-cmc 1}
イド-cmc-cMCStatusInfoオブジェクト識別子:、:= イド-cmc1
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF INTEGER,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
CMCStatusInfo:、:= 系列、cMCStatus CMCStatus、整数のbodyList系列サイズ(1..MAX)、任意のstatusString UTF8String otherInfo選択、failInfo CMCFailInfo
Myers, et al. Standards Track [Page 43] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[43ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
pendInfo PendInfo } OPTIONAL
}
pendInfo PendInfo 任意
PendInfo ::= SEQUENCE {
pendToken INTEGER,
pendTime GENERALIZEDTIME
}
PendInfo:、:= 系列pendToken整数、pendTime GENERALIZEDTIME
CMCStatus ::= INTEGER {
success (0),
-- you got exactly what you asked for
failed (2),
-- you don't get it, more information elsewhere in the message
pending (3),
-- the request body part has not yet been processed,
-- requester is responsible to poll back on this
noSupport (4)
-- the requested operation is not supported
}
CMCStatus:、:= 整数失敗されて、要求本体が分ける(2)(あなたはそれを得ません、(3)までメッセージのほかの場所の詳しい情報)がまだ処理されていないので、あなたはまさに尋ねたものを得ました--リクエスタがこのnoSupport(4)で投票するのにおいて原因となるという要求された操作がサポートされない成功(0)
CMCFailInfo ::= INTEGER {
badAlg (0),
-- Unrecognized or unsupported algorithm
badMessageCheck (1),
-- integrity check failed
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- Message time field was not sufficiently close to the system
time
badCertId (4),
-- No certificate could be identified matching the provided
criteria
unsuportedExt (5),
-- A requested X.509 extension is not supported by the recipient
CA.
mustArchiveKeys (6),
-- Private key material must be supplied
badIdentity (7),
-- Identification Attribute failed to verify
popRequired (8),
-- Server requires a POP proof before issuing certificate
popFailed (9),
-- Server failed to get an acceptable POP for the request
noKeyReuse (10)
-- Server policy does not allow key re-use
internalCAError (11)
tryLater (12)
CMCFailInfo:、:= INTEGER、badAlg(0)--認識されていないかサポートされないアルゴリズムbadMessageCheck(1)--保全チェックはbadRequest(2)、分野がシステム時間badCertId(4)の十分近くにありませんでした--提供された評価基準unsuportedExt(5)を合わせながら証明書を全く特定できなかった--取引の受入れられなかったか支持されなかったbadTime(3)--メッセージ時間に失敗しました; 要求されたX.509拡張子はカリフォルニア受取人mustArchiveKeys(6)によってサポートされません--badIdentity(7)を秘密鍵の材料に供給しなければなりません--識別AttributeはpopRequired(8)について確かめませんでした--証明書popFailed(9)を発行する前に、サーバはPOP証拠を必要とします--サーバは要求noKeyReuse(10)のために許容できるPOPを得ませんでした--サーバ方針は主要な再使用internalCAError(11)tryLaterを許容しません。(12)
Myers, et al. Standards Track [Page 44] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[44ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
}
}
-- Used for LRAs to add extensions to certificate requests
id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}
-- LRAsが証明書要求イド-cmc-addExtensions OBJECT IDENTIFIERに拡大を加えるのにおいて中古:、:= イド-cmc8
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
AddExtensions:、:= 系列pkiDataReference BodyPartID、certReferences SEQUENCE OF BodyPartID、拡大SEQUENCE OF Extension
id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9}
id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10}
イド-cmc-encryptedPOP物の識別子:、:= イド-cmc9イド-cmc-decryptedPOP物の識別子:、:= イド-cmc10
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
EncryptedPOP:、:= 系列TaggedRequest(cm ContentInfo、thePOPAlgID AlgorithmIdentifier、witnessAlgID AlgorithmIdentifier)がOCTET STRINGを目撃するよう要求してください。
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
DecryptedPOP:、:= 系列bodyPartID BodyPartID、thePOPAlgID AlgorithmIdentifier、thePOP八重奏ストリング
id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11}
イド-cmc-lraPOPWitness物の識別子:、:= イド-cmc11
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE OF BodyPartID
}
LraPopWitness:、:= 系列pkiDataBodyid BodyPartID、BodyPartIDのbodyIds系列
--
id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15}
-- イド-cmc-getCert物の識別子:、:= イド-cmc15
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
GetCert:、:= 系列issuerName GeneralName、serialNumber整数
id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16}
イド-cmc-getCRL物の識別子:、:= イド-cmc16
GetCRL ::= SEQUENCE {
GetCRL:、:= 系列
Myers, et al. Standards Track [Page 45] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[45ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
issuerName Name(cRLName GeneralName OPTIONAL、時間GeneralizedTime OPTIONAL)はReasonFlags OPTIONALを推論します。
id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17}
イド-cmc-revokeRequest物の識別子:、:= イド-cmc17
RevRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
passphrase OCTET STRING OPTIONAL,
comment UTF8String OPTIONAL }
RevRequest:、:= 系列issuerName Name(serialNumber INTEGER)はCRLReasonを推論して、invalidityDate GeneralizedTime OPTIONAL(パスフレーズOCTET STRING OPTIONAL)はUTF8String OPTIONALについて論評します。
id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {pkix-cmc 24}
イド-cmc-confirmCertAcceptance物の識別子:、:= pkix-cmc24
CMCCertId ::= IssuerSerial
CMCCertId:、:= IssuerSerial
-- The following is used to request V3 extensions be added to a certificate
-- 以下は、V3拡張子が証明書に追加されるよう要求するのに使用されます。
id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 14}
イド-ExtensionReq物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9)14をメンバーと同じくらい具体化させます。
ExtensionReq ::= SEQUENCE OF Extension
ExtensionReq:、:= 拡大の系列
-- The following exists to allow Diffie-Hellman Certificate Requests Messages to be -- well-formed
-- 以下がディフィー-ヘルマンCertificate Requests Messagesは許容するために存在している、--、よく形成します。
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
イド-alg-noSignature物の識別子:、:= イド-pkixイド-alg(6)2
NoSignatureValue ::= OCTET STRING
NoSignatureValue:、:= 八重奏ストリング
END
終わり
Myers, et al. Standards Track [Page 46] RFC 2797 Certificate Management Messages over CMS April 2000
マイアーズ、他 標準化過程[46ページ]RFC2797はcm2000年4月の間、管理メッセージを証明します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Myers, et al. Standards Track [Page 47]
マイアーズ、他 標準化過程[47ページ]
一覧
スポンサーリンク
