[要約] RFC 4212は、X.509（PKIX）証明書管理プロトコルを使用する公開鍵インフラストラクチャの代替証明書形式に関する規格です。このRFCの目的は、PKIX証明書管理プロトコルにおける証明書の形式を拡張し、柔軟性と相互運用性を向上させることです。
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
X.509（PKIX）証明書管理プロトコルを使用したパブリックキーインフラストラクチャの代替証明書形式
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).
Copyright（c）The Internet Society（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.
このドキュメントは、インターネット標準のレベルの候補ではありません。IETFは、あらゆる目的のためにこのドキュメントのフィットネスに関する知識を放棄します。特に、セキュリティ、混雑制御、展開プロトコルとの不適切な相互作用などのIETFレビューはなかったことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。
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）構文を使用して、そのような証明書を要求する方法を指定します。また、PKIX証明書管理プロトコル（PKIX-CMP）やCMS（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）の完全な証明書ライフサイクル管理には、自動処理とエンドユーザーの透明性を実現するためにプロトコルサポートが必要です。このようなプロトコルには、複数のベンダーが単一の組織のPKI展開において、エンドエンティティ（EE）、認証局（CA）、登録機関（RA）をさまざまな分割して提供できるようにするため、または複数の展開を許可するために、標準化が必要です。、独立して展開された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形式の機能の1つは、CertTemplateコンストラクトの使用です。これにより、要求者（EE、またはRAがEEに代わって作用する）が、要求された証明書のコンテンツに関して希望するほど多くの場合、またはほんの少しと指定できます。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]).
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.
このセクションでは、セクション1で定義されている代替証明書の各タイプにAltCertTemplateを指定します。
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は、Object Identifier（oid）を定義し、ID-regctrl-altcerttemplateコントロールで使用する対応する値を定義するだけで使用できます。これらは次のように指定されています。
OID:
OID：
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証明書の証明書は、Object Identifier（OID）を定義し、ID-regctrl-AltcertTemplateコントロールで使用する対応する値を定義して使用できます。これらは次のように指定されています。
OID:
OID：
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.
- 各サブキーパケットの後、ゼロまたは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 CERTTEMPLATEを構築および解析するために、既存の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仕様が許容値のセット（たとえば、署名タイプまたは署名パケットの公開キーアルゴリズムフィールド）を定義するフィールドには、定義されたセットから値が必要です。要求者が、たとえば署名アルゴリズムなどの特別な設定を持っていなくても、最も望ましい1つの値を選択する必要があります。
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を保持しているフィールドの場合：0xffffffffffffffffffの値は「任意のキー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つの値は、すべてのビットが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から公開キーパケットが省略されている場合、この証明書は公開キーの値を制限しません（つまり、「任意の」公開キーを指します）。
- The order of Signature packets following a User ID packet and the order of User ID packets within the CertTemplate are not important.
- CertTemplate内のユーザーIDパケットとユーザー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).
- ユーザーIDパケットに続く署名のリストに存在する署名テンプレートは、CAがこのユーザー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を知っていると想定されています。前のユーザーIDのない署名テンプレートは、CAがユーザーのすべての既知のユーザーIDをOpenPGP証明書に挿入し、それぞれを証明することを要求します。署名テンプレートは、これらの認証署名のパラメーターを定義します。
- 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を証明するように要求されます。このような証明書は、認証署名のパラメーターを明示的に定義するものではありませんが、CAはガイド（例：キーフラグフィールド）として認証自己署名（CertTemplateに存在する場合）のパラメーターを使用する必要があります。
- 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がこれらのユーザーIDをOpenPGP証明書に挿入し、それぞれを証明することを要求します。認証署名のパラメーターは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証明書の要求全体を拒否する必要があります。
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の長さと同じ長さであることを指定します（たとえば、RSAのパブリックモジュラスNの長さ鍵）。
- 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.
完全なOpenPGP証明書を返すために、新しいキーとユーザーIDの証明に加えて、CA（またはRA）も自己署名を作成する必要があります（つまり、新しい公開キーとユーザー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がユーザーの主要な秘密鍵を知らない場合、CA/RAからクライアントに返される結果のOpenPGP証明書は不完全になることに注意してください（つまり、サブキーの拘束力のある署名はありません）。拘束力のある署名を作成して追加し、最終的な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/Subkeyパケットもキーテンプレートパケットも含まれていない場合、CAのポリシーに従ってCAがキー/サブキーを生成することを要求します。
The OpenPGPCertTemplateExtended structure enables additional extensions and controls to be added to the basic OpenPGP CertTemplate.
OpenPGPCERTTEMPLATEEXTEDED構造により、追加の拡張機能とコントロールを基本的な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、つまり次の構造を持つopenPGP certtemplatesをサポートするには、適合実装が必要です（付録の例を参照）。
- One Public Key packet (not a Key Template).
- 1つの公開キーパケット（キーテンプレートではありません）。
- 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コントロール）にサブジェクトと * publickey値が含まれている場合、poposkinputは省略する必要があり、署名はcertreqmsg certreq（またはder-encoded値（またはder-encoded値）の値で計算する必要があります。* 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.
OpenPGP CertTemplateは、公開キーパケット（キーテンプレートではない）と少なくとも1つのユーザーIDパケットがある場合、このメモの条件を満たすと見なされます。
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
-- management protocol, should a need ever arise to support
-- such generality.
Building on this framework, this document expands the above CHOICE construct as follows.
このフレームワークに基づいて、このドキュメントは上記の選択コンストラクトを次のように拡張します。
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.
上記のように選択コンストラクトを拡張すると、X.509属性証明書と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構造の主題およびpublicKeyフィールドの特定の制約を定義します。代替証明書タイプが使用される場合、同じ制約が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コントロール）にサブジェクトフィールドとPublicKeyフィールドの両方を含める必要があります。
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証明書が要求された場合、リクエストの送信者フィールドはASN.1 GeneralName（CMPとCMCの両方）としてエンコードされ、被験者はPGP useridとして表されます。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).
これらの状況では、PGP証明書のユーザーIDを構築するときは、CAにとってより安全です。これは、リクエストからユーザー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ストアへの書き込みアクセスが必要です。
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:
CA certifies Alice's User ID and the public key and creates the following OpenPGP certificate:
CAはAliceのユーザー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:
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
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
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:
CA generates keys, certifies Alice's User ID and the public key, and creates the following OpenPGP certificate:
CAはキーを生成し、Aliceのユーザー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
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:
Normative References
引用文献
[ASN1] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
[ASN1] CCITT推奨X.208：抽象的構文表記の仕様（ASN.1）、1988。
[ATTCERT] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[Attcert] Farrell、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] Myers、M.、Liu、X.、Schaad、J。、およびJ. Weinstein、「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] Adams、C.、Farrell、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] Callas、J.、Donnerhacke、L.、Finney、H。、およびR. Thayer、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Authors' Addresses
著者のアドレス
Mikhail Blinov Guardeonic Solutions Fitzwilliam Court, Leeson Close Dublin 2, Ireland
ミハイル・ブリノフ・ガーデニック・ソリューションフィッツウィリアム・コート、リーソン・クローズ・ダブリン2、アイルランド
EMail: 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キング・エドワード・アベニューP.O.Box 450、STN A OTTAWA、オンタリオ州、カナダK1N 6N5
EMail: cadams@site.uottawa.ca
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。