Network Working Group M. Blinov
Request for Comments: 4212 Guardeonic Solutions
Category: Informational C. Adams
University of Ottawa
October 2005
Alternative Certificate Formats for the
Public-Key Infrastructure Using X.509 (PKIX)
Certificate Management Protocols
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
IESG Note
IESG注意
This document is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this document for any purpose, and in particular notes that it has not had IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment.
この文書はインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、それが展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFのレビューを受けていない特定のノートに、このドキュメントのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。
Abstract
抽象
The Public-Key Infrastructure using X.509 (PKIX) Working Group of the Internet Engineering Task Force (IETF) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well. This document specifies how such certificates may be requested using the Certificate Request Message Format (CRMF) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX Certificate Management Protocol (PKIX-CMP) and Certificate Management Messages over CMS (CMC).
インターネットエンジニアリングタスクフォース（IETF）の公開鍵インフラストラクチャ使用してX.509（PKIX）ワーキンググループは、証明書管理プロトコルの数を定義しました。これらのプロトコルは、主のX.509v3公開鍵証明書に焦点を当てています。しかし、同様に代替フォーマットで証明書を管理することが望ましい場合があります。この文書では、そのような証明書は、いくつかの異なるプロトコルで使用される証明書要求メッセージフォーマット（CRMF）構文を使用して要求することができる方法を指定します。また、代替証明書フォーマットは、CMSを超えるPKIX証明書管理プロトコル（PKIX-CMP）と証明書の管理メッセージ（CMC）などの一般的なプロトコルに組み込むことができる方法を説明します。
Full certificate life-cycle management in a Public-Key Infrastructure (PKI) requires protocol support in order to achieve automated processing and end user transparency. Such protocols require standardization in order to allow more than one vendor to supply various pieces -- End Entity (EE), Certification Authority (CA), Registration Authority (RA) -- in the PKI deployment of a single organization, or to allow multiple, independently-deployed PKIs to be interconnected usefully.
公開鍵基盤（PKI）で完全な証明書のライフサイクル管理を自動処理し、エンドユーザーの透明性を達成するために、プロトコルのサポートが必要です。複数のベンダーがさまざまな部分を供給することを可能にするために、このようなプロトコルが標準化を必要と - エンドエンティティ（EE）、認証局（CA）、登録局（RA） - 単一の組織のPKIの展開で、または複数許可します、独立して、展開のPKIを有効に相互接続されます。
The IETF PKIX (Public-Key Infrastructure using X.509) Working Group currently has several certificate management protocols and certificate request syntax specifications on the standards track. Although these specifications are primarily focused on X.509v3 public-key certificates, some of them can be easily extended to handle certificates in alternative formats as well.
IETF PKIX（X.509を使用して公開鍵基盤）ワーキンググループは、現在、いくつかの証明書管理プロトコルと標準トラック上の証明書要求の構文の仕様を持っています。これらの仕様は、主のX.509v3公開鍵証明書に焦点を当てているが、そのうちのいくつかは、簡単にだけでなく、代替フォーマットの証明書を処理するために拡張することができます。
This document focuses on a popular certificate request syntax called CRMF (Certificate Request Message Format) [CRMF]. Although the original specification of CRMF is X.509-specific, extensions have already been proposed to allow for alternative certificate templates [CMP]. However, those extensions have only defined a framework; they did not define the exact format to be used for various certificate types.
この文書では、CRMF（証明書要求メッセージ形式）[CRMF]と呼ばれる人気の証明書要求の構文に焦点を当てています。 CRMFのオリジナルの仕様はX.509固有のものですが、拡張子がすでに代替の証明書テンプレート[CMP]を可能にするために提案されてきました。しかし、これらの拡張子は唯一のフレームワークを定義しています。彼らは、さまざまな証明書の種類に使用する正確なフォーマットを定義していませんでした。
This document builds on top of the framework mentioned above and defines how CRMF can be used to request certificates of the following types:
この文書では、上記のフレームワークの上に構築され、CRMFは、次の種類の証明書を要求するために使用する方法を定義します。
- X.509 attribute certificates [ATTCERT]
- X.509属性証明書[ATTCERT]
- OpenPGP certificates [OPENPGP]
- OpenPGPの証明書[のOpenPGP]
The CRMF syntax is used by such popular protocols as PKIX-CMP (PKIX Certificate Management Protocol) [CMP] and CMC (Certificate Management Messages over CMS) [CMC]. This means that CRMF extensions proposed in this document enable these protocols to request certificates of the above types. However, it is not enough to be able to request a certificate. The protocol should be prepared to handle certificates of a particular type and, for example, return them to the user.
CRMF構文はPKIX-CMP（PKIX証明書管理プロトコル）[CMP]とCMC（CMSオーバー証明書管理メッセージ）[CMC]などの一般的なプロトコルで使用されます。これは、この文書で提案CRMFの拡張子は、上記の種類の証明書を要求するためにこれらのプロトコルを有効にすることを意味します。しかし、証明書を要求することができることが十分ではありません。プロトコルは、特定のタイプの証明書を処理し、例えば、ユーザに戻すように準備されるべきです。
This document proposes extensions to the PKIX-CMP and CMC protocols that are required to manage certificates in alternative formats.
この文書では、代替フォーマットで証明書を管理するために必要とされているPKIX-CMPとCMCのプロトコルへの拡張を提案しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
One of the features of the CRMF format is its use of the CertTemplate construct, which allows a requester (EE, or RA acting on behalf of an EE) to specify as much or as little as they wish regarding the content of the requested certificate. It is explicitly noted that the CA has final authority over the actual certificate content; that is, the CA may alter certificate fields or may add, delete, or alter extensions according to its operating policy (if the resulting certificate is unacceptable to the EE or RA, then that certificate may be rejected and/or revoked prior to any publication/use).
CRMF形式の特徴の一つは、同じくらいか、わずか彼らは要求された証明書の内容についての望むように指定するには、依頼者（EE、またはRAは、EEのために行動する）ことができますCertTemplateのの使用構築、です。明示的にCAは、実際の証明書の内容を超える最終的な権限を持っていることに留意されたいです。すなわち、CAが証明書フィールドを変更することができる、または、追加、削除、または得られた証明書は、その証明書が拒否されてもよく、および/または任意の出版物の前に失効EE又はRAに対して許容できない場合（その動作ポリシーに従って拡張機能を変更することができる、あります/つかいます）。
A similar flexibility in the request must be available for alternative certificate types as well. For this purpose, an AltCertTemplate extension was introduced in [CMP] as follows (where id-regCtrl = {1 3 6 1 5 5 7 5 1}, as defined in [CRMF]).
リクエストで同様の柔軟性は、同様に、代替の証明書タイプのために利用可能でなければなりません。この目的のために、AltCertTemplate拡張子が[CMP]で導入された次のように（ここで、[CRMF]で定義されるように、ID-regCtrl = {1 3 6 1 5 7 5 1}）。
CertRequest ::= SEQUENCE {
certReqId INTEGER,
certTemplate CertTemplate,
controls Controls OPTIONAL }
-- If certTemplate is an empty SEQUENCE (i.e., all fields
-- omitted), then controls MAY contain the
-- id-regCtrl-altCertTemplate control, specifying a template
-- for a certificate other than an X.509v3 public-key
-- certificate. Conversely, if certTemplate is not empty
-- (i.e., at least one field is present), then controls
-- MUST NOT contain id-regCtrl-altCertTemplate. The new
-- control is defined as follows:
id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
AltCertTemplate ::= AttributeTypeAndValue
In this section, an AltCertTemplate is specified for each of the alternative certificate types defined in Section 1.
このセクションでは、AltCertTemplateはセクション1に定義された代替的な証明書の種類ごとに指定されています。
A CertTemplate for an X.509 attribute certificate can be used by simply defining an object identifier (OID) and corresponding value for use in the id-regCtrl-altCertTemplate control. These are specified as follows.
X.509属性証明書のCertTemplateのは、単に、ID-regCtrl-altCertTemplate制御における使用のためのオブジェクト識別子（OID）と対応する値を定義して使用することができます。これらは次のように指定されています。
OID:
ON：
id-acTemplate OBJECT IDENTIFIER ::=
{id-regCtrl-altCertTemplate 1}
Value:
値：
AttCertTemplate ::= SEQUENCE {
version AttCertVersion OPTIONAL,
holder Holder OPTIONAL,
issuer AttCertIssuer OPTIONAL,
signature AlgorithmIdentifier OPTIONAL,
serialNumber CertificateSerialNumber OPTIONAL,
attrCertValidityPeriod OptionalAttCertValidity OPTIONAL,
attributes SEQUENCE OF Attribute OPTIONAL,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL
}
OptionalAttCertValidity ::= SEQUENCE {
notBeforeTime GeneralizedTime OPTIONAL,
notAfterTime GeneralizedTime OPTIONAL
} -- at least one must be present
Similar to certificate templates defined above, a CertTemplate for an OpenPGP certificate can be used by defining an object identifier (OID) and corresponding value for use in the id-regCtrl-altCertTemplate control. These are specified as follows:
上記で定義された証明書テンプレート、OpenPGPの証明書のCertTemplateのと同様に、ID-regCtrl-altCertTemplate制御における使用のためのオブジェクト識別子（OID）と対応する値を定義して使用することができます。これらは次のように指定されています。
OID:
ON：
id-openPGPCertTemplateExt OBJECT IDENTIFIER ::=
{id-regCtrl-altCertTemplate 2}
Value:
値：
OpenPGPCertTemplateExtended ::= SEQUENCE {
nativeTemplate OpenPGPCertTemplate,
controls Controls OPTIONAL }
OpenPGPCertTemplate ::= OCTET STRING
-- contains the OpenPGP CertTemplate data structure defined
-- below (binary format without Radix-64 conversions)
-- encoded as an ASN.1 OCTET STRING
Similar to the X.509 CertTemplate, the OpenPGP CertTemplate is an OpenPGP certificate (OpenPGP Transferable Public Key) [OPENPGP] with all fields optional. The essential elements of an OpenPGP CertTemplate are:
X.509 CertTemplateのと同様に、OpenPGPのCertTemplateのは、オプションのすべてのフィールドで[のOpenPGP]のOpenPGP証明書（OpenPGPの譲渡公開鍵）です。 OpenPGP CertTemplateのの本質的な要素は以下のとおりです。
- Zero or one Public Key packet.
- ゼロまたは1つの公開鍵パケット。
- Zero or more Direct Key Self Signature packets.
- ゼロ以上のダイレクトキーの自己署名パケット。
- Zero or more Certification Signature packets (only if no User ID packets are present).
- ゼロ以上の認証署名パケット（ユーザーIDパケットが存在しない場合のみ）。
- Zero or more User ID packets.
- ゼロ以上のユーザーIDパケット。
- After each User ID packet, zero or more Certification Signature packets.
- 各ユーザIDパケット、ゼロまたはそれ以上の認証署名パケット後。
- Zero or more Subkey packets.
- ゼロ以上のサブキーパケット。
- After each Subkey packet, zero or one Subkey Binding Signature packet.
- 各サブキーのパケット後に、0または1サブキーは、署名パケットを結合します。
Each packet in the OpenPGP CertTemplate MUST be a syntactically correct OpenPGP packet. This will enable conformant implementations to use existing PGP libraries for building and parsing OpenPGP CertTemplates.
OpenPGPのCertTemplateの中の各パケットは、構文的に正しいのOpenPGPパケットでなければなりません。これは、OpenPGPのCertTemplatesを構築し、解析するために、既存のPGPライブラリを使用する準拠の実装を可能にします。
The following implications of this rule should be explicitly noted:
このルールの以下の意味合いを明示的に注意する必要があります。
- Fields for which the OpenPGP specification defines a set of permitted values (e.g., the signature type or the public key algorithm fields of the Signature packet) MUST have a value from the defined set. Even if the requester does not have any particular preferences for, for example, the signature algorithm, it MUST choose one value that is the most desirable.
- フィールドのOpenPGP仕様が許容値のセットを定義するため（例えば、署名タイプまたは署名パケットの公開鍵アルゴリズムフィールド）が定義されたセットからの値を有しなければなりません。依頼者は、例えば、署名アルゴリズムのための特定の好みを持っていない場合であっても、それが最も望ましい一つの値を選択する必要があります。
Rationale: An alternative solution could be to define extra "any" values, but this would be a modification of the OpenPGP syntax, which is not considered appropriate in this document.
理論的根拠：代替ソリューションは、余分な「任意の」値を定義するかもしれないが、これは、この文書では適切であると考えられていないのOpenPGP構文の変更になります。
- All subpackets of the Signature packet defined by the OpenPGP specification as mandatory (e.g., the creation time and the issuer's key id subpackets) MUST be present even though they do not make much sense in the context of a certificate request.
- 彼らは、証明書の要求のコンテキストであまり意味がありませんが必須としてのOpenPGP仕様で定義された署名パケットのすべてのサブパケットが（例えば、作成時間や発行者のキーIDサブパケット）が存在しなければなりません。
- The number of MPIs at the end of the Key Material and the Signature packets MUST match the number defined by the OpenPGP specification for the given algorithm (the algorithm is controlled by the value of the "algorithm" field). For example, there should be 2 MPIs for DSA signatures. Note that the OpenPGP specification does not define validation rules for the content of those MPIs.
- 暗号化キーおよび署名パケットの末尾のMPIの数は、与えられたアルゴリズム（アルゴリズムは「アルゴリズム」フィールドの値によって制御される）のためのOpenPGP仕様で定義された数と一致しなければなりません。たとえば、DSA署名のための2つのMPIがあるべきです。 OpenPGPの仕様は、これらのMPIのコンテンツの検証ルールを定義していないことに注意してください。
Though it is not considered appropriate here to define extra "any" values for fields of enumerated types, such values can still be defined for some other fields where the OpenPGP specification is not that strict.
それが列挙型のフィールドのための余分な「任意の」値を定義するために、ここでは適切ではないと考えられるが、このような値はまだOpenPGPの仕様がその厳格されていないいくつかの他のフィールドのために定義することができます。
The following extra values are defined in the context of the OpenPGP CertTemplate. Note that these definitions do not modify the syntax of OpenPGP packets, and existing PGP libraries can still be used to generate and parse them.
以下の余分な値は、OpenPGPのCertTemplateの文脈の中で定義されています。これらの定義は、OpenPGPのパケットの構文を変更しないことに注意し、既存のPGPライブラリがまだそれらを生成し、解析するために使用することができます。
- For fields representing time (e.g., signature creation time): the value of zero means "any time".
- 時間（例えば、署名作成時間）を表すフィールドの場合：ゼロの値は、「いつでも」を意味します。
- For fields holding key IDs: the value of 0xFFFFFFFFFFFFFFFF means "any key id".
- キーIDを保持するフィールドについて：0xFFFFFFFFFFFFFFFFの値は、「任意のキーID」を意味します。
- For signature fields: the "any signature" value is encoded as a sequence of MPIs such that:
- 署名フィールドの場合：「任意の署名」値は、それのMPIのシーケンスとして符号化されます
* the number of MPIs matches the number of MPIs defined by the OpenPGP specification for the given algorithm, and
*のMPIの数は、与えられたアルゴリズムのためのOpenPGP仕様で定義されたのMPIの数と一致し、そして
* the value of each MPI is 0xFF.
*各MPIの値が0xFFです。
A Signature packet with the "any" value in the signature fields is called a Signature Template.
署名フィールド内の「任意」の値を有する署名パケットは、署名テンプレートと呼ばれています。
Example: The "any signature" value for a DSA signature would look like [00 08 FF 00 08 FF]
例：DSA署名について「任意の署名」の値は、[00 08 FF 00 08 FF]のようになります。
- For key material fields: the "any key" value is encoded as a sequence of MPIs such that:
- 鍵素材フィールドについて：「任意のキー」の値は、その結果のMPIのシーケンスとして符号化されます。
* the number of MPIs matches the number of MPIs defined by the OpenPGP specification for the given algorithm, and
*のMPIの数は、与えられたアルゴリズムのためのOpenPGP仕様で定義されたのMPIの数と一致し、そして
* the value of at least one of the MPIs is a bit string with all its bits set to 1.
*のMPIの少なくとも一方の値が1に設定され、すべてのビットのビット列です。
A Key Material packet with the "any" value in the key material fields is called a Key Template. (See Key Template section for further details.)
キー材料分野における「任意の」値を持つ鍵データパケットは、キーテンプレートと呼ばれています。 （詳細はキーテンプレートのセクションを参照してください。）
Example: The "any key" value for a DSA public key may look like [00 08 FF 00 10 FF FF 00 10 85 34 00 08 FF]
例：DSA公開鍵の "任意のキー" の値は、[00 08 FF 00 10 FF FF 00 10 85 34 00 08 FF]のように見えるかもしれ
The following rules apply to the sequence of packets within the OpenPGP CertTemplate:
次の規則がOpenPGPのCertTemplateの中の一連のパケットに適用されます。
- If the Public Key packet is omitted from the OpenPGP CertTemplate, then this CertTemplate does not constrain the value of the public key (i.e., it refers to "any" public key).
- 公開鍵パケットはOpenPGPのCertTemplateのから省略されている場合、このCertTemplateのは（すなわち、それは「あらゆる」公開鍵をいう。）公開鍵の値を制約しません。
- The order of Signature packets following a User ID packet and the order of User ID packets within the CertTemplate are not important.
- ユーザーIDパケットとCertTemplateの中のユーザーIDパケットの順序以下の署名パケットの順序は重要ではありません。
- If an OpenPGP CertTemplate does not contain any User ID packets, then it refers to "any" user IDs that are relevant to a given request.
- OpenPGPのCertTemplateのは、任意のユーザーIDパケットが含まれていない場合、それは与えられたリクエストに関連している「すべての」ユーザーIDを指します。
Since an OpenPGP certificate can have several certification signatures, the OpenPGP CertTemplate uses Signature Templates to define where certification signatures should occur. The values of the fields of the Signature Templates define the parameters of the new certification signatures. The following rules apply:
OpenPGPの証明書は、いくつかの認証署名を持つことができるので、OpenPGPのCertTemplateのは、認証署名が発生する場所を定義するために署名テンプレートを使用します。署名テンプレートのフィールドの値は、新しい認証署名のパラメータを定義します。次の規則が適用されます。
- A Signature Template that is present in the list of signatures following a User ID packet requests that the CA certify this User ID and the public key and replace the Signature Template with the new certification signature. The Signature Template does not mandate the exact place of the certification signature within the list. The certification signature may be inserted at any position within the list of signatures (following the certified User ID packet).
- CAは、このユーザーIDと公開鍵を証明し、新しい証明書の署名と署名のテンプレートを置き換えるユーザIDのパケット要求、次のシグニチャのリストに存在する署名テンプレート。署名テンプレートは、リスト内の認証署名の正確な場所を強制しません。認証署名は、（認定ユーザーIDパケットに続く）署名のリスト内の任意の位置に挿入することができます。
- A Signature Template may be present in the OpenPGP CertTemplate without any preceding User ID packet. In this case, it is assumed that the CA knows the ID(s) of the user by some other means. A Signature Template without a preceding User ID requests that the CA insert all known User IDs of the user into the OpenPGP certificate and certify each of them. The Signature Template defines the parameters of these certification signatures.
- 署名テンプレートいずれかユーザーIDパケットなしのOpenPGP CertTemplateの中に存在してもよいです。この場合、CAは、いくつかの他の手段によってユーザのID（複数）を知っているものとします。 CAは、OpenPGPの証明書へのユーザのすべての既知のユーザIDを挿入し、それらの各々を認証前のユーザーIDを要求せずに署名テンプレート。署名テンプレートは、これらの認証署名のパラメータを定義します。
- If an OpenPGP CertTemplate contains no Signature Templates, then the CA is requested to certify all User IDs that are present in the OpenPGP CertTemplate. Such a CertTemplate does not define parameters of the certification signatures explicitly, but the CA SHOULD use parameters of the certification self-signatures (if present in the CertTemplate) as a guide (e.g., key flags fields).
- OpenPGPのCertTemplateのは何の署名テンプレートが含まれていない場合は、CAは、OpenPGPのCertTemplateの中に存在するすべてのユーザーIDを認証するために要求されています。そのようなCertTemplateの明示的認証署名のパラメータを定義していないが、（CertTemplateの中に存在する場合）CAは、ガイド（例えば、キーフラグフィールド）として認定自己署名のパラメータを使用すべきです。
- If neither Signature Templates nor User IDs are present in the OpenPGP CertTemplate, then the CA is expected to know the ID(s) of the user by some other means. In this case, the CertTemplate requests that the CA insert these User IDs into the OpenPGP certificate and certify each of them. The parameters of the certification signatures are left to the CA.
- どちらの署名テンプレートやユーザIDがOpenPGPのCertTemplateの中に存在する場合、CAは、いくつかの他の手段によってユーザのID（複数）を知っていると期待されます。この場合、CertTemplateのは、CAがOpenPGPの証明書にこれらのユーザーIDを挿入し、それらのそれぞれを証明することを要求します。認証署名のパラメータは、CAに残っています
If several certification signatures have to be produced according to an OpenPGP CertTemplate, and any of them cannot be granted (even with modifications) for whatever reason, then the whole request with this OpenPGP CertTemplate MUST be rejected.
いくつかの認証署名がOpenPGPのCertTemplateのに従って製造する必要があり、それらのいずれかが何らかの理由で（でも修正を加えて）付与することができない場合は、このOpenPGPのCertTemplateの持つ全体の要求を拒絶しなければなりません。
The client SHOULD provide enough information in its request that the CA could produce a complete OpenPGP certificate. For example, the client SHOULD include in the template all relevant subkeys with their binding signatures so that the CA can include them in the resultant OpenPGP certificate as well. Rationale: In some environments, the CA/RA is responsible for publishing certificates.
クライアントは、CAが完了したOpenPGP証明書を作ることができ、その要求に十分な情報を提供する必要があります。 CAは、同様に結果のOpenPGP証明書に含めることができるように例えば、クライアントがテンプレートにそれらの結合署名と関連するすべてのサブキーを含むべきです。理由は：一部の環境では、CA / RAは、証明書の公開に責任があります。
The OpenPGP CertTemplate can also be used to request certification of centrally-generated keys. This is accomplished by using Key Templates.
OpenPGP CertTemplateのはまた、中央生成キーの認証を要求するために使用することができます。これは、キーテンプレートを使用することによって達成されます。
If the Public Key packet of an OpenPGP CertTemplate is a Key Template, then this OpenPGP CertTemplate requests that the CA/RA generate the key pair prior to certifying it. Fields of the Key Template define parameters of the new key pair as follows (see examples in the Appendix):
OpenPGP CertTemplateのの公開鍵パケットがキーテンプレートである場合、これのOpenPGP CertTemplateのは、CAが/ RAそれを証明する前に鍵のペアを生成することを要求します。 （付録の例を参照）、次のようにキーテンプレートのフィールドは、新しい鍵ペアのパラメータを定義します。
- The "public key algorithm" field specifies the algorithm to be used for the key generation.
- 「公開鍵アルゴリズム」フィールドには、キーの生成に使用するアルゴリズムを指定します。
- MPI fields with the value of 0xFF ([00 08 FF]) specify that no constraint is placed on the corresponding part of the key.
- 0xFFの（[00 08 FF]）の値にMPIフィールドには制約がキーの対応する部分上に配置されていないことを指定します。
- MPI fields that contain any other bit strings in which all bits are set to 1, specify that the corresponding part of the key should be of the same length as the length of the MPI (e.g., the length of the public modulus n of the RSA key).
- すべてのビットが1に設定されている他の任意のビット列を含むMPIフィールドは、キーの対応する部分は、MPI（例えば、公共のモジュラスNの長さの長さと同じ長さでなければならないことを指定しますRSAキー）。
- MPI fields that contain any other values specify that the corresponding part of the key should be of the given value (key generation parameters).
- 任意の他の値を含むMPIフィールドはキーの対応する部分が所定の値（鍵生成パラメータ）でなければならないことを指定します。
In order to return a complete OpenPGP certificate, in addition to certifying the new key and the User ID, the CA (or RA) SHOULD also create a self-signature (i.e., sign the new public key and the User ID with the new private key) and include it after the User ID packet. This SHOULD be done for all User IDs certified by the CA.
また、自己署名を作成する必要があり、新しいキーとユーザーID、CA（またはRA）を証明することに加えて、完全なOpenPGPの証明書を戻すためには（すなわち、新しいプライベートで新しい公開鍵とユーザーIDに署名キー）とユーザーIDパケットの後にそれを含めます。これは、CAによって認定され、すべてのユーザーIDのために行われるべきです
If a Subkey packet of an OpenPGP CertTemplate is a Key Template, then this OpenPGP CertTemplate requests that the CA/RA generate a subkey. Fields of the Key Template define parameters of the new subkey. The new subkey obviously does not have to be certified. However, the CA/RA SHOULD produce the binding signature and include it after the subkey, if the CA/RA knows the user's primary private key (e.g., it was centrally generated as well). Note that if the CA/RA does not know the user's primary private key, then the resultant OpenPGP certificate returned from the CA/RA to the client will be incomplete (i.e., there will be no binding signature for the subkey). It will be the responsibility of the client to produce and add the binding signature and to publish the final OpenPGP certificate.
OpenPGP CertTemplateのサブキーのパケットがキーテンプレートの場合、このOpenPGPのCertTemplateのはCA / RAは、サブキーを生成することを要求します。キーテンプレートのフィールドは、新しいサブキーのパラメータを定義します。新しいサブキーは明らかに認定されている必要はありません。しかし、CA / RAは結合署名を生成するべきであり、CA / RA（例えば、それは中心部だけでなく生成された）ユーザの主秘密鍵を知っている場合、サブキー後にそれを含めます。 CA / RAは、ユーザーのプライマリプライベート鍵を知らない場合は、結果のOpenPGP証明書がクライアントにCA / RAから返されることに注意してください（すなわち、サブキーのための結合署名は行われません）不完全になります。生産と結合署名を追加し、最終のOpenPGP証明書を発行するために、クライアントの責任になります。
If an OpenPGP CertTemplate contains neither PublicKey/Subkey packets nor Key Template packets, then it requests that the CA generate keys/subkeys according to the CA's policies.
OpenPGPのCertTemplateのは、どちらのPublicKey /サブキーパケットもキーテンプレートのパケットが含まれている場合、それはCAがCAのポリシーに従ってキー/サブキーを生成することを要求します。
The OpenPGPCertTemplateExtended structure enables additional extensions and controls to be added to the basic OpenPGP CertTemplate.
OpenPGPCertTemplateExtended構造は、基本のOpenPGP CertTemplateのに追加される追加の拡張機能とコントロールを可能にします。
A conformant implementation is REQUIRED to support OpenPGP CertTemplates that are valid OpenPGP certificates, i.e., that have the following structure (see examples in the Appendix):
準拠実装は、有効なOpenPGPの証明書、つまり、次のような構造を持っていること（付録の例を参照）しているのOpenPGP CertTemplatesをサポートするために必要です。
- One Public Key packet (not a Key Template).
- 一つの公開鍵パケット（ないキーテンプレート）。
- Zero or more Direct Key Self Signature packets (without Signature Templates).
- （署名テンプレートなし）ゼロ以上のダイレクトキーの自己署名パケット。
- One or more User ID packets.
- 1つ以上のユーザーIDパケット。
- After each User ID packet, zero or more Certification Signature packets (without Signature Templates).
- 各ユーザIDパケットの後、ゼロまたはそれ以上の認定署名パケット（オリジナルテンプレートなし）。
- Zero or more Subkey packets (without Key Templates).
- （キーテンプレートなし）ゼロ以上のサブキーパケット。
- After each Subkey packet, one Subkey Binding Signature packet (not a Signature Template).
- 各サブキーパケットの後、1つのサブキーバインディング署名パケット（不署名テンプレート）。
A conformant implementation is REQUIRED to recognise Key Templates and Signature Templates and is REQUIRED to either support them or reject requests containing them if it does not.
準拠の実装は、主なテンプレートと署名テンプレートを認識する必要があり、それらをサポートするか、そうでない場合は、それらを含む要求を拒否するかのいずれかが必要です。
A CRMF request includes a Proof-of-Possession (POP) field that contains proof that an End Entity has possession of the private key corresponding to the public key for which a certificate is requested.
CRMF要求は、エンドエンティティ証明書が要求されている公開鍵に対応する秘密鍵の所有を持っていることの証明が含まれている実証の所持（POP）フィールドを含みます。
The following rule applies to this field (with modifications from [CMP]):
以下のルールは、（[CMP]から変更して）このフィールドに適用されます。
* NOTE: If CertReqMsg certReq certTemplate (or the * altCertTemplate control) 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 (or the DER-encoded value * of AltCertTemplate).
*注：CertReqMsg CERTREQ CertTemplateの（または* altCertTemplate制御）が被写体と*公開鍵値が含まれている場合、同時にpoposkInputは*省略しなければならなくて、署名がCertReqMsg CERTREQ（またはDERエンコードのDER符号化された*値を計算しなければなりませんAltCertTemplateの値*）。
An OpenPGP CertTemplate is considered to satisfy the conditions of this note if it has a Public Key packet (not a Key Template) and at least one User ID packet.
それは公開鍵パケット（ないキーテンプレート）と少なくとも1つのユーザーIDパケットを持っている場合のOpenPGP CertTemplateのは、このノートの条件を満たすように考えられています。
This section explains how alternative certificate formats may be incorporated into such popular protocols as PKIX-CMP and CMC.
このセクションでは、代替の証明書フォーマットはPKIX-CMPとCMCなどの一般的なプロトコルに組み込むことができる方法を説明します。
In PKIX-CMP, the ASN.1 [ASN1] construct, and corresponding comment for a certificate is given as follows.
PKIX-CMPにおいて、ASN.1は、[ASN1]構築し、次のように証明書に対応するコメントが付与されます。
CMPCertificate ::= CHOICE {
x509v3PKCert Certificate
}
-- This syntax, while bits-on-the-wire compatible with the -- standard X.509 definition of "Certificate", allows the -- possibility of future certificate types (such as X.509 -- attribute certificates, WAP WTLS certificates, or -- other kinds of certificates) within this certificate
- この構文は、ビット・オン・ザ・ワイヤと互換性つつ - 属性証明書、WAP WTLS - 例えばX.509証明書などの将来の種類（の可能性 - 「証明書」の標準X.509定義は、可能証明書、または - この証明書内の証明書の他の種類）
-- management protocol, should a need ever arise to support -- such generality.
- そのような普遍性を - 管理プロトコルは、必要性がこれまでサポートするために発生する必要があります。
Building on this framework, this document expands the above CHOICE construct as follows.
このフレームワーク上で構築する、このドキュメントは、次のように上記CHOICEが構築拡張されます。
CMPCertificate ::= CHOICE {
x509v3PKCert Certificate,
x509v2AttCert [0] AttributeCertificate,
-- defined in [ATTCERT]
openPGPCert [2] OpenPGPCert
}
OpenPGPCert ::= OCTET STRING
-- contains the OpenPGP certificate (OpenPGP Transferable
-- Public Key) data structure from the OpenPGP specification
-- [OPENPGP] (binary format without Radix-64 conversions),
-- encoded as an ASN.1 OCTET STRING
Expanding the CHOICE construct as above allows X.509 attribute certificates and OpenPGP certificates to be used within the PKIX-CMP management messages. In the future, this construct may be expanded further (in subsequent revisions of this document) to accommodate other certificate types, if this is found to be necessary.
CHOICEは、上記のように構築し展開すると、X.509証明書とのOpenPGP証明書がPKIX-CMP管理メッセージ内で使用される属性ができます。これが必要であることが見出された場合、将来的に、この構築物は、他の証明書の種類に対応するために（この文書のその後の改訂に）さらに拡張することができます。
The CMC protocol uses the CMS (Cryptographic Message Syntax) syntax [CMS], which defines the certificate type as
CMCプロトコルは、証明書のタイプを定義するCMS（暗号メッセージ構文）構文[CMS]を、使用し
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2 }
Similar to PKIX-CMP, this CHOICE can be extended to include additional types of certificates as follows.
PKIX-CMPと同様に、この選択は、次のように証明書の追加タイプを含むように拡張することができます。
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2,
openPGPCert [3] IMPLICIT OpenPGPCert }
This allows both X.509 attribute certificates and OpenPGP certificates to be used within the CMC management messages. In the future, this construct may be expanded further (in subsequent revisions of this document) to accommodate other certificate types, if this is found to be necessary.
これは、X.509属性証明書とのOpenPGP証明書の両方が、CMC管理メッセージ内で使用することができます。これが必要であることが見出された場合、将来的に、この構築物は、他の証明書の種類に対応するために（この文書のその後の改訂に）さらに拡張することができます。
The CMC specification defines certain constraints on the subject and publicKey fields of the CRMF's CertTemplate structure. The same constraints should apply to the AltCertTemplate structure if alternative certificate types are used. For example, the CMC specification mandates that
CMC仕様はCRMFのCertTemplateの構造の対象と公開鍵フィールドに特定の制約を定義します。代替の証明書タイプが使用されている場合、同じ制約がAltCertTemplate構造に適用されるべきです。例えば、CMC仕様義務付けています
When CRMF message bodies are used in the Full Enrollment Request message, each CRMF message MUST include both the subject and publicKey fields in the CertTemplate.
CRMFメッセージ体をフル登録要求メッセージに使用される場合、各CRMFメッセージは、対象とCertTemplateの中の公開鍵フィールドの両方を含まなければなりません。
If alternative certificate types are used, this should be extended as
代替の証明書タイプが使用されている場合は、これは次のように拡張されなければなりません
When CRMF message bodies are used in the Full Enrollment Request message, each CRMF message MUST include both the subject and publicKey fields in the CertTemplate (or in the altCertTemplate control).
CRMFメッセージ体をフル登録要求メッセージに使用される場合、各CRMFメッセージは、対象と公開鍵フィールドCertTemplateの中に（またはaltCertTemplate制御で）の両方を含まなければなりません。
This document defines extensions to the CRMF format, so security considerations from the CRMF specification [CRMF] apply here as well. In particular, the security of alternative certificate templates relies upon the security mechanisms of the protocol or process used to communicate with CAs.
CRMF仕様からセキュリティ上の考慮事項は、[CRMF]ここにも適用されますので、この文書では、CRMF形式に拡張を定義します。具体的には、別の証明書テンプレートのセキュリティは、CASと通信するために使用されるプロトコルまたはプロセスのセキュリティメカニズムに依存しています。
Exact security requirements depend on a particular PKI deployment, but integrity protection and message origin authentication are typically required for certification requests. The CMP and CMC certificate management protocols mentioned in this document provide both integrity protection and message origin authentication for request messages (which includes certificate templates as well).
正確なセキュリティ要件は、特定のPKI展開に依存するが、完全性保護とメッセージの発信元認証は、通常、証明書の要求のために必要とされます。この文書に記載CMPとCMC証明書管理プロトコルが完全性保護と（同様の証明書テンプレートが含まれます）、要求メッセージのメッセージ起点認証の両方を提供しています。
Confidentiality may also be required where alternative certificate templates contain subscriber-sensitive information. The CMC protocol allows the content of request messages to be encrypted. CMP does not include confidentiality mechanisms for certification requests, but if confidentiality is needed, it can be achieved with a lower-layer security protocol (e.g., TLS or IPsec).
代替の証明書テンプレートは、加入者の機密情報を含む場合守秘義務も必要になることがあります。 CMCプロトコルは、要求メッセージの内容を暗号化することができます。 CMPは、認証要求のための機密保持機構を含んでいないが、機密性が必要な場合、それは下位層セキュリティプロトコル（例えば、TLSやIPsec）を用いて達成することができます。
In order to make a decision as to whether a request should be accepted, a CA should normally be able to compare the (authenticated) name of the sender of the request with the request subject name.
要求が受け入れられるか否かの判断を行うために、CAは、通常、要求サブジェクト名を持つリクエストの送信元の（認証済み）の名前を比較することができるはずです。
For example, an End Entity may be allowed to request additional certificates for himself/herself. In this case, the CA will accept a request if the Sender is equal to the Subject (of course, other conditions will have to be checked as well before the certificate is granted).
例えば、エンドエンティティは、彼自身/彼女自身のために追加の証明書を要求することを許可することができます。送信者は、件名に等しいこの場合、CAは要求を受け入れます（証明書が付与される前に、もちろん、他の条件も同様にチェックする必要があります）。
If a PGP certificate is requested using the extensions proposed here, the Sender field of the request will be encoded as an ASN.1 GeneralName (in both CMP and CMC), while the Subject will be represented as a PGP UserID. Since the PGP UserID is effectively an unrestricted octet string, it is not always trivial to compare these two types. It is possible that an attacker may try to submit requests with specially crafted UserIDs (e.g., that include obscure characters) in order to trick the CA comparison algorithm and obtain a PGP certificate with a UserID that belongs to someone else.
PGP証明書がここで提案された拡張機能を使用して要求された場合件名PGPユーザIDとして表現される一方、要求の送信者フィールドは、（CMPとCMCの両方で）ASN.1のGeneralNameとして符号化されます。 PGPのユーザーIDが効果的に無制限のオクテット文字列であるので、常にこれらの2つのタイプを比較するのは簡単ではありません。攻撃者がCA比較アルゴリズムをだましや他の誰かに属しているユーザーIDとPGP証明書を取得するためには（曖昧な文字が含まれ、例えば、）特別に細工されたユーザIDとの要求を提出しようとする可能性があります。
In these circumstances, it is safer for the CA, when building the PGP certificate's UserID, to completely rebuild the UserID based on the content of the authenticated Sender name rather than take the UserID from the request. To achieve this, additional information about the End Entity may be required at the CA (e.g., the EE's email address).
このような状況では、それはCAのために安全である、PGP証明書のユーザーIDを構築する際に、完全に認証された送信者名の内容に基づいてユーザーIDを再構築するのではなく、要求からのユーザーIDを取ります。これを達成するために、エンドエンティティに関する追加情報は、CA（例えば、EEのメールアドレス）で必要になることがあります。
Software components that implement the proposed extensions (e.g., CMP or CMC servers) will necessarily increase in complexity. If a "standard" server is expected to be able to parse ASN.1 streams, the "extended" server is required to be able to parse PGP streams as well. A PGP parser code may introduce new security vulnerabilities that can be exploited by an attacker to mount a DoS attack or gain access to the server.
提案された拡張を実装するソフトウェアコンポーネント（例えば、CMPまたはCMCのサーバー）は、必ずしも複雑に増加します。 「標準」サーバーがASN.1ストリームを解析することができると予想される場合、「拡張」サーバは、PGPは、同様にストリームを解析することが可能であることが要求されます。 PGPパーサコードは、DoS攻撃をマウントするか、サーバーへのアクセスを得るために、攻撃者によって悪用される可能性があります新しいセキュリティの脆弱性を導入することができます。
In order to reduce the consequences of a successful attack, it is recommended that the CMP or CMC servers be run on a separate machine from the main CA server. These protocol servers should not have access to the main CA key and should not have write access to the CA store.
攻撃が成功の影響を軽減するためには、CMPまたはCMCのサーバーがメインのCAサーバから別のマシン上で実行することをお勧めします。これらのプロトコル・サーバーは、メインのCAキーへのアクセス権を持つべきではないとCAストアへの書き込みアクセス権を持つべきではありません。
Appendix A. Examples of OpenPGP CertTemplates
OpenPGPのCertTemplatesの付録A.例
This Appendix presents examples of OpenPGP CertTemplates that are used for requesting OpenPGP certificates from a CA.
この付録では、CAからのOpenPGP証明書を要求するために使用されているのOpenPGP CertTemplatesの例を紹介します
A1. Simple Certificate Request
A1。シンプルな証明書要求
Alice requests an OpenPGP certificate for her public key accompanied by a subkey.
アリスは、サブキーを伴って彼女の公開鍵のためのOpenPGP証明書を要求します。
The content of the OpenPGP CertTemplate in the request is as follows. This CertTemplate conforms to the OpenPGP CertTemplate Required Profile.
次のようにリクエスト中のOpenPGP CertTemplateの内容です。このCertTemplateのは、OpenPGPのCertTemplateの必須プロファイルに準拠しています。
0000: 99 01 A2 === Pub Key packet === 0003: 04 3C 58 27 A2 11 ver 4, created 30 Jan 2002, DSA 0009: 00 E3 FB 9D .. 2B EF DSA prime p 008B: 00 A0 FF 7E .. BA 71 DSA group order q 00A1: 03 FF 68 BC .. 56 71 DSA group generator g 0123: 03 FE 38 1F .. F2 63 DSA public key value y 01A5: B4 19 === User ID packet === 01A7: 41 6C .. 6D 3E "Alice <alice@example.com>" 01C0: 89 00 49 === Signature packet (self-signature) === 01C3: 04 10 11 02 ver 4, gen cert, DSA, SHA1 01C7: 00 09 05 02 3C 58 27 A2 02 1B 03 created 30 Jan 2002, key usage: sign data and certify other keys 01D2: 00 0A 09 10 43 5C .. 06 77 issuer key id 01DE: 5A C2 left 16 bits of signed hash value 01E0: 00 A0 EB 00 .. 1B 75 DSA value r 01F6: 00 A0 F4 E4 .. A8 3D DSA value s 020C: B9 02 0D === Public Subkey packet === 020F: 04 3C 58 27 A2 10 ver 4, created 30 Jan 2002, Elgamal (encrypt-only) algorithm 0215: 08 00 F6 42 .. 0B 3B Elgamal prime p 0317: 00 02 02 Elgamal group generator g 031A: 07 FE 37 BA .. DF 21 Elgamal public key value y 041C: 89 00 49 === Signature packet (subkey binding) === 041F: 04 18 11 02 ver 4, subkey binding, DSA, SHA1 0423: 00 09 05 02 3C 58 27 A2 02 1B 0C created 30 Jan 2002, key usage: encrypt communications and storage 042E: 00 0A 09 10 43 5C .. 06 77 issuer key id 043A: C7 DE left 16 bits of signed hash value 043C: 00 9E 21 33 .. 39 1B DSA value r 0452: 00 9F 64 D7 .. 63 08 DSA value s 0468:
0000：99 01 A2 ===パブキーパケット=== 0003：00 E3 FB 9D .. 2B EF DSA素数pの008B：00 A0 FF 7E 4版04 3C 58 27 A2 11は、2002年1月30日、DSA 0009を作成しました.. BA 71 DSAグループ次数q 00A1：03 FF 68 BC .. 56 71 DSAグループジェネレータG 0123：03 FE 38 1F .. F2 63 DSA公開鍵の値y 01A5：B4 19 ===ユーザIDパケット=== 01A7：41 6C .. 6D 3E "アリス<alice@example.com>" 01C0：89 00 49 ===署名パケット（自己署名）=== 01C3：4版04 10 11 02、GENのCERT、DSA、 SHA1 01C7：符号データと他のキー01D2証明：00 09 05 02（c）58 27 A2 02（B）03 2002年1月30日、鍵使用法を作成した00 0A 09 10 43（c）を.. 06 77発行者鍵ID 01DE：5A C2は16ビットを残し署名されたハッシュ値01E0の：00 A0 EB 00 .. 1B 75 DSA値r 01F6：00 A0 F4 E4 .. A8 3D DSA値s 020C：B9 02 0D ===公開サブキーパケット=== 020F：04（c）58 27 08 00 F6 42 .. 0B 3Bエルガマル素数pを0317：00 02 02エルガマル群ジェネレータG 031A：07 FE 37 BA .. DF 21はElgamal 4版A2 10は、2002年1月30日、はElgamal（暗号化のみ）アルゴリズム0215を作成し公開鍵ヴァルUE Y 041C：89 00 49 ===署名パケット（サブキー結合）=== 041F：04 18 11 02 4版、サブキー結合、DSA、SHA1 0423：00 09 05 02（c）58 27 A2 02 1B 0C 30 2011/12/31作成しました2002は、主要な用法：暗号化通信およびストレージ042E：00 0A 09 10 43（c）.. 06 77発行者鍵ID 043A：1B DSA値R 0452 39 .. 00 9E 21 33：C7 DEは、署名されたハッシュ値043Cの16ビットを残しました。 00 9F 64 D7 ... 63 08 DSA値s 0468：
CA certifies Alice's User ID and the public key and creates the following OpenPGP certificate:
CAは、アリスのユーザーIDと公開鍵を認証すると、次のOpenPGP証明書を作成します。
0000: 99 01 A2 === Pub Key packet === 0003: <the same as in the request> 01A5: B4 19 === User ID packet === 01A7: <the same as in the request> 01C0: 89 00 49 === Signature packet (self-signature) === 01C3: <the same as in the request> 020C: 89 00 49 === Signature packet (certification) === 020F: 04 13 11 02 ver 4, positive cert, DSA, SHA1 0213: 00 09 05 02 3C 58 28 1A 02 1B 03 created 30 Jan 2002, key usage: sign data and certify other keys 021E: 00 0A 09 10 F0 0D .. 1F CA issuer key id 022A: 06 DF left 16 bits of signed hash value 022C: 00 9F 57 2D .. 26 E3 DSA value r 0242: 00 A0 B3 02 .. CE 65 DSA value s 0258: B9 02 0D === Public Subkey packet === 025B: <the same as in the request> 0468: 89 00 49 === Signature packet (subkey binding) === 046B: <the same as in the request> 04B4:
0000：99 01 A2 ===パブキーパケット=== 0003：<要求と同じ> 01A5：B4 19 ===ユーザーIDパケット=== 01A7：<要求と同じ> 01C0：89 4版04 13 11 02、00 49 ===署名パケット（自己署名）=== 01C3：020C <リクエストと同様> 89 00 49 ===署名パケット（認証）=== 020F正CERT、DSA、SHA1 0213：00 09 05 02（c）58 28 1A 02 1B 03は、2002年1月30日、鍵使用法を作成した：符号データ及び他のキーを021E証明：00 0A 09 10 F0 0Dを.. 1F CAの発行者鍵ID 022A： 00 9F 57 2D .. 26 E3 DSA値R 0242：06 DFは、署名されたハッシュ値022Cの16ビットを左に00 A0のB3 02 .. CE 65 DSA値S 0258：B9 02 0D ===公開サブキーパケット=== 025B ：0468 <リクエストと同様> 89 00 49 ===署名パケット（サブキー結合）=== 046B：04B4 <リクエストと同様>
A2. Certificate Request with Central Key Generation
A2。中央キーの生成と証明書要求
Alice requests that the CA generate an RSA key pair that will be used for signing, an RSA key pair that will be used for encryption, and requests that the CA certify these keys. The RSA keys are requested to be 2048 bits long with the public exponent 65537.
アリスは、CAが署名に使用されるRSA鍵のペア、暗号化に使用されるRSA鍵ペアを生成することを要求し、CAは、これらのキーを証明することを要求します。 RSA鍵は、公開指数65537との長い2048ビットであることを要求されています。
The content of the OpenPGP CertTemplate in the request is as follows:
次のようにリクエスト中のOpenPGP CertTemplateのの内容は次のとおりです。
0000: 99 01 0D === Pub Key packet (Template) === 0003: 04 FF FF FF FF 01 ver 4, any creation date, RSA 0009: 08 00 FF FF .. FF FF RSA public modulus n - given length 010B: 00 11 01 00 01 RSA public exponent e 0110: B4 19 === User ID packet === 0112: 41 6C .. 6D 3E "Alice <alice@example.com>" 012B: 89 00 23 === Signature packet (Template) === 012E: 04 10 11 02 ver 4, gen cert, DSA, SHA1 0132: 00 09 05 02 FF FF FF FF 02 1B 03 any creation date, key usage: sign data and certify other keys 013D: 00 0A 09 10 FF FF .. FF FF issuer key id - any 0149: 05 3A left 16 bits of signed hash value 014B: 00 08 FF DSA value r - any 014E: 00 08 FF DSA value s - any
0000：99 01 0Dは===キーパケット（テンプレート）=== 0003 PUB：04 FF FF FF FF 01版4、任意の作成日、RSA 0009：08 00 FF FFの.. FF FF RSA公開モジュラスN - 長与え010B：00 11 01 00 01 RSA公開指数e 0110：B4 19 ===ユーザIDパケット=== 0112：41 6C .. 6D 3E "アリス<alice@example.com>" 012B：89 00 23 ===署名パケット（テンプレート）=== 012E：04 10 11 02 4版、GENのCERT、DSA、SHA1 0132：00 09 05 02 FF FF FF FF 02（B）03、任意の作成日、鍵使用：符号データと証明他のキー013D ：00 0A 09 10 FF FF ... FF FF発行者鍵ID - 任意0149：00 08 FF DSA値r - 任意014E：05（a）は、署名されたハッシュ値014Bの16ビット左に00 08 FF DSA値s - いずれかを
0151: 99 01 0D === Public Subkey packet (Template) === 0154: 04 FF FF FF FF 01 ver 4, any creation date, RSA 015A: 08 00 FF FF .. FF FF RSA public modulus n - given length 025C: 00 11 01 00 01 RSA public exponent e 0261: 89 00 20 === Signature packet (Template) === 0264: 04 18 01 02 ver 4, subkey binding, RSA, SHA1 0268: 00 09 05 02 FF FF FF FF 02 1B 0C any creation date, key usage: encrypt communications and storage
0151：99 01 0D ===公開サブキーパケット（テンプレート）=== 0154：04 FF FF FF FF 01 4版、任意の作成日、RSA 015A：08 00 FF FFの.. FF FF RSA公開モジュラスN - 指定された長さ025C：00 11 01 00 01 RSA公開指数e 0261：89 00 20 ===署名パケット（テンプレート）=== 0264：04 18 01 02 4版、サブキー結合、RSA、SHA1 0268：00 09 05 02 FF FF FF FF 02 1B 0C任意の作成日、鍵使用：暗号化通信およびストレージ
0273: 00 0A 09 10 FF FF .. FF FF issuer key id - any 027F: 12 E6 left 16 bits of signed hash value 0281: 00 08 FF RSA signature value - any 0284:
0273：00 0A 09 10 FF FFの.. FF FF発行者鍵ID - 任意027F：00 08 FF RSA署名値 - 任意0284：12 E6は、署名されたハッシュ値0281の16ビットを残しました。
CA generates keys, certifies Alice's User ID and the public key, and creates the following OpenPGP certificate:
CAは、鍵を生成し、アリスのユーザーIDと公開鍵を証明し、次のOpenPGP証明書を作成します。
0000: 99 01 0D === Pub Key packet === 0003: 04 3C 5A A5 BB 01 ver 4, created 01 Feb 2002, RSA 0009: 08 00 C7 21 .. 5B EB RSA public modulus n 010B: 00 11 01 00 01 RSA public exponent e 0110: B4 19 === User ID packet === 0112: 41 6C .. 6D 3E "Alice <alice@example.com>" 012B: 89 01 1F === Signature packet (self-signature) === 012E: 04 10 01 02 ver 4, gen cert, RSA, SHA1 0132: 00 09 05 02 3C 5A A5 BB 02 1B 03 created 01 Feb 2002, key usage: sign data and certify other keys 014D: 00 0A 09 10 8E AF .. 1A 18 issuer key id 0149: 3B 21 left 16 bits of signed hash value 014B: 07 FE 2F 1D .. C0 81 RSA signature value 024D: 89 00 49 === Signature packet (certification) === 0250: 04 13 11 02 ver 4, positive cert, DSA, SHA1 0254: 00 09 05 02 3C 5A A5 DC 02 1B 03 created 01 Feb 2002, key usage: sign data and certify other keys 025F: 00 0A 09 10 F0 0D .. 1F CA issuer key id 026B: BA C2 left 16 bits of signed hash value 026D: 00 9F 5E 58 .. 30 B3 DSA value r 0283: 00 A0 D1 D7 .. 5A AF DSA value s 0299: 99 01 0D === Public Subkey packet === 029C: 04 3C 5A A5 C5 01 ver 4, created 01 Feb 2002, RSA 02A2: 08 00 C3 03 .. 8C 53 RSA public modulus n 03A4: 00 11 01 00 01 RSA public exponent e 03A9: 89 01 1F === Signature packet (subkey binding) === 03AC: 04 18 01 02 ver 4, subkey binding, RSA, SHA1
0000：99 01 0D ===パブキーパケット=== 0003：08 00 C7 21 .. 5B EB RSA公開モジュラスN 010B：00 11 01 04 3C 5A A5 BB 01 4のver、2002年2月1日、RSA 0009を作成し00 01 RSA公開指数e 0110：B4 19 ===ユーザIDパケット=== 0112：41 6C .. 6D 3E "アリス<alice@example.com>" 012B：89 01 1F ===署名パケット（自己署名）=== 012E：4版04 10 01 02、GENのCERTは、RSA、SHA1 0132：00 09 05 02 3C 5A A5 BB 02（B）03は、2002年2月1日に作成した鍵の使用：符号データ及び他のキーを014D証明：00 0A 09 10 8E AF .. 1A 18発行者鍵ID 0149：= 89 00 49 ===署名パケット（認証）：3B 21は、署名されたハッシュ値014Bの16ビット左：07 FE 2F 1Dを.. C0 81 RSA署名値024D == 0250：4版04 13 11 02、正CERT、DSAは、SHA1 0254：00 09 05 02 3C 5A A5 DC 02（B）03は、2002年2月01を作成した鍵の使用：符号データ及び他のキーを025F証明：00 0A 09 10 F0 0D .. 1F CAの発行者鍵ID 026B：.. 30 B3 DSA値R 0283 00 9F 5E 58：BA C2は、署名されたハッシュ値の16ビット026Dを左に00 A0 D1 D7を.. 5A AF DSA値S 0299 ：99 01 0D ===公開サブキーパケット=== 029C：04 3C 5A A5 C5 01 4版、2002年2月1日、RSA 02A2作成：08 00 C3 03 .. 8C 53 RSA公開モジュラスN 03A4：00 11 01 00 01 RSA公開指数e 03A9：89 01 1F ===署名パケット（サブキー結合）=== 03AC：04 18 01 02 4版、サブキー結合、RSA、SHA1
03B0: 00 09 05 02 3C 5A A5 C5 05 1B 0C created 01 Feb 2002, key usage: encrypt communications and storage 03BB: 00 0A 09 10 8E AF .. 1A 18 issuer key id 03C7: C8 44 left 16 bits of signed hash value 03C9: 07 FB 04 D7 .. 75 BE RSA signature value 04CB:
03B0：00 09 05 02 3C 5A A5 C5 05 1B 0Cは、2002年2月01を作成した鍵の使用：暗号化通信および記憶03BB：00 0A 09 10 8E AF .. 1A 18発行者鍵ID 03C7：C8 44は、署名されたハッシュの16ビットを残し値03C9：07 FB 04 D7 .. 75 BE RSA署名値04CB：
Normative References
引用規格
[ASN1] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
[ASN1] CCITT勧告X.208：抽象構文記法1（ASN.1）、1988の仕様。
[ATTCERT] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[ATTCERT]ファレル、S.とR. Housley氏、 "認可のためのインターネット属性証明書プロフィール"、RFC 3281、2002年4月。
[CMC] Myers, M., Liu, X., Schaad, J., and J. Weinstein, "Certificate Management Messages over CMS", RFC 2797, April 2000.
[CMC]マイヤーズ、M.、劉、X.、Schaad、J.、およびJ.ワインスタイン、 "CMSオーバー証明書の管理のメッセージ"、RFC 2797、2000年4月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[CMP] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure: Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[CMP]アダムス、C.、ファレル、S.、Kause、T.、およびT. Mononen、 "インターネットX.509公開鍵インフラストラクチャ：証明書管理プロトコル（CMP）"、RFC 4210、2005年9月。
[CRMF] Schaad, J., "Internet X.509 Public Key Infrastructure: Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[CRMF] Schaad、J.、 "インターネットX.509公開鍵インフラストラクチャ：証明書要求メッセージ・フォーマット（CRMF）"、RFC 4211、2005年9月。
[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
【のOpenPGP]カラス、J.、Donnerhacke、L.、フィニー、H.、およびR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 2440、1998年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Authors' Addresses
著者のアドレス
Mikhail Blinov Guardeonic Solutions Fitzwilliam Court, Leeson Close Dublin 2, Ireland
ミハイルBlinov Guardeonicソリューションフィッツウィリアム裁判所、リーソン閉じるダブリン2、アイルランド
EMail: mikblinov@online.ie
メールアドレス：mikblinov@online.ie
Carlisle Adams School of Information Technology and Engineering (SITE) University of Ottawa 800 King Edward Avenue P.O. Box 450, Stn A Ottawa, Ontario, Canada K1N 6N5
情報技術とエンジニアリングのカーライルアダムス・スクール（SITE）オタワ大学800キングエドワードアベニュー私書箱ボックス450、駅Aオタワ、オンタリオ州、カナダK1N 6N5
EMail: cadams@site.uottawa.ca
メールアドレス：cadams@site.uottawa.ca
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に及びwww.rfc-editor.org/copyright.htmlに含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。