[要約] RFC 2726は、RIPEデータベースの更新におけるPGP認証についての規格です。目的は、データベースの更新を保護し、信頼性を確保するために、PGPを使用した認証メカニズムを提供することです。
Network Working Group J. Zsako
Request for Comments: 2726 BankNet
Category: Standards Track December 1999
PGP Authentication for RIPE Database Updates
RIPEデータベースの更新用のPGP認証
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.
Copyright（c）The Internet Society（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データベースの更新のより強力な認証方法の提案を提示します。この提案は、デジタル署名方法に関する限り、可能な限り一般的であることを試みますが、最初に実装される方法として、主にPGPに集中します。この提案は、熟した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.
データベースの更新時にデータベースメンテナーのより強力な認証（オブジェクトの追加、変更、削除）が必要になっています。既存の認証方法には深刻なセキュリティの問題があります。メールフォームには、メールヘッダーが非常に簡単に鍛造できるという欠点がありますが、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.
データベースをできるだけ多くの自己一貫性を実現するために、重要な証明書は熟したデータベースに保存されます。効率的な理由で、パブリックキーのローカルキーリングも維持されますが、ローカルキーリングには、データベースに存在するキー証明書のコピーのみが含まれます。データベースとローカルキーリングの同期は、可能な限り頻繁に行われます。データベースオブジェクトは、現在の電子メールメカニズム（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.
データベースにキー証明書が存在すると、データベースのユーザーがメンテナーの「ID」をチェックすることができます。これは、メンテナーを認証するためにデータベースソフトウェアが使用するキーの証明書をデータベースに照会できるという意味で、メンテナーの「ID」を確認できます。このキー証明書は、既存の署名をチェックでき、同じユーザーに対して他の手段で得られたキー証明書と比較することができます（例：公開キーサーバーからの所有者自身から）。主要な証明書は、任意の数の署名を使用して熟したデータベースに保存できますが、RIPEデータベースは公開キーサーバーと直接通信していないため、可能な最小数の署名でキー証明書を追加することをお勧めします（できればできればたった1つの署名があります：それ自体の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] [ ]
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.
Key-Cert：PGPKEY-HHHHHHHHHでは、HHHHHHHHHがPGPキーの4つのバイトIDのHEX表現を表しています。Certif属性に詳述されているキー証明書は、ID HHHHHHHHのPGPキーに属します。プレフィックスとしてPGPKeyを持つ理由は、後日、他のタイプのキー証明書を許可し、同時に、人クエリとキー証明書クエリの間のクエリ時間に明確に区別できるようにするためです。KeyCertオブジェクトの作成/変更時に、データベースソフトウェアは、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).
方法：署名方法の名前を含む行。これは、デジタル署名メソッドの名前です。現在の証明書は、指定された方法を使用してメッセージに署名するためのキーに属します。メソッド属性は、キーキャットオブジェクトの作成時にデータベースソフトウェアによって自動的に生成されます。作成の提出時にオブジェクトに存在するメソッド属性は無視されます。この方法は、キーキャット属性のIDのプレフィックスと、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キーの場合、所有者はキーに関連付けられているユーザーIDです。キー証明書に存在するユーザーIDごとに、キーキャットオブジェクトの作成時に所有者属性がデータベースソフトウェアによって自動的に生成されます。作成の提出時にオブジェクトに存在する所有者属性は無視されます。
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属性は無視されます。この属性（および所有者属性）を持つ理由は、データベースのクエリでキー証明書を簡単に確認できるようにするためです。Querierは、証明書を自分の公開キーリングに追加することなく、所有者と指紋情報を取得します。また、これらの2つの属性は、証明書のデータベースソフトウェアによって_generated _であるため、それらを信頼することができます（データベース自体を信頼できる限り）。
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の場合、それらには区切り線（PGPの開始/終了の公開ブロック）も含まれています。明らかに、ラインの順序が不可欠であるため、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-by：通常の構文この属性は、このオブジェクトの_mandatory_です。したがって、MNTNERオブジェクトの存在は、キーケルトオブジェクトの作成の前提条件です。MNT-by属性で参照されているMNTNERには、auth属性がNoneに設定されていない場合があります。
remarks:, notify:, changed:, source: the usual syntax and semantics.
備考：、Notify：、変更：、出典：通常の構文とセマンティクス。
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の場合、キーキャットオブジェクトが作成されると、関連するキーもパブリックキーのローカルキーリングに追加されます。キーキャットオブジェクトが削除されると、対応する公開キーもローカルキーリングから削除されます。キーキャットオブジェクトが変更されると、キーがローカルキーリングから削除され、新しい証明書に関連付けられているキーがキーリングに追加されます（明らかに、これはデータベースの更新が承認されている場合にのみ実行されます。属性キーケルトで指定された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.
唯一の変更は、AUTH属性に新しい可能な値があることです。この値はPgpkey- <id>の形式です。ここで、<id>は認証に使用されるPGP公開キーの4バイトIDの16進表現です。
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キーが、Auto-DBM@Ripeに送信された作成/変更/削除メッセージの署名を確認するために使用されることです。この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.
他の値と同様に、AUTH属性は複数になる可能性があります。以前にもそうではなかったように、異なる方法（例：pgpkey- <id> and 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署名されたメッセージであるかどうかを確認することを意味します。もしそうなら、有効な署名をチェックし、この署名をメッセージに送信したオブジェクトと関連付けます。メッセージには、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-by属性があり、それぞれのMNTNERがpgpkey- <id>値を持つauth属性を持っている場合、データベースソフトウェアはオブジェクトに署名があるかどうかをチェックします（つまり、メッセージがメッセージに関連付けられているかどうか処理されているのは署名されていました）、およびメッセージの署名に使用される署名のタイプ（この実装フェーズのPGP）とキーのIDが（auth属性の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_に署名する場合、別のアプローチが必要になります。オブジェクトが署名された場合、パーサーはどのオブジェクトが署名されたかを識別し、各オブジェクトの署名を個別に確認し、署名が（とりわけ）署名があるかどうかに応じて、オブジェクトレベルで更新を許可/拒否する必要があります。有効であり、それがメンテナーに（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.
キーケルトオブジェクトを作成するために提出されたキー証明書には、キー自体の署名が含まれている必要があります。証明書には他の署名も含まれている場合がありますが、証明書にできるだけ少ない署名を持つキーケルトオブジェクトを作成することをお勧めします。キーの信頼性に関心のある人なら誰でも、公開キーサーバーからキー証明書のコピーを取得する（または他の適切な手段によって_that_証明書に存在する署名を確認する必要があります。そのようなチェックが実行された場合は、両方をチェックするように注意する必要があります。キーの指紋とキータイプと長さは、2つの証明書（熟したデータベースから取得され、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 nccに連絡し、これをRipe-dbm@ripe.netに報告する必要があります。とにかく、彼/彼女は、新しいキーを作成し、Ripeデータベースに_ITS_証明書を登録する必要がある場合があります。このような手順は、非常に起こりそうにありませんが、それぞれのメンテナーに深刻な問題を引き起こすべきではありません。
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.
熟したデータベースには、auth：none以外の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.
独自のキーの証明書を取得し、そこからキーケルトオブジェクトを準備する必要があります。オブジェクトは、上記のMNTNERごとにMNTで参照する必要があります。
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に送信して、熟したデータベースにキーキャットオブジェクトを作成します。明らかに、MNTNERオブジェクトで必要な認証チェックを渡す必要があります（つまり、事前定義されたアドレスからメールを送信するか、正しいパスワードを送信します）。
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：pgpkey- <id>の属性値を持つことを意味します。ここで、<id>はPGPキーの160個です。
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によって維持されているすべてのオブジェクトを確認します（できればコマンドでは、データベースにより多くの信頼性を割り当てるために、より強力な認証方法から利益を得る唯一の方法です。。
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.
これからは、熟したデータベースに提出したキーを使用して、あなたが維持しているオブジェクトを参照する（全体の）更新メッセージに常に署名します。
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
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.
現在の提案は、ヨアヒム・シュミッツとウィルフリード・ウォーバーのイニシアチブでダブリンのRipe 27に設立されたRipe DBSECタスクフォース内での議論の結果です。さまざまなオコシオン（TFミーティングと電子メールを介して）での議論に貢献した参加者のリストは（アルファベット順）です：Cengiz Allaettinoglu、Joao Luis Silva Damas、Havard Eidnes、Chris Fletcher、Daniel Karrenberg、David Kessens、ジェイク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。
[1] Meyer, D., Villamizar, C., Alaettinoglu, C. and S. Murphy, "Routing Policy System Security", RFC 2725, December 1999.
[1] Meyer、D.、Villamizar、C.、Alaettinoglu、C。、およびS. Murphy、「ルーティングポリシーシステムセキュリティ」、RFC 2725、1999年12月。
Janos Zsako BankNet 1121 Budapest Konkoly-Thege ut 29-33. Hungary
Janos Zsako Banknet 1121 Budapest Konkoly-Thege UT 29-33。ハンガリー
Phone: +36 1 395 90 28
Fax: +36 1 395 90 32
EMail: 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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。