RFC4212 日本語訳
4212 Alternative Certificate Formats for the Public-Key InfrastructureUsing X.509 (PKIX) Certificate Management Protocols. M. Blinov, C.Adams. October 2005. (Format: TXT=41757 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Blinov
Request for Comments: 4212 Guardeonic Solutions
Category: Informational C. Adams
University of Ottawa
October 2005
Blinovがコメントのために要求するワーキンググループM.をネットワークでつないでください: 4212年のGuardeonicソリューションカテゴリ: オタワ2005年10月の情報のC.アダムス大学
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)インターネット協会(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).
X.509(PKIX)インターネット・エンジニアリング・タスク・フォース作業部会(IETF)を使用する公開鍵暗号基盤は多くの証明書管理プロトコルを定義しました。 これらのプロトコルは主としてX.509v3公開鍵証明書に焦点を合わせられます。 しかしながら、また、代替の形式で証明書を管理するのは時々望ましいです。 このドキュメントはそのような証明書がいくつかの異なったプロトコルによって使用されるCertificate Request Message Format(CRMF)構文を使用することでどう要求されているかもしれないかを指定します。 また、それで、CMS(CMC)の上でPKIX Certificate Managementプロトコル(PKIX-CMP)とCertificate Management Messagesのようなポピュラーなプロトコルに代替の証明書形式がどう法人組織であるかもしれないかがわかります。
Blinov & Adams Informational [Page 1] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[1ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
1. Introduction
1. 序論
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)における完全な証明書ライフサイクル管理は、自動化された処理とエンドユーザ透明を達成するためにプロトコルサポートを必要とします。 そのようなプロトコルは、1つ以上のベンダーが、単純組織のPKI展開における様々な断片(終わりのEntity(EE)、認証局(カリフォルニア)Registration Authority(RA))を供給するか、または複数の、そして、独自に配布しているPKIsが有効にインタコネクトされるのを許容するのを許容するために標準化を必要とします。
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(証明書Request Message Format)[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 Certificate Managementプロトコル)[CMP]とCMC(CMSの上の証明書Management Messages)[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プロトコルに拡大を提案します。
Blinov & Adams Informational [Page 2] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[2ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Certificate Template
2. 証明書テンプレート
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、またはEEを代表して行動するRA)は要求された証明書の中身に関して願っているのと同じくらい多くか同じくらい小さいとしてそれで、指定します)。 カリフォルニアが実際の証明書内容の上に最終的な権威を持っていることに明らかに注意されます。 運営方針に従って、すなわち、カリフォルニアは、拡大を証明書分野を変更するか、加えるか、削除するか、または変更するかもしれません(結果として起こる証明書が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]で紹介されました(どこイド-regCtrlは1 3 6 1 5 5 7 5 1と等しいか、[CRMF]で定義されるように)。
CertRequest ::= SEQUENCE {
certReqId INTEGER,
certTemplate CertTemplate,
controls Controls OPTIONAL }
CertRequest:、:= 系列certReqId INTEGER(certTemplate CertTemplate)は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
-- certTemplateが空のSEQUENCE(すなわちすべての分野--省略される)であるなら、コントロールは--X.509v3公開鍵以外の証明書にテンプレートを指定するイド-regCtrl-altCertTemplateコントロール--証明書を含むかもしれません。 逆に、certTemplateがそうでないなら空になってください。--(すなわち、少なくとも1つの分野が存在しています、)、次に、コントロール--イド-regCtrl-altCertTemplateを含んではいけません。 新しさ--コントロールは以下の通り定義されます: イド-regCtrl-altCertTemplateオブジェクト識別子:、:= イド-regCtrl7、AltCertTemplate:、:= AttributeTypeAndValue
In this section, an AltCertTemplate is specified for each of the alternative certificate types defined in Section 1.
このセクションでは、AltCertTemplateはセクション1で定義された証明書代替のタイプ各人に指定されます。
2.1. X.509 Attribute Certificate CertTemplate
2.1. X.509属性証明書CertTemplate
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.
イド-regCtrl-altCertTemplateコントロールにおける使用のために単にオブジェクト識別子(OID)と換算値を定義することによって、X.509属性証明書のためのCertTemplateを使用できます。 これらは以下の通り指定されます。
Blinov & Adams Informational [Page 3] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[3ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
OID:
OID:
id-acTemplate OBJECT IDENTIFIER ::=
{id-regCtrl-altCertTemplate 1}
イド-acTemplateオブジェクト識別子:、:= イド-regCtrl-altCertTemplate1
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
AttCertTemplate:、:= SEQUENCE、バージョンAttCertVersion OPTIONAL、所有者Holder OPTIONAL、発行人AttCertIssuer OPTIONAL、署名AlgorithmIdentifier OPTIONAL、serialNumber CertificateSerialNumber OPTIONAL、attrCertValidityPeriod OptionalAttCertValidity OPTIONAL、属性SEQUENCE OF Attribute OPTIONAL、issuerUniqueID UniqueIdentifier OPTIONAL、拡大Extensions OPTIONAL、OptionalAttCertValidity:、:= SEQUENCE、notBeforeTime GeneralizedTime OPTIONAL、notAfterTime GeneralizedTime OPTIONAL、--少なくとも存在していなければならない
2.2. OpenPGP Certificate CertTemplate
2.2. OpenPGP証明書CertTemplate
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:
上で定義されたテンプレートを証明するために同様です、イド-regCtrl-altCertTemplateコントロールにおける使用のためにオブジェクト識別子(OID)と換算値を定義することによって、OpenPGP証明書のためのCertTemplateを使用できます。 これらは以下の通り指定されます:
OID:
OID:
id-openPGPCertTemplateExt OBJECT IDENTIFIER ::=
{id-regCtrl-altCertTemplate 2}
イド-openPGPCertTemplateExtオブジェクト識別子:、:= イド-regCtrl-altCertTemplate2
Value:
値:
OpenPGPCertTemplateExtended ::= SEQUENCE {
nativeTemplate OpenPGPCertTemplate,
controls Controls OPTIONAL }
OpenPGPCertTemplateExtended:、:= 系列nativeTemplate OpenPGPCertTemplate、コントロール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
OpenPGPCertTemplate:、:= OCTET STRING--、(Radix-64変換のないバイナリフォーマット)の下でASN.1OCTET STRINGとしてコード化されていた状態で定義されたOpenPGP CertTemplateデータ構造を含んでいます。
Blinov & Adams Informational [Page 4] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[4ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
2.2.1. OpenPGP CertTemplate Data Structure
2.2.1. OpenPGP CertTemplateデータ構造
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 Transferable Public Key)[OPENPGP]です。 OpenPGP CertTemplateの必須元素は以下の通りです。
- Zero or one Public Key packet.
- ゼロか1つのPublic Keyパケット。
- Zero or more Direct Key Self Signature packets.
- ゼロか、より多くのDirect Key Self Signatureパケット。
- Zero or more Certification Signature packets (only if no User ID
packets are present).
- ゼロか、より多くのCertification Signatureパケット(どんなUser IDパケットも存在していない場合にだけ)。
- Zero or more User ID packets.
- ゼロか、より多くのUser IDパケット。
- After each User ID packet, zero or more Certification Signature
packets.
- それぞれのUser IDパケット、ゼロまたは、より多くのCertification Signatureパケットの後に。
- Zero or more Subkey packets.
- ゼロか、より多くのSubkeyパケット。
- After each Subkey packet, zero or one Subkey Binding Signature
packet.
- それぞれのSubkeyパケット、ゼロまたは1つのSubkey Binding Signatureパケットの後に。
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パケットであるに違いありません。 これは、conformant実装が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仕様が1セットの受入れられた値(例えば、署名タイプかSignatureパケットの公開鍵アルゴリズム分野)を定義する分野は定義されたセットからの値を持たなければなりません。 リクエスタに例えば、署名アルゴリズムのための特定の好みが少しのなくても、それは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.
原理: 代替のソリューションは「any」の値を余分に定義することであることができましたが、これは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仕様で義務的であると定義されたSignatureパケット(例えば、作成時間と発行人の主要なイド「副-パケット」)のすべての「副-パケット」が存在していなければなりません。
Blinov & Adams Informational [Page 5] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[5ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
- 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.
- Key MaterialとSignatureパケットの端のMPIsの数は与えられたアルゴリズムのためのOpenPGP仕様で定義された数に合わなければなりません(アルゴリズムは「アルゴリズム」分野の値によって制御されます)。 例えば、DSA署名のための2MPIsがあるはずです。 OpenPGP仕様がそれらのMPIsの内容のために合法化規則を定義しないことに注意してください。
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.
それは「any」の値を列挙型の分野と余分に定義するのがここで適切であると考えられませんが、まだ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の値は「どんな主要なイドも」を意味します。
- For signature fields: the "any signature" value is encoded as a
sequence of MPIs such that:
- 署名分野に: MPIsの値がコード化される「どんな署名も」a系列、以下のことのようなもの
* the number of MPIs matches the number of MPIs defined by the
OpenPGP specification for the given algorithm, and
* そしてMPIsの数が与えられたアルゴリズムのためのOpenPGP仕様で定義されたMPIsの数を合わせる。
* 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.
「いくらか」という値が署名分野にあるSignatureパケットはSignature Templateと呼ばれます。
Example: The "any signature" value for a DSA signature would look
like [00 08 FF 00 08 FF]
例: DSA署名のための値がそうする「どんな署名も」外観は好きです。[00 08、ff00 08ff]
- For key material fields: the "any key" value is encoded as a
sequence of MPIs such that:
- キー材料分野に: MPIsの値がコード化される「どんなキーも」a系列、以下のことのようなもの
* the number of MPIs matches the number of MPIs defined by the
OpenPGP specification for the given algorithm, and
* そしてMPIsの数が与えられたアルゴリズムのためのOpenPGP仕様で定義されたMPIsの数を合わせる。
* the value of at least one of the MPIs is a bit string with all
its bits set to 1.
* 少なくともMPIsの1つの値はすべてで1に設定されたビットを少し結ぶことです。
Blinov & Adams Informational [Page 6] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[6ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
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.)
「いくらか」という値がキー材料分野にあるKey MaterialパケットはKey Templateと呼ばれます。 (さらに詳しい明細についてはKey Template部を見てください。)
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、ff00 10ff ff00 10 85 34 00 08ff]
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).
- Public KeyパケットがOpenPGP CertTemplateから省略されるなら、このCertTemplateは公開鍵の値を抑制しません(すなわち、それは「any」の公開鍵について言及します)。
- The order of Signature packets following a User ID packet and the
order of User ID packets within the CertTemplate are not important.
- User IDパケットに続くSignatureパケットの注文とCertTemplateの中のUser 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がどんなUser IDパケットも含んでいないなら、それは「any」の与えられた要求に関連しているユーザIDを示します。
2.2.2. OpenPGP CertTemplate in Certificate Requests
2.2.2. 証明書要求におけるOpenPGP CertTemplate
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は証明署名がどこに起こるべきであるかを定義するのにSignature Templatesを使用します。 Signature Templatesの分野の値は新しい証明署名のパラメタを定義します。 以下の規則は適用されます:
- 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).
- User IDパケットに続いて、折記号表に存在しているSignature Templateは、カリフォルニアがこのUserがIDと公開鍵であることを公認して、Signature Templateを新しい証明署名に取り替えるよう要求します。 Signature Templateはリストの中で証明署名の正確な場所を強制しません。 証明署名は折記号表の中のどんな見解でも挿入されるかもしれません(公認されたUser 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.
- Signature TemplateはOpenPGP CertTemplateに少しも前のUser IDパケットなしで存在しているかもしれません。 この場合、カリフォルニアがユーザについてある他の手段でIDを知っていると思われます。 前のUser IDのないSignature Templateは、カリフォルニア差し込みがユーザのUser IDをOpenPGP証明書にすべて知って、それぞれのそれらを公認するよう要求します。 Signature Templateはこれらの証明署名のパラメタを定義します。
Blinov & Adams Informational [Page 7] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[7ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
- 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がSignature Templatesを全く含んでいないなら、カリフォルニアがOpenPGP CertTemplateですべての存在しているUser IDを公認するよう要求されます。 そのようなCertTemplateは明らかに証明署名のパラメタを定義しませんが、CA SHOULDはガイドとして証明自己署名(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.
- Signature TemplatesもUser IDもOpenPGP CertTemplateに存在していないなら、カリフォルニアがユーザについてある他の手段でIDを知ると予想されます。 この場合、CertTemplateは、カリフォルニアがこれらのUser IDをOpenPGP証明書に挿入して、それぞれのそれらを公認するよう要求します。 証明署名のパラメタはカリフォルニアに発たれます。
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.
クライアントSHOULDはカリフォルニアが完全なOpenPGP証明書を製作できたという要求における十分な情報を提供します。 例えば、クライアントSHOULDは、カリフォルニアがまた、結果のOpenPGP証明書にそれらを含むことができるように、テンプレートに彼らの拘束力がある署名があるすべての関連サブキーを含んでいます。 原理: いくつかの環境で、カリフォルニア/RAは出版証明書に責任があります。
2.2.3. Key Templates and Central Key Generation
2.2.3. 主要なテンプレートと主要なキー生成
The OpenPGP CertTemplate can also be used to request certification of centrally-generated keys. This is accomplished by using Key Templates.
また、中心で発生しているキーの証明を要求するのにOpenPGP CertTemplateを使用できます。 これは、Key Templatesを使用することによって、達成されます。
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のPublic KeyパケットがKey Templateであるなら、このOpenPGP CertTemplateは、それを公認する前にカリフォルニア/RAが主要な組を生成するよう要求します。 Key Templateの分野は以下の新しい主要な組のパラメタを定義します(Appendixの例を見てください):
- 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 08FF])の値がある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).
- ビット列をいかなる他のも含むMPI分野がすべてのビットがどれであるかに1に設定されて、キーの対応する部分がMPI(例えば、RSAキーの公共の係数nの長さ)の長さと同じ長さのものであるはずであると指定してください。
Blinov & Adams Informational [Page 8] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[8ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
- 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.
新しいキーとUser IDを公認することに加えて完全なOpenPGP証明書を返すために、カリフォルニア(または、RA)SHOULDはまた、自己署名(すなわち、新しい秘密鍵で新しい公開鍵とUser IDに署名する)を作成して、User IDパケットの後にそれを含んでいます。 このSHOULD、カリフォルニアによって公認されたすべてのUser 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のSubkeyパケットがKey Templateであるなら、このOpenPGP CertTemplateは、カリフォルニア/RAがサブキーを生成するよう要求します。 Key Templateの分野は新しいサブキーのパラメタを定義します。 新しいサブキーは明らかに公認される必要はありません。 しかしながら、カリフォルニア/RA SHOULDは拘束力がある署名を起こして、サブキーの後にそれを含んでいます、カリフォルニア/RAがユーザのプライマリ秘密鍵を知っているなら(また、例えばそれは中心で生成されました)。 カリフォルニア/RAがユーザのプライマリ秘密鍵を知らないならカリフォルニア/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/サブキーパケットもKey Templateパケットも含んでいないなら、それは、CAの方針によると、カリフォルニアがキー/サブキーを生成するよう要求します。
2.2.4. OpenPGPCertTemplateExtended
2.2.4. OpenPGPCertTemplateExtended
The OpenPGPCertTemplateExtended structure enables additional extensions and controls to be added to the basic OpenPGP CertTemplate.
OpenPGPCertTemplateExtended構造は、追加拡大とコントロールが基本的なOpenPGP CertTemplateに加えられるのを可能にします。
2.2.5. OpenPGP CertTemplate Required Profile
2.2.5. 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):
conformant実装はすなわち有効なOpenPGP証明書であるOpenPGP CertTemplatesをサポートする以下の構造を持っているREQUIRED(Appendixの例を見る)です:
- One Public Key packet (not a Key Template).
- 1つのPublic Keyパケット(Key Templateでない)。
- Zero or more Direct Key Self Signature packets (without Signature
Templates).
- ゼロか、より多くのDirect Key Self Signatureパケット(Signature Templatesのない)。
- One or more User ID packets.
- 1つ以上のUser IDパケット。
- After each User ID packet, zero or more Certification Signature
packets (without Signature Templates).
- それぞれのUser IDパケット、ゼロまたは、より多くのCertification Signatureパケット(Signature Templatesのない)の後に。
Blinov & Adams Informational [Page 9] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[9ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
- Zero or more Subkey packets (without Key Templates).
- ゼロか、より多くのSubkeyパケット(Key Templatesのない)。
- After each Subkey packet, one Subkey Binding Signature packet (not
a Signature Template).
- それぞれのSubkeyパケット、1つのSubkey Binding Signatureパケット(Signature Templateでない)の後に。
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.
conformant実装は、Key TemplatesとSignature Templatesを認識するREQUIREDであり、彼らをサポートするか、または要求を拒絶する含んでいないならそれらを含むREQUIREDです。
3. Proof-of-Possession
3. 所有物の証拠
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要求はEnd Entityが秘密鍵の所有物を証明書が要求されている公開鍵に対応するようにするという証拠を含む所有物のProof(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(または、AltCertTemplateのDERによってコード化された値*)のDERによってコード化された*値で*と署名を計算しなければならないということでなければなりません。
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.
Public Keyパケット(Key Templateでない)と少なくとも1つのUser IDパケットを持っているなら、OpenPGP CertTemplateがこの注意の状態を満たすと考えられます。
4. Protocol-specific Issues
4. プロトコル特有の問題
This section explains how alternative certificate formats may be incorporated into such popular protocols as PKIX-CMP and CMC.
このセクションは代替の証明書形式がどう法人組織であるかもしれないかをPKIX-CMPとCMCのようなポピュラーなプロトコルに説明します。
4.1. PKIX-CMP
4.1. PKIX-Cmp
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
}
CMPCertificate:、:= 選択x509v3PKCert証明書
-- 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
-- または、ワイヤのビット互換性があるこの構文、--「証明書」の標準のX.509定義、許容、--、将来の証明書の可能性がタイプする(X.509--証明書、WAP WTLS証明書を結果と考えるのなどように--、他の種類の証明書)、この証明書
Blinov & Adams Informational [Page 10] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[10ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
-- 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
}
CMPCertificate:、:= 選択x509v3PKCert Certificate、x509v2AttCert[0]AttributeCertificate--[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
OpenPGPCert:、:= OCTET STRING--、ASN.1OCTET STRINGとしてコード化されたOpenPGP仕様[OPENPGP](Radix-64変換のないバイナリフォーマット)からのOpenPGP証明書(OpenPGP Transferable--公共のKey)データ構造を含んでいます。
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管理メッセージの中で使用されるのを許容します。 将来、この構造物は他の証明書タイプに対応するためにさらに(このドキュメントのその後の改正で)広げられるかもしれません、これが必要であることがわかっているなら。
4.2. CMC
4.2. CMC
The CMC protocol uses the CMS (Cryptographic Message Syntax) syntax [CMS], which defines the certificate type as
プロトコルが証明書タイプを定義するCMS(暗号のMessage Syntax)構文[CMS]を使用するCMC
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2 }
CertificateChoices:、:= 選択証明書Certificate(extendedCertificate[0]IMPLICIT ExtendedCertificate(時代遅れのv1AttrCert[1]IMPLICIT AttributeCertificateV1))はv2AttrCert[2]IMPLICIT AttributeCertificateV2を時代遅れにします。
Similar to PKIX-CMP, this CHOICE can be extended to include additional types of certificates as follows.
PKIX-CMPと同様であることで、以下の追加タイプの証明書を含むようにこのCHOICEを広げることができます。
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2,
openPGPCert [3] IMPLICIT OpenPGPCert }
CertificateChoices:、:= 選択証明書Certificate(extendedCertificate[0]IMPLICIT ExtendedCertificate(時代遅れのv1AttrCert[1]IMPLICIT AttributeCertificateV1))はv2AttrCert[2]IMPLICIT AttributeCertificateV2を時代遅れにします、openPGPCert[3]IMPLICIT OpenPGPCert
Blinov & Adams Informational [Page 11] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[11ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
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メッセージボディーがFull Enrollment Requestメッセージで使用されるとき、それぞれのCRMFメッセージはCertTemplateの対象とpublicKey分野の両方を含まなければなりません。
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メッセージボディーがFull Enrollment Requestメッセージで使用されるとき、それぞれのCRMFメッセージはCertTemplate(またはaltCertTemplateコントロールで)の対象とpublicKey分野の両方を含まなければなりません。
5. Security Considerations
5. セキュリティ問題
5.1. Protection of Alternative Certificate Templates
5.1. 代替の証明書テンプレートの保護
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)でそれを達成できます。
Blinov & Adams Informational [Page 12] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[12ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
5.2. Request Authorisation
5.2. 認可を要求してください。
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.
要求を受け入れるべきであるかどうかに関して決定するために、通常、カリフォルニアは要求の送付者の(認証されます)名を要求対象名にたとえることができるはずです。
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).
例えば、End Entityは自分で/自体のための追加証明書を要求できるかもしれません。 この場合、SenderがSubjectと等しいなら(もちろん、証明書を与える前にまた、他の状態をチェックしなければならないでしょう)、カリフォルニアは申し込みに応じるでしょう。
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証明書がここで提案された拡張子を使用することで要求されると、要求のSender分野はASN.1GeneralName(CMPとCMCの両方の)としてコード化されるでしょう、SubjectがPGP UserIDとして表されるでしょうが。 PGP UserIDが事実上無制限な八重奏ストリングであるので、これらの2つのタイプを比較するのはいつも些細であるというわけではありません。 攻撃者が特に、作られたUserIDsとの要求を提出しようとするのは(例えば、それは不鮮明なキャラクタを含んでいます)、他の誰かのものUserIDと共にカリフォルニア比較アルゴリズムをだまして、PGP証明書を入手するために可能です。
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).
むしろという認証されたSender名の内容に基づくUserIDを完全に再建するためにPGP証明書のUserIDを造るとき、こういう事情ですから、カリフォルニアには、それが要求からのUserIDを取るより安全です。 これを達成するために、End Entityに関する追加情報がカリフォルニア(例えば、EEのEメールアドレス)で必要であるかもしれません。
5.3. PGP Parser
5.3. PGPパーサ
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サーバが. これらのプロトコルサーバで主なカリフォルニアにキーをアクセスさせるべきでなくて、カリフォルニア店へのアクセスを書くべきでないメインカリフォルニアサーバからの別々のマシンにおける走行であることはお勧めです。
Blinov & Adams Informational [Page 13] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[13ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
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.
このAppendixはカリフォルニアから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 Required Profileに従います。
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 01A2=== パブKeyパケット=== 0003: 04 3 C58 27A2 11ver4、作成された2002年1月30日、DSA0009: 00E3FB9D。 2B EF DSAはp008Bを用意します: 00 A0ff7E。 BA71DSAグループはq00A1を注文します: 03 ff紀元前68年。 56 71DSAグループジェネレータg0123: 03 FE38 1F。 F2 63DSA公開鍵価値yの01A5: B4 19=== ユーザIDパケット=== 01A7: 41 6C。 6D3E、「 Alice <alice@example.com 、gt;、」 01C0: 89 00 49 === 署名パケット(自己署名)=== 01C3: 04 10 11 02ver4、本命、DSA、SHA1 01C7に情報を得てください: 00 09 05 02 3C58 27A2 02 1B03は2002年1月30日、主要な用法を作成しました: データに署名してください、そして、他のキーが01D2であることを公認してください: 00 0A09 10 43 5C。 06 77の発行人の主要なイド01DE: 5A C2は署名しているハッシュ値01E0の16ビットを残しました: 00 A0 EB00。 1B75DSAはr01F6を評価します: 00 A0 F4E4。 A8の3D DSAはsを020C評価します: B9 02 0D=== 公共のSubkeyパケット=== 020F: 04 3C58 27A2 10ver4、作成された2002年1月30日、Elgamal、(暗号化、-単に、)、アルゴリズム0215: 08 00F6 42。 0B 3B Elgamalはp0317を用意します: 00 02 02Elgamalグループジェネレータg031A: 07 FE37Ba。 DF21Elgamal公開鍵価値yの041C: 89 00 49 === 署名パケット(サブキー結合)=== 041F: 04 18 11 02ver4、サブキー結合、DSA、SHA1 0423: 00 09 05 02 3C58 27A2 02 1B0Cは2002年1月30日、主要な用法を作成しました: コミュニケーションとストレージを042E暗号化してください: 00 0A09 10 43 5C。 06 77の発行人の主要なイド043A: C7 DEは署名しているハッシュ値の16ビットを043Cに残しました: 00 9E21 33。 39 1B DSAはr0452を評価します: 00 9Fの64D7。 63 08DSAはs0468を評価します:
Blinov & Adams Informational [Page 14] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[14ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
CA certifies Alice's User ID and the public key and creates the following OpenPGP certificate:
カリフォルニアは、アリスのUserが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 01A2=== パブKeyパケット=== 0003: 要求>01A5と同じ<: B4 19=== ユーザIDパケット=== 01A7: 要求>01C0と同じ<: 89 00 49 === 署名パケット(自己署名)=== 01C3: 要求>020Cと同じ<: 89 00 49 === 署名パケット(証明)=== 020F: 04 13 11 02ver4、積極的な本命、DSA、SHA1 0213: 00 09 05 02 3C58 28 1A02 1B03は2002年1月30日、主要な用法を作成しました: データに署名してください、そして、他のキーを021E公認してください: 00 0A09 10F0 0D。 1Fのカリフォルニアの発行人の主要なイド022A: 06 DFは署名しているハッシュ値の16ビットを022Cに残しました: 00 9Fの57 2D。 26の3EのDSAはr0242を評価します: 00 A0 B3 02。 CE65DSAはs0258を評価します: B9 02 0D=== 公共のSubkeyパケット=== 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.
アリスは、カリフォルニアが署名に使用される、RSA主要な組、暗号化に使用される、RSA主要な組、およびカリフォルニアがこれらのキーを公認するという要求を生成するよう要求します。 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=== パブKeyパケット(テンプレート)=== 0003: 04 FF FF FF FF01ver4、どんな作成日付、RSA0009も: 08 00ff ff。 FF FF RSAの公共の係数n--与えられた長さの010B: 00 11 01 00 01のRSAの公共の解説者e0110: B4 19=== ユーザIDパケット=== 0112: 41 6C。 6D3E、「 Alice <alice@example.com 、gt;、」 012B: 89 00 23 === 署名パケット(テンプレート)=== 012E: 04 10 11 02ver4、本命、DSA、SHA1 0132に情報を得てください: どんな作成日付の00 09 05 02FF FF FF FF02 1B03、主要な用法も: データに署名してください、そして、他のキーが013Dであることを公認してください: 00 0A09 10ff ff。 FF FFの発行人の主要なイド--どんな0149も: 05 3Aは署名しているハッシュ値の16ビットを014Bに残しました: 00 08FF DSAはr--どんな014Eも評価します: 00 08FF DSA価値s--いくらか
Blinov & Adams Informational [Page 15] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[15ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
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=== 公共のSubkeyパケット(テンプレート)=== 0154: 04 FF FF FF FF01ver4、どんな作成日付、RSA 015A: 08 00ff ff。 FF FF RSAの公共の係数n--与えられた025Cの長さ: 00 11 01 00 01のRSAの公共の解説者e0261: 89 00 20 === 署名パケット(テンプレート)=== 0264: 04 18 01 02ver4、サブキー結合、RSA、SHA1 0268: どんな作成日付の00 09 05 02FF FF FF FF02 1B0C、主要な用法も: コミュニケーションとストレージを暗号化してください。
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 0A09 10ff ff。 FF FFの発行人の主要なイド--どんな027Fも: 12E、6は署名しているハッシュ値0281の16ビットを残しました: 00 08FF RSA署名価値--どんな0284も:
CA generates keys, certifies Alice's User ID and the public key, and creates the following OpenPGP certificate:
カリフォルニアは、キーを生成して、アリスのUserが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=== パブKeyパケット=== 0003: 04 3 C5A A5掲示板01ver4、作成された2002年2月1日、RSA0009: 08 00C7 21。 5B EB RSAの公共の係数n010B: 00 11 01 00 01のRSAの公共の解説者e0110: B4 19=== ユーザIDパケット=== 0112: 41 6C。 6D3E、「 Alice <alice@example.com 、gt;、」 012B: 89 01、1F=== 署名パケット(自己署名)=== 012E: 04 10 01 02ver4、本命、RSA、SHA1 0132に情報を得てください: 00 09 05 02 3C5A A5掲示板02 1B03は2002年2月1日、主要な用法を作成しました: データに署名してください、そして、他のキーが014Dであることを公認してください: 00 0A09 10 8EのAF。 1A18の発行人の主要なイド0149: 3B21は署名しているハッシュ値の16ビットを014Bに残しました: 07 FE2F1D。 C0 81RSA署名値の024D: 89 00 49 === 署名パケット(証明)=== 0250: 04 13 11 02ver4、積極的な本命、DSA、SHA1 0254: 00 09 05 02 3C5A A5DC02 1B03は2002年2月1日、主要な用法を作成しました: データに署名してください、そして、他のキーが025Fであることを公認してください: 00 0A09 10F0 0D。 1Fのカリフォルニアの発行人の主要なイド026B: BA C2は署名しているハッシュ値の16ビットを026Dに残しました: 00 9F5E58。 30 B3 DSAはr0283を評価します: 00 A0 D1 D7。 5A AF DSAはs0299を評価します: 99 01 0D=== 公共のSubkeyパケット=== 029C: 04 3 C5A A5 C5 01ver4、作成された2002年2月1日、RSA 02A2: 08 00C3 03。 8 C53のRSAの公共の係数n03A4: 00 11 01 00 01のRSAの公共の解説者e03A9: 89 01、1F=== 署名パケット(サブキー結合)=== 03AC: 04 18 01 02ver4、サブキー結合、RSA、SHA1
Blinov & Adams Informational [Page 16] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[16ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
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 3C5A A5 C5 05 1B0Cは2002年2月1日、主要な用法を作成しました: コミュニケーションとストレージ03BBを暗号化してください: 00 0A09 10 8EのAF。 1A18の発行人の主要なイド03C7: C8 44は署名しているハッシュ値の16ビットを03C9に残しました: 07 FB04D7。 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、「承認のためのインターネット属性証明書プロフィール」、RFC3281、2002年4月。
[CMC] Myers, M., Liu, X., Schaad, J., and J. Weinstein,
"Certificate Management Messages over CMS", RFC 2797, April
2000.
2000年4月の[CMC]マイアーズとM.とリュウとX.とSchaad、J.とJ.ワインスタイン、「cmの上の証明書管理メッセージ」RFC2797。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、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)」、2005年9月のRFC4210。
[CRMF] Schaad, J., "Internet X.509 Public Key Infrastructure:
Certificate Request Message Format (CRMF)", RFC 4211,
September 2005.
[CRMF]Schaad、J.、「インターネットX.509公開鍵基盤:」 「証明書要求メッセージ形式(CRMF)」、2005年9月のRFC4211。
[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[OPENPGP] カラスとJ.とDonnerhackeとL.とフィニー、H.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Blinov & Adams Informational [Page 17] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[17ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
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
情報技術のカーライルアダムス学校と工学(サイト)オタワ大学800キング・エドワードアベニュー私書箱450、Stnオタワ、オンタリオ(カナダ)K1N 6N5
EMail: cadams@site.uottawa.ca
メール: cadams@site.uottawa.ca
Blinov & Adams Informational [Page 18] RFC 4212 Alternative Certificate Formats October 2005
Blinovとアダムス情報[18ページ]のRFC4212Alternativeは2005年10月に書式を証明します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78と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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Blinov & Adams Informational [Page 19]
BlinovとアダムスInformationalです。[19ページ]
一覧
スポンサーリンク
