Network Working Group J. Zsako
Request for Comments: 2726 BankNet
Category: Standards Track December 1999
Network Working Group J. Zsako
Request for Comments: 2726 BankNet
Category: Standards Track December 1999
PGP Authentication for RIPE Database Updates
用于成熟数据库更新的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.
版权所有（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.
本文件提出了一种基于数字签名的更强大的数据库更新认证方法的建议。就数字签名方法而言，该提案试图尽可能具有一般性，但是，它主要集中于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.
现已查明，越来越需要在数据库更新（添加、修改和删除对象）时对数据库维护人员进行更强有力的身份验证。现有的身份验证方法存在严重的安全问题：MAIL-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).
当前的目标是改进身份验证方法，仅此而已（特别是，本文不尝试讨论与身份验证相关的授权问题）。
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.
为了使数据库尽可能具有自一致性，密钥证书存储在成熟的数据库中。出于效率原因，还将维护公钥的本地密钥环，但是，本地密钥环将仅包含数据库中存在的密钥证书的副本。数据库与本地密钥环的同步将尽可能频繁。数据库对象将仅通过当前电子邮件机制（自动）创建-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.
数据库中密钥证书的存在将允许数据库用户检查维护者的“身份”，也就是说，他们可以在数据库中查询数据库软件用于认证维护者的密钥证书。然后可以检查该密钥证书是否存在签名，并且可以将其与通过其他方式为同一用户（例如，从公钥服务器的所有者本人处）获得的密钥证书进行比较。尽管密钥证书可以存储在具有任意数量签名的成熟数据库中，但由于成熟数据库不直接与公钥服务器通信，因此最好使用尽可能少的签名（最好仅使用一个签名：本身的签名）添加密钥证书。另见第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] [ ]
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.
密钥证书：格式为PGPKEY-HHHHHHHHH，其中HHHHHHHHHH代表PGP密钥的四个字节ID的十六进制表示形式。certif属性中详细说明的密钥证书属于id为hhhhhhhh的PGP密钥。使用PGPKEY-作为前缀的原因是允许以后使用其他类型的密钥证书，同时能够在查询时清楚地区分个人查询和密钥证书查询。在创建/修改密钥证书对象时，数据库软件会检查certif属性中的密钥证书是否确实属于此处指定的PGP id。只有在这两个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).
方法：包含签名方法名称的行。这是数字签名方法的名称。当前证书属于使用指定方法对消息进行数字签名的密钥。方法属性由数据库软件在创建密钥证书对象时自动生成。将忽略提交创建时对象中存在的任何方法属性。该方法必须与key cert属性中的id前缀以及certif属性中包含的证书一致。如果后两者（即前缀和证书）不一致，则拒绝密钥证书对象创建。对于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属性。拥有此属性（以及所有者属性）的原因是允许在查询数据库时轻松检查密钥证书。查询者获得所有者和指纹信息，而无需将证书添加到他/她自己的公钥环中。此外，由于这两个属性是由数据库软件从证书生成的，因此可以信任它们（就像信任数据库本身一样）。
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属性行（作为查询结果返回），并将其余部分导入本地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 by：通常的语法通常的语义此属性对于此对象是_强制性的。因此，mntner对象的存在是创建密钥证书对象的先决条件。mnt by属性中引用的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的情况下，当创建密钥证书对象时，关联的密钥也会添加到公钥的本地密钥环中。删除密钥证书对象时，相应的公钥也将从本地密钥环中删除。每当修改密钥证书对象时，都会从本地密钥环中删除密钥，并将与新证书相关联的密钥添加到密钥环中（显然，这仅在授权数据库更新时执行，特别是当新密钥证书确实属于属性密钥证书中指定的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公钥的四个字节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密钥用于检查发送给auto的任何创建/修改/删除消息的签名-dbm@ripe.net影响此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属性可以是多个。拥有两个具有不同方法的auth属性（例如PGPKEY-<id>和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-<id>值的auth方法，则语义是已知的，即接受_或_签名。
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 by属性，并且相应的mntner具有带有PGPKEY-<id>值的auth属性，则数据库软件将检查该对象是否具有与其关联的签名（即，正在处理的消息是否已签名）以及签名的类型（此实现阶段中的PGP）用于对消息进行签名的密钥的id与auth属性中的id相同。仅当此身份验证成功时，才会执行对象的创建/修改/删除。
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 u进行签名，而不是对更新消息进行签名，则需要采用不同的方法。如果要对对象进行签名，解析器必须识别哪些对象被签名，分别检查每个对象上的签名，并允许/拒绝对象级别的更新，这取决于（除其他外）签名是否有效以及它是否属于（其中一个）维护者。这种方法允许混合使用由不同维护人员签名的相同电子邮件对象（这可能不是典型的），还允许将签名存储在数据库中（以便在查询时验证签名）。后者（即将签名存储在数据库中）超出了实施第一阶段的范围。这可能在以后成为一个目标。
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软件版本没有任何限制。支持2.x版和5.0版的密钥，但建议使用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.
为创建密钥证书对象而提交的密钥证书必须包含密钥本身的签名。尽管证书也可能包含其他签名，但建议在证书中创建签名尽可能少的密钥证书对象。任何关心密钥可信度的人都应该从公钥服务器检索密钥证书的副本（或通过任何其他适当方式，并检查该证书中的签名。如果进行此类检查，应注意检查密钥指纹以及密钥类型和长度，以确保两个证书（从成熟数据库检索的密钥和从公钥服务器检索或通过其他方式收集的密钥）属于同一密钥。
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相同的密钥证书。如果后一个密钥已经使用了一段时间，并且已经在公钥服务器上注册了一段时间，则指定人员应联系成熟的NCC并向成熟的NCC报告-dbm@ripe.net. 无论如何，他/她可能必须创建一个新密钥并将其证书注册到成熟的数据库中。这种程序虽然不太可能发生，但不应给相应的维护人员造成严重问题。
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.
在成熟的数据库中，必须有一个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.
您必须获得自己密钥的证书，并从中准备密钥证书对象。对象必须由上述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对象更改为具有PGPKEY-<id>的auth:attribute值，其中<id>是PGP密钥的十六进制id。
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
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
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.
本提案是成熟的DBSEC工作组内部讨论的结果，该工作组在约阿希姆·施密茨（Joachim Schmitz）和威尔弗里德·沃伯（Wilfried Woeber）的倡议下于27日在都柏林成立。在不同地点（TF会议和通过电子邮件）参与讨论的参与者名单（按字母顺序排列）：森吉兹·阿莱蒂诺格鲁、若昂·路易斯·席尔瓦·达马斯、哈瓦德·艾恩斯、克里斯·弗莱彻、丹尼尔·卡伦伯格、大卫·凯森斯、杰克·库恩、克雷格·拉博维茨、卡尔·马拉默德、戴夫·迈耶、马尔德温·莫里斯、桑迪·墨菲、迈克·诺里斯、，卡罗尔·奥兰治、约阿希姆·施密茨、汤姆·斯平德勒、唐·斯蒂克沃特、柯蒂斯·维拉米扎、杰拉尔德·温特斯、威尔弗里德·沃伯、雅诺斯·扎科。
[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 27251999年12月。
Janos Zsako BankNet 1121 Budapest Konkoly-Thege ut 29-33. Hungary
雅诺斯·扎科银行网1121布达佩斯孔科利泰格大学，邮编29-33。匈牙利
Phone: +36 1 395 90 28
Fax: +36 1 395 90 32
EMail: zsako@banknet.net
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.
版权所有（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编辑功能的资金目前由互联网协会提供。