RFC4211 日本語訳
4211 Internet X.509 Public Key Infrastructure Certificate RequestMessage Format (CRMF). J. Schaad. September 2005. (Format: TXT=86136 bytes) (Obsoletes RFC2511) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Schaad Request for Comments: 4211 Soaring Hawk Consulting Obsoletes: 2511 September 2005 Category: Standards Track
Schaadがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4211年の高く昇っているタカのコンサルティングは以下を時代遅れにします。 2511 2005年9月のカテゴリ: 標準化過程
Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)
インターネットX.509公開鍵暗号基盤証明書要求メッセージ形式(CRMF)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol.
このドキュメントはCertificate Request Message Format(CRMF)構文と意味論について説明します。 この構文は認証局(カリフォルニア)に証明書に関する要求を伝えるのに使用されます、ことによるとRegistration Authority(RA)を通して、X.509証明書生産の目的のために。 要求は公開鍵と関連レジスト情報を通常含むでしょう。 このドキュメントは証明書要求プロトコルを定義しません。
Schaad Standards Track [Page 1] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[1ページ]。
Table Of Contents
目次
1. Introduction and Terminology ....................................3
2. Overview ........................................................3
2.1. Changes since RFC 2511 .....................................4
3. CertReqMessage Syntax ...........................................4
4. Proof-of-Possession (POP) .......................................5
4.1. Signature Key POP ..........................................7
4.2. Key Encipherment Keys ......................................9
4.2.1. Private Key Info Content Type ......................11
4.2.2. Private Key Structures .............................12
4.2.3. Challenge-Response Guidelines ......................13
4.3. Key Agreement Keys ........................................14
4.4. Use of Password-Based MAC .................................14
5. CertRequest syntax .............................................16
6. Controls Syntax ................................................18
6.1. Registration Token Control ................................18
6.2. Authenticator Control .....................................19
6.3. Publication Information Control ...........................19
6.4. Archive Options Control ...................................21
6.5. OldCert ID Control ........................................23
6.6. Protocol Encryption Key Control ...........................23
7. RegInfo Controls ...............................................23
7.1. utf8Pairs .................................................23
7.2. certReq ...................................................24
8. Object Identifiers .............................................24
9. Security Considerations ........................................25
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
11. Acknowledgements ..............................................28
Appendix A. Use of RegInfo for Name-Value Pairs ..................29
A.1. Defined Names ............................................29
A.2. IssuerName, SubjectName, and Validity Value Encoding .....29
Appendix B. ASN.1 Structures and OIDs ............................32
Appendix C. Why do Proof-of-Possession (POP) .....................38
1. 序論と用語…3 2. 概要…3 2.1. RFC2511以来の変化…4 3. CertReqMessage構文…4 4. 所有物の証拠(飛び出します)…5 4.1. 署名キーポップス…7 4.2. 主要な暗号文キー…9 4.2.1. 秘密鍵インフォメーションcontent type…11 4.2.2. 秘密鍵構造…12 4.2.3. チャレンジレスポンスガイドライン…13 4.3. 主要な協定キー…14 4.4. パスワードベースのMACの使用…14 5. CertRequest構文…16 6. 規制構文…18 6.1. 登録トークンコントロール…18 6.2. 固有識別文字コントロール…19 6.3. 公表情報管理…19 6.4. オプションコントロールを格納してください…21 6.5. OldCert IDコントロール…23 6.6. 暗号化の主要なコントロールについて議定書の中で述べてください…23 7. RegInfoは制御します…23 7.1utf8ペア…23 7.2certReq…24 8. オブジェクト識別子…24 9. セキュリティ問題…25 10. 参照…26 10.1. 標準の参照…26 10.2. 有益な参照…27 11. 承認…28 RegInfoの名前価値のペアの付録A.使用…29 A.1。 名前を定義します…29 A.2。 IssuerName、SubjectName、および正当性はコード化を評価します…29付録B.ASN.1構造とOIDs…32 付録C.Whyは所有物のProof(POP)をします…38
Schaad Standards Track [Page 2] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[2ページ]。
1. Introduction and Terminology
1. 序論と用語
This document describes the Certificate Request Message Format (CRMF). A Certificate Request Message object is used within a protocol to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information.
このドキュメントはCertificate Request Message Format(CRMF)について説明します。 Certificate Request Messageオブジェクトは認証局(カリフォルニア)に証明書に関する要求を伝えるのにプロトコルの中で使用されます、ことによるとRegistration Authority(RA)を通して、X.509証明書生産の目的のために。 要求は公開鍵と関連レジスト情報を通常含むでしょう。
The certificate request object defined in this document is not a stand-alone protocol. The information defined in this document is designed to be used by an externally defined Certificate Request Protocol (CRP). The referencing protocol is expected to define what algorithms are used, and what registration information and control structures are defined. Many of the requirements in this document refer to the referencing Certificate Request Protocol (CRP).
本書では定義された証明書要求オブジェクトはスタンドアロンのプロトコルではありません。 本書では定義された情報は、外部的に定義されたCertificate Requestプロトコル(CRP)によって使用されるように設計されています。 参照箇所プロトコルが、どんなアルゴリズムが使用されているか、そして、どんなレジスト情報と制御構造が定義されるかを定義すると予想されます。 要件の多くが本書では、参照をつけたCertificate Requestプロトコル(CRP)を示します。
Certificate requests may be submitted by an RA requesting a certificate on behalf of a Subject, by a CA requesting a cross- certificate from another CA, or directly by an End Entity (EE).
証明書要求はSubjectを代表して証明書を要求するRAによって提出されるかもしれません、別のカリフォルニア、または直接End Entityによる十字証明書を要求するカリフォルニアのそばで(EE)。
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document (in uppercase, as shown) are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメント(示されるとしての大文字の)のキーワード「必要で」、“SHOULD"の、そして、「お勧め」の“MUST"、および「5月」はRFC2119[RFC2119]で説明されるように解釈されることです。
2. Overview
2. 概要
Construction of a certification request involves the following steps:
証明要求の工事は以下のステップにかかわります:
a) A CertRequest object is constructed. This object may include the
public key, all or a portion of the Subject name, other requested
certificate fields, and additional control information related to
the registration process. Depending on the CRP, this information
can be specified by the Subject and potentially modified by an
RA, or specified by the RA based on knowledge of the Subject or
documentation presented by the Subject.
a) CertRequestオブジェクトは組み立てられます。 このオブジェクトはSubject名、他の要求された証明書分野、および登録手続に関連する追加制御情報の公開鍵、すべてまたは部分を含むかもしれません。 CRPによって、この情報をSubjectによって指定されて、RAが潜在的に変更するか、またはSubjectに関する知識に基づくRAかSubjectによって提示されたドキュメンテーションは指定できます。
b) If required, a proof-of-possession (of the private key
corresponding to the public key for which a certificate is being
requested) value is calculated.
b) 必要なら、所有物の証拠(証明書が要求されている公開鍵に対応する秘密鍵の)値は計算されます。
c) Additional registration information can be combined with the
proof-of-possession value and the CertRequest structure to form a
CertReqMessage. Additional registration information can be added
by both the Subject and an RA.
c) CertReqMessageを形成するために所有物の証拠値とCertRequest構造に追加レジスト情報を結合できます。 SubjectとRAの両方で追加レジスト情報を加えることができます。
Schaad Standards Track [Page 3] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[3ページ]。
d) The CertReqMessage is securely communicated to a CA. Specific
means of secure transport are to be specified by each CRP that
refers to this document.
d) CertReqMessageはしっかりとカリフォルニアに伝えられます。 安全な輸送の特定の手段はこのドキュメントを示す各CRPによって指定されることです。
2.1. Changes since RFC 2511
2.1. RFC2511以来の変化
1. Addition of an introduction section.
1. 序論部の参加。
2. Addition of the concept of a CRP and language relating to CRPs.
2. CRPsに関連するCRPと言語の概念の追加。
3. In section 6.2, changed regToken to authenticator.
3. セクション6.2、固有識別文字への変えられたregTokenで。
4. Add information describing the contents of the EncryptedValue
structure.
4. EncryptedValue構造のコンテンツについて説明する情報を加えてください。
5. Changed name and contents of OID {id-regInfo 1}.
5. OIDイド-regInfo1の変名とコンテンツ。
6. Added text detailing what goes into the fields of the different
structures defined in the document.
6. 何がドキュメントで定義された異なった構造の分野に行くかを詳しく述べるテキストを加えました。
7. Replaced Appendix A with a reference to [RFC2875]. The only
difference is that the old text specified to use subject alt name
instead of subject name if subject name was empty. This is not
possible for a CA certificate issued using PKIX. It would
however be useful to update RFC 2875 to have this fallback
position.
7. Appendix Aを[RFC2875]の参照に取り替えました。 唯一の違いは対象の名前が空であったなら対象のaltを使用するために指定された古いテキストが受けることがあることの代わりに名前を挙げるということです。 PKIXを使用することで発行されたカリフォルニア証明書には、これは可能ではありません。 しかしながら、この後退位置を持つためにRFC2875をアップデートするのは役に立つでしょう。
7. Insert Appendix C describing why POP is necessary and what some
of the different POP attacks are.
7. POPがなぜ必要であるか、そして、異なったPOP攻撃のいくつかが何であるかを説明して、Appendix Cを挿入してください。
8. pop field in the CertReqMsg structure has been renamed to popo to
avoid confusion between POP and pop.
8. CertReqMsg構造の大衆的な分野は、POPとポップスの間の混乱を避けるためにpopoに改名されました。
9. The use of the EncryptedValue structure has been deprecated in
favor of the EnvelopedData structure.
9. EncryptedValue構造の使用はEnvelopedData構造を支持して推奨しないです。
10. Add details on how private keys are to be structured when
encrypted.
10. 暗号化されるとどう構造化されるかに関する秘密鍵がことである詳細を加えてください。
11. Allow for POP on key agreement algorithms other than DH.
11. DH以外の主要な協定アルゴリズムのPOPを考慮してください。
3. CertReqMessage Syntax
3. CertReqMessage構文
A certificate request message is composed of the certificate request, an optional proof-of-possession field, and an optional registration information field.
証明書要求メッセージは証明書要求、任意の所有物の証拠分野、および任意のレジスト情報分野で構成されます。
Schaad Standards Track [Page 4] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[4ページ]。
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMessages:、:= CertReqMsgの系列サイズ(1..MAX)
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL
}
CertReqMsg:、:= 系列certReq CertRequest、popo ProofOfPossession OPTIONAL、--内容がAttributeTypeAndValue OPTIONALの主要なタイプregInfo SEQUENCE SIZE(1..MAX)による
The fields of CertReqMsg have the following meaning:
CertReqMsgの分野には、以下の意味があります:
certReq contains the template of the certificate being requested.
The template is filled in by (or on behalf of) the Subject. Not
all fields within the template need to be specified. Details on
this field are found in section 5.
certReqは要求されている証明書のテンプレートを含んでいます。 を代表してまたは、テンプレートがいっぱいにされる、()、Subject。 テンプレートの中のすべての分野が、指定される必要があるというわけではありません。 このフィールドに関する詳細はセクション5で見つけられます。
popo contains the value used to demonstrate that the entity that
will be identified as the Subject of the certificate is actually
in possession of the corresponding private key. This field varies
in structure and content based on the public key algorithm and the
mode (encryption vs. signature) in which the algorithm is used, as
specified in the KeyUsage field of the certificate to be issued.
Details on this field are found in section 4.
popoは証明書のSubjectとして特定される実体が実際に対応する秘密鍵の所有物にあるのを示すのに使用される値を含んでいます。 この分野はアルゴリズムが使用されている公開鍵アルゴリズムとモード(暗号化対署名)に基づく構造と内容で異なります、発行される証明書のKeyUsage分野で指定されるように。 このフィールドに関する詳細はセクション4で見つけられます。
regInfo field SHOULD contain only supplementary information
relating to the context of the certificate request, where such
information is required to fulfill the request. This information
might include subscriber contact information, billing information,
or other ancillary information useful to fulfillment of the
request.
regInfo分野SHOULDはそのような情報が要求を実現させるのに必要である証明書要求の文脈に関連する補助情報だけを含んでいます。 この情報は要求の遂行の役に立つ加入者問い合わせ先、支払い情報、または他の補助的情報を含むかもしれません。
Information directly related to certificate content SHOULD be included in the certReq content. However, inclusion of additional certReq content by RAs can invalidate the popo field (depending on the details of the POP method used). Therefore, data intended for certificate content MAY be provided in regInfo.
含まれていて、情報はcertReq内容で直接証明書内容SHOULDに関連しました。 しかしながら、RAsによる追加certReq内容の包含はpopo分野を無効にすることができます(メソッドが使用したPOPの細部によって)。 したがって、証明書内容のために意図するデータをregInfoに提供するかもしれません。
It is the responsibility of a referencing CRP to define the details of what can be specified in the regInfo field. This document describes one method of encoding the information found in this field. Details on this encoding are found in Appendix A.
それは参照箇所CRPがregInfo分野で指定できることに関する詳細を定義する責任です。 このドキュメントはこの野原で発見される情報をコード化する1つのメソッドを説明します。 このコード化に関する詳細はAppendix Aで見つけられます。
4. Proof-of-Possession (POP)
4. 所有物の証拠(ポップス)です。
In order to prevent certain attacks (see Appendix C) and to allow a CA/RA to properly check the validity of the binding between a subject and a key pair, the PKI management structures specified here make it possible for a subject to prove that it has possession of (i.e., is
すなわちある攻撃(Appendix Cを見る)を防いで、カリフォルニア/RAが適切に対象と主要な組の間の結合の正当性をチェックするのを許容するために、ここで指定されたPKI経営組織で対象が、所有物を持っていると立証するのにおいて可能になる、(。
Schaad Standards Track [Page 5] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[5ページ]。
able to use) the private key corresponding to the public key for which a certificate is requested. A given CRP is free to choose how to enforce POP (e.g., out-of-band procedural means versus the CRMF in-band message) in its certification exchanges. Within a given CRP, CAs and RAs are free to choose from among the POP methods provided (i.e., this is a policy issue local to an RA/CA). A CRP SHOULD define either which POP methods are required, or specify a mechanism for clients to discover the POP methods supported.
使用) 証明書が要求されている公開鍵に対応する秘密鍵に、できます。 与えられたCRPが自由にPOPを実施する方法を選ぶことができる、(例えば、外、-、-バンドにおけるCRMFメッセージ) 証明が交換するコネに対して手続き上の手段を括ってください。 与えられたCRPの中では、CAsとRAsは提供されたPOPメソッドから自由に選ぶことができます(すなわち、これはRA/カリフォルニアへのローカルの政策問題です)。 CRP SHOULDは、どのPOPメソッドが必要であるかを定義するか、またはクライアントがメソッドがサポートしたPOPを発見するように、メカニズムを指定します。
Any CRP referencing this document MUST enforce POP by some means. There are currently many non-PKIX operational protocols in use (various electronic mail protocols are one example) that do not explicitly check the binding between the end entity and the private key. Until operational protocols that do verify the binding (for signature, encryption, and key agreement key pairs) exist, and are ubiquitous, this binding cannot be assumed to have been verified by the CA/RA. Therefore, one cannot truly know if the binding of the public key and the identity in the certificate is actually correct.
このドキュメントに参照をつけるどんなCRPもどうでもPOPを実施しなければなりません。 終わりの実体と秘密鍵の間には、明らかに結合をチェックしない使用中の多くの非PKIX操作上のプロトコル(様々な電子メールプロトコルは1つの例である)が現在、あります。 結合(署名、暗号化、および主要な協定主要な組)について確かめる操作上のプロトコルが存在していて、遍在するまで、カリフォルニア/RAによって確かめられたとこの結合を思うことができません。 したがって、本当に、人は、公開鍵の結合と証明書のアイデンティティが実際に正しいかどうかを知ることができません。
POP is accomplished in different ways depending on the type of key for which a certificate is requested. If a key can be used for multiple purposes (e.g., a signing and decryption RSA key), then any of the methods MAY be used. Protocol designers need to be aware that there can be hardware limitations on what POP methods may be usable, e.g., if the private key is maintained in a hardware token.
POPは証明書が要求されているキーのタイプに頼る異なった方法で達成されます。 複数の目的(例えば、署名と復号化RSAキー)にキーを使用できるなら、メソッドのいずれも使用されるかもしれません。 プロトコルデザイナーは、どんなPOPメソッドが使用可能であるかもしれないかに関してハードウェア制限があることができるのを意識している必要があります、例えば、秘密鍵がハードウェアトークンで維持されるなら。
This specification allows for cases where POP is validated by the CA, the RA, or both. Some policies require the CA to verify POP during certificate issuance, in which case the RA MUST forward the end entity's CertRequest and ProofOfPossession fields unaltered to the CA. (In this case, the RA could verify the POP and reject failing certificate requests rather than forwarding them to the CA.) If the CA is not required by policy to verify POP, then the RA SHOULD forward the end entity's request and proof, unaltered, to the CA as above. If this is not possible (for example because the RA verifies POP by an out-of-band method), then the RA uses the raVerified element to attest to the CA that the required proof has been validated. If the CA/RA uses an out-of-band method to verify POP (such as physical delivery of CA/RA-generated private keys), then the ProofOfPossession field is omitted.
この仕様はPOPがカリフォルニア、RA、または両方によって有効にされるケースを考慮します。 いくつかの方針が証明書発行の間、POPについて確かめるためにカリフォルニアを必要とします、その場合、RA MUSTは終わりの実体のCertRequestとProofOfPossessionにカリフォルニアに非変更された野原を送ります。 (この場合、RAはそれらをカリフォルニアに送るよりむしろPOPについて確かめて、失敗証明書要求を拒絶できました。) カリフォルニアがPOPについて確かめるために方針によって必要とされないなら、RA SHOULDは非変更された終わりの実体の要求と証拠を上のカリフォルニアに転送します。 これが可能でないなら(例えば、RAがバンドで出ているメソッドでPOPについて確かめるので)、RAは必要な証拠が有効にされたとカリフォルニアに証明するのにraVerified要素を使用します。 カリフォルニア/RAがPOP(RAがカリフォルニア/発生している秘密鍵の物理的な配送などの)について確かめるバンドで出ているメソッドを使用するなら、ProofOfPossession分野は省略されます。
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }
ProofOfPossession:、:= 選択[0]NULL、署名[1]POPOSigningKey、keyEncipherment[2]POPOPrivKey、keyAgreement[3]POPOPrivKeyをraVerifiedしました。
Schaad Standards Track [Page 6] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[6ページ]。
The fields of ProofOfPossession have the following meaning:
ProofOfPossessionの分野には、以下の意味があります:
raVerified indicates that the RA has performed the POP required on
the certificate request. This field is used by an RA when 1) the
CA is not required to do its own POP verification and 2) the RA
needs to change the contents of the certReq field. CRPs MUST
provide a method for the RA to sign the ProofOfPossession. A
requestor MUST NOT set this field and an RA/CA MUST NOT accept a
ProofOfPossession where the requestor sets this field.
raVerifiedされました。RAが証明書要求のときに必要であったPOPを実行したのを示します。 それ自身のPOP検証と2) RAをするカリフォルニアは必要でない1が、)certReq分野のコンテンツを変える必要があるとき、この分野がRAによって使用されます。 CRPsはRAがProofOfPossessionに署名するメソッドを提供しなければなりません。 要請者はこの分野を設定してはいけません、そして、RA/カリフォルニアは要請者がこの分野を設定するProofOfPossessionを受け入れてはいけません。
signature is used for performing POP with signature keys. The
details of this field are covered in section 4.1.
署名は、署名キーでPOPを実行するのに使用されます。 この分野の詳細はセクション4.1でカバーされています。
keyEncipherment is used for performing POP with key encipherment
encryption based keys (i.e., RSA). The details of this field are
covered in section 4.2.
keyEnciphermentは、主要な暗号文暗号化に基づいているキー(すなわち、RSA)でPOPを実行するのに使用されます。 この分野の詳細はセクション4.2でカバーされています。
keyAgreement is used for performing POP with key agreement type
encryption keys (i.e., DH). The details of this field are covered
in section 4.3.
keyAgreementは、主要な協定タイプ暗号化キー(すなわち、DH)でPOPを実行するのに使用されます。 この分野の詳細はセクション4.3でカバーされています。
4.1. Signature Key POP
4.1. 署名キー大衆的です。
POP for a signature key is accomplished by performing a signature operation on a piece of data containing the identity for which the certificate is desired.
証明書が望まれているアイデンティティを含んでいて、署名キーのためのPOPは、データの断片で署名操作を実行することによって、達成されます。
There are three cases that need to be looked at when doing a POP for a signature key:
署名キーのためにPOPをするとき、見られる必要がある3つのケースがあります:
1. The certificate subject has not yet established an authenticated
identity with a CA/RA, but has a password and identity string
from the CA/RA. In this case, the POPOSigningKeyInput structure
would be filled out using the publicKeyMAC choice for authInfo,
and the password and identity would be used to compute the
publicKeyMAC value. The public key for the certificate being
requested would be placed in both the POPOSigningKeyInput and the
Certificate Template structures. The signature field is computed
over the DER-encoded POPOSigningKeyInput structure.
1. 証明書対象には、カリフォルニア/RAと共に認証されたアイデンティティをまだ確立していませんが、パスワードとアイデンティティストリングがカリフォルニア/RAからあります。 この場合、authInfoにpublicKeyMAC選択を使用することでPOPOSigningKeyInput構造は書き込まれるでしょう、そして、パスワードとアイデンティティは、publicKeyMAC値を計算するのに使用されるでしょう。 要求されている証明書のための公開鍵はPOPOSigningKeyInputとCertificate Template構造の両方に置かれるでしょう。 署名分野はDERによってコード化されたPOPOSigningKeyInput構造で計算されます。
2. The CA/RA has established an authenticated identity for the
certificate subject, but the requestor is not placing it into the
certificate request. In this case, the POPOSigningKeyInput
structure would be filled out using the sender choice for
authInfo. The public key for the certificate being requested
would be placed in both the POPOSigningKeyInput and the
Certificate Template structures. The signature field is computed
over the DER-encoded POPOSigningKeyInput structure.
2. カリフォルニア/RAは証明書対象のために認証されたアイデンティティを確立しましたが、要請者は証明書要求にそれを置いていません。 この場合、authInfoに送付者選択を使用することでPOPOSigningKeyInput構造は書き込まれるでしょう。 要求されている証明書のための公開鍵はPOPOSigningKeyInputとCertificate Template構造の両方に置かれるでしょう。 署名分野はDERによってコード化されたPOPOSigningKeyInput構造で計算されます。
Schaad Standards Track [Page 7] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[7ページ]。
3. The certificate subject places its name in the Certificate
Template structure along with the public key. In this case the
poposkInput field is omitted from the POPOSigningKey structure.
The signature field is computed over the DER-encoded certificate
template structure.
3. 証明書対象は公開鍵に伴うCertificate Template構造に名前を置きます。 この場合、poposkInput分野はPOPOSigningKey構造から省略されます。 署名分野はDERによってコード化された証明書テンプレート構造で計算されます。
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
POPOSigningKey:、:= 系列poposkInput[0]POPOSigningKeyInput OPTIONAL、algorithmIdentifier AlgorithmIdentifier、署名BIT STRING
The fields of POPOSigningKey have the following meaning:
POPOSigningKeyの分野には、以下の意味があります:
poposkInput contains the data to be signed, when present. This
field MUST be present when the certificate template does not
contain both the public key value and a subject name value.
存在しているとき、poposkInputは署名されるデータを含んでいます。 証明書テンプレートが公開鍵値と対象の名前値の両方を含まないとき、この分野は存在していなければなりません。
algorithmIdentifier identifiers the signature algorithm and an
associated parameters used to produce the POP value.
署名アルゴリズムと関連パラメタがPOP値を生産するのに使用したalgorithmIdentifier識別子。
signature contains the POP value produce. If poposkInput is
present, the signature is computed over the DER-encoded value of
poposkInput. If poposkInput is absent, the signature is computed
over the DER-encoded value of certReq.
署名はPOP値の生産物を含んでいます。 poposkInputが存在しているなら、署名はpoposkInputのDERによってコード化された値に関して計算されます。 poposkInputが欠けるなら、署名はcertReqのDERによってコード化された値に関して計算されます。
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- used only if an authenticated identity has been
-- established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate)
publicKeyMAC PKMACValue },
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- on the DER-encoded value of publicKey
publicKey SubjectPublicKeyInfo } -- from CertTemplate
POPOSigningKeyInput:、:= SEQUENCE、CertTemplateからのpublicKey publicKey SubjectPublicKeyInfoのDERによってコード化された値の送付者[0]GeneralNameの、そして、認証されたアイデンティティがあった場合にだけ使用されて、送付者(例えば、aからのDN--以前に、発行されるのと現在の有効な証明書)publicKeyMAC PKMACValueにおいて、確立したauthInfo CHOICE(いいえ認証されたGeneralNameが現在存在する--送付者; publicKeyMACがパスワードベースのMACを含んでいるなら、使用されます)
The fields of POPOSigningKeyInput have the following meaning:
POPOSigningKeyInputの分野には、以下の意味があります:
sender contains an authenticated identity that has been previously
established for the subject.
送付者は以前に対象のために確立された認証されたアイデンティティを含みます。
publicKeyMAC contains a computed value that uses a shared secret
between the CA/RA and the certificate requestor.
publicKeyMACはカリフォルニア/RAと証明書要請者の間に共有秘密キーを使用する計算された値を含んでいます。
publicKey contains a copy of the public key from the certificate
template. This MUST be exactly the same value as is contained in
the certificate template.
publicKeyは証明書テンプレートからの公開鍵のコピーを含んでいます。 これは証明書テンプレートに含まれているまさに同じ値であるに違いありません。
Schaad Standards Track [Page 8] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[8ページ]。
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
value BIT STRING }
PKMACValue:、:= 系列algId AlgorithmIdentifier、値のBIT STRING
The fields of PKMACValue have the following meaning:
PKMACValueの分野には、以下の意味があります:
algId identifies the algorithm used to compute the MAC value. All
implementations MUST support id-PasswordBasedMAC. The details on
this algorithm are presented in section 4.4.
algIdはMAC値を計算するのに使用されるアルゴリズムを特定します。 すべての実装がイド-PasswordBasedMACをサポートしなければなりません。 このアルゴリズムに関する詳細はセクション4.4に提示されます。
value contains the computed MAC value. The MAC value is computed
over the DER-encoded public key of the certificate subject.
値は計算されたMAC値を含んでいます。 MAC値は証明書対象のDERによってコード化された公開鍵に関して計算されます。
The CA/RA identifies the shared secret to be used by looking at 1) the general name field in the certificate request or 2) either the regToken (see section 6.1) or authToken (see section 6.2) controls.
カリフォルニア/RAは、1時に見ます) 証明書要求か2における一般名分野) regToken(セクション6.1を見る)かauthToken(セクション6.2を見る)コントロールで使用されるために共有秘密キーを特定します。
4.2. Key Encipherment Keys
4.2. 主要な暗号文キー
POP for key encipherment keys is accomplished by one of three different methods. The private key can be provided to the CA/RA, an encrypted challenge from the CA/RA can be decrypted (direct method), or the created certificate can be returned encrypted and used as the challenge response (indirect method).
主要な暗号文キーのためのPOPは3つの異なったメソッドの1つで達成されます。 カリフォルニア/RAに秘密鍵を提供できて、(ダイレクトメソッド)であるとカリフォルニア/RAからの暗号化された挑戦を解読することができるか、チャレンジレスポンス(間接的なメソッド)として作成された証明書を暗号化されていた状態で返して、使用できます。
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING, -- deprecated
subsequentMessage [1] SubsequentMessage,
dhMAC [2] BIT STRING, -- deprecated
agreeMAC [3] PKMACValue,
encryptedKey [4] EnvelopedData }
-- for keyAgreement (only), possession is proven in this message
-- (which contains a MAC (over the DER-encoded value of the
-- certReq parameter in CertReqMsg, which must include both subject
-- and publicKey) based on a key derived from the end entity's
-- private DH key and the CA's public DH key);
-- the dhMAC value MUST be calculated as per the directions given
-- in RFC 2875 for static DH proof-of-possession.
POPOPrivKey:、:= CHOICE、thisMessage[0]BIT STRING--推奨しないsubsequentMessage[1]SubsequentMessage、dhMAC[2]BIT STRING--推奨しないagreeMAC[3]PKMACValue、(単に)のkeyAgreementのためのencryptedKey[4]EnvelopedData、所有物はこのメッセージで立証されます--、(どれがMACを含んでいるか、(DERによってコード化された値、--、certReqパラメタ、CertReqMsg、それの必須が対象とpublicKeyの両方を含んでいるコネ) 終わりの実体のものから得られたキーに基づいています--、個人的なDHキーとCAの公共のDHキー)、。 -- 与えられた方向に従って所有物の静的なDH証拠のためにRFC2875でdhMAC値について計算しなければなりません。
SubsequentMessage ::= INTEGER {
encrCert (0),
challengeResp (1) }
SubsequentMessage:、:= 整数encrCert(0)、challengeResp(1)
The fields of POPOPrivKey have the following meaning:
POPOPrivKeyの分野には、以下の意味があります:
thisMessage contains the encrypted private key for which a
certificate is to be issued. The possession of the private key is
proved by providing it to the CA/RA. This field was incorrectly
thisMessageは発行される証明書がことである暗号化された秘密鍵を含んでいます。 秘密鍵の所有物は、カリフォルニア/RAにそれを供給することによって、立証されます。 この分野は不当にそうでした。
Schaad Standards Track [Page 9] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[9ページ]。
typed when the specification was first written. The correct way
to use this field is to create an EncryptedValue structure where
the encrypted content is the private key, the EncryptedValue
structure is then wrapped in the BIT STRING type. This field has
been deprecated in favor of encryptedKey.
仕様が最初に書かれたとき、タイプされます。 この分野を使用する適度の方法は暗号化された内容が秘密鍵である、次にEncryptedValue構造がBIT STRINGタイプで包装されるEncryptedValue構造を作成することです。 この分野はencryptedKeyを支持して推奨しないです。
subsequentMessage is used to indicate that the POP will be
completed by decrypting a message from the CA/RA and returning a
response. The type of message to be decrypted is indicated by the
value used.
subsequentMessageは、POPがカリフォルニア/RAからのメッセージを解読して、応答を返すことによって完成するのを示すのに使用されます。 解読されるべきメッセージのタイプは使用される値によって示されます。
encrCert indicates that the certificate issued is to be
returned in an encrypted form. The requestor is required to
decrypt the certificate and prove success to the CA/RA. The
details of this are provided by the CRP.
encrCertは、発行された証明書が暗号化されたフォームで返されることであることを示します。 要請者は、カリフォルニア/RAに証明書を解読して、成功を立証しなければなりません。 この詳細はCRPによって明らかにされます。
challengeResponse indicates that a challenge message is to be
sent from the CA/RA to the requestor. The details of the
challenge message and the response are to be provided by the
CRP.
challengeResponseは、挑戦メッセージがカリフォルニア/RAから要請者に送られることであることを示します。 挑戦メッセージと応答の詳細はCRPによって提供されることです。
dhMAC is used for Diffie-Hellman key agreement keys. It contains
a computed MAC that is obtained by using the requestor's private
key and the CA/RA public key. The use of this field is deprecated
in favor of the agreeMAC field. Details are covered in section
4.3.
dhMACはディフィー-ヘルマンの主要な協定キーに使用されます。 それは要請者の秘密鍵とカリフォルニア/RA公開鍵を使用することによって入手される計算されたMACを含んでいます。 この分野の使用はagreeMAC分野を支持して推奨しないです。 詳細はセクション4.3でカバーされています。
agreeMAC is used for key agreement keys. It contains a computed
MAC that is obtained by using the requestor's private key and a
matching CA/RA public key. Details are covered in section 4.3.
agreeMACは主要な協定キーに使用されます。 それは要請者の秘密鍵を使用することによって入手される計算されたMACと合っているカリフォルニア/RA公開鍵を含んでいます。 詳細はセクション4.3でカバーされています。
macAlg contains the algorithm identifying the method used to
compute the MAC value.
macAlgはMAC値を計算するのに使用されるメソッドを特定するアルゴリズムを含んでいます。
macValue contains the computed MAC value.
macValueは計算されたMAC値を含んでいます。
encryptedKey contains the encrypted private key matching the
public key for which the certificate is to be issued. It also
contains an identification value to indicate it was constructed by
the requestor of the certificate. The enveloped content type MUST
be id-ct-encKeyWithID.
encryptedKeyは発行される証明書がことである公開鍵に合っている暗号化された秘密鍵を含んでいます。 また、それはそれが証明書の要請者によって組み立てられたのを示す識別値を含んでいます。 おおわれたcontent typeがそうであるに違いない、イドct encKeyWithID
It is expected that protocols that incorporate this specification will include the confirmation and challenge-response messages necessary for a complete protocol.
この仕様を取り入れるプロトコルが完全なプロトコルに必要な確認とチャレンジレスポンスメッセージを含むと予想されます。
Schaad Standards Track [Page 10] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[10ページ]。
4.2.1. Private Key Info Content Type
4.2.1. 秘密鍵インフォメーションcontent type
This content type is used for 1) proving possession of private keys and 2) escrow of private keys (using the archive options control in section 6.4). This structure is based on the private key info structure from [PKCS8] but has one deliberate difference. There is a potential attack on escrow agents if they decrypt the private key but don't know to whom the encrypted key is supposed to belong. An attacker could intercept the encrypted private key, build a certificate request around it and then ask for a recovery operation on the private key.
このcontent typeは、1に)秘密鍵と2の所有物) 秘密鍵のエスクローを立証しながら(セクション6.4でアーカイブオプションコントロールを使用して)、使用されます。 この構造には、[PKCS8]からの秘密鍵インフォメーション構造に基づいていますが、1つの慎重な違いがあります。 彼らが秘密鍵を解読するなら、条件付き証書受託者の上に起こり得るかもしれない攻撃がありますが、暗号化されたキーがだれに属するべきであるかを知らないでください。 攻撃者は、暗号化された秘密鍵を妨害して、それの周りで証明書要求を組み込んで、次に、秘密鍵で回復動作を求めることができました。
This content type and its structure are:
このcontent typeとその構造は以下の通りです。
id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}
イドct encKeyWithID、オブジェクト識別子:、:= イドct21
EncKeyWithID ::= SEQUENCE {
privateKey PrivateKeyInfo,
identifier CHOICE {
string UTF8String,
generalName GeneralName
} OPTIONAL
}
EncKeyWithID:、:= 系列privateKey PrivateKeyInfo、識別子CHOICEがUTF8String、generalName GeneralNameを結ぶ、OPTIONAL
PrivateKeyInfo ::= SEQUENCE {
version INTEGER,
privateKeyAlgorithm AlgorithmIdentifier,
privateKey OCTET STRING,
attributes [0] IMPLICIT Attributes OPTIONAL
}
PrivateKeyInfo:、:= 系列バージョンINTEGER、privateKeyAlgorithm AlgorithmIdentifier、privateKey OCTET STRING、属性[0]IMPLICIT Attributes OPTIONAL
Attributes ::= SET OF Attribute
属性:、:= 属性のセット
The fields of EncKeyWithID are defined as:
EncKeyWithIDの分野は以下と定義されます。
privateKey contains the encoded private key. Definitions for
three private key formats are included in this document.
Specifications for asymmetric algorithms need to include both the
public and private key definitions for consistency.
privateKeyはコード化された秘密鍵を含んでいます。 3つの秘密鍵形式のための定義は本書では含まれています。 非対称のアルゴリズムのための仕様は、公衆と一貫性のための秘密鍵定義の両方を含む必要があります。
identifier contains a name that the CA/RA can associate with the
requestor. This will generally be either the DN of a certificate
or a text token passed and known to both the requestor and the
CA/RA. This field MUST be present if the purpose is to prove
possession of the private key. The field SHOULD be present if
archiving a key and the archive agent is expected to decrypt the
key.
識別子はカリフォルニア/RAが要請者に関連づけることができる名前を含んでいます。 一般に、これは、証明書のDNかテキストトークンのどちらかに要請者とカリフォルニア/RAの両方に渡されて、知られているなるでしょう。 この分野は目的が秘密鍵の所有物を立証することであるなら存在していなければなりません。 a主要な状態で現在の、しかし、格納しているSHOULDをさばいてください。そうすれば、アーカイブエージェントがキーを解読すると予想されます。
Schaad Standards Track [Page 11] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[11ページ]。
The fields of PrivatekeyInfo are define as:
PrivatekeyInfoの分野がそうである、以下との定義
version MUST be the value 0
バージョンは値0であるに違いない。
privateKeyAlgorithm contains the identifier for the private key
object
privateKeyAlgorithmは秘密鍵オブジェクトのための識別子を含んでいます。
privateKey is an octet string whose contents is the private key
and whose format is defined by the value of privateKeyAlgorithm.
privateKeyはコンテンツが秘密鍵であり、書式がprivateKeyAlgorithmの値によって定義される八重奏ストリングです。
attributes is a set of attributes. They are extended information
that is part of the private key information.
属性は1セットの属性です。 それらは秘密鍵情報の一部である拡張情報です。
4.2.2. Private Key Structures
4.2.2. 秘密鍵構造
We are defining the structures here to be used for three algorithms.
私たちは、3つのアルゴリズムに使用されるためにここで構造を定義しています。
4.2.2.1. D-H Private Keys
4.2.2.1. D-H秘密鍵
When creating a PrivateKeyInfo for a D-H key, the following rules apply:
D-HキーのためにPrivateKeyInfoを作成するとき、以下の規則は適用されます:
1. The privateKeyAlgorithm MUST be set to id-dh-private-number.
The parameter for id-dh-private-number is DomainParameters
(imported from [PKIXALG]).
1. privateKeyAlgorithmはイドのdhの個人的な番号に用意ができなければなりません。 イドのdhの個人的な番号のためのパラメタはDomainParameters([PKIXALG]から、インポートされる)です。
2. The ASN structure for privateKey MUST be
2. privateKeyのためのASN構造はそうであるに違いありません。
DH-PrivateKey ::= INTEGER
DH-PrivateKey:、:= 整数
3. The attributes field MUST be omitted.
3. 属性分野を省略しなければなりません。
4.2.2.2. DSA Private Keys
4.2.2.2. DSA秘密鍵
When creating a PrivateKeyInfo for a DSA key, the following rules apply:
DSAキーのためにPrivateKeyInfoを作成するとき、以下の規則は適用されます:
1. The privateKeyAlgorithm MUST be set to id-dsa. The parameters
for id-dsa is Dss-Parms (imported from [PKIXALG]).
1. privateKeyAlgorithmはイド-dsaに用意ができなければなりません。 イド-dsaのためのパラメタはDss-Parms([PKIXALG]から、インポートされる)です。
2. The ASN structure for privateKey MUST be
2. privateKeyのためのASN構造はそうであるに違いありません。
DSA-PrivateKey ::= INTEGER
DSA-PrivateKey:、:= 整数
3. The attributes field MUST be omitted.
3. 属性分野を省略しなければなりません。
Schaad Standards Track [Page 12] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[12ページ]。
4.2.2.3. RSA Private Keys
4.2.2.3. RSA秘密鍵
When creating a PrivateKeyInfo for an RSA key, the following rules apply:
RSAキーのためにPrivateKeyInfoを作成するとき、以下の規則は適用されます:
1. The privateKeyAlgorithm MUST be set to rsaEncryption.
1. privateKeyAlgorithmはrsaEncryptionに用意ができなければなりません。
2. The ASN structure for privateKey MUST be RSAPrivateKey (defined
in [PKCS1])
2. privateKeyのためのASN構造はRSAPrivateKeyであるに違いありません。([PKCS1]では、定義されます)
3. The attributes field MUST be omitted.
3. 属性分野を省略しなければなりません。
4.2.3. Challenge-Response Guidelines
4.2.3. チャレンジレスポンスガイドライン
The following provides guidelines to enrollment protocol authors about how an indirect proof-of-possession is expected to work and about some of the areas where one needs to be careful in crafting the messages to implement this POP method.
以下は所有物の間接的な証拠が働くとどう予想されるかの周りと、そして、ものがこのPOPメソッドを実装するメッセージを作るのにおいて慎重である必要がある領域のいくつか周りに関して登録プロトコル作者にガイドラインを提供します。
1. The original enrollment request includes a proof of identity of
some type and the public portion of the encryption key. Note
that the proof of identity needs to cover the public portion of
the encryption key to prevent substitution attacks (where the
attacker changes your public key for his public key).
1. オリジナルの登録要求はタイプの身元の証拠と暗号化キーの公共の部分を含んでいます。 身元の証拠が、代替攻撃(攻撃者が彼の公開鍵のためにあなたの公開鍵を変えるところ)を防ぐために主要な暗号化の公共の部分をカバーする必要に注意してください。
2. The response message from the server includes an encrypted data
value of some type. That value needs to be authenticated in some
fashion as having come from the server. The specification needs
to include the specifics of how this value is returned for the
different key types. For RSA keys, the value can be specified as
being directly encrypted by the RSA public key; this will not
work for a D-H key where you need to specify an indirect
mechanism to encrypt the value.
2. サーバからの応答メッセージはタイプの暗号化されたデータ値を含んでいます。 その値は、サーバから来たと何らかのファッションで認証される必要があります。仕様は、異なった主要なタイプのためにどうこの値を返すかに関する詳細を含む必要があります。 RSAキーにおいて、RSA公開鍵によって直接暗号化されると値を指定できます。 これはあなたが値を暗号化するために間接的機構を指定する必要があるD-Hキーのために働かないでしょう。
3. The second request message includes a hash of the decrypted
value. This message MUST NOT be just the hash of the encrypted
value, as one should never "sign" a completely random value. It
is desirable to include information such as the identity string
in the hashing process so that this can be made explicitly. This
returned value MUST be included in a second proof of identity.
3. 2番目の要求メッセージは解読された価値のハッシュを含んでいます。 このメッセージはまさしく暗号化された価値のハッシュであるはずがありません、完全に無作為の値に決して「署名するべきでない」とき。 論じ尽くすプロセスのアイデンティティストリングなどの情報を含んでいるのは、明らかにこれを作ることができるくらい望ましいです。 身元の2番目の証拠にこの戻り値を含まなければなりません。
It is strongly suggested that transaction identifiers and nonce values be required when performing indirect POP, as this allows for 1) tying the different messages in the process together and 2) letting each entity inject some amount of random data into the process of doing identity proofs.
間接的なPOPを実行するとき、トランザクション識別子と一回だけの値が必要であることが強く提案されます、これが、1)タイイングのために一緒にプロセスと2における異なったメッセージ) 各実体にいくらかの量の無作為のデータをアイデンティティに証拠をするプロセスに注がせるのを許容するように。
Schaad Standards Track [Page 13] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[13ページ]。
4.3. Key Agreement Keys
4.3. 主要な協定キー
POP for key agreement keys is accomplished by one of four different methods. The first three are identical to those presented above for key encryption keys. The fourth method takes advantage of the fact that a shared secret is produced and that the value can be used to MAC information.
主要な協定キーのためのPOPは4つの異なったメソッドの1つで達成されます。 最初の3は主要な暗号化キーのために上に提示されたものと同じです。 4番目のメソッドは共有秘密キーを作り出して、MAC情報に値を使用できるという事実を利用します。
When the direct or indirect encryption methods presented above are used, the CA/RA will need to create an ephemeral key for those cases where the encryption algorithm parameters do not match between the CA/RA and the requestor.
上に提示された直接の、または、間接的な暗号化メソッドが使用されているとき、カリフォルニア/RAは、暗号化アルゴリズムパラメタがカリフォルニア/RAと要請者の間で合っていないそれらのケースのためのはかないキーを作成する必要があるでしょう。
The end entity may also MAC the certificate request (using a shared secret key derived from computation) as a fourth alternative for demonstrating POP. This option may be used only if the CA/RA already has a certificate that is known to the end entity and if the Subject is able to use the CA/RA's parameters.
また、終わりの実体がそうするかもしれない、MAC、4分の1にPOPのデモをするのにおける代替としての証明書要求(計算から得られた共有された秘密鍵を使用します)。 カリフォルニア/RAで終わりの実体に知られている証明書が単に既にあって、Subjectがカリフォルニア/RAのパラメタを使用できるなら、このオプションは使用されるかもしれません。
For the DH key agreement algorithm, all implementations MUST support the static DH Proof-of-Possession. Details on this algorithm can be found in section 3 of [RFC2875]. NOTE: If either the subject or issuer name in the CA certificate is empty, then the alternative name should be used in its place.
DHの主要な協定アルゴリズムのために、すべての実装が所有物の静的なDH Proofをサポートしなければなりません。 [RFC2875]のセクション3でこのアルゴリズムに関する詳細を見つけることができます。 以下に注意してください。 カリフォルニア証明書の対象か発行人名が空であるなら、代替名は場所で使用されるべきです。
4.4. Use of Password-Based MAC
4.4. パスワードベースのMACの使用
This MAC algorithm was designed to take a shared secret (a password) and use it to compute a check value over a piece of information. The assumption is that, without the password, the correct check value cannot be computed. The algorithm computes the one-way function multiple times in order to slow down any dictionary attacks against the password value.
このMACアルゴリズムは、共有秘密キー(パスワード)を取って、1つの情報に関してチェック値を計算するのにそれを使用するように設計されました。 仮定はパスワードなしで正しいチェック値を計算できないということです。 アルゴリズムは、パスワード値に対してどんな辞書攻撃も減速させるために複数の回一方向関数を計算します。
The algorithm identifier and parameter structure used for Password- Based MAC is:
PasswordのベースのMACに使用されるアルゴリズム識別子とパラメタ構造は以下の通りです。
id-PasswordBasedMAC OBJECT IDENTIFIER ::=
{ 1 2 840 113533 7 66 13}
イド-PasswordBasedMACオブジェクト識別子:、:= { 1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
iterationCount INTEGER,
mac AlgorithmIdentifier
)
PBMParameter:、:= SEQUENCE、塩のOCTET STRING、owf AlgorithmIdentifier、iterationCount INTEGER、mac AlgorithmIdentifier)
Schaad Standards Track [Page 14] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[14ページ]。
The fields of PEMParameter have the following meaning:
PEMParameterの分野には、以下の意味があります:
salt contains a randomly generated value used in computing the key
of the MAC process. The salt SHOULD be at least 8 octets (64
bits) long.
塩はMACプロセスのキーを計算する際に使用される手当たりしだいに発生している値を含んでいます。 塩のSHOULDは少なくともそうです。長さ(64ビット)の8つの八重奏。
owf identifies the algorithm and associated parameters used to
compute the key used in the MAC process. All implementations MUST
support SHA-1.
owfはMACプロセスで使用されるキーを計算するのに使用されるアルゴリズムと関連パラメタを特定します。 すべての実装がSHA-1をサポートしなければなりません。
iterationCount identifies the number of times the hash is applied
during the key computation process. The iterationCount MUST be a
minimum of 100. Many people suggest using values as high as 1000
iterations as the minimum value. The trade off here is between
protection of the password from attacks and the time spent by the
server processing all of the different iterations in deriving
passwords. Hashing is generally considered a cheap operation but
this may not be true with all hash functions in the future.
iterationCountはハッシュが主要な計算プロセスの間、適用されるという回の数を特定します。 iterationCountは最低100歳であるに違いありません。 多くの人々が、最小値として値を1000繰り返しと同じくらい高く使用することを提案します。 ここでの取り引きは攻撃からのパスワードの保護と時間の間ではパスワードを引き出すことにおける異なった繰り返しのすべてにサーバ処理で費やされていたということです。 論じ尽くすことは安い操作であると一般に考えられますが、これは将来、すべてのハッシュ関数では本当でないかもしれません。
mac identifies the algorithm and associated parameters of the MAC
function to be used. All implementations MUST support HMAC-SHA1
[HMAC]. All implementations SHOULD support DES-MAC and Triple-
DES-MAC [PKCS11].
macは、使用されるためにMAC機能のアルゴリズムと関連パラメタを特定します。 すべての実装がHMAC-SHA1[HMAC]をサポートしなければなりません。 すべての実装SHOULDが、DES-MACとTripleがデス-Mac[PKCS11]であるとサポートします。
The following is pseudo-code for the algorithm:
↓これはアルゴリズムのための中間コードです:
Inputs:
pw - an octet string containing the user's password
data - an octet string containing the value to be MAC-ed
Iter - iteration count
入力: pw--ユーザのパスワードデータ--MAC-教育Iterになるように値を含む八重奏ストリング--繰り返しカウントを含む八重奏ストリング
Output:
MAC - an octet string containing the resultant MAC value
出力: MAC--結果のMAC値を含む八重奏ストリング
1. Generate a random salt value S
1. 無作為の塩の値がSであると生成してください。
2. Append the salt to the pw. K = pw || salt.
2. 塩をpwに追加してください。 K=pw|| 塩。
3. Hash the value of K. K = HASH(K)
3. K.K=HASHの値を論じ尽くしてください。(K)
4. If Iter is greater than zero. Iter = Iter - 1. Goto step 3.
4. Iterがゼロ以上であるなら。 IterはIterと等しいです--1。 ゴトーのステップ3。
5. Compute an HMAC as documented in [HMAC].
5. [HMAC]に記録されるようにHMACを計算してください。
MAC = HASH( K XOR opad, HASH( K XOR ipad, data) )
Mac=ハッシュ(K XOR opad、HASH(K XOR ipad、データ))
Where opad and ipad are defined in [HMAC].
opadとipadが[HMAC]で定義されるところ。
Schaad Standards Track [Page 15] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[15ページ]。
5. CertRequest syntax
5. CertRequest構文
The CertRequest syntax consists of a request identifier, a template of certificate content, and an optional sequence of control information.
CertRequest構文は要求識別子、証明書内容のテンプレート、および制御情報の任意の系列から成ります。
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
certTemplate CertTemplate, --Selected fields of cert to be issued
controls Controls OPTIONAL } -- Attributes affecting issuance
CertRequest:、:= SEQUENCE、certReqId INTEGER(合っている要求と回答certTemplate CertTemplateのためのID)は、コントロールControls OPTIONALが本命の分野に発行されるのを選択しました--感激的な発行を結果と考えます。
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }
CertTemplate:、:= 系列バージョン[0]バージョンOPTIONAL、serialNumber[1]INTEGER OPTIONAL、signingAlg[2]AlgorithmIdentifier OPTIONAL、発行人[3]名前OPTIONAL(正当性[4]OptionalValidity OPTIONAL)は[5] 名前OPTIONALをかけます、publicKey[6]SubjectPublicKeyInfo OPTIONAL、issuerUID[7]UniqueIdentifier OPTIONAL、subjectUID[8]UniqueIdentifier OPTIONAL、拡大[9]拡大OPTIONAL
OptionalValidity ::= SEQUENCE {
notBefore [0] Time OPTIONAL,
notAfter [1] Time OPTIONAL } --at least one must be present
OptionalValidity:、:= SEQUENCE、notBefore[0]はOPTIONAL、notAfter[1]時間OPTIONALを調節します--少なくとも存在していなければなりません。
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
以下を調節してください:= 選択utcTime UTCTime、generalTime GeneralizedTime
The fields of CertRequest have the following meaning:
CertRequestの分野には、以下の意味があります:
certReqId contains an integer value that is used by the
certificate requestor to associate a specific certificate request
with a certificate response.
certReqIdは特定の証明書要求を証明書応答に関連づけるのに証明書要請者によって使用される整数値を含んでいます。
certTemplate contains a template of an X.509 certificate. The
requestor fills in those fields for which specific values are
desired. Details on the fields are given below.
certTemplateはX.509証明書のテンプレートを含んでいます。 要請者は特定の値が望まれているそれらの分野に記入します。 フィールドに関する詳細は以下に述べられます。
controls contains attributes that are not part of the certificate,
but control the context in which the certificate is to be issued.
Details on the controls defined in this document can be found in
section 6. Other documents may define other controls. CRPs are
responsible for specifying which controls are required.
コントロールは証明書の一部でない属性を含みますが、発行される証明書がことである文脈を制御してください。 セクション6で本書では定義されたコントロールに関する詳細を見つけることができます。 他のドキュメントは他のコントロールを定義するかもしれません。 どのコントロールが必要であるかを指定するのにCRPsは責任があります。
Schaad Standards Track [Page 16] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[16ページ]。
The fields of CertTemplate have the following meaning:
CertTemplateの分野には、以下の意味があります:
version MUST be 2 if supplied. It SHOULD be omitted.
供給するなら、バージョンは2であるに違いありません。 それ、SHOULD、省略されてください。
serialNumber MUST be omitted. This field is assigned by the CA
during certificate creation.
serialNumberを省略しなければなりません。 この分野は証明書作成の間、カリフォルニアによって割り当てられます。
signingAlg MUST be omitted. This field is assigned by the CA
during certificate creation.
signingAlgを省略しなければなりません。 この分野は証明書作成の間、カリフォルニアによって割り当てられます。
issuer is normally omitted. It would be filled in with the CA
that the requestor desires to issue the certificate in situations
where an RA is servicing more than one CA.
通常、発行人は省略されます。 それは要請者が状況におけるRAが1つ以上を修理している証明書にカリフォルニアを発行することを望んでいるカリフォルニアと共に記入されるでしょう。
validity is normally omitted. It can be used to request that
certificates either start at some point in the future or expire at
some specific time. A case where this field would commonly be
used is when a cross certificate is issued for a CA. In this case
the validity of an existing certificate would be placed in this
field so that the new certificate would have the same validity
period as the existing certificate. If validity is not omitted,
then at least one of the sub-fields MUST be specified. The sub-
fields are as follows:
通常、正当性は省略されます。 証明書が将来、何らかのポイントで始まるか、またはいつかの特定の時に期限が切れるよう要求するのにそれを使用できます。 この分野が一般的に使用されるケースは交差している証明書がカリフォルニアに発行される時です。 この場合、既存の証明書の正当性は、新しい証明書には既存の証明書と同じ有効期間があるように、この分野に置かれるでしょう。 正当性が省略されないなら、少なくともサブ分野の1つを指定しなければなりません。 サブ分野は以下の通りです:
notBefore contains the requested start time of the certificate.
The time follows the same rules as the notBefore time in
[PROFILE].
notBeforeは証明書の要求された開始時刻を含んでいます。 時間は[PROFILE]でnotBefore時間と同じ規則に従います。
notAfter contains the requested expiration time of the
certificate. The time follows the same rules as the notAfter
time in [PROFILE].
notAfterは証明書の要求された満了時間を含んでいます。 時間は[PROFILE]でnotAfter時間と同じ規則に従います。
subject is filled in with the suggested name for the requestor.
This would normally be filled in by a name that has been
previously issued to the requestor by the CA.
対象は要請者のために提案された名前で記入されます。 通常、これは以前にカリフォルニアによって要請者に発行された名前によって記入されるでしょう。
publicKey contains the public key for which the certificate is
being created. This field MUST be filled in if the requestor
generates its own key. The field is omitted if the key is
generated by the RA/CA.
publicKeyは証明書が作成されている公開鍵を含んでいます。 要請者がそれ自身のキーを生成するなら、この分野に記入しなければなりません。 キーがRA/カリフォルニアによって生成されるなら、分野は省略されます。
issuerUID MUST be omitted. This field has been deprecated in
[PROFILE].
issuerUIDを省略しなければなりません。 この分野は[PROFILE]で推奨しないです。
subjectUID MUST be omitted. This field has been deprecated in
[PROFILE].
subjectUIDを省略しなければなりません。 この分野は[PROFILE]で推奨しないです。
Schaad Standards Track [Page 17] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[17ページ]。
extensions contains extensions that the requestor wants to have
placed in the certificate. These extensions would generally deal
with things such as setting the key usage to keyEncipherment.
拡大は要請者が証明書に置きたがっていた拡大を含んでいます。 一般に、これらの拡大は主要な用法をkeyEnciphermentに設定などなどのものに対処するでしょう。
With the exception of the publicKey field, the CA/RA is permitted to alter any requested field. The returned certificate needs to be checked by the requestor to see if the fields have been set in an acceptable manner. CA/RA SHOULD use the template fields if possible.
publicKey分野を除いて、カリフォルニア/RAがどんな要求された分野も変更することが許可されています。 返された証明書は、分野が許容できる方法で設定されたかどうか確認するために要請者によってチェックされる必要があります。 できれば、カリフォルニア/RA SHOULDはテンプレート分野を使用します。
There are cases where all fields of the template can be omitted. If the key generation is being done at the CA/RA and the identity proof is placed in a different location (such as the id-regCtrl-regToken below), then there are no fields that need to be specified by the certificate requestor.
ケースがテンプレートのすべての分野を省略できるところにあります。 カリフォルニア/RAにキー生成をしていて、別の場所(以下のイド-regCtrl-regTokenなどの)にアイデンティティ証拠を置くなら、証明書要請者によって指定される必要がある分野が全くありません。
6. Controls Syntax
6. 規制構文
The generator of a CertRequest may include one or more control values pertaining to the processing of the request.
CertRequestのジェネレータは要求の処理に関係する1つ以上のコントロール値を含むかもしれません。
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
コントロール:、:= AttributeTypeAndValueの系列サイズ(1..MAX)
The following controls are defined by this document: regToken (section 6.1); authenticator (section 6.2); pkiPublicationInfo (section 6.3); pkiArchiveOptions (section 6.4); oldCertID (section 6.5); protocolEncrKey (section 6.6). Each CRP MUST define the set of controls supported by that protocol. Additional controls may be defined by additional RFCs or by the CRP protocol itself.
以下のコントロールはこのドキュメントによって定義されます: regToken(セクション6.1)。 固有識別文字(セクション6.2)。 pkiPublicationInfo(セクション6.3)。 pkiArchiveOptions(セクション6.4)。 oldCertID(セクション6.5)。 protocolEncrKey(セクション6.6)。 各CRP MUSTはそのプロトコルで後押しされているコントロールのセットを定義します。 追加コントロールは追加RFCsかCRPプロトコル自体によって定義されるかもしれません。
6.1. Registration Token Control
6.1. 登録トークンコントロール
A regToken control contains one-time information (either based on a secret value or other shared information) intended to be used by the CA to verify the identity of the subject prior to issuing a certificate. Upon receipt of a certification request containing a value for regToken, the receiving CA verifies the information in order to confirm the identity claimed in the certification request.
regTokenコントロールは証明書を下付する前に対象のアイデンティティについて確かめるのにカリフォルニアによって使用されることを意図する1回の情報(秘密の値か他の共有された情報に基づいた)を含んでいます。 regTokenのための値を含む証明要求を受け取り次第、受信カリフォルニアは、証明要求で要求されたアイデンティティを確認するために情報について確かめます。
The value for regToken may be generated by the CA and provided out of band to the subscriber, or may otherwise be available to both the CA and the subscriber. The security of any out-of-band exchange should be commensurate with the risk that the CA will tolerate with regard to accepting an intercepted value from someone other than the intended subscriber. The regToken value is not encrypted on return, if the data is considered to be sensitive, it needs to be shrouded by the requestor.
regTokenのための値は、カリフォルニアが生成して、バンドから加入者に提供するかもしれないか、またはそうでなければ、カリフォルニアと加入者の両方に利用可能であるかもしれません。 どんなバンドで出ている交換のセキュリティもカリフォルニアが意図している加入者以外のだれかから妨害された値を受け入れることに関して許容する危険について等しいはずです。 regToken値はリターンのときに暗号化されません、データが敏感であると考えられるならそれは、要請者によって覆い隠される必要があります。
Schaad Standards Track [Page 18] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[18ページ]。
The regToken control is used only for initialization of an end entity into the PKI, whereas the authenticator control (see section 7.2) can be used for the initial as well as subsequent certification requests.
regTokenコントロールは終わりの実体の初期化にだけPKIに使用されますが、初期の、そして、その後の証明要求に、固有識別文字コントロール(セクション7.2を見る)を使用できます。
In some instances of use the value for regToken could be a text string or a numeric quantity such as a random number. In the latter case, the value is encoded as a text string representation of the binary quantity. The encoding of regToken SHALL be UTF8String.
使用のいくつかのインスタンスでは、regTokenのための値は、乱数などのテキスト文字列か数値量であるかもしれません。 後者の場合では、値は2進の量のテキスト文字列表現としてコード化されます。 UTF8StringになってくださいregToken SHALLがコード化されて。
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
イド-regCtrl-regTokenオブジェクト識別子:、:= イド-regCtrl1
Without prior agreement between the subscriber and CA agents, this value would be a textual shared secret of some type. If a computed value based on that shared secret is to be used instead, it is suggested that the CRP define a new registration control for that specific computation.
加入者とカリフォルニアのエージェントとの事前同意がなければ、この値はタイプの原文の共有秘密キーでしょう。 その共有秘密キーに基づく計算された値が代わりに使用されることであるなら、CRPがその特定の計算のための新規登録コントロールを定義することが提案されます。
6.2. Authenticator Control
6.2. 固有識別文字コントロール
An authenticator control contains information used on an ongoing basis to establish a non-cryptographic check of identity in communication with the CA. Examples include: mother's maiden name, last four digits of social security number, or other knowledge-based information shared with the subscriber's CA; a hash of such information; or other information produced for this purpose. The value for an authenticator control may be generated by the subscriber or by the CA.
固有識別文字コントロールはカリフォルニアとのコミュニケーションにおける、アイデンティティの非暗号のチェックを確立する進行中ベースに使用される情報を含んでいます。 例は: 母親の旧姓、社会保険番号の下4ケタ、または他の知識ベースの情報が加入者のカリフォルニアと共有されました。 そのような情報のハッシュ。 または、他の情報はこのために作り出されました。 固有識別文字コントロールのための値は加入者かカリフォルニアによって生成されるかもしれません。
In some instances of use, the value for authenticator could be a text string or a numeric quantity such as a random number. The value in the latter case is encoded as a text string representation of the binary quantity. The encoding of authenticator SHALL be UTF8String.
ある場合に、役に立ちます、固有識別文字のための値は、乱数などのテキスト文字列か数値量であるかもしれません。 後者の場合における値は2進の量のテキスト文字列表現としてコード化されます。 UTF8Stringになってください固有識別文字SHALLがコード化されて。
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
イドregCtrl固有識別文字オブジェクト識別子:、:= イド-regCtrl2
When deciding whether to use an authenticator or a regToken, use the following guidelines. If the value is a one-time usage value, then regToken would be used. If the value has a long-term usage, then the authenticator control would be used.
固有識別文字かregTokenを使用するかどうか決めるときには、以下のガイドラインを使用してください。 値が1回の用法値であるなら、regTokenは使用されるでしょう。 値に長期の用法があるなら、固有識別文字コントロールは使用されるでしょう。
6.3. Publication Information Control
6.3. 公表情報管理
The pkiPublicationInfo control enables subscribers to influence the CA/RA's publication of the certificate. This control is considered advisory and can be ignored by CAs/RAs. It is defined by the following OID and syntax:
pkiPublicationInfoコントロールは、加入者がカリフォルニア/RAの証明書の公表に影響を及ぼすのを可能にします。 このコントロールを顧問であると考えて、CAs/RAsは無視できます。 それは以下のOIDと構文で定義されます:
Schaad Standards Track [Page 19] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[19ページ]。
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
イド-regCtrl-pkiPublicationInfoオブジェクト識別子:、:= イド-regCtrl3
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
PKIPublicationInfo:、:= 系列動作INTEGER、dontPublish(0)、pleasePublish(1)、pubInfos SEQUENCE SIZE(1..MAX)OF SinglePubInfo OPTIONAL
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
SinglePubInfo:、:= 系列pubMethod INTEGER、pubLocation GeneralName OPTIONAL、dontCare(0)(x500(1)、ウェブ(2))は(3)をldapします。
The fields of PKIPublicationInfo have the following meaning:
PKIPublicationInfoの分野には、以下の意味があります:
action indicates whether or not the requestor wishes the CA/RA to
publish the certificate. The values and their means are:
動作は、要請者が、カリフォルニア/RAに証明書を発表して欲しいかどうかを示します。 値とそれらの手段は以下の通りです。
dontPublish indicates that the requester wishes the CA/RA not
to publish the certificate (this may indicate that the
requester intends to publish the certificate him/herself). If
dontPublish is used, the pubInfos field MUST be omitted.
dontPublishは、リクエスタが、カリフォルニア/RAが証明書を発表しない必要であるのを示します(これは、リクエスタが自己に証明書を発表するつもりであるのを示すかもしれません)。 dontPublishが使用されているなら、pubInfos分野を省略しなければなりません。
pleasePublish indicates that the requestor wishes the CA/RA to
publish the certificate.
pleasePublishは、要請者が、カリフォルニア/RAに証明書を発表して欲しいのを示します。
pubInfos holds the locations where the requestor desires the CA/RA
to publish the certificate. This field is omitted if the
dontPublish choice is selected. If the requestor wants to specify
some locations for the certificate to be published, and to allow
the CA/RA to publish in other locations, it would specify multiple
values of the SinglePubInfo structure, one of which would be
dontCare.
pubInfosは要請者が、カリフォルニア/RAが証明書を発表することを望んでいる位置を保持します。 dontPublish選択が選択されるなら、この分野は省略されます。 要請者が証明書が発表されて、カリフォルニア/RAが他の位置で発行するのを許容するために数個の位置を指定したいと思うなら、それはSinglePubInfo構造の複数の値を指定するでしょう。その1つはdontCareでしょう。
The fields of SinglePubInfo have the following meaning:
SinglePubInfoの分野には、以下の意味があります:
pubMethod indicates the address type for the location at which the
requestor desires the certificate to be placed by the CA/RA.
pubMethodは要請者が、証明書がカリフォルニア/RAによって置かれることを望んでいる位置にアドレスタイプを示します。
dontCare indicates that the CA/RA can publish the certificate
in whatever locations it chooses. If dontCare is used, the
pubInfos field MUST be omitted.
dontCareは、カリフォルニア/RAがそれが選ぶどんな位置でも証明書を発表できるのを示します。 dontCareが使用されているなら、pubInfos分野を省略しなければなりません。
Schaad Standards Track [Page 20] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[20ページ]。
x500 indicates that the requestor wishes for the CA/RA to
publish the certificate in a specific location. The location
is indicated in the x500 field of pubLocation.
x500は、要請者が、カリフォルニア/RAに特定の位置で証明書を発表して欲しいのを示します。 位置はpubLocationのx500分野で示されます。
ldap indicates that the requestor wishes for the CA/RA to
publish the certificate in a specific location. The location
is indicated in the ldap field of pubLocation.
ldapは、要請者が、カリフォルニア/RAに特定の位置で証明書を発表して欲しいのを示します。 位置はpubLocationのldap分野で示されます。
web indicates that the requestor wishes for the CA/RA to
publish the certificate in a specific location. The location
is indicated in the http field of pubLocation.
ウェブは、要請者が、カリフォルニア/RAに特定の位置で証明書を発表して欲しいのを示します。 位置はpubLocationのhttp分野で示されます。
pubLocation contains the address at which the certificate is to be
placed. The choice in the general name field is dictated by the
pubMethod selection in this structure.
pubLocationは置かれる証明書がことであるアドレスを含んでいます。 一般名分野での選択はこの構造にpubMethod選択で書き取られます。
Publication locations can be supplied in any order. All locations are to be processed by the CA for purposes of publication.
順不同に公表位置を供給できます。 すべての位置が公表の目的のためにカリフォルニアによって処理されることになっています。
6.4. Archive Options Control
6.4. アーカイブオプションコントロール
The pkiArchiveOptions control enables subscribers to supply information needed to establish an archive of the private key corresponding to the public key of the certification request. It is defined by the following OID and syntax:
pkiArchiveOptionsコントロールは、加入者が証明要求の公開鍵に対応する秘密鍵のアーカイブを確立するのに必要である情報を提供するのを可能にします。 それは以下のOIDと構文で定義されます:
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
イド-regCtrl-pkiArchiveOptionsオブジェクト識別子:、:= イド-regCtrl4
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey,
-- the actual value of the private key
keyGenParameters [1] KeyGenParameters,
-- parameters which allow the private key to be re-generated
archiveRemGenPrivKey [2] BOOLEAN }
-- set to TRUE if sender wishes receiver to archive the private
-- key of a key pair that the receiver generates in response to
-- this request; set to FALSE if no archival is desired.
PKIArchiveOptions:、:= に対応してCHOICE、encryptedPrivKey[0]EncryptedKey--秘密鍵keyGenParameters[1]KeyGenParametersの実価--秘密鍵が作り直されたarchiveRemGenPrivKey[2]であることをブールで許容するパラメタ(送付者が兵卒を格納するために受信機を願うなら、TRUEに設定される)が受信機が生成する主要な組に合わせる、--この要求。 記録保管所でないなら、FALSEへのセットは望まれています。
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue, -- deprecated
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedKey:、:= CHOICE、encryptedValue EncryptedValue--、推奨しないenvelopedData[0]EnvelopedData、--暗号化された秘密鍵をenvelopedDataに置かなければなりません--encryptedContentInfo encryptedContent OCTET STRING
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- the intended algorithm for which the value will be used
symmAlg [1] AlgorithmIdentifier OPTIONAL,
EncryptedValue:、:= SEQUENCE、intendedAlg[0]AlgorithmIdentifier OPTIONAL--値が中古のsymmAlg[1]AlgorithmIdentifier OPTIONALである意図しているアルゴリズム
Schaad Standards Track [Page 21] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[21ページ]。
-- the symmetric algorithm used to encrypt the value
encSymmKey [2] BIT STRING OPTIONAL,
-- the (encrypted) symmetric key used to encrypt the value
keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- algorithm used to encrypt the symmetric key
valueHint [4] OCTET STRING OPTIONAL,
-- a brief description or identifier of the encValue content
-- (may be meaningful only to the sending entity, and used only
-- if EncryptedValue might be re-examined by the sending entity
-- in the future)
encValue BIT STRING }
-- The use of the EncryptedValue field has been deprecated in favor
-- of the EnvelopedData structure.
--
-- When EncryptedValue is used to carry a private key (as opposed to
-- a certificate), implementations MUST support the encValue field
-- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
-- section 12.11. If encValue contains some other format/encoding
-- for the private key, the first octet of valueHint MAY be used
-- to indicate the format/encoding (but note that the possible values
-- of this octet are not specified at this time). In all cases, the
-- intendedAlg field MUST be used to indicate at least the OID of
-- the intended algorithm of the private key, unless this information
-- is known a priori to both sender and receiver by some other means.
-- 左右対称のアルゴリズムは以前はよく値のencSymmKey[2]BIT STRING OPTIONALを暗号化していました--(暗号化される)の対称鍵は以前はよく値のkeyAlg[3]AlgorithmIdentifier OPTIONALを暗号化していました--アルゴリズムは以前はよく対称鍵valueHint[4]OCTET STRING OPTIONAL--encValue内容に関する簡単な説明か識別子--(送付実体だけに重要であるかもしれなく、使用されて、EncryptedValue力であるなら未来の送付実体によって単に再検討されてください)encValue BIT STRINGを暗号化していました。 -- EncryptedValue分野の使用はEnvelopedData構造で賛成していた状態で推奨しないです。 -- -- と対照的に、EncryptedValueが秘密鍵を運ぶのに使用される、(--、証明書)、実装は、[PKCS11]で定義されるように暗号化されたPrivateKeyInfoを含んでいるencValue分野がセクション12.11であるとサポートしなければなりません。 encValueが秘密鍵のためのある他の形式/コード化を含んでいるなら、valueHintの最初の八重奏は使用されるかもしれません--(この八重奏の可能な値をある注意がこのとき、指定しなかった)形式/コード化を示すために。 すべての場合で--intendedAlg分野は少なくともOIDを示すのにおいて使用されているに違いありません--、秘密鍵の意図しているアルゴリズム、この情報--ある他の手段によって先験的に送付者と受信機の両方に知られています。
KeyGenParameters ::= OCTET STRING
KeyGenParameters:、:= 八重奏ストリング
The fields of PKIArchiveOptions have the following meaning:
PKIArchiveOptionsの分野には、以下の意味があります:
encryptedPrivKey contains an encrypted version of the private key.
encryptedPrivKeyは秘密鍵の暗号化されたバージョンを含んでいます。
keyGenParameters contains the information needed by the requestor
to regenerate the private key. As an example, for many RSA
implementations one could send the first random number(s) tested
for primality. The structure to go here is not defined by this
document. CRPs that define content for this structure MUST define
not only the content that is to go here, but also how that data is
shrouded from unauthorized access.
keyGenParametersは秘密鍵を作り直すために要請者によって必要とされた情報を含んでいます。 例として、多くのRSA実装のために、1つはprimalityがないかどうかテストされた最初の乱数を送るかもしれません。 ここに行く構造はこのドキュメントによって定義されません。 この構造のための内容を定義するCRPsはそのデータがここに行くことになっている内容だけではなく、不正アクセスからどう覆い隠されもするかも定義しなければなりません。
archiveRemGenPrivKey indicates that the requestor desires that the
key generated by the CA/RA on the requestor's behalf be archived.
archiveRemGenPrivKeyは、キーが要請者の代理のカリフォルニア/RAで生んだ要請者願望が格納されるのを示します。
The fields of EncryptedKey have the following meaning:
EncryptedKeyの分野には、以下の意味があります:
encryptedValue is longer used. This field has been deprecated
along with the EncryptedValue structure.
encryptedValue is longer used. This field has been deprecated along with the EncryptedValue structure.
Schaad Standards Track [Page 22] RFC 4211 Internet X.509 CRMF September 2005
Schaad Standards Track [Page 22] RFC 4211 Internet X.509 CRMF September 2005
envelopedData contains the encrypted value of the private key.
CPRs that use this structure MUST define the entity or entities
for whom the data is to be encrypted (the EE, escrow agents, CAs)
and how that key or set of keys is to be determined. Details on
constructing an EnvelopedData structure are found in [CMS]. The
encrypted content MUST be an id-ct-encKeyWithID. The identifier
can be omitted unless this structure is also being used to do
proof-of-possession.
envelopedData contains the encrypted value of the private key. CPRs that use this structure MUST define the entity or entities for whom the data is to be encrypted (the EE, escrow agents, CAs) and how that key or set of keys is to be determined. Details on constructing an EnvelopedData structure are found in [CMS]. The encrypted content MUST be an id-ct-encKeyWithID. The identifier can be omitted unless this structure is also being used to do proof-of-possession.
6.5. OldCert ID Control
6.5. OldCert ID Control
If present, the OldCertID control specifies the certificate to be updated by the current certification request. The OID and syntax is:
If present, the OldCertID control specifies the certificate to be updated by the current certification request. The OID and syntax is:
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER
}
CertId ::= SEQUENCE { issuer GeneralName, serialNumber INTEGER }
6.6. Protocol Encryption Key Control
6.6. Protocol Encryption Key Control
If present, the protocolEncrKey control specifies a key that the CA is to use in encrypting a response to CertReqMessages. The OID for this control is id-regCtrl-protocolEncrKey. The parameter structure for this field is SubjectPublicKeyInfo. (This structure is defined in [PROFILE].)
If present, the protocolEncrKey control specifies a key that the CA is to use in encrypting a response to CertReqMessages. The OID for this control is id-regCtrl-protocolEncrKey. The parameter structure for this field is SubjectPublicKeyInfo. (This structure is defined in [PROFILE].)
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
This control is used when a CA has information to send to the subscriber that needs to be encrypted. Such information includes a private key generated by the CA for use by the subscriber.
This control is used when a CA has information to send to the subscriber that needs to be encrypted. Such information includes a private key generated by the CA for use by the subscriber.
7. RegInfo Controls
7. RegInfo Controls
This section documents the controls that are to be placed in the regInfo field of the CertReqMsg structure.
This section documents the controls that are to be placed in the regInfo field of the CertReqMsg structure.
7.1. utf8Pairs
7.1. utf8Pairs
This control is used to convey text-based information from the Subject to an RA to a CA issuing a certificate. The OID for this structure is id-regInfo-utf8Paris and has a type of UTF8String.
This control is used to convey text-based information from the Subject to an RA to a CA issuing a certificate. The OID for this structure is id-regInfo-utf8Paris and has a type of UTF8String.
id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
Schaad Standards Track [Page 23] RFC 4211 Internet X.509 CRMF September 2005
Schaad Standards Track [Page 23] RFC 4211 Internet X.509 CRMF September 2005
The name is terminated by the question mark character ('?'). The
value is terminated by the percent character '%'. Name value pairs
can be repeated. Thus the syntax is:
The name is terminated by the question mark character ('?'). The value is terminated by the percent character '%'. Name value pairs can be repeated. Thus the syntax is:
Name?Value%[Name?Value%]*
Name?Value%[Name?Value%]*
The %xx mechanism of [RFC1738] is used to encode '?' (%3f) and '%' (%25) if they are not being used for their reserved purpose. Names MUST NOT start with a numeric character.
The %xx mechanism of [RFC1738] is used to encode '?' (%3f) and '%' (%25) if they are not being used for their reserved purpose. Names MUST NOT start with a numeric character.
This control can appear multiple times in the regInfo structure. Resolution of conflicts of information is a matter of local policy on the RA/CA.
This control can appear multiple times in the regInfo structure. Resolution of conflicts of information is a matter of local policy on the RA/CA.
Appendix A contains a set of common names and data formats corresponding to fields that commonly appear in certificates and directories.
Appendix A contains a set of common names and data formats corresponding to fields that commonly appear in certificates and directories.
7.2. certReq
7.2. certReq
This control is designed to deal with the problem where an RA needs to modify the certificate template proposed by a Subject, but the Subject used the certificate template as part of its POP calculation. In this case, the RA can place a new certificate template in the regInfo sequence.
This control is designed to deal with the problem where an RA needs to modify the certificate template proposed by a Subject, but the Subject used the certificate template as part of its POP calculation. In this case, the RA can place a new certificate template in the regInfo sequence.
This control has the OID id-regInfo-certReq and the structure CertRequest. There can only be one instance of this attribute in the regInfo sequence. If this control exists in the regInfo structure, then the certificate template in the request is ignored. The RA MUST copy all data from the core template to this attribute.
This control has the OID id-regInfo-certReq and the structure CertRequest. There can only be one instance of this attribute in the regInfo sequence. If this control exists in the regInfo structure, then the certificate template in the request is ignored. The RA MUST copy all data from the core template to this attribute.
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
8. Object Identifiers
8. Object Identifiers
The OID id-pkix has the value
The OID id-pkix has the value
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
-- arc for Internet X.509 PKI protocols and their components
id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) }
-- arc for Internet X.509 PKI protocols and their components id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) }
-- arc for Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
-- arc for Registration Controls in CRMF id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
Schaad Standards Track [Page 24] RFC 4211 Internet X.509 CRMF September 2005
Schaad Standards Track [Page 24] RFC 4211 Internet X.509 CRMF September 2005
-- arc for Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }
-- arc for Registration Info in CRMF id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }
9. Security Considerations
9. Security Considerations
Enrollment protocols, by their very nature, involve large amounts of private information. This can include private keys, identity numbers, credit card numbers, and the like. The security of any CRP is based on the security mechanisms of the protocol and/or process used to communicate between CAs, RAs and EEs. All protocols must provide for masking, either via encryption or off-line processing, of all subscriber-sensitive information.
Enrollment protocols, by their very nature, involve large amounts of private information. This can include private keys, identity numbers, credit card numbers, and the like. The security of any CRP is based on the security mechanisms of the protocol and/or process used to communicate between CAs, RAs and EEs. All protocols must provide for masking, either via encryption or off-line processing, of all subscriber-sensitive information.
Many enrollment protocols provide for the initial establishment of identity between the CA/RA and the EE by the use of a token. Generally this token is delivered using an out-of-band delivery method (such as the governmental mail system). The security of any out-of-band exchange needs to be commensurate with the risk that the CA/RA will tolerate with regard to interception of the token by a third party.
Many enrollment protocols provide for the initial establishment of identity between the CA/RA and the EE by the use of a token. Generally this token is delivered using an out-of-band delivery method (such as the governmental mail system). The security of any out-of-band exchange needs to be commensurate with the risk that the CA/RA will tolerate with regard to interception of the token by a third party.
Implementation must implement Proof-of-Possession (POP) values during certificate enrollment processes. A good POP algorithm needs to provide proof of two things: 1) that the key is tied to a specific user and 2) that the user has use of the key in question. Failure to implement POP allows people to create certificates where the public key and the name values do not correctly bind. This allows for impersonation on signature keys and interception of encrypted messages.
Implementation must implement Proof-of-Possession (POP) values during certificate enrollment processes. A good POP algorithm needs to provide proof of two things: 1) that the key is tied to a specific user and 2) that the user has use of the key in question. Failure to implement POP allows people to create certificates where the public key and the name values do not correctly bind. This allows for impersonation on signature keys and interception of encrypted messages.
Implementations must use high entropy random number generators in producing private keys. Implementations must randomly generate content-encryption keys, message-authentication keys, initialization vectors (IVs), salt, and padding. The use of inadequate pseudo- random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.
Implementations must use high entropy random number generators in producing private keys. Implementations must randomly generate content-encryption keys, message-authentication keys, initialization vectors (IVs), salt, and padding. The use of inadequate pseudo- random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.
Implementations must protect private keys. The compromise of a signer's private key permits third parties to masquerade as the signer. The compromise of a decryption private key allows for interception of messages by a third party.
Implementations must protect private keys. The compromise of a signer's private key permits third parties to masquerade as the signer. The compromise of a decryption private key allows for interception of messages by a third party.
Schaad Standards Track [Page 25] RFC 4211 Internet X.509 CRMF September 2005
Schaad Standards Track [Page 25] RFC 4211 Internet X.509 CRMF September 2005
One feature of the certificate message request syntax is for the key generation to be performed remotely from the creation of the certificate request. This feature should never be used for generation of signing keys. If signing keys are generated for the user, then an element of repudiation comes into play. The user can claim that an item was signed by the entity that generated the key as well as any entity that might have seen the key value during transfer from the generator the to EE. Care must be taken to protect encryption keys by the remote key generator to protect against interception of the keys by a third party. This means that the encryption algorithms used need to be secure, and a content encryption key or a key encryption key must be used to mask the private key during transport back to the user. CRP protocols must never assume that a signature key generated by the user can be used to decrypt the package in which an encryption private key is transported.
One feature of the certificate message request syntax is for the key generation to be performed remotely from the creation of the certificate request. This feature should never be used for generation of signing keys. If signing keys are generated for the user, then an element of repudiation comes into play. The user can claim that an item was signed by the entity that generated the key as well as any entity that might have seen the key value during transfer from the generator the to EE. Care must be taken to protect encryption keys by the remote key generator to protect against interception of the keys by a third party. This means that the encryption algorithms used need to be secure, and a content encryption key or a key encryption key must be used to mask the private key during transport back to the user. CRP protocols must never assume that a signature key generated by the user can be used to decrypt the package in which an encryption private key is transported.
This document describes a method by which key escrow may be done. There are several issues that need to be taken into account when doing key escrow. First, the client must be able to correctly identify the entity to which a key is to be escrowed or the CRP must provide a method by which the client can discover this information. A CRP cannot assume that the key escrow agent and the CA are the same entity and thus have the same names. Second, the algorithms used to mask the private key or other key generation information during transport to the escrow agent need to be commensurate with the value of the data being protected by the key. Third, the escrow agent needs to provide sufficient safeguards that an escrowed key is returned only to entities that should be able to obtain the private key. Generally, this should be restricted to the entity that escrowed the data. Fourth, the escrow data base needs to be stored in a secure manner. One common method for doing this is to re- encrypt the data to keys that only the escrow agent has access to. In this case, one may need to escrow the escrow agent key as well. Access to either the escrow agent or the archived key would amount to access to all private keys that have been escrowed with that agent.
This document describes a method by which key escrow may be done. There are several issues that need to be taken into account when doing key escrow. First, the client must be able to correctly identify the entity to which a key is to be escrowed or the CRP must provide a method by which the client can discover this information. A CRP cannot assume that the key escrow agent and the CA are the same entity and thus have the same names. Second, the algorithms used to mask the private key or other key generation information during transport to the escrow agent need to be commensurate with the value of the data being protected by the key. Third, the escrow agent needs to provide sufficient safeguards that an escrowed key is returned only to entities that should be able to obtain the private key. Generally, this should be restricted to the entity that escrowed the data. Fourth, the escrow data base needs to be stored in a secure manner. One common method for doing this is to re- encrypt the data to keys that only the escrow agent has access to. In this case, one may need to escrow the escrow agent key as well. Access to either the escrow agent or the archived key would amount to access to all private keys that have been escrowed with that agent.
10. References
10. References
10.1. Normative References
10.1. Normative References
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
Schaad Standards Track [Page 26] RFC 4211 Internet X.509 CRMF September 2005
Schaad Standards Track [Page 26] RFC 4211 Internet X.509 CRMF September 2005
[PKCS11] RSA Laboratories, The Public-Key Cryptography Standards -
"PKCS #11 v2.11: Cryptographic Token Interface Standard",
RSA Security Inc., June 2001.
[PKCS11] RSA Laboratories, The Public-Key Cryptography Standards - "PKCS #11 v2.11: Cryptographic Token Interface Standard", RSA Security Inc., June 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002.
[PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC2875] Prafullchandra, H. and J. Schaad, "Diffie-Hellman
Proof-of-Possession Algorithms", RFC 2875, July 2000.
[RFC2875] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-of-Possession Algorithms", RFC 2875, July 2000.
10.2. Informative References
10.2. Informative References
[DSS] National Institute of Standards and Technology, FIPS Pub
186: Digital Signature Standard, May 1994.
[DSS] National Institute of Standards and Technology, FIPS Pub 186: Digital Signature Standard, May 1994.
[PKCS8] RSA Laboratories, "PKCS #8: Private-Key Information Syntax
Standard", PKCS #8 v1.2, November 1993.
[PKCS8] RSA Laboratories, "PKCS #8: Private-Key Information Syntax Standard", PKCS #8 v1.2, November 1993.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
HMAC-SHA-1", RFC 2202, September 1997.
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", RFC 2202, September 1997.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
Schaad Standards Track [Page 27] RFC 4211 Internet X.509 CRMF September 2005
Schaad Standards Track [Page 27] RFC 4211 Internet X.509 CRMF September 2005
11. Acknowledgements
11. Acknowledgements
The working group would like to thank Michael Myers, Carlisle Adams, Dave Solo, and David Kemp, who authored the original version of this document.
The working group would like to thank Michael Myers, Carlisle Adams, Dave Solo, and David Kemp, who authored the original version of this document.
The working group also gratefully acknowledges the contributions of Barbara Fox, Warwick Ford, Russ Housley, and John Pawling, whose review and comments significantly clarified and improved the utility of this specification. The members of the ca-talk mailing list also provided significant input with respect to interoperability testing.
The working group also gratefully acknowledges the contributions of Barbara Fox, Warwick Ford, Russ Housley, and John Pawling, whose review and comments significantly clarified and improved the utility of this specification. The members of the ca-talk mailing list also provided significant input with respect to interoperability testing.
The text of Appendix C (Why do POP) was taken from an e-mail message by Al Arsenault and was originally part of the PKIX Roadmap document.
The text of Appendix C (Why do POP) was taken from an e-mail message by Al Arsenault and was originally part of the PKIX Roadmap document.
Schaad Standards Track [Page 28] RFC 4211 Internet X.509 CRMF September 2005
Schaad Standards Track [Page 28] RFC 4211 Internet X.509 CRMF September 2005
Appendix A. Use of RegInfo for Name-Value Pairs
Appendix A. Use of RegInfo for Name-Value Pairs
The "value" field of the id-regInfo-utf8Pairs string (with "tag" field equal to 12 and appropriate "length" field) will contain a series of UTF-8 name/value pairs.
The "value" field of the id-regInfo-utf8Pairs string (with "tag" field equal to 12 and appropriate "length" field) will contain a series of UTF-8 name/value pairs.
This Appendix lists some common examples of such pairs for the purpose of promoting interoperability among independent implementations of this specification. It is recognized that this list is not exhaustive and will grow with time and implementation experience.
This Appendix lists some common examples of such pairs for the purpose of promoting interoperability among independent implementations of this specification. It is recognized that this list is not exhaustive and will grow with time and implementation experience.
A.1. Defined Names
A.1. Defined Names
The following table defines a recommended set of named elements. The value in the column "Name Value" is the exact text string that will appear in the regInfo.
The following table defines a recommended set of named elements. The value in the column "Name Value" is the exact text string that will appear in the regInfo.
Name Value
----------
version -- version of this variation of regInfo use
corp_company -- company affiliation of subscriber
org_unit -- organizational unit
mail_firstName -- personal name component
mail_middleName -- personal name component
mail_lastName -- personal name component
mail_email -- subscriber's email address
jobTitle -- job title of subscriber
employeeID -- employee identification number or string
mailStop -- mail stop
issuerName -- name of CA
subjectName -- name of Subject
validity -- validity interval
Name Value ---------- version -- version of this variation of regInfo use corp_company -- company affiliation of subscriber org_unit -- organizational unit mail_firstName -- personal name component mail_middleName -- personal name component mail_lastName -- personal name component mail_email -- subscriber's email address jobTitle -- job title of subscriber employeeID -- employee identification number or string mailStop -- mail stop issuerName -- name of CA subjectName -- name of Subject validity -- validity interval
For example:
For example:
version?1%corp_company?Example, Inc.%org_unit?Engineering%
mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader%
mail_email?john@example.com%
version?1%corp_company?Example, Inc.%org_unit?Engineering% mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader% mail_email?john@example.com%
A.2. IssuerName, SubjectName, and Validity Value Encoding
A.2. IssuerName, SubjectName, and Validity Value Encoding
When they appear in id-regInfo-utf8Pairs syntax as named elements, the encoding of values for issuerName, subjectName, and validity SHALL use the following syntax. The characters [] indicate an optional field, ::= and | have their usual BNF meanings, and all other symbols (except spaces, which are insignificant) outside non- terminal names are terminals. Alphabetics are case-sensitive.
When they appear in id-regInfo-utf8Pairs syntax as named elements, the encoding of values for issuerName, subjectName, and validity SHALL use the following syntax. The characters [] indicate an optional field, ::= and | have their usual BNF meanings, and all other symbols (except spaces, which are insignificant) outside non- terminal names are terminals. Alphabetics are case-sensitive.
Schaad Standards Track [Page 29] RFC 4211 Internet X.509 CRMF September 2005
Schaad Standards Track [Page 29] RFC 4211 Internet X.509 CRMF September 2005
issuerName ::= <names>
subjectName ::= <names>
<names> ::= <name> | <names>:<name>
issuerName ::= <names> subjectName ::= <names> <names> ::= <name> | <names>:<name>
<validity> ::= validity ? [<notbefore>]-[<notafter>]
<validity> ::= validity ? [<notbefore>]-[<notafter>]
<notbefore> ::= <time>
<notafter> ::= <time>
<notbefore> ::= <time> <notafter> ::= <time>
Where <time> is UTC time in the form YYYYMMDD[HH[MM[SS]]]. HH, MM, and SS default to 00 and are omitted if at the and of value 00.
Where <time> is UTC time in the form YYYYMMDD[HH[MM[SS]]]. HH, MM, and SS default to 00 and are omitted if at the and of value 00.
Example validity encoding:
Example validity encoding:
validity?-19991231%
validity?-19991231%
is a validity interval with no value for notBefore, and a value of December 31, 1999 for notAfter.
is a validity interval with no value for notBefore, and a value of December 31, 1999 for notAfter.
Each name comprises a single character name form identifier, followed by a name value of one or more UTF-8 characters. Within a name value, when it is necessary to disambiguate a character that has formatting significance at an outer level, the escape sequence %xx SHALL be used, where xx represents the hex value for the encoding concerned. The percent symbol is represented by %%.
Each name comprises a single character name form identifier, followed by a name value of one or more UTF-8 characters. Within a name value, when it is necessary to disambiguate a character that has formatting significance at an outer level, the escape sequence %xx SHALL be used, where xx represents the hex value for the encoding concerned. The percent symbol is represented by %%.
<name> ::= X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname>
<name> ::= X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname>
Name forms and value formats are as follows:
Name forms and value formats are as follows:
X.500 directory name form (identifier "X"):
X.500 directory name form (identifier "X"):
<xname> ::= <rdns>
<rdns> ::= <rdn> | <rdns> , <rdn>
<rdn> ::= <avas>
<avas> ::= <ava> | <avas> + <ava>
<ava> ::= <attyp> = <avalue>
<attyp> ::= OID.<oid> | <stdat>
<xname> ::= <rdns> <rdns> ::= <rdn> | <rdns> , <rdn> <rdn> ::= <avas> <avas> ::= <ava> | <avas> + <ava> <ava> ::= <attyp> = <avalue> <attyp> ::= OID.<oid> | <stdat>
Schaad Standards Track [Page 30] RFC 4211 Internet X.509 CRMF September 2005
Schaad Standards Track [Page 30] RFC 4211 Internet X.509 CRMF September 2005
Standard attribute type <stdat> is an alphabetic attribute type identifier from the following set:
Standard attribute type <stdat> is an alphabetic attribute type identifier from the following set:
C (country)
L (locality)
ST (state or province)
O (organization)
OU (organizational unit)
CN (common name)
STREET (street address)
E (E-mail address).
C (country) L (locality) ST (state or province) O (organization) OU (organizational unit) CN (common name) STREET (street address) E (E-mail address).
<avalue> is a name component in the form of a UTF-8 character string of 1 to 64 characters, with the restriction that in the IA5 subset of UTF-8 only the characters of ASN.1 PrintableString may be used.
<avalue> is a name component in the form of a UTF-8 character string of 1 to 64 characters, with the restriction that in the IA5 subset of UTF-8 only the characters of ASN.1 PrintableString may be used.
Other name form (identifier "O"):
<oname> ::= <oid> , <utf8string>
Other name form (identifier "O"): <oname> ::= <oid> , <utf8string>
E-mail address (rfc822name) name form (identifier "E"):
<ename> ::= <ia5string>
E-mail address (rfc822name) name form (identifier "E"): <ename> ::= <ia5string>
DNS name form (identifier "D"):
<dname> ::= <ia5string>
DNS name form (identifier "D"): <dname> ::= <ia5string>
URI name form (identifier "U"):
<uname> ::= <ia5string>
URI name form (identifier "U"): <uname> ::= <ia5string>
IP address (identifier "I"):
<iname> ::= <oid>
IP address (identifier "I"): <iname> ::= <oid>
For example:
For example:
issuerName?XOU=Our CA,O=Example,C=US% subjectName?XCN=John Smith,
O=Example, C=US, E=john@example.com%
issuerName?XOU=Our CA,O=Example,C=US% subjectName?XCN=John Smith, O=Example, C=US, E=john@example.com%
Schaad Standards Track [Page 31] RFC 4211 Internet X.509 CRMF September 2005
Schaad Standards Track [Page 31] RFC 4211 Internet X.509 CRMF September 2005
Appendix B. ASN.1 Structures and OIDs
Appendix B. ASN.1 Structures and OIDs
PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36)}
PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36)}
DEFINITIONS IMPLICIT TAGS ::= BEGIN
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
-- Directory Authentication Framework (X.509)
Version, AlgorithmIdentifier, Name, Time,
SubjectPublicKeyInfo, Extensions, UniqueIdentifier, Attribute
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)} -- found in [PROFILE]
IMPORTS -- Directory Authentication Framework (X.509) Version, AlgorithmIdentifier, Name, Time, SubjectPublicKeyInfo, Extensions, UniqueIdentifier, Attribute FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)} -- found in [PROFILE]
-- Certificate Extensions (X.509)
GeneralName
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19)} -- found in [PROFILE]
-- Certificate Extensions (X.509) GeneralName FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19)} -- found in [PROFILE]
-- Cryptographic Message Syntax
EnvelopedData
FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms-2004(24) }; -- found in [CMS]
-- Cryptographic Message Syntax EnvelopedData FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }; -- found in [CMS]
-- The following definition may be uncommented for use with -- ASN.1 compilers that do not understand UTF8String.
-- The following definition may be uncommented for use with -- ASN.1 compilers that do not understand UTF8String.
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents of this type correspond to RFC 2279.
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING -- The contents of this type correspond to RFC 2279.
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 7 }
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) 7 }
-- arc for Internet X.509 PKI protocols and their components
-- arc for Internet X.509 PKI protocols and their components
id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 } -- content types
id-ct OBJECT IDENTIFIER ::= { id-smime 1 } -- content types
Schaad Standards Track [Page 32] RFC 4211 Internet X.509 CRMF September 2005
Schaad Standards Track [Page 32] RFC 4211 Internet X.509 CRMF September 2005
-- Core definitions for this module
-- Core definitions for this module
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
CertReqMsg ::= SEQUENCE { certReq CertRequest, popo ProofOfPossession OPTIONAL, -- content depends upon key type regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
certTemplate CertTemplate, -- Selected fields of cert to be issued
controls Controls OPTIONAL } -- Attributes affecting issuance
CertRequest ::= SEQUENCE { certReqId INTEGER, -- ID for matching request and reply certTemplate CertTemplate, -- Selected fields of cert to be issued controls Controls OPTIONAL } -- Attributes affecting issuance
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }
CertTemplate ::= SEQUENCE { version [0] Version OPTIONAL, serialNumber [1] INTEGER OPTIONAL, signingAlg [2] AlgorithmIdentifier OPTIONAL, issuer [3] Name OPTIONAL, validity [4] OptionalValidity OPTIONAL, subject [5] Name OPTIONAL, publicKey [6] SubjectPublicKeyInfo OPTIONAL, issuerUID [7] UniqueIdentifier OPTIONAL, subjectUID [8] UniqueIdentifier OPTIONAL, extensions [9] Extensions OPTIONAL }
OptionalValidity ::= SEQUENCE {
notBefore [0] Time OPTIONAL,
notAfter [1] Time OPTIONAL } -- at least one MUST be present
OptionalValidity ::= SEQUENCE { notBefore [0] Time OPTIONAL, notAfter [1] Time OPTIONAL } -- at least one MUST be present
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type OBJECT IDENTIFIER,
value ANY DEFINED BY type }
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue AttributeTypeAndValue ::= SEQUENCE { type OBJECT IDENTIFIER, value ANY DEFINED BY type }
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
-- used if the RA has already verified that the requester is in
-- possession of the private key
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }
ProofOfPossession ::= CHOICE { raVerified [0] NULL, -- used if the RA has already verified that the requester is in -- possession of the private key signature [1] POPOSigningKey, keyEncipherment [2] POPOPrivKey, keyAgreement [3] POPOPrivKey }
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
POPOSigningKey ::= SEQUENCE { poposkInput [0] POPOSigningKeyInput OPTIONAL, algorithmIdentifier AlgorithmIdentifier, signature BIT STRING }
Schaad Standards Track [Page 33] RFC 4211 Internet X.509 CRMF September 2005
Schaad Standards Track [Page 33] RFC 4211 Internet X.509 CRMF September 2005
-- The signature (using "algorithmIdentifier") is on the -- DER-encoded value of poposkInput. NOTE: If the CertReqMsg -- certReq CertTemplate contains the subject and publicKey values, -- then poposkInput MUST be omitted and the signature MUST be -- computed over the DER-encoded value of CertReqMsg certReq. If -- the CertReqMsg certReq CertTemplate does not contain both the -- public key and subject values (i.e., if it contains only one -- of these, or neither), then poposkInput MUST be present and -- MUST be signed.
-- The signature (using "algorithmIdentifier") is on the -- DER-encoded value of poposkInput. NOTE: If the CertReqMsg -- certReq CertTemplate contains the subject and publicKey values, -- then poposkInput MUST be omitted and the signature MUST be -- computed over the DER-encoded value of CertReqMsg certReq. If -- the CertReqMsg certReq CertTemplate does not contain both the -- public key and subject values (i.e., if it contains only one -- of these, or neither), then poposkInput MUST be present and -- MUST be signed.
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- used only if an authenticated identity has been
-- established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate)
publicKeyMAC PKMACValue },
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- on the DER-encoded value of publicKey
publicKey SubjectPublicKeyInfo } -- from CertTemplate
POPOSigningKeyInput ::= SEQUENCE { authInfo CHOICE { sender [0] GeneralName, -- used only if an authenticated identity has been -- established for the sender (e.g., a DN from a -- previously-issued and currently-valid certificate) publicKeyMAC PKMACValue }, -- used if no authenticated GeneralName currently exists for -- the sender; publicKeyMAC contains a password-based MAC -- on the DER-encoded value of publicKey publicKey SubjectPublicKeyInfo } -- from CertTemplate
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
-- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13}
-- parameter value is PBMParameter
value BIT STRING }
PKMACValue ::= SEQUENCE { algId AlgorithmIdentifier, -- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13} -- parameter value is PBMParameter value BIT STRING }
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [HMAC, RFC2202])
PBMParameter ::= SEQUENCE { salt OCTET STRING, owf AlgorithmIdentifier, -- AlgId for a One-Way Function (SHA-1 recommended) iterationCount INTEGER, -- number of times the OWF is applied mac AlgorithmIdentifier -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], } -- or HMAC [HMAC, RFC2202])
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING, -- Deprecated
-- possession is proven in this message (which contains the private
-- key itself (encrypted for the CA))
subsequentMessage [1] SubsequentMessage,
-- possession will be proven in a subsequent message
dhMAC [2] BIT STRING, -- Deprecated
agreeMAC [3] PKMACValue,
encryptedKey [4] EnvelopedData }
POPOPrivKey ::= CHOICE { thisMessage [0] BIT STRING, -- Deprecated -- possession is proven in this message (which contains the private -- key itself (encrypted for the CA)) subsequentMessage [1] SubsequentMessage, -- possession will be proven in a subsequent message dhMAC [2] BIT STRING, -- Deprecated agreeMAC [3] PKMACValue, encryptedKey [4] EnvelopedData }
Schaad Standards Track [Page 34] RFC 4211 Internet X.509 CRMF September 2005
Schaad Standards Track [Page 34] RFC 4211 Internet X.509 CRMF September 2005
-- for keyAgreement (only), possession is proven in this message -- (which contains a MAC (over the DER-encoded value of the -- certReq parameter in CertReqMsg, which MUST include both subject -- and publicKey) based on a key derived from the end entity's -- private DH key and the CA's public DH key);
-- for keyAgreement (only), possession is proven in this message -- (which contains a MAC (over the DER-encoded value of the -- certReq parameter in CertReqMsg, which MUST include both subject -- and publicKey) based on a key derived from the end entity's -- private DH key and the CA's public DH key);
SubsequentMessage ::= INTEGER {
encrCert (0),
-- requests that resulting certificate be encrypted for the
-- end entity (following which, POP will be proven in a
-- confirmation message)
challengeResp (1) }
-- requests that CA engage in challenge-response exchange with
-- end entity in order to prove private key possession
SubsequentMessage ::= INTEGER { encrCert (0), -- requests that resulting certificate be encrypted for the -- end entity (following which, POP will be proven in a -- confirmation message) challengeResp (1) } -- requests that CA engage in challenge-response exchange with -- end entity in order to prove private key possession
-- Object identifier assignments --
-- Object identifier assignments --
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }
-- Registration Controls in CRMF id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
--with syntax:
RegToken ::= UTF8String
イド-regCtrl-regToken物の識別子:、:= 構文があるイド-regCtrl1: RegToken:、:= UTF8String
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
--with syntax:
Authenticator ::= UTF8String
イドregCtrl固有識別文字物の識別子:、:= 構文があるイド-regCtrl2: 固有識別文字:、:= UTF8String
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
--with syntax:
イド-regCtrl-pkiPublicationInfo物の識別子:、:= 構文があるイド-regCtrl3:
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
PKIPublicationInfo:、:= SEQUENCE、動作INTEGER、dontPublish(0)、pleasePublish(1)、pubInfos SEQUENCE SIZE(1..MAX)OF SinglePubInfo OPTIONAL、--pubInfosは動作が"dontPublish"であるなら存在しているはずがありません--(pubInfosは省略されます--動作が"pleasePublish"であり、"dontCare"が想定されるなら)
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
SinglePubInfo:、:= 系列pubMethod INTEGER、pubLocation GeneralName OPTIONAL、dontCare(0)(x500(1)、ウェブ(2))は(3)をldapします。
Schaad Standards Track [Page 35] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[35ページ]。
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
--with syntax:
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey,
-- the actual value of the private key
keyGenParameters [1] KeyGenParameters,
-- parameters that allow the private key to be re-generated
archiveRemGenPrivKey [2] BOOLEAN }
-- set to TRUE if sender wishes receiver to archive the private
-- key of a key pair that the receiver generates in response to
-- this request; set to FALSE if no archival is desired.
イド-regCtrl-pkiArchiveOptions物の識別子:、:= 構文があるイド-regCtrl4: PKIArchiveOptions:、:= に対応してCHOICE、encryptedPrivKey[0]EncryptedKey--秘密鍵keyGenParameters[1]KeyGenParametersの実価--秘密鍵が作り直されたarchiveRemGenPrivKey[2]であることをブールで許容するパラメタ(送付者が兵卒を格納するために受信機を願うなら、TRUEに設定される)が受信機が発生させる主要な組に合わせる、--この要求。 記録保管所でないなら、FALSEへのセットは望まれています。
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue, -- Deprecated
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedKey:、:= CHOICE、encryptedValue EncryptedValue--envelopedData[0]EnvelopedDataを非難します--秘密鍵が置かれたコネがenvelopedDataであったならそうしなければならないコード化--encryptedContentInfo encryptedContent OCTET STRING。
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- the intended algorithm for which the value will be used
symmAlg [1] AlgorithmIdentifier OPTIONAL,
-- the symmetric algorithm used to encrypt the value
encSymmKey [2] BIT STRING OPTIONAL,
-- the (encrypted) symmetric key used to encrypt the value
keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- algorithm used to encrypt the symmetric key
valueHint [4] OCTET STRING OPTIONAL,
-- a brief description or identifier of the encValue content
-- (may be meaningful only to the sending entity, and used only
-- if EncryptedValue might be re-examined by the sending entity
-- in the future)
encValue BIT STRING }
-- the encrypted value itself
-- When EncryptedValue is used to carry a private key (as opposed to
-- a certificate), implementations MUST support the encValue field
-- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
-- section 12.11. If encValue contains some other format/encoding
-- for the private key, the first octet of valueHint MAY be used
-- to indicate the format/encoding (but note that the possible values
-- of this octet are not specified at this time). In all cases, the
-- intendedAlg field MUST be used to indicate at least the OID of
-- the intended algorithm of the private key, unless this information
-- is known a priori to both sender and receiver by some other means.
EncryptedValue:、:= 系列 アルゴリズムが値をコード化するのに使用した左右対称のintendedAlg0AlgorithmIdentifier OPTIONAL(値が中古のsymmAlgが1AlgorithmIdentifier OPTIONALであったならそうする意図しているアルゴリズム)encSymmKey2BIT STRING OPTIONAL--、(コード化される); keyAlg3AlgorithmIdentifier OPTIONAL--左右対称の主要なvalueHint4OCTET STRING OPTIONALをコード化するのに使用されるアルゴリズム--encValueに関する簡単な説明か識別子が満足させる値をコード化するのに使用される対称鍵--(EncryptedValueがそうするかもしれないなら、送付実体だけに重要であるかもしれなく、使用されて、未来の送付実体によって単に再検討されてください) encValue BIT STRING; と対照的に、EncryptedValueが秘密鍵を運ぶのに使用されるとき、コード化がそれ自体を評価する、(--、証明書)、PKCS11で定義されるようにコード化されたPrivateKeyInfoを含んでいて、実現はencValue分野を支持しなければなりません--セクション12.11 encValueが秘密鍵のためのある他の形式/コード化を含んでいるなら、valueHintの最初の八重奏は使用されるかもしれません--(この八重奏の可能な値をある注意がこのとき、指定しなかった)形式/コード化を示すために。 すべての場合で--intendedAlg分野は少なくともOIDを示すのにおいて使用されているに違いありません--、秘密鍵の意図しているアルゴリズム、この情報--ある他の手段によって先験的に送付者と受信機の両方に知られています。
KeyGenParameters ::= OCTET STRING
KeyGenParameters:、:= 八重奏ストリング
Schaad Standards Track [Page 36] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[36ページ]。
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
--with syntax:
OldCertId ::= CertId
イド-regCtrl-oldCertID物の識別子:、:= 構文があるイド-regCtrl5: OldCertId:、:= CertId
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER }
CertId:、:= 系列発行人GeneralName、serialNumber INTEGER
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
--with syntax:
ProtocolEncrKey ::= SubjectPublicKeyInfo
イド-regCtrl-protocolEncrKey物の識別子:、:= 構文があるイド-regCtrl6: ProtocolEncrKey:、:= SubjectPublicKeyInfo
-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 }
-- CRMFイド-regInfo物の識別子の登録インフォメーション:、:= イド-pkip2
id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
UTF8Pairs ::= UTF8String
イド-regInfo-utf8Pairs物の識別子:、:= 構文UTF8Pairsがあるイド-regInfo1:、:= UTF8String
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax
CertReq ::= CertRequest
イド-regInfo-certReq物の識別子:、:= 構文CertReqがあるイド-regInfo2:、:= CertRequest
-- id-ct-encKeyWithID is a new content type used for CMS objects. -- it contains both a private key and an identifier for key escrow -- agents to check against recovery requestors.
-- イドct encKeyWithID、新しく満足しているタイプはCMS物に使用されますか? -- それは回復要請者に対してチェックするキーエスクロー--エージェントのための秘密鍵と識別子の両方を含んでいます。
id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}
イドct encKeyWithID、物の識別子:、:= イドct21
EncKeyWithID ::= SEQUENCE {
privateKey PrivateKeyInfo,
identifier CHOICE {
string UTF8String,
generalName GeneralName
} OPTIONAL
}
EncKeyWithID:、:= 系列privateKey PrivateKeyInfo、識別子CHOICEがUTF8String、generalName GeneralNameを結ぶ、OPTIONAL
PrivateKeyInfo ::= SEQUENCE {
version INTEGER,
privateKeyAlgorithm AlgorithmIdentifier,
privateKey OCTET STRING,
attributes [0] IMPLICIT Attributes OPTIONAL
}
PrivateKeyInfo:、:= 系列バージョンINTEGER、privateKeyAlgorithm AlgorithmIdentifier、privateKey OCTET STRING、属性[0]IMPLICIT Attributes OPTIONAL
Attributes ::= SET OF Attribute
属性:、:= 属性のセット
END
終わり
Schaad Standards Track [Page 37] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[37ページ]。
Appendix C. Why do Proof-of-Possession (POP)
付録C.Whyは所有物のProofをします。(ポップス)です。
Proof-of-Possession, or POP, means that the CA is adequately convinced that the entity requesting a certificate for the public key Y, has access to the corresponding private key X.
所有物の証拠、またはPOPが、カリフォルニアがaを要求する実体が公開鍵のためにYを証明すると適切に確信していて、対応する秘密鍵Xに近づく手段を持っていることを意味します。
POP is important because it provides an appropriate level of assurance of the correct operation of the PKI as a whole. At its lowest level, POP counters the "self-inflicted denial of service"; that is, an entity voluntarily gets a certificate that cannot be used to sign or encrypt/decrypt information. However, as the following two examples demonstrate, POP also counters less direct, but more severe, threats:
全体でPKIの正しい操作の適正水準を保証を提供するので、POPは重要です。 最も低いレベルでは、POPは「自己によって加えられたサービスの否定」を打ち返します。 すなわち、実体は自発的に、情報をサインするか、コード化する、または解読するのに使用できない証明書を手に入れます。 しかしながら、以下の2つの例が示すように、また、POPはそれほどダイレクトでない、しかし、より厳しい脅威に対抗します:
POP for signing keys: it is important to provide POP for keys used
to sign material, in order to provide non-repudiation of
transactions. For example, suppose Alice legitimately has private
key X and its corresponding public key Y. Alice has a certificate
from Charlie, a CA, containing Y. Alice uses X to sign a
transaction T. Without POP, Mal could also get a certificate from
Charlie containing the same public key, Y. Now, there are two
possible threats: Mal could claim to have been the real signer of
T; or Alice can falsely deny signing T, claiming that it was
instead Mal. Since no one can reliably prove that Mal did or did
not ever possess X, neither of these claims can be refuted, and
thus the service provided by and the confidence in the PKI has
been defeated. (Of course, if Mal really did possess X, Alice's
private key, then no POP mechanism in the world will help, but
that is a different problem.)
キーにサインするためのPOP: 取引の非拒否を提供して、材料にサインするのに使用されるキーにPOPを供給するのは重要です。 例えば、Y.アリスには、アリスに秘密鍵Xとその対応する公開鍵が合法的にあるなら、チャーリーからの証明書があって、カリフォルニア、Y.アリスを含むと、Xは取引T.Without POPにサインするのに使用されて、また、Malは現在同じ公開鍵、Y.を含むチャーリーから証明書を手に入れることができて、2つの可能な脅威があります: 悪-、Tの本当の署名者であったと主張してください;であることができました または、それが代わりにMalであったと主張して、アリスは、Tにサインすることを間違って否定する場合があります。 だれも、Malがしたか、またはかつてXを所有していなかったと確かに立証できないので、これらのクレームのどちらも反駁できません、そして、その結果、提供されたサービスとPKIでの信用はくじかれました。 (もちろん、MalにX、アリスの秘密鍵が本当にあったなら、世界のPOPメカニズムは全く助けないでしょうが、それは異なった問題です。)
Note that one level of protection can be gained by having Alice
(as the true signer of the transaction) include in the signed
information, her certificate or an identifier of her certificate
(e.g., a hash of her certificate). This might make it more
difficult for Mal to claim authorship; he would have to assert
that he incorrectly included Alice's certificate, rather than his
own. However, it would not stop Alice from falsely repudiating
her actions. Since the certificate itself is a public item, Mal
indeed could have inserted Alice's certificate or identifier into
the signed transaction, and thus its presence does not indicate
that Alice was the one who participated in the now-repudiated
transaction. The only reliable way to stop this attack is to
require that Mal prove he possesses X before his certificate is
issued.
アリス(取引の本当の署名者としての)に彼女の証明書に関するサインされた情報、彼女の証明書または識別子で(例えば、彼女の証明書の細切れ肉料理)を入れさせることによって1つのレベルの保護を獲得できることに注意してください。 これで、Malが著述業を要求するのが、より難しくなるかもしれません。 彼は、不当に彼自身のよりむしろアリスの証明書を入れたと断言しなければならないでしょう。 しかしながら、それは、アリスが間違って彼女の動作を拒否するのを止めないでしょう。 証明書自体が公共の項目であるので、本当に、Malはアリスの証明書か識別子をサインされた取引に挿入したかもしれません、そして、その結果、存在はアリスが現在否認された取引に参加した人であったのを示しません。 この攻撃を止める唯一の信頼できる方法はMalが、彼の証明書を発行する前に彼がXを所有していると立証するのが必要であることです。
Schaad Standards Track [Page 38] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[38ページ]。
For signing keys used only for authentication, and not for non-
repudiation, the threat is lower because users may not care about
Alice's after-the-fact repudiation, and thus POP becomes less
important. However, POP SHOULD still be done wherever feasible in
this environment, by either off-line or on-line means.
非拒否に使用されるのではなく、認証にだけ使用されるキーにサインするために、ユーザが事実の後のアリスの拒否を心配しないかもしれないので、脅威は低く、その結果、POPは、より重要でなくなります。 しかしながら、POP SHOULDを静まらせます。どこでも、オフラインの、または、オンラインの手段でこの環境で可能であるところでしてください。
POP for key management keys: Similarly, POP for key management
keys (that is, keys used for either key agreement or key exchange)
can help to prevent undermining confidence in the PKI. Suppose
that Al is a new instructor in the Computer Science Department of
a local university. Al has created a draft final exam for the
Introduction to Networking course he is teaching. He wants to
send a copy of the draft final to Dorothy, the Department Head,
for her review prior to giving the exam. This exam will of course
be encrypted, as several students have access to the computer
system. However, a quick search of the certificate repository
(e.g., search the repository for all records with
subjectPublicKey=Dorothy's-value) turns up the fact that several
students have certificates containing the same public key
management key as Dorothy. At this point, if no POP has been done
by the CA, Al has no way of knowing whether all of the students
have simply created these certificates without knowing the
corresponding private key (and thus it is safe to send the
encrypted exam to Dorothy), or whether the students have somehow
acquired Dorothy's private key (and thus it is certainly not safe
to send the exam). Thus, the service to be provided by the PKI
allowing users to communicate with one another, with confidence in
who they are communicating with, has been totally defeated. If
the CA is providing POP, then either no students will have such
certificates, or Al can know with certainty that the students do
indeed know Dorothy's private key, and act accordingly.
かぎ管理キーのためのPOP: 同様に、かぎ管理キー(すなわち、主要な協定か主要な交換のどちらかに使用されるキー)のためのPOPは、PKIでの信用を損ねるのを防ぐのを助けることができます。 アルが地元大学のコンピュータ理学部の新しいインストラクターであると仮定してください。 アルは彼が教えているNetworkingコースへのIntroductionのために草稿期末試験を作成しました。 彼は草稿決勝のコピーをドロシーに送りたがっています、部のHead、試験を与える前の彼女のレビューのために。 数人の学生がコンピュータ・システムに近づく手段を持っているとき、この試験はもちろんコード化されるでしょう。 しかしながら、証明書倉庫(例えば、すべての記録のためにsubjectPublicKey=ドロシーのもの-価値で倉庫を捜す)の迅速な検索は数人の学生にはドロシーとして主要な同じ公開鍵管理を含む証明書があるという事実を見つけます。 ここに、アルには、カリフォルニアがPOPを全く完了していなかったなら、学生が皆、単に対応する秘密鍵を知らないでこれらの証明書を作成したかどうか(その結果、コード化された試験をドロシーに送るのは安全です)、または学生がどうにかドロシーの秘密鍵を取得したかどうかを(その結果、確かに、試験を送るのは安全ではありません)知る方法が全くありません。 したがって、彼らがだれと交信する予定であるかにユーザが自信をもってお互いにコミュニケートできるPKIによって提供されるサービスは完全に破られました。 カリフォルニアがPOPを提供していると、どんな学生にも、そのような証明書がないだろうか、またはアルは学生が本当に、ドロシーの秘密鍵を知って、善処するという確実性で知ることができます。
Author's Address
作者のアドレス
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
ジムSchaad高く昇るタカのコンサルティング私書箱675金の延べ棒、ワシントン 98251
EMail: jimsch@exmsft.com
メール: jimsch@exmsft.com
Schaad Standards Track [Page 39] RFC 4211 Internet X.509 CRMF September 2005
Schaad規格はインターネットX.509 CRMF2005年9月にRFC4211を追跡します[39ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Schaad Standards Track [Page 40]
Schaad標準化過程[40ページ]
一覧
スポンサーリンク
