Network Working Group J. Zsako
Request for Comments: 2726 BankNet
Category: Standards Track December 1999
PGP Authentication for RIPE Database Updates
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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データベースのアップデートの強力な認証方式の提案を提示しています。提案は、デジタル署名方法を懸念しているように、第1の方法を実装する限り、しかし、それは、PGPに主に集中できる限り一般的なことしよう。提案はRIPE DBSECタスクフォース内での議論の結果です。
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.
増加の必要性は、データベースの更新（オブジェクトの追加、変更、削除）の際に、データベースのメンテナの強力な認証のために同定されています。既存の認証方法は、重大なセキュリティ上の問題を抱えている：MAIL-からパスワードを更新メールメッセージで暗号化されずに送信されるので、メールヘッダには、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).
現在の目的は、改善された認証方法と何よりも（特に、この論文は、認証に関連するもの以外の許可の問題をカバーしようとしない）ためです。
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データベースに格納されています。公開鍵のローカルキーリングも維持される効率上の理由から、しかし、地元のキーリングは、データベースに存在する鍵証明書のコピーが含まれます。ローカルキーリングを使用してデータベースの同期は、できるだけ頻繁に行われます。データベース・オブジェクトは、特に何の公開鍵証明書がデータベースソフトウェアにより鍵サーバから取得されず、唯一の現在の電子メール機構（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）：ひとつのシグネチャを持ちます。詳細はまた、部4を参照してください。
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] [ ]
キー-CERT：[必須] [シングル] [プライマリ/ルックアップキー]方法：[生成] [シングル] []オーナー：[生成] [複数の] [] fingerpr：[生成] [シングル] [] certif： [必須] [シングル] []備考：[オプション] [複数の] []通知：[オプション] [複数の] [逆キー] MNTバイ：[必須] [複数の] [逆キー]は変更された：[必須] [複数] []源：[必須] [シングル] []
The syntax and the semantics of the different attributes are described below.
構文と異なる属性の意味は、以下に記載されています。
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.
キー-CERT：HHHHHHHHは、PGPキーの4バイトのIDの16進表現のための略で、フォームのPGPKEY-HHHHHHHH、です。 certif属性で詳述鍵証明書は、ID HHHHHHHHとPGPキーに属します。接頭辞としてPGPKEY-を持つ理由は、後日鍵証明書の他のタイプを可能にすることであると同時に、明らかに人のクエリと鍵証明書クエリの間で、クエリ時に区別できるようにします。キー-CERTオブジェクトの作成/変更時に、certifで鍵証明書が実際に属性データベースソフトウェアかどうかをチェックここで指定したPGP IDに属します。作成/変更はこれらの2つのIDの一致により承認されています。
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).
方法：署名メソッドの名前を含む行。これは、デジタル署名方式の名称です。現在の証明書は、デジタル指定された方法を使用してメッセージに署名するためのキーに属します。 method属性は、キー-CERTオブジェクトの作成時にデータベースソフトウェアによって自動的に生成されます。創造のための提出時に、対象中に存在する任意のmethod属性は無視されます。この方法は、キー証明書の属性にとcertif属性に含まれる証明書とIDの接頭辞の両方と一致しなければなりません。これら後者の2つ（すなわち、接頭辞および証明書）が一致しない場合、キーCERTオブジェクト作成は拒否されます。 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キーの場合は、所有者がキーに関連付けられたユーザーIDです。鍵証明書内に存在するユーザID毎に、所有者属性がキーCERTオブジェクトの作成時にデータベース・ソフトウェアによって自動的に生成されます。任意の所有者は無視されます作成のための提出時にオブジェクトに存在属性。
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属性は無視されます。この属性（及び所有者属性）を持つ理由は、データベースのクエリ時に鍵証明書の簡単なチェックを可能にすることです。クエリアは、彼/彼女の自身の公開鍵束に証明書を追加することなく、所有者と指紋情報を取得します。これら二つの属性は、証明書からデータベースソフトウェアによって_generated_されているので、（1がデータベース自体を信頼することができますできるだけ多くを）また、一つは彼らを信頼することができます。
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属性ラインを取り除き、スクリプトを含めることができ、文字列と以下のホワイトスペースとローカルキーリングに残りをインポートします。
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-によって：通常の構文通常のセマンティクスこの属性は、このオブジェクトの_mandatory_です。したがって、のmntnerオブジェクトの存在は、キー証明書オブジェクトを作成するための前提条件です。 MNT-によって属性で参照のmntnerが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).
キーCERTオブジェクトが作成されるときにPGPの場合において、関連する鍵は、公開鍵のローカル鍵リングに追加されます。キーCERTオブジェクトが削除されると、対応する公開鍵は、同様にローカル鍵リングから削除されます。キーCERTオブジェクトが変更されるたびに、新しい鍵証明書の場合、明らかにこれは特に、データベースの更新が認可されている場合にのみ実行される（キーは、ローカル鍵リングから削除され、新しい証明書に関連付けられた鍵を鍵リングに追加され上記参照）、属性鍵証明書で指定されたIDに属しありません。
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.
唯一の変更は、認証属性の新しい可能な値があるということです。この値は、<ID>は、認証のために使用PGP公開鍵の4バイトのIDの16進表現であるフォームPGPKEY- <ID>、です。
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-IDによって識別される鍵証明書のオブジェクトに格納された鍵証明書に関連付けられたPGP鍵が熟した自動DBMの@に送信された作成/変更/削除メッセージの署名を確認するために使用されることです。ネットこののmntnerによって維持オブジェクトに影響を与えます。
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.
ただ、他の値と同様に、認証属性は、複数のことができます。それはないか、以前やったように、（例えばPGPKEY- <ID>とNONE :)））の異なる方法で属性あまり意味が2つの認証を持っていることはありません。
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- <ID>の値を持ついくつかの認証方法がある場合、セマンティクスは_either_署名が受け入れられたこと、すなわち、既に公知のものです。
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署名されたメッセージであるか否かをデータベース・ソフトウェアは、最初に確認することを、意味します。もしそうであれば、それは有効な署名をチェックし、メッセージ内に提出されたオブジェクトとこの署名を関連付けます。メッセージは、唯一の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オブジェクトは、それに関連付けられた署名を有するかどうかをPGPKEY- <ID>の値は、データベース・ソフトウェア・チェックとAUTH属性（複数）（すなわち、メッセージかどうかを有する場合署名された処理）と署名（PGPこの実施段階で）、メッセージに署名するために使用されるキーのIDのタイプかどうかに1（の1つ）認証属性（単数または複数）と同じであるています。オブジェクトの作成/変更/削除は、この認証が成功した場合にのみ実行されます。
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.
このアプローチは、メッセージ解析処理の簡略化を可能にします。一つはなく、その後、更新メッセージを_objects_に署名するならば、異なるアプローチが必要であろう。オブジェクトが署名される場合、パーサは、それぞれが個別にオブジェクトと許可は/署名があるかどうかを（とりわけ）に応じて、オブジェクトレベルで更新を拒否に署名（S）を確認し、署名されたオブジェクトを識別しなければなりません有効な、それは（の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文字を使用することを確認するなど、スペースのタブの変換、文字の特定の番号の後行折り返しです。
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.
キー証明書オブジェクトを作成するために提出鍵証明書は、キー自体の署名が含まれている必要があります。証明書は、他の署名が含まれていてもよいが、証明書にできるだけ少ない署名と鍵証明書オブジェクトを作成することをお勧めします。キーのtrustfulness懸念は誰でも、公開鍵サーバから鍵証明書のコピーを取得（または任意の他の適切な手段によって、および_that_証明書に署名を確認する必要があります。そのようなチェックが実行されている場合は1が、両方をチェックするために注意する必要があります鍵のフィンガープリントと、2つの証明書を確認するために、キーの種類と長さが（RIPEデータベースから取り出さ1と公開鍵サーバーから取得または他の手段によって収集された1）が同じキーに属します。
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.
それは非常に低いですが、保守の鍵のIDと同一のIDを持つ鍵証明書がすでにRIPEデータベースに存在することが起こり得ます。場合には、この後者のキーがしばらく使用されていた、それはいくつかの時間のために公開鍵サーバに登録されていた、与えられた人は、RIPE NCCに連絡してripe-dbm@ripe.netにこれを報告しなければなりません。とにかく、彼/彼女は新しいキーを作成し、RIPEデータベースに証明書を_its_登録する必要があります。このような手順は、起こることは非常に可能性は低いものの、それぞれのメンテナに深刻な問題を作成しないでください。
5. Short overview of the tasks to be performed in order to use PGP authentication
PGP認証を使用するために実行されるタスクの5簡単な概要
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.
NONE以外：あなたは、認証とRIPEデータベース内のmntnerオブジェクトを持っている必要があります。 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).
auto-dbm@ripe.netに上記で調製したオブジェクトを送信することによって、RIPEデータベース内のキー証明書オブジェクトを作成します。明らかに、あなたは（すなわち、事前に定義されたアドレスからのメールや、正しいパスワードを送信）のmntnerオブジェクトによって必要な認証チェックをパスしなければなりません。
Change the mntner object to have the auth: attribute value of PGPKEY-<id>, where <id> is the hex id of your PGP key.
<ID>は、あなたのPGPキーの六角IDですPGPKEY- <ID>の属性値：AUTHを持っているのmntnerオブジェクトを変更します。
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（好ましくコマンドでこれがデータベースによりtrustfulnessを割り当てるために、より強力な認証方法から利益を得る唯一の方法です。あなたは、正しい可能矛盾をチェックすることができる唯一の人物であることを忘れないでくださいによって維持されるすべてのオブジェクトをチェック。
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データベースに提出キーを使用して、あなたによって維持されたオブジェクトを参照してください（全体）更新メッセージに署名します。
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-へ：MNT-NFY ncc@banknet.net ：ncc@banknet.net AUTH：PGPKEY-23F5CE35備考：これはBankNet関連するオブジェクトが通知全ての保守である：ncc@banknet.net MNTバイ：AS3244-MNTは、変更された：zsako@banknet.net 19980525ソース：RIPE
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
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]で扱われています。
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.
現在の提案は、ヨアヒム・シュミッツとウィルフリードWoeberの主導でダブリンのRIPE 27で設定されたRIPE DBSECタスクフォース内での議論の結果です。異なるocasionsでの議論に貢献してきた参加者のリスト（TF会議や電子メール経由）（アルファベット順）です：Cengiz Allaettinoglu、ジョアン・ルイス・シルバダマス、Havard Eidnes、クリス・フレッチャー、ダニエルKarrenberg、デビッドKessens、ジェイクKhuon、クレイグLabovitz、カール・マラマッド、デイブ・マイヤー、Maldwynモリス、サンディマーフィー、マイク・ノリス、キャロルオレンジ、ヨアヒム・シュミッツ、トム・スピンドラー、ドンStikvoort、カーティスVillamizar、ジェラルド・ウィンターズ、ウィルフリードWoeber、ヤーノシュZsako。
[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.マーフィー、 "ルーティングポリシーシステム・セキュリティ"、RFC 2725、1999年12月。
Janos Zsako BankNet 1121 Budapest Konkoly-Thege ut 29-33. Hungary
ヤーノシュはBankNet 1121 Konkoly-Thegeは29-33をユタサックス。ハンガリー
Phone: +36 1 395 90 28 Fax: +36 1 395 90 32 EMail: zsako@banknet.net
電話：+36 1 395 90 28ファックス：+36 1 395 90 32 Eメール：zsako@banknet.net
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は、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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専務に情報を扱ってください。
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。