[要約] RFC 2511は、インターネットX.509証明書リクエストメッセージの形式に関する仕様です。このRFCの目的は、証明書リクエストの標準化と相互運用性の向上です。
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
Internet X.509 Certificate Request Message Format
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
このドキュメントでは、証明書要求メッセージ形式（CRMF）について説明します。この構文は、X.509証明書の生産の目的のために（おそらく登録局（RA）を介して）認証局（CA）への証明書の要求を伝えるために使用されます。要求は、一般的に、公開鍵と関連する登録情報が含まれます。
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.
キーワード「MUST」、「REQUIRED」は、「推奨」、「SHOULD」、および「MAY」（図示のように、大文字で）この文書に記載されているRFC 2119に記載されるように解釈されるべきです。
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の）名前、他の要求された証明書フィールド、および登録プロセスに関連する追加の制御情報のすべてまたは一部を含んでもよいです。
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が確実にCAに伝達されます安全な輸送の具体的手段は、この仕様の範囲を超えています。
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
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
pop ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }
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フィールドは、認証要求のコンテキストに関連する補足情報を含むべきです。この情報は、加入者の連絡先情報、請求情報または証明書要求の実現に有用な他の補助的な情報を含むことができます。
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コンテンツに含まれるべきです。しかし、RAの追加によってCERTREQコンテンツを含めることは、ポップ・フィールドを無効にすることができます。したがって、証明書の内容を対象としたデータは、REGINFOに提供することができます。
See Section 8 and Appendix B for example regInfo contents.
内容REGINFO例えば第8章および付録Bを参照してください。
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.
特定の攻撃を防止し、CA / RAが適切にエンドエンティティと鍵ペア間の結合の有効性を確認できるようにするために、ここで指定したPKI管理操作は、それがの所持を持っていることを証明するために、エンドエンティティのためにそれを可能にします証明書が要求されている公開鍵に対応する秘密鍵（すなわち、使用することができます）。所与CA / RA（すなわち、これは、ポリシーの問題であってもよい）、その認証交換中（CRMFインバンドメッセージに対して、例えば、アウト・オブ・バンド手続き手段）POPを適用する方法を自由に選択することができます。しかし、現在使用中の多くの非PKIX運用プロトコル（様々な電子メールプロトコルは一例です）明示的にエンドエンティティとプライベートの間の結合をチェックしないことがあるので、CAは/ RASが何らかの手段でPOPを施行しなければならないことを義務付けられていますキー。 （署名、暗号化、および鍵合意鍵ペアのための）結合を確認するん運用プロトコルが存在し、かつユビキタスになるまで、この結合はCA / RAによって検証されているものとすることができます。結合がCA / 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がCA、RA、またはその両方によって検証されるケースを可能にします。いくつかのポリシーは、RAがCAに変更されていないエンドエンティティのcertrequestコマンドとProofOfPossessionフィールドを転送しなければならない、とオプションとしてもPOPを確認することができ、この場合には、認証時にPOPを確認するために、CAが必要な場合があります。 CAは、POPを検証するためのポリシーによって必要とされていない場合には、RAはエンドエンティティの要求と上記のようにCAに変更されていない証明を転送する必要があります。これは、（例えば、RAは、アウトオブバンド方法でPOPを検証するため）ことができない場合、RAは、必要な証明が検証されたことをCAに証明するかもしれません。 CAは、POPを確認するためにアウトオブバンド方式を使用する場合（例えばCA-生成された秘密鍵の物理的配達されるように）、次いでProofOfPossessionフィールドは使用されません。
For signature keys, the end entity can sign a value to prove possession of the private key.
署名鍵の場合、エンドエンティティは秘密鍵の所有を証明するために値を署名することができます。
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.
鍵暗号化キーの場合、エンドエンティティがCA / 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 / CAは、エンドエンティティによって即座に応答が必要とされているランダムなチャレンジを発行するための直接的な方法です。
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.
間接的な方法は、エンドエンティティのために暗号化された証明書を発行（およびエンドエンティティが確認メッセージにこの証明書を復号化する能力を実証してい）することです。これは、CAが唯一の目的とするエンドエンティティで使用できる形式で証明書を発行することができます。
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管理エンティティ（すなわち、CAまたはRA）は、復号化するためには、エンドエンティティ、すなわち、秘密鍵（の所有権を持っていることを証明するために、共有秘密鍵を確立する必要があります）証明書を暗号化または発行したチャレンジに対するレスポンスを構築します。 CAは、短期的に生成できることを提供 - 特に、のDiffie-Hellman鍵のためのエンドエンティティは自由にそのアルゴリズムのパラメータを選択することができます - これは、与えられたCAによって認証可能なキーに制限を課す必要はないことに注意してください必要なときに適切なパラメータを使用して（または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もPOPを実証するための第4の代替として（のDiffie-Hellman計算から導出さ共有秘密鍵を使用して）証明書要求をしてもよいです。このオプションは、CAが既にエンドエンティティへとEEはCAのDHパラメータを使用する意思がある場合は知られているDH証明書を持っている場合にのみ使用することができます。
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 }
-- 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.
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,
-- the algorithm value shall be PasswordBasedMac
-- {1 2 840 113533 7 66 13}
-- the parameter value is PBMParameter
value 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.
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/RA engage in challenge-response exchange with
-- end entity in order to prove private key possession
It is expected that protocols which incorporate this specification will include the confirmation and challenge-response messages necessary to a complete protocol.
この仕様を取り入れプロトコルが完全なプロトコルに必要な確認とチャレンジ・レスポンスメッセージを含むことが期待されます。
The following algorithm SHALL be used when publicKeyMAC is used in POPOSigningKeyInput to prove the authenticity of a request.
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])
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キーを生成するために共有秘密情報を使用しています。第二段階のMAC認証された値を生成するために、この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.
アルゴリズムの第一段階の初期化は、CA / RAとエンドエンティティ間の信頼できる方法で分散共有秘密の存在を想定しています。ソルト値は、共有シークレットに付加され、一方向関数（OWF）はiterationCount時間、塩漬け秘密は各連続反復のために、入力が出力に設定され、最初の反復に入力され、適用されます鍵Kを得前回の繰り返し、
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:
次のようにpublicKeyMACの値を生成するために、[HMAC]に記載されているように第2段階では、Kと公開鍵はHMACへの入力です。
publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) )
publicKeyMAC =ハッシュ（K XORのOPAD、ハッシュ（K XOR ipadと、公開鍵））
where ipad and opad are defined in [RFC2104].
iPadとOPADは[RFC2104]で定義されます。
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}.
OWFためのAlgorithmIdentifierはSHA1 {1 3 14 3 2 26}及びMACはHMAC-SHA1 {1 3 6 1 5 8 1 2}でなければならないためでなければなりません。
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
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
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
The generator of a CertRequest may include one or more control values pertaining to the processing of the request.
certrequestコマンドの発生器は、要求の処理に関連する一つまたは複数の制御値を含むことができます。
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
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。
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制御は、ワンタイム情報（秘密値または知識に基づいていずれか）の前の証明書を発行する対象のアイデンティティを検証するためにCAによって使用されることを意図含ま。 regTokenための値を含む認証要求を受信すると、受信したCAは、証明書要求に記載のアイデンティティを確認するための情報を確認します。
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の値は、CAによって生成され、加入者への帯域外に設けられ、又はそうでなければCAおよび加入者の両方に利用可能であることができます。すべてのアウトオブバンドの交換のセキュリティは、意図した加入者以外の者からの傍受値を受け入れるCAのリスクに見合っでなければなりません。
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.
オーセンティケータ制御（セクション7.2を参照）は、典型的には、初期並びに後続の認証要求に使用されるのに対し、regToken制御は、典型的には、PKIにのみエンドエンティティの初期化に使用されるであろう。
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の値は、テキスト文字列またはそのような乱数のような数値であってもよいです。後者の値は、バイナリ量として、またはバイナリ数の文字列表現としてのいずれかで符号化することができました。関係なく量の性質の値の一様な符号化を確実にするために、regTokenのエンコーディングは、UTF8でなければなりません。
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.
オーセンティケータコントロールは、CAとの通信にアイデンティティの非暗号化チェックを確立するために、継続的に使用される情報が含まれています例としては、母親の旧姓、社会保障番号の最後の4桁、または加入者のCAと共有する他の知識ベースの情報を。そのような情報のハッシュ。または他の情報は、この目的のために作ら。オーセンティケータの制御のための値は、加入者によって、またはCAによって生成されてもよいです
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の値は、テキスト文字列またはそのような乱数のような数値であってもよいです。後者の値は、バイナリ量として、またはバイナリ数の文字列表現としてのいずれかで符号化することができました。関係なく量の性質の値の一様な符号化を確実にするために、オーセンティケータのエンコーディングは、UTF8でなければなりません。
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 }
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
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は、それが選択するあらゆる手段を使用して証明書を発行することを示しています。
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.
X500、ウェブまたはLDAP値の1とDONTCAREとの1：リクエスタは、少なくともいくつかの場所に表示される証明書を希望するが、他のリポジトリ内の証明書を利用できるようにCAを有効にしたい場合は、pubInfosためSinglePubInfoの2つの値を設定します。
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).
依頼者は、（例えば、一般的な名前の中CHOICEは、URLとIPアドレスが含まれていることに注意してください）発見される証明書をご希望の場所出版物フィールドは、提供されている場合、を示しています。
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制御は、認証要求の公開鍵に対応する秘密鍵のアーカイブを確立するために必要な情報を提供するために、加入者を可能にします。それは、次の構文で定義されます。
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.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue,
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the 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 }
KeyGenParameters ::= OCTET STRING
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.
キーを送信する代わりに、（例えば、多くのRSAの実装のための1が素数のために最初にテストした乱数を送ることができる）KeyGenParametersの選択肢を使用して、キーを再生成する方法についての情報を送信することです。このパラメータの実際の構文は、この文書の後続バージョンまたは別の規格で定義されてもよいです。
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
}
If present, the protocolEncrKey control specifies a key the CA is to use in encrypting a response to CertReqMessages.
存在する場合、protocolEncrKey制御は、CAが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.
CAが暗号化される必要があり、加入者に送信する情報を持っているときに、このコントロールを使用することができます。このような情報は、加入者が使用するためにCAによって生成された秘密鍵が含まれています。
The encoding of protocolEncrKey SHALL be SubjectPublicKeyInfo.
protocolEncrKeyのエンコーディングはSubjectPublicKeyInfoでされなければなりません。
The OID id-pkix has the value
OID ID-PKIXの値を有します
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) }
- インターネットX.509 PKIプロトコルの円弧とそのコンポーネントID-pkipオブジェクト識別子:: {ID-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 }
-- 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
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と通信するために使用されるプロトコルまたはプロセスのセキュリティメカニズムに頼るあります。このようなプロトコルまたはプロセスは、メッセージの整合性、データ発信元の真正、およびプライバシーを確保する必要があります。それは加入者の機密情報が含まれている場合と、CAはエンドエンティティに知られている暗号化証明書を持っている場合CRMFの暗号化を強くお勧めします。
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
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の貢献を認めます。
Michael Myers VeriSign, Inc. 1390 Shorebird Way Mountain View, CA 94019
マイケル・マイヤーズベリサイン株式会社1390シギ・チドリ類ウェイマウンテンビュー、CA 94019
EMail: mmyers@verisign.com
メールアドレス：mmyers@verisign.com
Carlisle Adams Entrust Technologies 750 Heron Road, Suite E08 Ottawa, Canada, K1V 1A7
カーライルアダムスエントラストテクノロジーズ750ヘロン道路、スイートE08オタワ、カナダ、K1V 1A7
EMail: cadams@entrust.com
メールアドレス：cadams@entrust.com
Dave Solo Citicorp 666 Fifth Ave, 3rd Floor New York, Ny 10103
デイブ・ソロシティコープ666フィフスアベニュー、3階ニューヨーク、NY 10103
EMail: david.solo@citicorp.com
メールアドレス：david.solo@citicorp.com
David Kemp National Security Agency Suite 6734 9800 Savage Road Fort Meade, MD 20755
デビッド・ケンプ国家安全保障局（NSA）のスイート6734 9800サベージ道路フォートミード、MD 20755
EMail: dpkemp@missi.ncsc.mil
メールアドレス：dpkemp@missi.ncsc.mil
Appendix A. Constructing "dhMAC"
付録A.の構築「dhMAC」
This Appendix describes the method for computing the bit string "dhMAC" in the proof-of-possession POPOPrivKey structure for Diffie-Hellman certificate requests.
この付録では、のDiffie-Hellman証明書の要求のための実証の所持POPOPrivKey構造のビット列「dhMAC」を計算する方法を説明します。
The DH parameters used to calculate the public SHOULD be those
specified in the CA's DH certificate.
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
エンティティEについてCApub = G ^ X MOD P（G、pは確立DHパラメータであり、xはCAの秘密DH成分である）：DHプライベート値= Y電子出版= DHパブリック値= G ^ Y MOD CAのDH証明書からP
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フィールドの値は、バイナリ文字列が得られ、符号化されたDERです。これは、[HMAC]にいう「テキスト」、HMAC-SHA1を適用したデータです。
b) A shared DH secret is computed, as follows, shared secret = Kec = g^xy mod p
B）A共有DH秘密は、計算され、共有秘密= KECは= G ^ XY MOD pは次のように
[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.]
【これはCApubはCAのDH証明書から取得され、電子出版は、実際の認定要求から取得される電子出版^ XとしてCApub ^ yとエンティティEによって、およびCAによって行われます。]
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）キーKは、共有秘密KECとCAの証明書のサブジェクトと発行者の名前に由来しています。
K = SHA1(DER-encoded-subjectName | Kec | DER-encoded-issuerName)
K = SHA1（DER符号化され、サブジェクト名| 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.
ここで、「|」連結を意味します。 CA証明書内のサブジェクト名が空のシーケンスである場合、DERエンコード-のsubjectAltNameが代わりに使用されるべきです。同様に、issuerNameが空のシーケンスである場合、DERエンコード-issuerAltNameが代わりに使用されるべきです。
d) Compute HMAC-SHA1 over the data 'text' as per [RFC2104] as: SHA1(K XOR opad, SHA1(K XOR ipad, text))
D）として、[RFC2104]あたりのようなデータの 'text' オーバー計算HMAC-SHA1：SHA1（K XORのOPAD、SHA1（K XOR計算され、テキスト））
where, opad (outer pad) = the byte 0x36 repeated 64 times and ipad (inner pad) = the byte 0x5C repeated 64 times.
ここで、OPAD（アウターパッド）バイト0x36を64回繰り返し、=とのiPad（インナパッド）0x5Cを64回繰り返しバイト=。
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は長さ16バイトである場合、例えば、それは48ゼロのバイトは0x00が付加される）64バイトの文字列を作成するために、Kの末尾にゼロを追加します。 （2）アプリとのXOR（ビット単位の排他的OR）工程（1）で計算された64バイトの文字列を。 （3）ステップ（2）から得られた64バイト列へのデータストリーム「テキスト」を追加します。 （4）ステップ（3）で生成されたストリームにSHA1を適用します。 （5）XOR（ビット単位の排他的OR）OPADと工程（1）で計算された64バイトの文字列。 （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）の出力は、ビット列（値「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.実証の所有プロセスは、（D）を介してステップ（a）を実施した後、単にそれが「dhMAC」値として受け取ったものと工程（d）の結果を比較するためにCAを必要とします。それらが一致する場合は、次のように結論することができます。
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).
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.
CA）は、同じ共有秘密を計算するために、独自の秘密鍵を必要とするため2）のみ意図CAは、実際に（要求を確認することができます。これは、不正のCAから保護するのに役立ちます。
References
リファレンス
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ"、RFC 2104、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のテストケース"、RFC 2202、1997年9月。
Acknowledgements
謝辞
The details of this Appendix were provided by Hemma Prafullchandra.
この付録の詳細は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.
（12に等しい「タグ」フィールドと、適切な「長さ」フィールドを持つ）ID-REGINFO-utf8Pairsオクテット文字列の「値」フィールドには、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.
この付録では、この仕様の独立した実装間での相互運用性を促進する目的のために、このようなペアのいくつかの一般的な例を示しています。このリストは網羅的なものではなく、時間と実装経験と成長することが認識されています。
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が（ID-REGINFO-utf8Pairsを介して）一つ以上の名前と値のペアを伝えるために使用される場合、以下のように、第一およびその後のペアが構成されなければなりません。
[name?value][%name?value]*%
[名前？値] [％名前？値] *％
This string is then encoded into an OCTET STRING and placed into the regInfo SEQUENCE.
この文字列はオクテット列に符号化さREGINFO配列に配置されます。
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
mailStop -- mail stop issuerName -- name of CA subjectName -- name of Subject validity -- validity interval
メールストップ - メールストップissuerName - CAのサブジェクト名の名前 - 件名の妥当性の名 - 有効期間
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_company？アクメ社％のORG_UNIT？エンジニアリング％のmail_firstName？ジョン％のmail_lastName？スミス％jobTitle？チームリーダーの％のmail_email?john@acme.com%
B.1.1. IssuerName, SubjectName and Validity Value Encoding
B.1.1。 IssuerName、サブジェクト名や有効性の値のエンコーディング
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.
issuerName ::= <names>
subjectName ::= <names>
<names> ::= <name> | <names>:<name>
<validity> ::= validity ? [<notbefore>]-[<notafter>]
<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.
ここで、<時間>フォーム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は、当該符号化のためのHEX値を表し、エスケープシーケンス％のxxは、使用しなければならない。以内パーセント記号は%%で表されます。
<name> ::= X<xname>|O<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"）：
<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（一般名）STREET（ストリートアドレス）E（E-mailアドレス）。
<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は>は、UTF8のIA5サブセットにASN.1はPrintableStringの文字のみを使用することができる制限で、1〜64文字のUTF8文字列の形式で名前のコンポーネントです。
Other name form (identifier "O"):
<oname> ::= <oid> , <utf8string>
E-mail address (rfc822name) name form (identifier "E"):
<ename> ::= <ia5string>
DNS name form (identifier "D"):
<dname> ::= <ia5string>
URI name form (identifier "U"):
<uname> ::= <ia5string>
IP address (identifier "I"):
<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は、私たちのCAを=、O =アクメ、Cは= US％のSubjectName？XCN =ジョン・スミス、O = Acmeの、C = US、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、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
Appendix C. ASN.1 Structures and OIDs
付録C. ASN.1構造とのOID
PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(5)}
PKIXCRMF {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-CRMF（5）}
CRMF DEFINITIONS IMPLICIT TAGS ::=
BEGIN
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)}
輸入 - ディレクトリ認証フレームワーク（X.509）版、のAlgorithmIdentifier、名前、時間、SubjectPublicKeyInfoで、拡張機能、のUniqueIdentifier PKIX1Explicit88 FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-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)}
-- 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) };
- 暗号メッセージ構文EnvelopedDataの暗号メッセージ構文FROM {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（0）CMS（1）} ;
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
pop 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
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
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 }
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.
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
公開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 }
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])
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.
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 --
- オブジェクト識別子の割り当て -
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 id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }
-- 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
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
--with syntax:
RegToken ::= UTF8String
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
--with syntax:
Authenticator ::= UTF8String
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
--with syntax:
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)
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
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
-- 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.
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
KeyGenParameters ::= OCTET STRING
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
--with syntax:
OldCertId ::= CertId
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER }
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
--with syntax:
ProtocolEncrKey ::= SubjectPublicKeyInfo
-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 }
id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
UTF8Pairs ::= UTF8String
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax
CertReq ::= CertRequest
END
終わり
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。