RFC2511 日本語訳
2511 Internet X.509 Certificate Request Message Format. M. Myers, C.Adams, D. Solo, D. Kemp. March 1999. (Format: TXT=48278 bytes) (Obsoleted by RFC4211) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Myers
Request for Comments: 2511 VeriSign
Category: Standards Track C. Adams
Entrust Technologies
D. Solo
Citicorp
D. Kemp
DoD
March 1999
コメントを求めるワーキンググループM.マイアーズの要求をネットワークでつないでください: 2511年のベリサインカテゴリ: 標準化過程C.アダムスは1999年のシティコープのD.死毛DoD行進のときに技術D.独奏をゆだねます。
Internet X.509 Certificate Request Message Format
インターネットX.509証明書要求メッセージ形式
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
1. Abstract
1. 要約
This document describes the Certificate Request Message Format (CRMF). 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 associated registration information.
このドキュメントはCertificate Request Message Format(CRMF)について説明します。 この構文は、X.509証明書生産の目的のために認証局(カリフォルニア)(ことによるとRegistration Authority(RA)を通した)に証明書に関する要求を伝えるのに使用されます。 要求は公開鍵と関連レジスト情報を通常含むでしょう。
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.
このドキュメント(示されるとしての大文字の)のキーワード「必要で」、“SHOULD"の、そして、「お勧め」の“MUST"、および「5月」はRFC2119で説明されるように解釈されることです。
2. Overview
2. 概要
Construction of a certification request involves the following steps:
証明要求の工事は以下のステップにかかわります:
a) A CertRequest value is constructed. This value may include the
public key, all or a portion of the end-entity's (EE's) name,
other requested certificate fields, and additional control
information related to the registration process.
a) CertRequest値は構成されます。 この値は終わり実体の(EE)の名前、他の要求された証明書分野、および登録手続に関連する追加制御情報の公開鍵、すべてまたは部分を含むかもしれません。
Myers, et. al. Standards Track [Page 1] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[1ページ]。
b) A proof of possession (of the private key corresponding to the
public key for which a certificate is being requested) value may
be calculated across the CertRequest value.
b) 所有物(証明書が要求されている公開鍵に対応する秘密鍵の)価値の証拠はCertRequest値の向こう側に計算されるかもしれません。
c) Additional registration information may be combined with the
proof of possession value and the CertRequest structure to form a
CertReqMessage.
c) 追加レジスト情報は、CertReqMessageを形成するために所有物値とCertRequest構造の証拠に結合されるかもしれません。
d) The CertReqMessage is securely communicated to a CA. Specific
means of secure transport are beyond the scope of this
specification.
d) CertReqMessageはしっかりとカリフォルニアに伝えられます。 安全な輸送の特定の手段はこの仕様の範囲を超えています。
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.
証明書要求メッセージは証明書要求、所有物分野の任意の証拠、および任意の登録情報フィールドで構成されます。
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMessages:、:= CertReqMsgの系列サイズ(1..MAX)
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
pop ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }
CertReqMsg:、:= 系列certReq CertRequest、ProofOfPossession OPTIONALを飛び出させてください--内容はAttributeTypeAndValue OPTIONALの主要なタイプregInfo SEQUENCE SIZE(1..MAX)によります。
The proof of possession field is used to demonstrate that the entity to be associated with the certificate is actually in possession of the corresponding private key. This field may be calculated across the contents of the certReq field and varies in structure and content by public key algorithm type and operational mode.
所有物分野の証拠は、証明書に関連している実体が実際に対応する秘密鍵の所有物にあるのを示すのに使用されます。 この分野は、certReq分野のコンテンツの向こう側に計算されるかもしれなくて、構造と内容で公開鍵アルゴリズムタイプと操作上のモードで異なります。
The regInfo field SHOULD only contain supplementary information related to the context of the certification request when such information is required to fulfill a certification request. This information MAY include subscriber contact information, billing information or other ancillary information useful to fulfillment of the certification request.
そのような情報が証明要求を実現させるのに必要であるときにだけ、regInfo分野SHOULDは証明要求の文脈に関連する補助情報を含んでいます。 この情報は証明要求の遂行の役に立つ加入者問い合わせ先、支払い情報または他の補助的情報を含むかもしれません。
Information directly related to certificate content SHOULD be included in the certReq content. However, inclusion of additional certReq content by RAs may invalidate the pop field. Data therefore intended for certificate content MAY be provided in regInfo.
含まれていて、情報はcertReq内容で直接証明書内容SHOULDに関連しました。 しかしながら、RAsによる追加certReq内容の包含は大衆的な分野を無効にするかもしれません。 したがって、証明書内容のために意図するデータをregInfoに提供するかもしれません。
See Section 8 and Appendix B for example regInfo contents.
セクション8とAppendix B 例えばregInfoコンテンツを見てください。
Myers, et. al. Standards Track [Page 2] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[2ページ]。
4. Proof of Possession (POP)
4. 所有物の証拠(ポップス)です。
In order to prevent certain attacks and to allow a CA/RA to properly check the validity of the binding between an end entity and a key pair, the PKI management operations specified here make it possible for an end entity to prove that it has possession of (i.e., is able to use) the private key corresponding to the public key for which a certificate is requested. A given CA/RA 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 (i.e., this may be a policy issue). However, it is MANDATED that CAs/RAs MUST enforce POP by some means because 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 can only be assumed to have been verified by the CA/RA. Therefore, if the binding is not verified by the CA/RA, certificates in the Internet Public-Key Infrastructure end up being somewhat less meaningful.
ある攻撃を防いで、カリフォルニア/RAが適切に終わりの実体と主要な組の間の結合の正当性をチェックするのを許容するために、ここで指定されたPKI管理操作で、終わりの実体が、(すなわち、使用に、できます)秘密鍵の所有物を証明書が要求されている公開鍵に対応するようにすると立証するのが可能になります。 与えられたカリフォルニア/RAは自由に証明交換でPOPを実施する(-例えば、外では、バンドでは、手続き上の手段は対CRMF中でメッセージを括ります)方法を選ぶことができます(すなわち、これは政策問題であるかもしれません)。 しかしながら、現在、終わりの実体と秘密鍵の間には、明らかに結合をチェックしない使用中の多くの非PKIX操作上のプロトコル(様々な電子メールプロトコルは1つの例である)があるのでCAs/RAsがどうでもPOPを実施しなければならないのは、MANDATEDです。 結合(署名、暗号化、および主要な協定主要な組)について確かめる操作上のプロトコルが存在していて、遍在するまで、カリフォルニア/RAによって確かめられたとこの結合を思うことができるだけです。 したがって、結合がカリフォルニア/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., an RSA key) then any of the methods MAY be used.
POPは証明書が要求されているキーのタイプに頼る異なった方法で達成されます。 複数の目的(例えば、RSAキー)にキーを使用できるなら、メソッドのいずれも使用されるかもしれません。
This specification allows for cases where POP is validated by the CA, the RA, or both. Some policies may require the CA to verify POP during certification, in which case the RA MUST forward the end entity's CertRequest and ProofOfPossession fields unaltered to the CA, and as an option MAY also verify POP. 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 MAY attest to the CA that the required proof has been validated. If the CA uses an out-of-band method to verify POP (such as physical delivery of CA-generated private keys), then the ProofOfPossession field is not used.
この仕様はPOPがカリフォルニア、RA、または両方によって有効にされるケースを考慮します。 いくつかの方針が証明の間、POPについて確かめるためにカリフォルニアを必要とするかもしれません、その場合、RA MUSTはカリフォルニア、また、オプションがPOPについて確かめるかもしれないので非変更された野原を終わりの実体のCertRequestとProofOfPossessionに送ります。 カリフォルニアがPOPについて確かめるために方針によって必要とされないなら、RA SHOULDは上のカリフォルニアに非変更された終わりの実体の要求と証拠を転送します。 これが可能でないなら(例えば、RAがバンドで出ているメソッドでPOPについて確かめるので)、RA MAYは、必要な証拠が有効にされたとカリフォルニアに証明します。 カリフォルニアがPOP(カリフォルニアが発生している秘密鍵の物理的な配送などの)について確かめるバンドで出ているメソッドを使用するなら、ProofOfPossession分野は使用されていません。
4.1 Signature Keys
4.1 署名キー
For signature keys, the end entity can sign a value to prove possession of the private key.
署名キーに関しては、終わりの実体は、秘密鍵の所有物を立証するために値に署名することができます。
Myers, et. al. Standards Track [Page 3] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[3ページ]。
4.2 Key Encipherment Keys
4.2 主要な暗号文キー
For key encipherment keys, the end entity can provide the private key to the CA/RA, or can be required to decrypt a value in order to prove possession of the private key. Decrypting a value can be achieved either directly or indirectly.
主要な暗号文キーに関しては、終わりの実体は、カリフォルニア/RAに秘密鍵を供給できるか、または秘密鍵の所有物を立証するために値を解読するために必要とすることができます。 直接か間接的に値を解読するのを達成できます。
The direct method is for the RA/CA to issue a random challenge to which an immediate response by the end entity is required.
ダイレクトメソッドはRA/カリフォルニアが終わりの実体による即時型反応が必要である無作為の挑戦を発行することです。
The indirect method is to issue a certificate which is encrypted for the end entity (and have the end entity demonstrate its ability to decrypt this certificate in a confirmation message). This allows a CA to issue a certificate in a form which can only be used by the intended end entity.
間接的なメソッドは終わりの実体のために暗号化される証明書を発行する(終わりの実体に確認メッセージでこの証明書を解読する性能を示させてください)ことです。 これで、カリフォルニアは意図している終わりの実体で使用できるだけであるフォームで証明書を下付します。
4.3 Key Agreement Keys
4.3 主要な協定キー
For key agreement keys, the end entity can use any of the three methods given in Section 5.2 for encryption keys. For the direct and indirect methods, the end entity and the PKI management entity (i.e., CA or RA) must establish a shared secret key in order to prove that the end entity has possession of the private key (i.e., in order to decrypt the encrypted certificate or to construct the response to the issued challenge). Note that this need not impose any restrictions on the keys that can be certified by a given CA -- in particular, for Diffie-Hellman keys the end entity may freely choose its algorithm parameters -- provided that the CA can generate a short-term (or one-time) key pair with the appropriate parameters when necessary.
主要な協定キーのために、終わりの実体は暗号化キーのためにセクション5.2で与えられた3つのメソッドのいずれも使用できます。 ダイレクトで間接的なメソッド、終わりの実体、およびPKIに関しては、経営体(すなわち、カリフォルニアかRA)は、終わりの実体には秘密鍵(すなわち、暗号化された証明書を解読するか、または発行された挑戦への応答を構成する)の所有物があると立証するために共有された秘密鍵を設立しなければなりません。 これが与えられたカリフォルニアが公認できるキーに少しの制限も課す必要はないことに注意してください--必要であるときに、カリフォルニアが適切なパラメタで短期的で(1回)の主要な組を生成することができれば、ディフィー-ヘルマンキーのために、特に、終わりの実体は自由にアルゴリズムパラメタを選ぶかもしれません。
The end entity may also MAC the certificate request (using a shared secret key derived from a Diffie-Hellman computation) as a fourth alternative for demonstrating POP. This option may be used only if the CA already has a DH certificate that is known to the end entity and if the EE is willing to use the CA's DH parameters.
また、終わりの実体がそうするかもしれない、MAC、4分の1にPOPのデモをするのにおける代替としての証明書要求(ディフィー-ヘルマンの計算から得られた共有された秘密鍵を使用します)。 カリフォルニアで終わりの実体に知られているDH証明書が単に既にあって、EEが、CAのDHパラメタを使用しても構わないと思っているなら、このオプションは使用されるかもしれません。
4.4 Proof of Possession Syntax
2.2度の所有物構文
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:、:= 選択{raVerified[0]NULL--RAであるなら使用されるのは、中にリクエスタがあることを既に確かめました--秘密鍵署名[1]POPOSigningKey、keyEncipherment[2]POPOPrivKey、keyAgreement[3]POPOPrivKeyの所持}
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
POPOSigningKey:、:= 系列、poposkInput[0]POPOSigningKeyInput任意です。
Myers, et. al. Standards Track [Page 4] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[4ページ]。
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
-- 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 on the DER-encoded value of CertReqMsg certReq. If
-- the CertReqMsg certReq CertTemplate does not contain the public
-- key and subject values, then poposkInput MUST be present and
-- MUST be signed. This strategy ensures that the public key is
-- not present in both the poposkInput and CertReqMsg certReq
-- CertTemplate fields.
algorithmIdentifier AlgorithmIdentifier、署名BIT STRING -- 署名("algorithmIdentifier"を使用する)が進行中、--poposkInputのDERによってコード化された値。 以下に注意してください。 署名はそうであるに違いありません--certReq CertTemplateが対象とpublicKey値を含んでいるというCertReqMsgであるなら、poposkInputを省略しなければなりません、そして、CertReqMsg certReqのDERによってコード化された値では、計算されます。 そして、--、CertReqMsg certReq CertTemplateは公衆を含みません--主要で対象の値、次に、poposkInputが存在していなければならない--署名しなければなりません。 この戦略は、公開鍵が--poposkInputとCertReqMsg certReqの両方でのプレゼントでない--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
POPOSigningKeyInput:、:= SEQUENCE、CertTemplateからのpublicKey publicKey SubjectPublicKeyInfoのDERによってコード化された値の送付者[0]GeneralNameの、そして、認証されたアイデンティティがあった場合にだけ使用されて、送付者(例えば、aからのDN--以前に、発行されるのと現在の有効な証明書)publicKeyMAC PKMACValueにおいて、確立したauthInfo CHOICE(いいえ認証されたGeneralNameが現在存在する--送付者; publicKeyMACがパスワードベースのMACを含んでいるなら、使用されます)
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
-- the algorithm value shall be PasswordBasedMac
-- {1 2 840 113533 7 66 13}
-- the parameter value is PBMParameter
value BIT STRING }
PKMACValue:、:= 系列algId AlgorithmIdentifier--アルゴリズム値はPasswordBasedMacになるでしょう--、1 2、840、113533、7、66 13、--パラメタ値がPBMParameter値のBIT STRINGである
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- posession 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 }
-- 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 Appendix A.
POPOPrivKey:、:= CHOICE、thisMessage0BIT STRING、--、posessionによるこれで立証されて、(個人的を含むもの--キー(カリフォルニアに暗号化される)自体)subsequentMessage1SubsequentMessageを通信させてください--所有物がその後のメッセージdhMACで立証されるということである2BIT STRING; (単に)のkeyAgreementに関しては、所有物はこのメッセージで立証されます--、(どれがMACを含んでいるか、(DERによってコード化された値、--、certReqパラメタ、CertReqMsg、それの必須が対象とpublicKeyの両方を含んでいるコネ) 終わりの実体のものから得られたキーに基づいています--、個人的なDHキーとCAの公共のDHキー)、。 -- 与えられた方向に従ってAppendix AでdhMAC値について計算しなければなりません。
SubsequentMessage ::= INTEGER {
SubsequentMessage:、:= 整数
Myers, et. al. Standards Track [Page 5] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[5ページ]。
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/RA engage in challenge-response exchange with
-- end entity in order to prove private key possession
結果として起こる証明書が暗号化されるという(0)--要求をencrCertする、--(どれに続いて、POPはaで立証されるでしょう--確認メッセージ)という実体challengeResp(1)が終わりになってください -- カリフォルニア/RAがチャレンジレスポンス交換に従事する要求--秘密鍵所有物を立証するために実体を終わらせてください。
It is expected that protocols which incorporate this specification will include the confirmation and challenge-response messages necessary to a complete protocol.
この仕様を取り入れるプロトコルが完全なプロトコルに必要な確認とチャレンジレスポンスメッセージを含むと予想されます。
4.4.1 Use of Password-Based MAC
4.4.1 パスワードベースのMACの使用
The following algorithm SHALL be used when publicKeyMAC is used in POPOSigningKeyInput to prove the authenticity of a request.
以下のアルゴリズムSHALL、publicKeyMACが要求の信憑性を立証するのにPOPOSigningKeyInputで使用されたら、使用されてください。
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 [RFC2104, RFC2202])
PBMParameter:、:= SEQUENCE、塩のOCTET STRING、owf AlgorithmIdentifier--One-道のFunction(推薦されたSHA-1)iterationCount INTEGERのためのAlgId--OWFが適用されたmac AlgorithmIdentifierであるという回の数--、MAC AlgId(例えば、DES-MAC、デスMACを3倍にしてください、[PKCS11]HMAC[RFC2104、RFC2202)
The process of using PBMParameter to compute publicKeyMAC and so authenticate the origin of a public key certification request consists of two stages. The first stage uses shared secret information to produce a MAC key. The second stage MACs the public key in question using this MAC key to produce an authenticated value.
publicKeyMACを計算するので公開鍵証明要求の発生源を認証するのにPBMParameterを使用するプロセスは2つのステージから成ります。 第一段階は、MACキーを生産するのに共有秘密キー情報を使用します。 2番目はMACsを上演します。認証された値を生産するために主要なこのMACを使用する問題の公開鍵。
Initialization of the first stage of algorithm assumes the existence of a shared secret distributed in a trusted fashion between CA/RA and end-entity. The salt value is appended to the shared secret and the one way function (owf) is applied iterationCount times, where the salted secret is the input to the first iteration and, for each successive iteration, the input is set to be the output of the previous iteration, yielding a key K.
アルゴリズムの第一段階の初期設定はカリフォルニア/RAと終わり実体の間の信じられたファッションで分配された共有秘密キーの存在を仮定します。 塩の値を共有秘密キーに追加します、そして、一方通行の機能(owf)は辛辣の秘密が最初の繰り返しへの入力であり、それぞれの連続した繰り返しにおいて、入力が前の繰り返しの出力であるように設定されるところで主要なKをもたらす適用されたiterationCount回です。
In the second stage, K and the public key are inputs to HMAC as documented in [HMAC] to produce a value for publicKeyMAC as follows:
2番目の段階では、Kと公開鍵は以下のpublicKeyMACのために値を生産するために[HMAC]に記録されるようにHMACへの入力です:
publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) )
publicKeyMAC=ハッシュ(K XOR opad、Hash(K XOR ipad、公開鍵))
where ipad and opad are defined in [RFC2104].
ipadとopadが[RFC2104]で定義されるところ。
Myers, et. al. Standards Track [Page 6] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[6ページ]。
The AlgorithmIdentifier for owf SHALL be SHA-1 {1 3 14 3 2 26} and
for mac SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}.
AlgorithmIdentifier、owf SHALLに関しては、SHA-1になってください、1 3、14、3 2、26、mac SHALLには、HMAC-SHA1 1 3 6 1 5 5 8 1 2はそうです。
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
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 (it is recognized that this list may expand over time): regToken; authenticator; pkiPublicationInfo; pkiArchiveOptions; oldCertID; protocolEncrKey.
以下のコントロールは定義されます(このリストが時間がたつにつれて広がるかもしれないと認められます): regToken。 固有識別文字。 pkiPublicationInfo。 pkiArchiveOptions。 oldCertID。 protocolEncrKey。
Myers, et. al. Standards Track [Page 7] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[7ページ]。
6.1 Registration Token Control
6.1 登録トークンコントロール
A regToken control contains one-time information (either based on a secret value or on knowledge) 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 of the CA accepting an intercepted value from someone other than the intended subscriber.
regTokenのための値は、カリフォルニアが生成して、バンドから加入者に提供するかもしれないか、またはそうでなければ、カリフォルニアと加入者の両方に利用可能であるかもしれません。 カリフォルニアのリスクが意図している加入者以外のだれかから妨害された値を受け入れていて、どんなバンドで出ている交換のセキュリティも等しいはずです。
The regToken control would typically be used only for initialization of an end entity into the PKI, whereas the authenticator control (see Section 7.2) would typically be used for 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. The value in the latter case could be encoded either as a binary quantity or as a text string representation of the binary quantity. To ensure a uniform encoding of values regardless of the nature of the quantity, the encoding of regToken SHALL be UTF8.
使用のいくつかのインスタンスでは、regTokenのための値は、乱数などのテキスト文字列か数値量であるかもしれません。 2進の量として、または、2進の量のテキスト文字列表現として後者の場合における値をコード化できました。 量の本質にかかわらず値のコード化、regToken SHALLのコード化をユニフォームに確実にするためには、UTF8になってください。
6.2 Authenticator Control.
6.2 固有識別文字コントロール。
An authenticator control contains information used in 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 regToken could be a text string or a numeric quantity such as a random number. The value in the latter case could be encoded either as a binary quantity or as a text string representation of the binary quantity. To ensure a uniform encoding of values regardless of the nature of the quantity, the encoding of authenticator SHALL be UTF8.
使用のいくつかのインスタンスでは、regTokenのための値は、乱数などのテキスト文字列か数値量であるかもしれません。 2進の量として、または、2進の量のテキスト文字列表現として後者の場合における値をコード化できました。 量の本質にかかわらず値のコード化、固有識別文字SHALLのコード化をユニフォームに確実にするためには、UTF8になってください。
Myers, et. al. Standards Track [Page 8] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[8ページ]。
6.3 Publication Information Control
6.3 公表情報管理
The pkiPublicationInfo control enables subscribers to control the CA's publication of the certificate. It is defined by the following syntax:
pkiPublicationInfoコントロールは、加入者がCAの証明書の公表を制御するのを可能にします。 それは以下の構文で定義されます:
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
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
-- 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します。
If the dontPublish option is chosen, the requester indicates that the PKI should not publish the certificate (this may indicate that the requester intends to publish the certificate him/herself).
dontPublishオプションが選ばれているなら、リクエスタは、PKIが証明書を発表するはずがないのを示します(これは、リクエスタが自己に証明書を発表するつもりであるのを示すかもしれません)。
If the dontCare method is chosen, or if the PKIPublicationInfo control is omitted from the request, the requester indicates that the PKI MAY publish the certificate using whatever means it chooses.
dontCareメソッドが選ばれているか、またはPKIPublicationInfoコントロールが要求から省略されるなら、リクエスタは、PKI MAYがそれが選ばれることを意味するものなら何でも使用することで証明書を発表するのを示します。
If the requester wishes the certificate to appear in at least some locations but wishes to enable the CA to make the certificate available in other repositories, set two values of SinglePubInfo for pubInfos: one with x500, web or ldap value and one with dontCare.
リクエスタ願望であるなら、しかし少なくとも数個の位置で見える証明書は、カリフォルニアが他の倉庫で証明書を利用可能にするのを可能にしたがっていて、セットtwoはpubInfosのためのSinglePubInfoの値です: x500、ウェブまたはldap値がある1とdontCareがある1。
The pubLocation field, if supplied, indicates where the requester would like the certificate to be found (note that the CHOICE within GeneralName includes a URL and an IP address, for example).
供給するなら、pubLocation分野は、リクエスタがどこのようにそうするかを示します。見つけられる証明書(例えば、GeneralNameの中のCHOICEがURLとIPアドレスを含んでいるというメモ)。
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 syntax:
pkiArchiveOptionsコントロールは、加入者が証明要求の公開鍵に対応する秘密鍵のアーカイブを確立するのに必要である情報を提供するのを可能にします。 それは以下の構文で定義されます:
Myers, et. al. Standards Track [Page 9] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[9ページ]。
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 which 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,
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 }
EncryptedValue:、:= 系列{ アルゴリズムが値を暗号化するのに使用した左右対称のintendedAlg0AlgorithmIdentifier OPTIONAL(値が中古のsymmAlgが1AlgorithmIdentifier OPTIONALであったならそうする意図しているアルゴリズム)encSymmKey2BIT STRING OPTIONAL--、(暗号化される)の対称鍵が以前はよく値のkeyAlgを暗号化していた、3AlgorithmIdentifier OPTIONAL; アルゴリズムは以前はよくvalueHint4OCTET STRING OPTIONAL--encValue内容に関する簡単な説明か識別子--対称鍵(EncryptedValueがそうするかもしれないなら、送付実体だけに重要であるかもしれなく、使用されて、未来の送付実体によって単に再検討されてください)encValue BIT STRINGを暗号化していました; }
KeyGenParameters ::= OCTET STRING
KeyGenParameters:、:= 八重奏ストリング
An alternative to sending the key is to send the information about how to re-generate the key using the KeyGenParameters choice (e.g., for many RSA implementations one could send the first random numbers tested for primality). The actual syntax for this parameter may be defined in a subsequent version of this document or in another standard.
キーを送ることへの代替手段はKeyGenParameters選択を使用することでどうキーを作り直すかの情報を送る(例えば、多くのRSA実装のために、1つはprimalityがないかどうかテストされた最初の乱数を送るかもしれません)ことです。 このパラメタのための実際の構文はこのドキュメントのその後のバージョンか別の規格で定義されるかもしれません。
Myers, et. al. Standards Track [Page 10] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[10ページ]。
6.5 OldCert ID Control
6.5 OldCert IDコントロール
If present, the OldCertID control specifies the certificate to be updated by the current certification request. The syntax of its value is:
存在しているなら、OldCertIDコントロールは、現在の証明要求でアップデートするために証明書を指定します。 価値の構文は以下の通りです。
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER
}
CertId:、:= 系列発行人GeneralName、serialNumber INTEGER
6.6 Protocol Encryption Key Control
6.6 プロトコルの暗号化の主要なコントロール
If present, the protocolEncrKey control specifies a key the CA is to use in encrypting a response to CertReqMessages.
存在しているなら、protocolEncrKeyコントロールはカリフォルニアがCertReqMessagesへの応答を暗号化する際に使用することになっているキーを指定します。
This control can be 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.
カリフォルニアに暗号化される必要がある加入者に送る情報があると、このコントロールを使用できます。 そのような情報は使用のために加入者にカリフォルニアによって生成された秘密鍵を含んでいます。
The encoding of protocolEncrKey SHALL be SubjectPublicKeyInfo.
SubjectPublicKeyInfoになってくださいprotocolEncrKey SHALLがコード化されて。
7. Object Identifiers
7. オブジェクト識別子
The OID id-pkix has the value
OIDイド-pkixには、値があります。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
-- arc for Internet X.509 PKI protocols and their components
id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) }
-- インターネットX.509 PKIプロトコルのためのアークとそれらのコンポーネントイド-pkip OBJECT IDENTIFIER:、: イド-pkix pkip(5)
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
-- 登録はCRMFイド-regCtrlオブジェクト識別子で以下を制御します:= イド-pkip regCtrl(1)イド-regCtrl-regToken OBJECT IDENTIFIER:、:= イド-regCtrl1イドregCtrl固有識別文字オブジェクト識別子:、:= イド-regCtrl2イド-regCtrl-pkiPublicationInfoオブジェクト識別子:、:= イド-regCtrl3イド-regCtrl-pkiArchiveOptionsオブジェクト識別子:、:= イド-regCtrl4イド-regCtrl-oldCertIDオブジェクト識別子:、:= イド-regCtrl5イド-regCtrl-protocolEncrKeyオブジェクト識別子:、:= イド-regCtrl6
-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }
id-regInfo-asciiPairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax OCTET STRING
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax CertRequest
-- CRMFイド-regInfoオブジェクト識別子の登録インフォメーション:、:= イド-pkipイド-regInfo(2)、イド-regInfo-asciiPairs OBJECT IDENTIFIER:、:= 構文OCTET STRINGイド-regInfo-certReq OBJECT IDENTIFIERがあるイド-regInfo1:、:= 構文CertRequestがあるイド-regInfo2
Myers, et. al. Standards Track [Page 11] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[11ページ]。
8. Security Considerations
8. セキュリティ問題
The security of CRMF delivery is reliant upon the security mechanisms of the protocol or process used to communicate with CAs. Such protocol or process needs to ensure the integrity, data origin authenticity, and privacy of the message. Encryption of a CRMF is strongly recommended if it contains subscriber-sensitive information and if the CA has an encryption certificate that is known to the end entity.
CRMF配送のセキュリティがプロトコルのセキュリティー対策に頼っているか、または過程は以前はよくCAsとコミュニケートしていました。 そのようなプロトコルか過程が、保全、データ起源の信憑性、およびメッセージのプライバシーを確実にする必要があります。 加入者機密情報を含んでいて、カリフォルニアに終わりの実体に知られている暗号化証明書があるなら、CRMFの暗号化は強く推薦されます。
9. References
9. 参照
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
10. Acknowledgments
10. 承認
The authors gratefully acknowledge 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.
作者は感謝してバーバラフォックス、ウォリックフォード、ラスHousley、およびジョンPawlingの貢献を承諾します。(レビューとPawlingのコメントは、この仕様に関するユーティリティをかなりはっきりさせて、改良しました)。
Myers, et. al. Standards Track [Page 12] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[12ページ]。
11. Authors' Addresses
11. 作者のアドレス
Michael Myers VeriSign, Inc. 1390 Shorebird Way Mountain View, CA 94019
マイケルマイアーズベリサインInc.1390海岸にすむ鳥道マウンテンビュー(カリフォルニア)94019
EMail: mmyers@verisign.com
メール: mmyers@verisign.com
Carlisle Adams Entrust Technologies 750 Heron Road, Suite E08 Ottawa, Canada, K1V 1A7
08スイートEのオタワ(カナダ)K1V 1A7、カーライルアダムスは技術750サギの道路をゆだねます。
EMail: cadams@entrust.com
メール: cadams@entrust.com
Dave Solo Citicorp 666 Fifth Ave, 3rd Floor New York, Ny 10103
デーヴのソロのシティコープ666第5Ave、第3FloorニューヨークNy10103
EMail: david.solo@citicorp.com
メール: david.solo@citicorp.com
David Kemp National Security Agency Suite 6734 9800 Savage Road Fort Meade, MD 20755
デヴィッド死毛国家安全保障局スイート6734 9800サヴェージ道路フォートミード、MD 20755
EMail: dpkemp@missi.ncsc.mil
メール: dpkemp@missi.ncsc.mil
Myers, et. al. Standards Track [Page 13] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[13ページ]。
Appendix A. Constructing "dhMAC"
"dhMAC"を組み立てる付録A.
This Appendix describes the method for computing the bit string "dhMAC" in the proof-of-possession POPOPrivKey structure for Diffie- Hellman certificate requests.
このAppendixはディフィーのヘルマンの証明書要求のために所有物の証拠POPOPrivKey構造でビット列"dhMAC"を計算するための方法を説明します。
1. The entity generates a DH public/private key-pair.
1. 実体はDH公立の/秘密鍵組を発生させます。
The DH parameters used to calculate the public SHOULD be those
specified in the CA's DH certificate.
DHパラメタはCAのDHで指定されたものが証明書であったなら以前はよく公共のSHOULDについて計算していました。
From CA's DH certificate:
CApub = g^x mod p (where g and p are the established DH
parameters and x is the CA's private
DH component)
For entity E:
DH private value = y
Epub = DH public value = g^y mod p
CAのDHから、以下を証明してください。 CApubは実体Eのためにg^xモッズp(gとpがどこの確立したDHパラメタとxであるかはCAの個人的なDHの部品です)と等しいです: y DHの個人的な値=EpubはDH公共の値=g^yモッズpと等しいです。
2. The MACing process will then consist of the following steps.
2. そして、MACingの過程は以下のステップから成るでしょう。
a) The value of the certReq field is DER encoded, yielding a binary
string. This will be the 'text' referred to in [HMAC], the data to
which HMAC-SHA1 is applied.
a) certReq分野の値は2進のストリングをもたらして、コード化されたDERです。 これは[HMAC]で言及された'テキスト'、HMAC-SHA1が適用されているデータになるでしょう。
b) A shared DH secret is computed, as follows,
shared secret = Kec = g^xy mod p
b) 以下の通り、g^xy秘密の=Kec=モッズpは、共有されたDH秘密が計算されるのを共有しました。
[This is done by the entity E as CApub^y and by the CA as Epub^x,
where CApub is retrieved from the CA's DH certificate and Epub is
retrieved from the actual certification request.]
[Epub^x(CApubはCAのDH証明書とEpubから検索される)が実際の証明要求から検索されるとき、これがCApub^yとしての実体Eとカリフォルニアによって行われます。]
c) A key K is derived from the shared secret Kec and the subject and
issuer names in the CA's certificate as follows:
c) 以下のCAの証明書の共有秘密キーKec、対象、および発行人名から主要なKを得ます:
K = SHA1(DER-encoded-subjectName | Kec | DER-encoded-issuerName)
K=SHA1(DERはsubjectNameをコード化しました|、Kec|、DERがissuerNameをコード化した、)
where "|" means concatenation. If subjectName in the CA
certificate is an empty SEQUENCE then DER-encoded-subjectAltName
should be used instead; similarly, if issuerName is an empty
SEQUENCE then DER-encoded-issuerAltName should be used instead.
「どこ」|「連結を意味します。」 DERはカリフォルニア証明書のsubjectNameが空のSEQUENCEであるならsubjectAltNameをコード化しました。代わりに使用されるべきです。 同様に、DERはissuerNameが空のSEQUENCEであるならissuerAltNameをコード化しました。代わりに使用されるべきです。
d) Compute HMAC-SHA1 over the data 'text' as per [RFC2104] as:
SHA1(K XOR opad, SHA1(K XOR ipad, text))
d) [RFC2104]に従って以下として'テキスト'というデータに関してHMAC-SHA1を計算してください。 SHA1(K XOR opad、SHA1(K XOR ipad、テキスト))
Myers, et. al. Standards Track [Page 14] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[14ページ]。
where,
opad (outer pad) = the byte 0x36 repeated 64 times
and
ipad (inner pad) = the byte 0x5C repeated 64 times.
どこ、opad(外側のパッド)は64回繰り返されたバイト0x36と等しいか、そして、ipad(内側のパッド)は64回繰り返されたバイト0x5Cと等しいです。
Namely,
すなわち
(1) Append zeros to the end of K to create a 64 byte string
(e.g., if K is of length 16 bytes it will be appended with
48 zero bytes 0x00).
(2) XOR (bitwise exclusive-OR) the 64 byte string computed in
step (1) with ipad.
(3) Append the data stream 'text' to the 64 byte string
resulting from step (2).
(4) Apply SHA1 to the stream generated in step (3).
(5) XOR (bitwise exclusive-OR) the 64 byte string computed in
step (1) with opad.
(6) Append the SHA1 result from step (4) to the 64 byte string
resulting from step (5).
(7) Apply SHA1 to the stream generated in step (6) and output
the result.
(1) Kの終わりにゼロを追加して(例えば、Kが追加されたそれが16バイトの長さのものであるなら、48で、バイト0x00のゼロを合わせてください)、64バイトのストリングを作成してください。 (2) 64バイトのストリングがステップ(1)でipadで計算したXOR(排他的論理和をbitwiseします)。 (3) ステップ(2)から生じる64バイトのストリングにデータ・ストリーム'テキスト'を追加してください。 (4) ステップ(3)で発生する流れにSHA1を適用してください。 (5) 64バイトのストリングがステップ(1)でopadで計算したXOR(排他的論理和をbitwiseします)。 (6) ステップ(4)からステップ(5)から生じる64バイトのストリングまでSHA1結果を追加してください。 (7) ステップ(6)で発生する流れにSHA1を適用してください、そして、結果を出力してください。
Sample code is also provided in [RFC2104, RFC2202].
また、[RFC2104、RFC2202]にサンプルコードを提供します。
e) The output of (d) is encoded as a BIT STRING (the value "dhMAC").
e) (d)の出力はBIT STRING(値の"dhMAC")としてコード化されます。
3. The proof-of-possession process requires the CA to carry out
steps (a) through (d) and then simply compare the result of step
(d) with what it received as the "dhMAC" value. If they match then
the following can be concluded.
3. 所有物の証拠の過程は、"dhMAC"が評価するように、(d)を通してステップ(a)を行って、次に、単にそれが受けたものとステップ(d)の結果を比べるためにカリフォルニアを必要とします。 彼らが合っているなら、以下を結論づけることができます。
1) The Entity possesses the private key corresponding to the
public key in the certification request (because it needed the
private key to calculate the shared secret).
1) Entityには、証明要求における公開鍵に対応する秘密鍵があります(共有秘密キーについて計算するために秘密鍵を必要としたので)。
2) Only the intended CA can actually verify the request (because
the CA requires its own private key to compute the same shared
secret). This helps to protect from rogue CAs.
2) 意図しているカリフォルニアだけが実際に要求について確かめることができます(カリフォルニアが同じ共有秘密キーを計算するためにそれ自身の秘密鍵を必要とするので)。 これは、凶暴なCAsから保護するのを助けます。
References
参照
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
SHA-1", RFC 2202, September 1997.
[RFC2202] チェンとP.とR.グレンと「HMAC-MD5のためのテストケースとHMAC- SHA-1インチ、RFC2202、1997年9月。」
Myers, et. al. Standards Track [Page 15] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[15ページ]。
Acknowledgements
承認
The details of this Appendix were provided by Hemma Prafullchandra.
このAppendixの詳細はHemma Prafullchandraによって明らかにされました。
Appendix B. Use of RegInfo for Name-Value Pairs
RegInfoの名前価値のペアの付録B.使用
The "value" field of the id-regInfo-utf8Pairs OCTET STRING (with "tag" field equal to 12 and appropriate "length" field) will contain a series of UTF8 name/value pairs.
イド-regInfo-utf8Pairs OCTET STRING(12と等しい「タグ」分野と適切な「長さ」分野がある)の「値」分野は一連のUTF8名前/価値の組を含むでしょう。
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.
このAppendixはこの仕様の独立している実現の中で相互運用性を促進する目的のためにそのような組のいくつかの一般的な例をリストアップします。 このリストが徹底的でなく、時間と実現経験に応じて成長すると認められます。
B.1. Example Name/Value Pairs
B.1。 例の名前/価値のペア
When regInfo is used to convey one or more name-value pairs (via id- regInfo-utf8Pairs), the first and subsequent pairs SHALL be structured as follows:
regInfoが使用されているときには、1名前価値の組(イドregInfo-utf8Pairsを通した)以上、1番目の、そして、その後の組SHALLを運ぶために、以下の通り構造化されてください:
[name?value][%name?value]*%
[名前?値] [%名?値]*%
This string is then encoded into an OCTET STRING and placed into the regInfo SEQUENCE.
このストリングは、次に、OCTET STRINGにコード化されて、regInfo SEQUENCEに置かれます。
Reserved characters are encoded using the %xx mechanism of [RFC1738], unless they are used for their reserved purposes.
彼らが予約された目的に使用されない場合、控え目なキャラクタは、[RFC1738]の%xxなメカニズムを使用することでコード化されます。
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.
以下のテーブルはお勧めのセットの命名された要素を定義します。 「名前値」というコラムの値は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
名前値---------- バージョン--_corp_会社--加入者org_ユニットの会社の提携--組織的なユニットが_firstNameに郵送するregInfo使用のこの変化のバージョン--_個人名コンポーネントメールmiddleName--個人名コンポーネントメールlastName--個人名コンポーネントメール_メール--加入者のEメールアドレスjobTitle--加入者employeeIDの役職--従業員識別番号かストリング
mailStop -- mail stop
issuerName -- name of CA
mailStop--メール停止issuerName--カリフォルニアの名前
Myers, et. al. Standards Track [Page 16] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[16ページ]。
subjectName -- name of Subject
validity -- validity interval
subjectName--Subjectの正当性の名前--正当性間隔
For example:
例えば:
version?1%corp_company?Acme, Inc.%org_unit?Engineering%
mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader%
mail_email?john@acme.com%
バージョン? 1%のcorp_会社?頂上Inc.%org_単位?ジョン%が_lastName--スミス%jobTitle--班長% mail_email?john@acme.com% に郵送する工学%メール_firstName?
B.1.1. IssuerName, SubjectName and Validity Value Encoding
B.1.1。 IssuerName、SubjectName、および正当性値のコード化
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.
彼らが要素と命名されるようにイド-regInfo-utf8Pairs構文で見えるとき、issuerNameのための値のコード化、subjectName、および正当性SHALLは以下の構文を使用します。 キャラクタ[]が任意の分野を示す、:、:= そして| それらの普通のBNF意味を持ってください。そうすれば、非ターミナル名の外における他のすべてのシンボル(わずかな空間を除いた)が端末です。 Alphabeticsは大文字と小文字を区別しています。
issuerName ::= <names>
subjectName ::= <names>
<names> ::= <name> | <names>:<name>
issuerName:、:= <は>をsubjectNameと命名します:、:= <は><名を>に挙げます:、:= <名前>。| <は>: <を名前>と命名します。
<validity> ::= validity ? [<notbefore>]-[<notafter>]
<notbefore> ::= <time>
<notafter> ::= <time>
<の正当性>:、:= 正当性? [<notbefore>]--[<notafter>] <notbefore>:、:= <時間><notafter>:、:= <時間>。
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.
<時間>がフォームYYYYMMDD[HH[MM[SS]]]のUTC時間であるところ。 HH、MM、およびSSが00をデフォルトとして、省略される、価値00
Example validity encoding:
例の正当性コード化:
validity?-19991231%
正当性?-19991231%
is a validity interval with no value for notBefore and a value of December 31, 1999 for notAfter.
正当性間隔がnotBeforeのための値とnotAfterのための1999年12月31日の値なしでありますか?
Each name comprises a single character name form identifier followed by a name value of one or UTF8 characters. Within a name value, when it is necessary to disambiguate a character which 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 %%.
各名前は1の名前値があとに続いたただ一つのキャラクタ名前フォーム識別子かUTF8キャラクタを包括します。 名前値の中では、それが必要であるときには外側のレベル、エスケープシーケンス%xx SHALLに形式意味を持っているキャラクタのあいまいさを除くのに、使用されてください、xxがコード化のための値が関した十六進法を表すところで。 パーセントシンボルは%%表されます。
<name> ::= X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname>
<名前>:、:= X<xname>|○ <oname>|E<ename>|D<dname>|U<uname>|I<iname>。
Name forms and value formats are as follows:
名前フォームと値の形式は以下の通りです:
X.500 directory name form (identifier "X"):
X.500ディレクトリ名フォーム(識別子「X」):
Myers, et. al. Standards Track [Page 17] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[17ページ]。
<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>。
Standard attribute type <stdat> is an alphabetic attribute type identifier from the following set:
標準の属性タイプ<stdat>は以下のセットからのアルファベット属性タイプ識別子です:
C (country)
L (locality)
ST (state or province)
O (organization)
OU (organizational unit)
CN (common name)
STREET (street address)
E (E-mail address).
C(国)L(場所)ST(州か州)O(組織)OU(組織的なユニット)CN(一般名)通り(住所)E(Eメールアドレス)。
<avalue> is a name component in the form of a UTF8 character string of 1 to 64 characters, with the restriction that in the IA5 subset of UTF8 only the characters of ASN.1 PrintableString may be used.
<avalue>は1〜64のキャラクタのUTF8文字列の形の名前コンポーネントです、UTF8だけのIA5部分集合に、ASN.1PrintableStringのキャラクタが使用されるかもしれないという制限で。
Other name form (identifier "O"):
<oname> ::= <oid> , <utf8string>
他の名前フォーム(識別子「O」): <oname>:、:= <oid>、<utf8string>。
E-mail address (rfc822name) name form (identifier "E"):
<ename> ::= <ia5string>
Eメールアドレス(rfc822name)名前フォーム(識別子「E」): <ename>:、:= <ia5string>。
DNS name form (identifier "D"):
<dname> ::= <ia5string>
DNSは(識別子「D」)とフォームを命名します: <dname>:、:= <ia5string>。
URI name form (identifier "U"):
<uname> ::= <ia5string>
URI名前フォーム(識別子「U」): <uname>:、:= <ia5string>。
IP address (identifier "I"):
<iname> ::= <oid>
IPアドレス(「私」という識別子): <iname>:、:= <oid>。
For example:
例えば:
issuerName?XOU=Our CA,O=Acme,C=US%
subjectName?XCN=John Smith, O=Acme, C=US, E=john@acme.com%
issuerName?私たちのXOU=カリフォルニア、O=頂上、C=米国%subjectNameジョン・XCN=スミス、O=頂上、C=米国、E= john@acme.com% ?
References
参照
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill,
"Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] バーナーズ・リーとT.とMasinterとL.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
Myers, et. al. Standards Track [Page 18] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[18ページ]。
Appendix C. ASN.1 Structures and OIDs
付録C.のASN.1構造とOIDs
PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(5)}
PKIXCRMFiso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズcrmf(5)
CRMF DEFINITIONS IMPLICIT TAGS ::= BEGIN
CRMF定義、内在しているタグ:、:= 始まってください。
IMPORTS
-- Directory Authentication Framework (X.509)
Version, AlgorithmIdentifier, Name, Time,
SubjectPublicKeyInfo, Extensions, UniqueIdentifier
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
輸入--PKIX1Explicit88からのバージョン、AlgorithmIdentifierが命名するディレクトリ認証枠組み(X.509)、時間、SubjectPublicKeyInfo、拡大、UniqueIdentifieriso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の明白な88(1)
-- 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-88(2)}
-- PKIX1Implicit88からの証明書拡張子(X.509)GeneralNameiso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の内在している88(2)
-- Cryptographic Message Syntax
EnvelopedData
FROM CryptographicMessageSyntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms(1) };
-- 暗号のMessage Syntax EnvelopedData FROM CryptographicMessageSyntax、iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm(1)、。
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMessages:、:= CertReqMsgの系列サイズ(1..MAX)
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
pop ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
CertReqMsg:、:= 系列certReq CertRequest、ProofOfPossession OPTIONALを飛び出させてください--内容は主要なタイプ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(合っている要求と回答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,
CertTemplate:、:= SEQUENCE、バージョン[0]バージョンOPTIONAL、serialNumber[1]INTEGER OPTIONAL、signingAlg[2]AlgorithmIdentifier OPTIONAL、発行人[3]名前OPTIONAL(正当性[4]OptionalValidity OPTIONAL)は[5] 名前OPTIONALをかけます。
Myers, et. al. Standards Track [Page 19] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[19ページ]。
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions 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を調節します--少なくとも存在していなければなりません。
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
コントロール:、:= AttributeTypeAndValueの系列サイズ(1..MAX)
AttributeTypeAndValue ::= SEQUENCE {
type OBJECT IDENTIFIER,
value ANY DEFINED BY type }
AttributeTypeAndValue:、:= 系列OBJECT IDENTIFIERをタイプしてください、そして、値のANY DEFINED BYはタイプします。
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:、:= 選択{raVerified[0]NULL--RAであるなら使用されるのは、中にリクエスタがあることを既に確かめました--秘密鍵署名[1]POPOSigningKey、keyEncipherment[2]POPOPrivKey、keyAgreement[3]POPOPrivKeyの所持}
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
-- 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 on the DER-encoded value of CertReqMsg certReq. If
-- the CertReqMsg certReq CertTemplate does not contain the public
-- key and subject values, then poposkInput MUST be present and
-- MUST be signed. This strategy ensures that the public key is
-- not present in both the poposkInput and CertReqMsg certReq
-- CertTemplate fields.
POPOSigningKey:、:= SEQUENCE、poposkInput[0]POPOSigningKeyInput OPTIONAL、algorithmIdentifier AlgorithmIdentifier、署名BIT STRING、--、署名("algorithmIdentifier"を使用する)が進行中である--poposkInputのDERによってコード化された値。 以下に注意してください。 署名はそうであるに違いありません--certReq CertTemplateが対象とpublicKey値を含んでいるというCertReqMsgであるなら、poposkInputを省略しなければなりません、そして、CertReqMsg certReqのDERによってコード化された値では、計算されます。 そして、--、CertReqMsg certReq CertTemplateは公衆を含みません--主要で対象の値、次に、poposkInputが存在していなければならない--サインしなければなりません。 この戦略は、公開鍵が--poposkInputとCertReqMsg certReqの両方でのプレゼントでない--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
POPOSigningKeyInput:、:= SEQUENCE、authInfo CHOICE、送付者[0]GeneralName(認証されたアイデンティティがあった場合にだけ、使用される)が送付者のために設立した、(例えば、aからのDN--、以前に、発行されるのと現在の有効な証明書publicKeyMAC PKMACValue、--中古の、しかし、認証されなかったGeneralNameが現在--送付者;publicKeyMACがaパスワードベースのMACを含んでいるpublicKeyのDERによってコード化された値の上に存在する
Myers, et. al. Standards Track [Page 20] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[20ページ]。
publicKey SubjectPublicKeyInfo } -- from CertTemplate
パブリックキーSubjectPublicKeyInfo -- 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:、:= 系列algId AlgorithmIdentifier--アルゴリズムが、評価するPasswordBasedMacである、1 2、840、113533、7、66 13、--パラメタ値がPBMParameter値の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 [RFC2104, RFC2202])
PBMParameter:、:= SEQUENCE、塩のOCTET STRING、owf AlgorithmIdentifier--One-道のFunction(推薦されたSHA-1)iterationCount INTEGERのためのAlgId--OWFが適用されたmac AlgorithmIdentifierであるという回の数--、MAC AlgId(例えば、DES-MAC、デスMACを3倍にしてください、[PKCS11]HMAC[RFC2104、RFC2202)
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- posession 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 }
-- 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 Appendix A.
POPOPrivKey:、:= CHOICE、thisMessage0BIT STRING、--、posessionによるこれで立証されて、(個人的を含むもの--キー(カリフォルニアにコード化される)自体)subsequentMessage1SubsequentMessageを通信させてください--所有物がその後のメッセージdhMACで立証されるということである2BIT STRING; (単に)のkeyAgreementに関しては、所有物はこのメッセージで立証されます--、(どれがMACを含んでいるか、(DERによってコード化された値、--、対象とpublicKeyの両方を含まなければならないCertReqMsgのcertReqパラメタ、)、aに基づいて、キーが終わりの実体のものに由来していました--個人的なDHキーとCAが公共のDH主要である、)、。 -- 与えられた指示に従ってAppendix AでdhMAC値について計算しなければなりません。
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)--要求、--、実体が終わりになってください(どれに続いて、POPはaで立証されるでしょう--確認メッセージ) challengeResp(1)}--カリフォルニアがチャレンジレスポンス交換に従事する要求--秘密鍵所有物を立証するために実体を終わらせてください。
-- Object identifier assignments --
-- 物の識別子課題--
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 7 }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)、組織(3)dod(6)インターネット(1)セキュリティが特定された(5)メカニズム(5)7
-- arc for Internet X.509 PKI protocols and their components
-- インターネットX.509 PKIプロトコルとそれらのコンポーネントのためのアーク
Myers, et. al. Standards Track [Page 21] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[21ページ]。
id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
イド-pkip OBJECT IDENTIFIER:、:= イド-pkix5
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }
-- 登録はCRMFイド-regCtrl物の識別子で以下を制御します:= イド-pkip1
-- The following definition may be uncommented for use with -- ASN.1 compilers which do not understand UTF8String.
-- 以下の定義が使用のために非論評されるかもしれない、--UTF8Stringを理解していないASN.1コンパイラ。
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- UTF8String:、:= [普遍的な12]内在している八重奏ストリング
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します。
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 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 which the receiver generates in response to
イド-regCtrl-pkiArchiveOptions物の識別子:、:= 構文があるイド-regCtrl4: PKIArchiveOptions:、:= に対応してCHOICE、encryptedPrivKey[0]EncryptedKey--秘密鍵keyGenParameters[1]KeyGenParametersの実価--秘密鍵が作り直されたarchiveRemGenPrivKey[2]であることをブールで許容するパラメタ(送付者が兵卒を格納するために受信機を願うなら、TRUEに設定される)が受信機が発生させる主要な組に合わせる。
Myers, et. al. Standards Track [Page 22] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[22ページ]。
-- this request; set to FALSE if no archival is desired.
-- この要求。 記録保管所でないなら、FALSEへのセットは望まれています。
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue,
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
EncryptedValue:、:= 系列 アルゴリズムが値をコード化するのに使用した左右対称のintendedAlg0AlgorithmIdentifier OPTIONAL(値が中古のsymmAlgが1AlgorithmIdentifier OPTIONALであったならそうする意図しているアルゴリズム)encSymmKey2BIT STRING OPTIONAL--、(コード化される); keyAlg3AlgorithmIdentifier OPTIONAL--左右対称の主要なvalueHint4OCTET STRING OPTIONALをコード化するのに使用されるアルゴリズム--encValueに関する簡単な説明か識別子が満足させる値をコード化するのに使用される対称鍵--(EncryptedValueがそうするかもしれないなら、送付実体だけに重要であるかもしれなく、使用されて、未来の送付実体によって単に再検討されてください) encValue BIT STRING; コード化された値自体
KeyGenParameters ::= OCTET STRING
KeyGenParameters:、:= 八重奏ストリング
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 }
イド-regInfo-certReq物の識別子:、:= イド-regInfo2
Myers, et. al. Standards Track [Page 23] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[23ページ]。
--with syntax CertReq ::= CertRequest
--構文CertReqで:、:= CertRequest
END
終わり
Myers, et. al. Standards Track [Page 24] RFC 2511 Internet X.509 CRMF March 1999
etマイアーズ、アル。 規格は1999年のインターネットX.509 CRMF行進のときにRFC2511を追跡します[24ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Myers, et. al. Standards Track [Page 25]
etマイアーズ、アル。 標準化過程[25ページ]
一覧
スポンサーリンク
