RFC2726 日本語訳
2726 PGP Authentication for RIPE Database Updates. J. Zsako. December 1999. (Format: TXT=22594 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Zsako Request for Comments: 2726 BankNet Category: Standards Track December 1999
Zsakoがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2726年のBankNetカテゴリ: 標準化過程1999年12月
PGP Authentication for RIPE Database Updates
熟しているデータベース更新のためのPGP認証
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. The proposal tries to be as general as possible as far as digital signing methods are concerned, however, it concentrates mainly on PGP, as the first method to be implemented. The proposal is the result of the discussions within the RIPE DBSEC Task Force.
このドキュメントはデジタル署名に基づくRIPEデータベースのアップデートの、より強い認証方法のための提案を提示します。 提案はしかしながら、それが主にPGPに集中するのがデジタル署名メソッドに関する限り、できるだけ一般的になろうとします、実装するべき最初のメソッドとして。 提案はRIPE DBSEC Task Forceの中の議論の結果です。
1. Rationale
1. 原理
An increasing need has been identified for a stronger authentication of the database maintainer upon database updates (addition, modification and deletion of objects). The existing authentication methods have serious security problems: the MAIL-FROM has the drawback that a mail header is very easy to forge whereas CRYPT-PW is exposed to message interception, since the password is sent unencrypted in the update mail message.
増加する必要性はデータベース更新(オブジェクトの追加、変更、および削除)のデータベース維持装置の、より強い認証のために特定されました。 既存の認証方法には、重大な警備上の問題があります: メール-FROMには、鍛造するために、メールヘッダがそうである欠点が非常にたやすくありますが、CRYPT-PWはメッセージ妨害に暴露されます、アップデートメール・メッセージで非暗号化されていた状態でパスワードを送るので。
The goal was to implement a digital signature mechanism based on a widely available and deployed technology. The first choice was PGP, other methods may follow at a later date. PGP is presently quite widely used within the Internet community and is available both in and outside the US.
目標は広く利用可能で配布している技術に基づくデジタル署名メカニズムを実装することでした。 他のメソッドは、より後日、最初の選択がPGPであったのに続くかもしれません。 PGPは現在、インターネットコミュニティの中で全く広く使用されて、米国と米国の外で利用可能です。
The current aim is for an improved authentication method and nothing more (in particular, this paper does not try to cover authorization issues other than those related to authentication).
現在の目的は改良された認証方法のためのそうであり、何はも以上(特に、この紙は認証に関連するもの以外の承認問題をカバーしようとしない)ではありませんでも。
Zsako Standards Track [Page 1] RFC 2726 PGP Authentication for RIPE Database Updates December 1999
Zsako規格は1999年12月に熟しているデータベース更新のためのRFC2726PGP認証を追跡します[1ページ]。
2. Changes to the RIPE database
2. RIPEデータベースへの変化
In order to make the database as much self consistent as possible, the key certificates are stored in the RIPE database. For efficiency reasons a local keyring of public keys will also be maintained, however, the local keyring will only contain a copy of the key certificates present in the database. The synchronization of the database with the local keyring will be made as often as possible. The database objects will be created only via the current e-mail mechanism (auto-dbm@ripe.net), in particular no public key certificate will be retrieved from a key server by the database software.
多くの自己一貫するとしてのデータベースを可能にするように、主要な証明書はRIPEデータベースに保存されます。 また、公開鍵の地方のkeyringが維持される効率理由で、しかしながら、地方のkeyringはデータベースの現在の主要な証明書のコピーを含むだけでしょう。 できるだけ頻繁に地方のkeyringとのデータベースの同期をするでしょう。 単に現在のメールメカニズム( auto-dbm@ripe.net )でデータベースオブジェクトは作成されて、公開鍵証明書は特に全くデータベースソフトによって主要なサーバから検索されないでしょう。
The presence of the key certificates in the database will allow the users of the database to check the "identity" of the maintainer, in the sense that they can query the database for the certificate of the key the database software uses for authenticating the maintainer. This key certificate can then be checked for existing signatures and can possibly be compared with the key certificate obtained by other means for the same user (e.g. from the owner himself of from a public key server). Although the key certificates can be stored in the RIPE database with any number of signatures, since the RIPE database is not communicating directly with the public key servers, it is a good practice to add the key certificate with the minimum number of signatures possible (preferably with just one signature: the one of itself). See also section 4. for more details.
データベースでの主要な証明書の存在はデータベースのユーザに維持装置の「アイデンティティ」をチェックさせるでしょう、彼らがデータベースソフトが維持装置を認証するのに使用するキーの証明書のためのデータベースについて質問できるという意味で。 この主要な証明書を次に、既存の署名がないかどうかチェックできて、他の手段で同じユーザに入手する主要な証明書にたとえることができる、(例えば、所有者自身、公開鍵サーバ) RIPEデータベースにいろいろな署名で主要な証明書を保存できますが、RIPEデータベースが公開鍵サーバと共に直接伝達していないので、署名の最小の数が可能な状態で(ちょうど1つの署名: 望ましくは、それ自体の1つがある)主要な証明書を加えるのは、良い習慣です。 また、その他の詳細に関してセクション4を見てください。
2.1. The key-cert object
2.1. 主要な本命オブジェクト
A new object type is defined below for the purpose of storing the key certificates of the maintainers:
新しいオブジェクト・タイプは維持装置の主要な証明書を保存する目的のために以下で定義されます:
key-cert: [mandatory] [single] [primary/look-up key] method: [generated] [single] [ ] owner: [generated] [multiple] [ ] fingerpr: [generated] [single] [ ] certif: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ]
主要な本命: [義務的][単一の][予備選挙/ルックアップキー]のメソッド: [生成されます] [単一]の[ ]所有者: [生成されます] [複数]の[ ]fingerpr: [生成されます] [単一の] [ ]certif: [義務的][単一の]の[ ]所見: [任意の] [複数の] [ ] 通知してください: 近く[任意][複数の][逆さのキー]のmnt: [義務的な] [複数の] [逆さのキー]は変化しました: [義務的な] [複数]の[ ]ソース: [義務的]です[単一の]。[ ]
The syntax and the semantics of the different attributes are described below.
異なった属性の構文と意味論は以下で説明されます。
Zsako Standards Track [Page 2] RFC 2726 PGP Authentication for RIPE Database Updates December 1999
Zsako規格は1999年12月に熟しているデータベース更新のためのRFC2726PGP認証を追跡します[2ページ]。
key-cert: Is of the form PGPKEY-hhhhhhhh, where hhhhhhhh stands for for the hex representation of the four bytes ID of the PGP key. The key certificate detailed in the certif attribute belongs to the PGP key with the id hhhhhhhh. The reason for having PGPKEY- as a prefix is to allow for other types of key certificates at a later date, and at the same time to be able to clearly differentiate at query time between a person query and a key certificate query. At the time of the creation/modification of the key-cert object, the database software checks whether the key certificate in the certif attribute indeed belongs to the PGP id specified here. The creation/modification is authorized only upon the match of these two ids.
主要な本命: フォームPGPKEY-hhhhhhhhがあります。そこでは、hhhhhhhhが4バイトの十六進法表現のためにPGPキーのIDを表します。 certif属性で詳細な主要な証明書はイドhhhhhhhhによって主要なPGPに属します。 接頭語としてPGPKEYを持つ理由は、より後半の期日、および質問時に人の質問と主要な証明書質問の間で明確に差別化できる同時間に他のタイプの主要な証明書を考慮することです。 主要な本命オブジェクトの作成/変更時点で、データベースソフトは、本当に、certif属性における主要な証明書がここで指定されたPGPイドに属すかどうかチェックします。 作成/変更はこれらの2つのイドのマッチだけで認可されます。
method: Line containing the name of the signing method. This is the name of the digital signature method. The present certificate belongs to a key for digitally signing messages using the specified method. The method attribute is generated automatically by the database software upon creation of the key-cert object. Any method attribute present in the object at the time of the submission for creation is ignored. The method has to be consistent with both the prefix of the id in the key-cert attribute and with the certificate contained in the certif attributes. If these latter two (i.e. prefix and certificate) are not consistent, the key-cert object creation is refused. For the PGP method this will be the string "PGP" (without the quotes).
メソッド: 署名メソッドの名前を含んで、立ち並んでください。 これはデジタル署名メソッドの名前です。 現在の証明書は指定されたメソッドを使用することでメッセージにデジタルに署名するためのキーに属します。 メソッド属性は主要な本命オブジェクトの創案でデータベースソフトによって自動的に生成されます。 作成のための服従時点のオブジェクトの現在のどんなメソッド属性も無視されます。 メソッドは主要な本命属性と証明書があるイドの接頭語がcertif属性に含んだ両方と一致していなければなりません。 これらの後者の2(すなわち、接頭語と証明書)が一貫していないなら、主要な本命オブジェクト作成は拒否されます。 PGPメソッドのために、これはストリング"になるでしょう(引用文のない)"PGP。
owner: Line containing a description of the owner of the key. For a PGP key, the owners are the user ids associated with the key. For each user id present in the key certificate, an owner attribute is generated automatically by the database software upon creation of the key-cert object. Any owner attribute present in the object at the time of the submission for creation is ignored.
所有者: キーの所有者の記述を含んで、立ち並んでください。 PGPキーに関しては、所有者はキーに関連しているユーザイドです。 主要な証明書の現在のそれぞれのユーザイドにおいて、所有者属性は主要な本命オブジェクトの創案でデータベースソフトによって自動的に生成されます。 作成のための服従時点のオブジェクトの現在のどんな所有者属性も無視されます。
fingerpr: A given number of hex encoded bytes, separated for better readability by spaces. It represents the fingerprint of the key associated with the present certificate. This is also a field generated upon creation of the object instance. Any fingerpr attribute submitted to the robot is ignored. The reason for having this attribute (and the owner attribute) is to allow for an easy check of the key certificate upon a query of the database. The querier gets the owner and fingerprint information without having to add the certificate to his/her own public keyring. Also, since these two attributes are _generated_ by the database software from the certificate, one can trust them (as much as one can trust the database itself).
fingerpr: 与えられた数の十六進法が、より良い読み易さのために空間によって切り離されたバイトをコード化しました。 それは現在の証明書に関連しているキーの指紋を表します。 また、これはオブジェクトインスタンスの作成で生成された分野です。 ロボットに提出されたどんなfingerpr属性も無視されます。 この属性(そして、所有者属性)を持つ理由はデータベースの質問の主要な証明書の簡単なチェックを考慮することです。 その人の自己の公共のkeyringに証明書を加える必要はなくて、querierは所有者と指紋情報を得ます。 また、これらの2つの属性が証明書からのデータベースソフトによって_であると生成された_であるので、人はそれらを信じることができます(できるだけデータベース自体を信じてください)。
Zsako Standards Track [Page 3] RFC 2726 PGP Authentication for RIPE Database Updates December 1999
Zsako規格は1999年12月に熟しているデータベース更新のためのRFC2726PGP認証を追跡します[3ページ]。
certif: Line containing a line of the ASCII armoured key certificate. The certif attribute lines contain the key certificate. In the case of PGP, they also contain the delimiting lines (BEGIN/END PGP PUBLIC KEY BLOCK). Obviously the order of the lines is essential, therefore the certif attribute lines are presented at query time in the same order as they have been submitted at creation. A database client application could contain a script that strips the certif attribute lines (returned as a result of a query) from the leading "certif:" string and the following white spaces and import the remainder in the local keyring.
certif: ASCIIの装甲している主要な証明書の系列を含んで、立ち並んでください。 certif属性系列は主要な証明書を含んでいます。 また、PGPの場合では、それらは区切り系列(BEGIN/END PGP PUBLIC KEY BLOCK)を含んでいます。 明らかに、系列の注文が不可欠である、したがって、作成でそれらを提出したとき、質問時に同次でcertif属性系列を提示します。 データベースクライアントアプリケーションはそれがcertif属性系列(質問の結果、返す)を剥取るスクリプトを含むかもしれません。主は「以下をcertifします」。 ストリングと以下は、地方のkeyringで空間を空白にして、残りをインポートします。
mnt-by: The usual syntax the usual semantics this attribute is _mandatory_ for this object. Therefore, the existence of a mntner object is a prerequisite for the creation of a key-cert object. The mntner referenced in the mnt-by attribute may not have the auth attribute set to NONE.
近くmnt: 普通の構文、これが結果と考える普通の意味論はこのオブジェクトのための_の義務的な_です。 したがって、mntnerオブジェクトの存在は主要な本命オブジェクトの創案のための前提条件です。 近くmnt属性で参照をつけられるmntnerはauth属性をNONEに設定させないかもしれません。
remarks:, notify:, changed:, source: the usual syntax and semantics.
以下を述べさせて、変えて、以下に通知する、:、以下の出典を明示してください。 普通の構文と意味論。
In the case of PGP, when a key-cert object is created, the associated key is also added to a local keyring of public keys. When a key-cert object is deleted, the corresponding public key is deleted from the local keyring as well. Whenever a key-cert object is modified, the key is deleted from the local keyring and the key associated with the new certificate is added to the keyring (obviously this is performed only when the database update is authorized, in particular if the new key certificate does belong to the id specified in the attribute key-cert, see above).
また、PGPの場合では、主要な本命オブジェクトが作成されるとき、関連キーは公開鍵の地方のkeyringに加えられます。 主要な本命オブジェクトが削除されるとき、対応する公開鍵はまた、地方のkeyringから削除されます。 主要な本命オブジェクトが変更されているときはいつも、キーは地方のkeyringから削除されます、そして、新しい証明書に関連しているキーはkeyringに加えられます(データベース更新が認可されているときだけ、明らかに、これが実行されて、新しい主要な証明書が属性キー本命で指定されたイドに属すなら、特に、上を見てください)。
2.2. Changes to the mntner object
2.2. mntnerオブジェクトへの変化
The only change is that there is a new possible value for the auth attribute. This value is of the form PGPKEY-<id>, where <id> is the hex representation of the four bytes id of the PGP public key used for authentication.
唯一の変化はauth属性のための新しい可能な値があるということです。 この値はフォームPGPKEY-<のものです。イド>。(そこでは、<イド>が認証に使用されるPGP公開鍵の4バイトのイドの十六進法表現です)。
The semantics of this new value is that the PGP key associated with the key certificate stored in the key-cert object identified by PGPKEY-id is used to check the signature of any creation/modification/deletion message sent to auto-dbm@ripe.net affecting an object maintained by this mntner.
この新しい価値の意味論はPGPKEY-イドによって特定された主要な本命オブジェクトに保存される主要な証明書に関連しているPGPキーがこのmntnerによって維持されたオブジェクトに影響する auto-dbm@ripe.net に送られたどんな作成/変更/削除メッセージの署名もチェックするのに使用されるということです。
Zsako Standards Track [Page 4] RFC 2726 PGP Authentication for RIPE Database Updates December 1999
Zsako規格は1999年12月に熟しているデータベース更新のためのRFC2726PGP認証を追跡します[4ページ]。
Just as with other values, the auth attribute can be multiple. It does not make much sense to have two auth attributes with different methods (e.g. PGPKEY-<id> and NONE :)) ), just as it didn't earlier either.
ちょうど他の値なら、auth属性は複数である場合があります。 異なったメソッドでそれが2つのauth属性を持つ多くの意味にならない、(例えば、PGPKEY<イド>とNONE、:、) )、 より早くそうしただけではない、どちらか。
If there are several auth methods with a PGPKEY-<id> value, the semantics is the already known one, namely that _either_ signature is accepted.
_PGPKEY-<があるいくつかのauthメソッドがあれば、イド>価値、意味論は既に知られているものです、すなわち、どちらの_署名も受け入れます。
3. The PGP signed creation/modification/deletion
3. 作成/変更/削除であると署名されるPGP
The whole message has to be signed. This means, that the database software first checks whether the message is a PGP signed message. If it is, it checks for a valid signature and associates this signature with the objects submitted in the message. A message may contain only one PGP signature.
全体のメッセージは署名されなければなりません。 この手段であり、データベースソフトが、最初にメッセージがPGPであるかどうかチェックするのがメッセージに署名しました。 そうなら、それは有効な署名と仲間がないかどうかメッセージで提出するオブジェクトにこの署名について問い合わせます。 メッセージは1つのPGP署名だけを含むかもしれません。
If an object present in a message has a mnt-by attribute, and the respective mntner has auth attribute(s) with PGPKEY-<id> value, the database software checks whether the object has a signature associated with it (i.e. whether the message being processed had been signed) and whether the type of the signature (PGP in this implementation phase) and the id of the key used for signing the message is the same as the one in (one of) the auth attribute(s). The creation/modification/deletion of the object is performed only if this authentication succeeds.
メッセージの現在のオブジェクトには近くmnt属性があって、オブジェクトにそれに関連している署名がある(すなわち、処理されるメッセージが署名されたか否かに関係なく)か否かに関係なく、それぞれのmntnerがauthに(s) イド>価値、PGPKEY-<によるデータベースソフトチェックを結果と考えさせて、署名(この実施フェーズのPGP)のタイプとメッセージに署名するのに使用されるキーのイドが1つのコネと同じである、(1つ、)、auth属性。 この認証が成功する場合にだけ、オブジェクトの作成/変更/削除は実行されます。
This approach allows for a simplification of the message parsing process. A different approach would be necessary if one would sign the _objects_, rather then the update messages. In case the objects would be signed, the parser would have to identify which objects were signed, check the signature(s) on each object individually and permit/refuse the update at an object level, depending on (amongst others) whether the signature is valid and whether it belongs to (one of) the maintainer(s). This approach would allow for mixing in the same e-mail message objects signed by different maintainers (which would probably not be typical), and it would also allow for storing the signature in the database (in order to allow for the verification of the signature at query time). This latter (i.e. storing the signatures in the database) is beyond the scope of the first phase of the implementation. It may become a goal at a later date.
このアプローチはメッセージ構文解析プロセスの簡素化を考慮します。 1つが、_オブジェクトが_であると署名するなら、異なるアプローチが必要であるだろう、むしろその時はアップデートメッセージです。 オブジェクトは署名されるといけないでしょう、したがって、パーサが署名が有効であり、属するか否かに関係なく、オブジェクトがオブジェクトレベル、依存における進行中のアップデート(他のものの)にどれに署名されて、各オブジェクトの上に個別に署名をチェックして、可能にするか、または拒否するかを特定しなければならないだろう、(1つ、)、維持装置。 このアプローチは、異なった維持装置(たぶん典型的でない)によって署名される同じメールメッセージオブジェクトで混入すると考慮するでしょう、そして、また、それはデータベースにおける署名を保存すると考慮するでしょう(質問時に署名の検証を考慮するために)。 この後者(すなわち、データベースにおける署名を保存する)は実装の第1段階の範囲を超えています。 それは、より後日、目標になるかもしれません。
It is recommended to check that the mailer program does not make any transformations on the text of the e-mail message (and possibly configure it not to do any). Such common transformations are line- wrapping after a given number of characters, transforming of tabs in spaces, etc. Also check that you only use ASCII characters in the message.
郵送者プログラムがメールメッセージのテキストに関するどんな変換も作らないのをチェックするのはお勧めです(いずれもしないようにことによるとそれを構成してください)。 空間などにおけるタブを変形させて、そのような一般的な変換は与えられた数のキャラクタの後の系列ラッピングです。 また、メッセージでASCII文字を使用するだけであるのをチェックしてください。
Zsako Standards Track [Page 5] RFC 2726 PGP Authentication for RIPE Database Updates December 1999
Zsako規格は1999年12月に熟しているデータベース更新のためのRFC2726PGP認証を追跡します[5ページ]。
4. Requirements the PGP key certificates must meet
4. PGPの主要な証明書が満たさなければならない必要条件
There is no limitation imposed with respect to the version of the PGP software that is/was used for the creation of the key. Key of both version 2.x and 5.0 are supported, although the keys generated with version 5.0 are recommended.
PGPソフトウェアのバージョンに関して課された制限が全くありませんでした、すなわち、/はキーの作成に使用されました。 バージョン5.0で生成されたキーはお勧めですが、バージョン2.xと5.0の両方のキーは支えられます。
The key certificates submitted for creating a key-cert object must contain a signature of the key itself. Although the certificate may contain other signatures as well, it is recommended to create the key-cert object with as few signatures as possible in the certificate. Anyone concerned about the trustfulness of the key should retrieve a copy of the key certificate from a public key server (or by any other appropriate means and check the signatures present in _that_ certificate. If such a check is performed one should take care to check both the key fingerprint and the key type and length in order to make sure the two certificates (the one retrieved from the RIPE database and the one retrieved from the public key server or collected by other means) belong to the same key.
主要な本命オブジェクトを作成するために提出された主要な証明書はキー自体の署名を含まなければなりません。 証明書はまた、他の署名を含むかもしれませんが、同じくらいわずかな署名が証明書で可能な状態で主要な本命オブジェクトを作成するのはお勧めです。 いかなる他の適切な手段とチェックでも、署名は_にその_証明書を提示します。または、キーの信頼性に関して心配している人はだれでも公開鍵サーバからの主要な証明書のコピーを検索するべきである、(そのようなチェックが実行されるなら、2通の証明書(RIPEデータベースから検索されたものと公開鍵サーバから検索されたか、または他の手段で集められたもの)が同じキーに属すのを確実にするために主要な指紋と主要なタイプと長さの両方をチェックするために注意されるべきです。
Although it is highly unlikely, it may happen that a key-cert with the id identical to the id of the key of a maintainer already exists in the RIPE database. In case this latter key had been used for a while and it had been registered at public key servers for some time, the given person should contact the RIPE NCC and report this to ripe-dbm@ripe.net. Anyway, he/she may have to create a new key and register _its_ certificate into the RIPE database. Such a procedure, although highly unlikely to happen, should not create serious problems to the respective maintainer.
それは非常にありそうもないのですが、維持装置のキーのイドと同じイドをもっている主要な本命がRIPEデータベースに既に存在するのは起こるかもしれません。 しばらく、この後者のキーがしばらく使用されていて、それが公開鍵サーバで登録されているといけなかったので、与えられた人は、RIPE NCCに連絡して、これを ripe-dbm@ripe.net に報告するべきです。 とにかく、その人は、RIPEデータベースに新しいキーを作成して、__証明書を登録しなければならないかもしれません。 非常に起こりそうではありませんが、そのような手順はそれぞれの維持装置に深刻な問題を作成するべきではありません。
5. Short overview of the tasks to be performed in order to use PGP authentication
5. PGP認証を使用するために実行されるべきタスクの短い概要
You must have a mntner object in the RIPE database with auth: other than NONE. The mntner object has to be created in the traditional way.
あなたはRIPEデータベースにauthでmntnerオブジェクトを持たなければなりません: NONEを除いて。 mntnerオブジェクトは伝統的な方法で作成されなければなりません。
You must get a certificate of your own key and prepare a key-cert object from it. The object has to reference in mnt-by the mntner mentioned above.
あなたは、あなた自身のキーの証明書を手に入れて、それから主要な本命オブジェクトを準備しなければなりません。 オブジェクトは近くmntで前記のようにmntnerに参照をつけなければなりません。
Create the key-cert object in the RIPE database, by sending the object prepared above to auto-dbm@ripe.net. Obviously you must pass the authentication checks required by the mntner object (i.e. mail from a predefined address or send the correct password).
RIPEデータベースで上で auto-dbm@ripe.net に準備されたオブジェクトを送ることによって、主要な本命オブジェクトを作成してください。 明らかに、あなたはmntner目的によって必要とされた認証チェックを通過しなければなりません(すなわち、正しいパスワードを事前に定義されたアドレスから郵送するか、または送ってください)。
Zsako Standards Track [Page 6] RFC 2726 PGP Authentication for RIPE Database Updates December 1999
Zsako規格は1999年12月に熟しているデータベース更新のためのRFC2726PGP認証を追跡します[6ページ]。
Change the mntner object to have the auth: attribute value of PGPKEY-<id>, where <id> is the hex id of your PGP key.
mntnerオブジェクトを変えて、authを持ってください: <イド>があなたのPGPキーの十六進法イドである<イド>はPGPKEYを評価している属性。
Check all objects maintained by the given mntner (preferably with the command This is the only way to benefit from the stronger authentication method in order to assign more trustfulness to the database. Remember that you are the only person who can check for and correct possible inconsistencies.
与えられたmntnerによって維持されて、すべてのオブジェクトをチェックしてください。望ましくはコマンドで、Thisは、より多くの信頼性をデータベースに割り当てるために、より強い認証方法の利益を得る唯一の方法です。(あなたが可能な矛盾をチェックして、修正できる唯一の人であることを覚えていてください。
From now on always sign the (whole) update messages that refer to objects maintained by you, with the key you submitted to the RIPE database.
これから先、いつも(全体)のアップデートがあなたがRIPEデータベースに提出したキーであなたによって維持されたオブジェクトについて言及するメッセージであると署名してください。
Zsako Standards Track [Page 7] RFC 2726 PGP Authentication for RIPE Database Updates December 1999
Zsako規格は1999年12月に熟しているデータベース更新のためのRFC2726PGP認証を追跡します[7ページ]。
6. Example of objects using the new feature
6. 新機能を使用するオブジェクトに関する例
mntner: AS3244-MNT descr: BankNet, Budapest HU descr: Eastern European Internet Provider via own VSAT network admin-c: JZ38 tech-c: JZ38 tech-c: IR2-RIPE upd-to: ncc@banknet.net mnt-nfy: ncc@banknet.net auth: PGPKEY-23F5CE35 remarks: This is the maintainer of all BankNet related objects notify: ncc@banknet.net mnt-by: AS3244-MNT changed: zsako@banknet.net 19980525 source: RIPE
mntner: AS3244-MNT descr: BankNet、ブダペストHU descr: 自身のVSATを通した東欧プロバイダはアドミンcをネットワークでつなぎます: JZ38の科学技術のc: JZ38の科学技術のc: IR2-RIPE upd、-、: ncc@banknet.net mnt-nfy: ncc@banknet.net auth: PGPKEY-23F5CE35所見: これは関連するオブジェクトが通知するすべてのBankNetの維持装置です: 近く ncc@banknet.net mnt: AS3244-MNTは変化しました: zsako@banknet.net 19980525ソース: 熟す
key-cert: PGPKEY-23F5CE35 method: PGP owner: Janos Zsako <zsako@banknet.net> fingerpr: B5 D0 96 D0 D0 D3 2B B2 B8 C2 5D 22 D4 F5 78 92 certif: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2i + mQCNAzCqKdIAAAEEAPMSQtBNFFuTS0duoUiqnPHm05dxrI76rrOGwx+OU5tzGavx cm2iCInNtikeKjlIMD7FiCH1J8PWdZivpwhzuGeeMimT8ZmNn4z3bb6ELRyiZOvs 4nfxVlh+kKKD9JjBfy8DnuMs5sT0jw4FEt/PYogJinFdndzywXHzGHEj9c41AAUR tB9KYW5vcyBac2FrbyA8enNha29AYmFua25ldC5uZXQ+iQCVAwUQMjkx2XHzGHEj 9c41AQEuagP/dCIBJP+R16Y70yH75kraRzXY5rnsHmT0Jknrc/ihEEviRYdMV7X1 osP4pmDU8tNGf0OfGrok7KDTCmygIh7/me+PKrDIj0YkAVUhBX3gBtpSkhEmkLqf xbhYwDn4DV3zF7f5AMsbD0UCBDyf+vpkMzgd1Pbr439iXdgwgwta50qJAHUDBRAy OSsrO413La462EEBAdIuAv4+Cao1wqBG7+gIm1czIb1M2cAM7Ussx6y+oL1d+HqN PRhx4upLVg8Eqm1w4BYpOxdZKkxumIrIvrSxUYv4NBnbwQaa0/NmBou44jqeN+y2 xwxAEVd9BCUtT+YJ9iMzZlE= =w8xL -----END PGP PUBLIC KEY BLOCK----- remarks: This is an example of PGP key certificate mnt-by: AS3244-MNT changed: zsako@banknet.net 19980525 source: RIPE
主要な本命: PGPKEY-23F5CE35メソッド: PGP所有者: ジェイノス Zsako <zsako@banknet.net 、gt;、fingerpr: B5 D0 96D0 D0 D3 2B B2 B8 C2 5D22D4 F5 78 92certif: -----PGP公開鍵ブロックを始めてください。----- バージョン: 2.6; 2i+mQCNAzCqKdIAAAEEAPMSQtBNFFuTS0duoUiqnPHm05dxrI76rrOGwx+OU5tzGavx cm2iCInNtikeKjlIMD7FiCH1J8PWdZivpwhzuGeeMimT8ZmNn4z3bb6ELRyiZOvs4nfxVlh+kKKD9JjBfy8DnuMs5sT0jw4FEt/PYogJinFdndzywXHzGHEj9c41AAUR tB9KYW5vcyBac2FrbyA8enNha29AYmFua25ldC5uZXQ+iQCVAwUQMjkx2XHzGHEj 9c41AQEuagP/dCIBJP+R16Y70yH75kraRzXY5rnsHmT0Jknrc/ihEEviRYdMV7X1; osP4pmDU8tNGf0OfGrok7KDTCmygIh7/、私、+ PKrDIj0YkAVUhBX3gBtpSkhEmkLqf xbhYwDn4DV3zF7f5AMsbD0UCBDyf+vpkMzgd1Pbr439iXdgwgwta50qJAHUDBRAy OSsrO413La462EEBAdIuAv4+Cao1wqBG7+gIm1czIb1M2cAM7Ussx6y+oL1d+HqN PRhx4upLVg8Eqm1w4BYpOxdZKkxumIrIvrSxUYv4NBnbwQaa0/NmBou44jqeN+y2 xwxAEVd9BCUtT+YJ9iMzZlE= =w8xL-----端のPGP公開鍵ブロック----- 所見: これは近くPGPの主要な証明書mntに関する例です: AS3244-MNTは変化しました: zsako@banknet.net 19980525ソース: 熟す
Zsako Standards Track [Page 8] RFC 2726 PGP Authentication for RIPE Database Updates December 1999
Zsako規格は1999年12月に熟しているデータベース更新のためのRFC2726PGP認証を追跡します[8ページ]。
7. Security Considerations
7. セキュリティ問題
This document addresses authentication of transactions for making additions, deletions, and updates to the routing policy information through strong cryptographic means. The authorization of these transactions are addressed in [1].
このドキュメントは、強い暗号の手段でルーティングへの追加、削除、およびアップデートを方針情報にするようにトランザクションの認証を扱います。 これらのトランザクションの承認は[1]で扱われます。
8. Acknowledgements
8. 承認
The present proposal is the result of the discussions within the RIPE DBSEC Task Force, which was set up at RIPE 27 in Dublin at the initiative of Joachim Schmitz and Wilfried Woeber. The list of participants who have contributed to the discussions at different ocasions (TF meetings and via e-mail) is (in alphabetical order): Cengiz Allaettinoglu, Joao Luis Silva Damas, Havard Eidnes, Chris Fletcher, Daniel Karrenberg, David Kessens, Jake Khuon, Craig Labovitz, Carl Malamud, Dave Meyer, Maldwyn Morris, Sandy Murphy, Mike Norris, Carol Orange, Joachim Schmitz, Tom Spindler, Don Stikvoort, Curtis Villamizar, Gerald Winters, Wilfried Woeber, Janos Zsako.
現在の提案はRIPE DBSEC Task Forceの中の議論の結果です。RIPE DBSEC Task Forceはヨアヒム・シュミッツとWilfried WoeberのイニシアチブのときにダブリンでRIPE27で上がっているセットでした。 異なったocasions(ミーティングとメールを通したTF)での議論に貢献した関係者のリストは(アルファベット順に)以下の通りです。 Cengiz Allaettinoglu、ジョアン・ルイス・シルヴァ・ダマ、Havard Eidnes、クリスフレッチャー、ダニエルKarrenberg、デヴィッドKessens、ジェークKhuon、クレイグLabovitz、カール・マラマッド、デーヴ・マイヤー、Maldwynモリス、砂地のマーフィー、マイク・ノリス、キャロルOrange、ヨアヒム・シュミッツ、トムSpindler、ドンStikvoort、カーティスVillamizar、ジェラードは避寒します、Wilfried Woeber、ジェイノスZsako。
9. References
9. 参照
[1] Meyer, D., Villamizar, C., Alaettinoglu, C. and S. Murphy, "Routing Policy System Security", RFC 2725, December 1999.
[1] マイヤーとD.とVillamizarとC.とAlaettinogluとC.とS.マーフィー、「ルート設定方針システムセキュリティ」、RFC2725、1999年12月。
10. Author's Address
10. 作者のアドレス
Janos Zsako BankNet 1121 Budapest Konkoly-Thege ut 29-33. Hungary
ジェイノスZsako BankNet1121ブダペストKonkoly-Thege ut29-33。 ハンガリー
Phone: +36 1 395 90 28 Fax: +36 1 395 90 32 EMail: zsako@banknet.net
以下に電話をしてください。 +36 1 395、90 28、Fax: +36 1 395 90 32はメールされます: zsako@banknet.net
Zsako Standards Track [Page 9] RFC 2726 PGP Authentication for RIPE Database Updates December 1999
Zsako規格は1999年12月に熟しているデータベース更新のためのRFC2726PGP認証を追跡します[9ページ]。
11. Notices
11. 通知
PGP is a commercial software.
PGPは商用ソフトウェアです。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
Zsako Standards Track [Page 10] RFC 2726 PGP Authentication for RIPE Database Updates December 1999
Zsako規格は1999年12月に熟しているデータベース更新のためのRFC2726PGP認証を追跡します[10ページ]。
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Zsako Standards Track [Page 11]
Zsako標準化過程[11ページ]
一覧
スポンサーリンク