Internet Engineering Task Force (IETF) R. Kisteleki
Request for Comments: 7909 RIPE NCC
Updates: 2622, 4012 B. Haberman
Category: Standards Track JHU APL
ISSN: 2070-1721 June 2016
Internet Engineering Task Force (IETF) R. Kisteleki
Request for Comments: 7909 RIPE NCC
Updates: 2622, 4012 B. Haberman
Category: Standards Track JHU APL
ISSN: 2070-1721 June 2016
Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures
使用资源公钥基础结构（RPKI）签名保护路由策略规范语言（RPSL）对象
Abstract
摘要
This document describes a method that allows parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications of such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have authentication (based on Routing Policy System Security) of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. This document updates RFCs 2622 and 4012 to add the signature attribute to supported RPSL objects.
本文档描述了一种允许各方对路由策略规范语言对象进行电子签名并验证此类电子签名的方法。这允许依赖方检测此类对象的意外或恶意修改。它还允许运行Internet路由注册表或类似数据库但尚未对某些对象的维护者进行身份验证（基于路由策略系统安全性）的各方验证此类数据库对象的添加或修改是否由合法持有人完成这些对象中提到的Internet资源的名称。本文档更新了RFCs 2622和4012，以向支持的RPSL对象添加签名属性。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7909.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7909.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Signature Syntax and Semantics . . . . . . . . . . . . . . . 4
2.1. General Attributes and Meta Information . . . . . . . . . 4
2.2. Signed Attributes . . . . . . . . . . . . . . . . . . . . 5
2.3. Storage of the Signature Data . . . . . . . . . . . . . . 6
2.4. Number Resource Coverage . . . . . . . . . . . . . . . . 6
2.5. Validity Time of the Signature . . . . . . . . . . . . . 6
3. Signature Creation and Validation Steps . . . . . . . . . . . 6
3.1. Canonicalization . . . . . . . . . . . . . . . . . . . . 6
3.2. Signature Creation . . . . . . . . . . . . . . . . . . . 8
3.3. Signature Validation . . . . . . . . . . . . . . . . . . 9
4. Signed Object Types and Set of Signed Attributes . . . . . . 9
5. Keys and Certificates Used for Signature and Verification . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Signature Syntax and Semantics . . . . . . . . . . . . . . . 4
2.1. General Attributes and Meta Information . . . . . . . . . 4
2.2. Signed Attributes . . . . . . . . . . . . . . . . . . . . 5
2.3. Storage of the Signature Data . . . . . . . . . . . . . . 6
2.4. Number Resource Coverage . . . . . . . . . . . . . . . . 6
2.5. Validity Time of the Signature . . . . . . . . . . . . . 6
3. Signature Creation and Validation Steps . . . . . . . . . . . 6
3.1. Canonicalization . . . . . . . . . . . . . . . . . . . . 6
3.2. Signature Creation . . . . . . . . . . . . . . . . . . . 8
3.3. Signature Validation . . . . . . . . . . . . . . . . . . 9
4. Signed Object Types and Set of Signed Attributes . . . . . . 9
5. Keys and Certificates Used for Signature and Verification . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Objects stored in resource databases, like the RIPE DB, are generally protected by an authentication mechanism: anyone creating or modifying an object in the database has to have proper authorization to do so, and therefore has to go through an authentication procedure (provide a password, certificate, email signature, etc.). However, for objects transferred between resource databases, the authentication is not guaranteed. This means that when a Routing Policy Specification Language (RPSL) object is downloaded from a database, the consumer can reasonably claim that the object is authentic if it was locally created, but cannot make the same claim for an object imported from a different database. Also, once such an object is downloaded from the database, it becomes a simple (but still structured) text file with no integrity protection. More importantly, the authentication and integrity guarantees associated with these objects do not always ensure that the entity that generated them is authorized to make the assertions implied by the data contained in the objects.
存储在资源数据库中的对象（如数据库）通常受到身份验证机制的保护：任何在数据库中创建或修改对象的人都必须获得适当的授权才能这样做，因此必须经过身份验证过程（提供密码、证书、电子邮件签名等）。但是，对于在资源数据库之间传输的对象，不能保证身份验证。这意味着，当从数据库下载路由策略规范语言（RPSL）对象时，如果该对象是本地创建的，使用者可以合理地声明该对象是真实的，但不能对从其他数据库导入的对象做出相同的声明。此外，一旦从数据库下载了这样一个对象，它就会变成一个简单（但仍然是结构化的）文本文件，没有完整性保护。更重要的是，与这些对象相关联的身份验证和完整性保证并不总是确保生成它们的实体被授权进行对象中包含的数据所隐含的断言。
A potential use for resource certificates [RFC6487] is to use them to secure such (both imported and downloaded) database objects, by applying a digital signature over the object contents in lieu of methods such as Routing Policy System Security [RFC2725]. The signer of such signed database objects MUST possess a relevant resource certificate, which shows him/her as the legitimate holder of an Internet number resource. This mechanism allows the users of such database objects to verify that the contents are in fact produced by the legitimate holder(s) of the Internet resources mentioned in those objects. It also allows the signatures to cover whole RPSL objects, or just selected attributes of them. In other words, a digital signature created using the private key associated with a resource certificate can offer object security in addition to the channel security already present in most resource databases. Object security in turn allows such objects to be hosted in different databases and still be independently verifiable.
资源证书[RFC6487]的一个潜在用途是，通过在对象内容上应用数字签名来代替路由策略系统安全[RFC2725]等方法，使用它们来保护此类（导入和下载的）数据库对象。此类已签名数据库对象的签名者必须拥有相关的资源证书，该证书表明他/她是Internet号码资源的合法持有人。此机制允许此类数据库对象的用户验证这些内容实际上是由这些对象中提到的互联网资源的合法持有人生成的。它还允许签名覆盖整个RPSL对象，或仅覆盖它们的选定属性。换句话说，使用与资源证书相关联的私钥创建的数字签名可以提供对象安全性以及大多数资源数据库中已经存在的通道安全性。对象安全性反过来允许这些对象托管在不同的数据库中，并且仍然可以独立验证。
While the approach outlined in this document mandates the use of the Resource Public Key Infrastructure (RPKI) for certificate distribution, it is not dependent upon the RPKI for correct functionality. Equivalent functionality can be achieved with a more traditional Certification Authority (CA), using the extensions described in [RFC3779] within the certificates, and the appropriate trust anchor material to verify the digital signature.
虽然本文档中概述的方法强制使用资源公钥基础设施（RPKI）进行证书分发，但它并不依赖RPKI来实现正确的功能。使用更传统的证书颁发机构（CA），在证书中使用[RFC3779]中描述的扩展，并使用适当的信任锚材料来验证数字签名，可以实现等效功能。
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中大写的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
When signing an RPSL object [RFC2622] [RFC4012], the input for the signature process is transformed into a sequence of strings of ASCII data. The approach is similar to the one used in Domain Key Identified Mail (DKIM) [RFC6376]. In the case of RPSL, the object to be signed closely resembles an SMTP header, so it seems reasonable to adapt DKIM's relevant features.
对RPSL对象[RFC2622][RFC4012]进行签名时，签名过程的输入将转换为ASCII数据字符串序列。该方法类似于域密钥识别邮件（DKIM）[RFC6376]中使用的方法。在RPSL的情况下，要签名的对象非常类似于SMTP头，因此调整DKIM的相关特性似乎是合理的。
The digital signature associated with an RPSL object is itself a new attribute named "signature". It consists of mandatory and optional fields. These fields are structured in a sequence of name and value pairs, separated by a semicolon ";" and a whitespace. Collectively, these fields make up the value for the new "signature" attribute. The "name" part of such a component is always a single ASCII character that serves as an identifier; the value is an ASCII string the contents of which depend on the field type. Mandatory fields MUST appear exactly once, whereas optional fields MUST appear at most once.
与RPSL对象关联的数字签名本身就是一个名为“签名”的新属性。它由必填字段和可选字段组成。这些字段按名称和值对的顺序构造，由分号“；”和空格分隔。这些字段共同构成新“签名”属性的值。此类组件的“名称”部分始终是用作标识符的单个ASCII字符；该值是ASCII字符串，其内容取决于字段类型。必填字段必须只显示一次，而可选字段最多只能显示一次。
Mandatory fields of the "signature" attribute:
“签名”属性的必填字段：
o Version of the signature (field "v"): This field MUST be set to "rpkiv1" and MAY be the first field of the signature attribute to simplify the parsing of the attributes' fields. The signature format described in this document applies when the version field is set to "rpkiv1". All the rest of the signature attributes are defined by the value of the version field.
o 签名版本（字段“v”）：此字段必须设置为“rpkiv1”，并且可能是签名属性的第一个字段，以简化属性字段的解析。当版本字段设置为“rpkiv1”时，本文档中描述的签名格式适用。其余所有签名属性都由版本字段的值定义。
o Reference to the certificate corresponding to the private key used to sign this object (field "c"): The value of this field MUST be a URL of type "rsync" [RFC5781] or "http(s)" [RFC7230] that points to a specific resource certificate in an RPKI repository [RFC6481]. Any non URL-safe characters (including semicolon ";" and plus "+") must be URL encoded [RFC3986].
o 引用与用于签名此对象的私钥对应的证书（字段“c”）：此字段的值必须是类型为“rsync”[RFC5781]或“http（s）”[RFC7230]的URL，该URL指向RPKI存储库[RFC6481]中的特定资源证书。任何非URL安全字符（包括分号“；”和加号“+”）必须是URL编码的[RFC3986]。
o Signature method (field "m"): What hash and signature algorithms were used to create the signature. This specification follows the algorithms defined in RFC 6485 [RFC6485]. The algorithms are referenced within the signature attribute by the ASCII names of the algorithms.
o 签名方法（字段“m”）：创建签名时使用了哪些哈希和签名算法。本规范遵循RFC 6485[RFC6485]中定义的算法。算法在signature属性中由算法的ASCII名称引用。
o Time of signing (field "t"): The format of the value of this field MUST be in the Internet Date/Time ABNF format [RFC3339]. All times MUST be converted to Universal Coordinated Time (UTC), i.e., the ABNF time-offset is always "Z".
o 签名时间（字段“t”）：此字段的值格式必须为Internet日期/时间ABNF格式[RFC3339]。所有时间必须转换为世界协调时间（UTC），即ABNF时间偏移始终为“Z”。
o The signed attributes (field "a"): This is a list of attribute names, separated by an ASCII "+" character (if more than one attribute is enumerated). The list must include any attribute at most once.
o 签名属性（字段“a”）：这是属性名称的列表，由ASCII“+”字符分隔（如果枚举了多个属性）。列表最多只能包含一次任何属性。
o The signature itself (field "b"): This MUST be the last field in the list. The signature is the output of the signature algorithm using the appropriate private key and the calculated hash value of the object as inputs. The value of this field is the digital signature in base64 encoding (Section 4 of [RFC4648]).
o 签名本身（字段“b”）：这必须是列表中的最后一个字段。签名是签名算法的输出，使用适当的私钥和对象的计算哈希值作为输入。该字段的值是base64编码的数字签名（RFC4648的第4节）。
Optional fields of the "signature" attribute:
“签名”属性的可选字段：
o Signature expiration time (field "x"): The format of the value of this field MUST be in the Internet Date/Time format [RFC3339]. All times MUST be represented in UTC.
o 签名过期时间（字段“x”）：此字段的值格式必须为Internet日期/时间格式[RFC3339]。所有时间必须以UTC表示。
One can look at an RPSL object as an (ordered) set of attributes, each having a "key: value" syntax. Understanding this structure can help in developing more flexible methods for applying digital signatures.
可以将RPSL对象视为一组（有序的）属性，每个属性都有一个“key:value”语法。了解这种结构有助于开发更灵活的数字签名应用方法。
Some of these attributes are automatically added by the database, some are database-dependent, yet others do not carry operationally important information. This specification allows the maintainer of such an object to decide which attributes are important (signed) and which are not (not signed), from among all the attributes of the object; in other words, we define a way of including important attributes while excluding irrelevant ones. Allowing the maintainer of an object to select the attributes that are covered by the digital signature achieves the goals established in Section 1.
其中一些属性是由数据库自动添加的，一些属性依赖于数据库，而另一些属性则不包含操作上重要的信息。本规范允许此类对象的维护者从对象的所有属性中决定哪些属性是重要的（已签名的），哪些属性不是（未签名的）；换句话说，我们定义了一种包含重要属性而排除不相关属性的方法。允许对象的维护者选择数字签名所涵盖的属性可以实现第1节中确定的目标。
The type of the object determines the minimum set of attributes that MUST be signed. The signer MAY choose to sign additional attributes, in order to provide integrity protection for those attributes too.
对象的类型决定了必须签名的最小属性集。签名者可以选择对其他属性进行签名，以便为这些属性提供完整性保护。
When verifying the signature of an object, the verifier has to check whether the signature itself is valid, and whether all the specified attributes are referenced in the signature. If not, the verifier MUST reject the signature and treat the object as a regular, unsigned RPSL object.
验证对象的签名时，验证者必须检查签名本身是否有效，以及签名中是否引用了所有指定的属性。否则，验证器必须拒绝签名，并将该对象视为常规的、未签名的RPSL对象。
The result of applying the signature mechanism once is exactly one new attribute for the object. As an illustration, the structure of a signed RPSL object is as follows:
应用签名机制一次的结果正好是对象的一个新属性。作为说明，签名RPSL对象的结构如下所示：
attribute1: value1
attribute2: value2
attribute3: value3
...
signature: v=rpkiv1; c=rsync://.....; m=sha256WithRSAEncryption;
t=2014-12-31T23:59:60Z;
a=attribute1+attribute2+attribute3+...;
b=<base64 data>
attribute1: value1
attribute2: value2
attribute3: value3
...
signature: v=rpkiv1; c=rsync://.....; m=sha256WithRSAEncryption;
t=2014-12-31T23:59:60Z;
a=attribute1+attribute2+attribute3+...;
b=<base64 data>
Even if the signature over the object is valid according to the signature validation rules, it may not be relevant to the object; it also needs to cover the relevant Internet number resources mentioned in the object.
即使根据签名验证规则，对象上的签名有效，也可能与对象无关；它还需要涵盖对象中提到的相关互联网号码资源。
Therefore, the Internet number resources present in [RFC3779] extensions of the certificate referred to in the "c" field of the signature MUST cover the resources in the primary key of the object (e.g., value of the "aut-num:" attribute of an aut-num object, value of the "inetnum:" attribute of an inetnum object, values of "route:", and "origin:" attributes of a route object, etc.).
因此，签名的“c”字段中提到的证书的[RFC3779]扩展中存在的Internet号码资源必须覆盖对象主键中的资源（例如，aut num对象的“aut num:”属性的值、inetnum对象的“inetnum:”属性的值、“route:”和“origin:”的值：路由对象的属性等）。
The validity time interval of a signature is the intersection of the validity time of the certificate used to verify the signature, the "not before" time specified by the "t" field of the signature, and the optional "not after" time specified by the "x" field of the signature.
签名的有效时间间隔是用于验证签名的证书的有效时间、签名的“t”字段指定的“非之前”时间和签名的“x”字段指定的可选“非之后”时间的交点。
When checking multiple signatures, these checks are individually applied to each signature.
检查多个签名时，这些检查将分别应用于每个签名。
The notion of canonicalization is essential to digital signature generation and validation whenever data representations may change between a signer and one or more signature verifiers. Canonicalization defines how one transforms a representation of data
每当签名者和一个或多个签名验证者之间的数据表示可能发生变化时，规范化的概念对于数字签名的生成和验证至关重要。规范化定义了如何转换数据的表示形式
into a series of bits for signature generation and verification. The task of canonicalization is to make irrelevant differences in representations of the same object, which would otherwise cause signature verification to fail. Examples of this could be:
转换为一系列位，用于签名生成和验证。规范化的任务是在同一对象的表示中产生不相关的差异，否则将导致签名验证失败。例如：
o data transformations applied by the databases that host these objects (such as notational changes for IPv4/IPv6 prefixes, automatic addition/modification of "changed" attributes, etc.)
o 承载这些对象的数据库应用的数据转换（例如IPv4/IPv6前缀的符号更改、自动添加/修改“已更改”属性等）
o the difference of line terminators across different systems
o 不同系统中线路终端的差异
This means that the destination database might change parts of the submitted data after it was signed, which would cause signature verification to fail. This document specifies strict canonicalization rules to overcome this problem.
这意味着目标数据库在签名后可能会更改部分提交的数据，这将导致签名验证失败。本文档指定了克服此问题的严格规范化规则。
The following steps MUST be applied in order to achieve canonicalized representation of an object, before the actual signature (verification) process can begin:
在实际签名（验证）过程开始之前，必须应用以下步骤以实现对象的规范化表示：
1. Comments (anything beginning with a "#") MUST be omitted.
1. 注释（任何以“#”）开头的内容都必须省略。
2. Any trailing whitespace MUST be omitted.
2. 必须省略任何尾随空格。
3. A multi-line attribute MUST be converted into its single-line equivalent. This is accomplished by:
3. 多行属性必须转换为其单线等效属性。这是通过以下方式实现的：
* Converting all line endings to a single blank space (ASCII code 32).
* 将所有行尾转换为单个空格（ASCII代码32）。
* Concatenating all lines into a single line.
* 将所有行合并为一行。
* Replacing the trailing blank space with a single new line ("\n", ASCII code 10).
* 用一个新行（“\n”，ASCII代码10）替换尾随空格。
4. Numerical fields MUST be converted to canonical representations. These include:
4. 数值字段必须转换为规范表示。这些措施包括：
* Date and time fields MUST be converted to UTC and MUST be represented in the Internet Date/Time format [RFC3339].
* 日期和时间字段必须转换为UTC，并且必须以Internet日期/时间格式[RFC3339]表示。
* AS numbers MUST be converted to ASPLAIN syntax [RFC5396].
* AS数字必须转换为ASPLAIN语法[RFC5396]。
* IPv6 addresses MUST be canonicalized as defined in [RFC5952].
* IPv6地址必须按照[RFC5952]中的定义进行规范化。
* IPv4 addresses MUST be represented as the ipv4-address type defined by RPSL [RFC2622].
* IPv4地址必须表示为RPSL[RFC2622]定义的IPv4地址类型。
* All IP prefixes (IPv4 and IPv6) MUST be represented in Classless Inter-Domain Routing (CIDR) notation [RFC4632].
* 所有IP前缀（IPv4和IPv6）必须以无类域间路由（CIDR）表示法[RFC4632]表示。
5. All ranges, lists, or sets of numerical fields are represented using the appropriate RPSL attribute and each numerical element contained within those attributes MUST conform to the canonicalization rules in this document. The ordering of values within such fields MUST be maintained during database transfers.
5. 所有数值字段的范围、列表或集合都使用适当的RPSL属性表示，这些属性中包含的每个数值元素必须符合本文档中的规范化规则。在数据库传输期间，必须维护这些字段中值的顺序。
6. The name of each attribute MUST be converted into lower case, and MUST be kept as part of the attribute line.
6. 每个属性的名称必须转换为小写，并且必须作为属性行的一部分保留。
7. Tab characters ("\t", ASCII code 09) MUST be converted into spaces.
7. 制表符（“\t”，ASCII代码09）必须转换为空格。
8. Multiple whitespaces MUST be collapsed into a single space (" ", ASCII code 32) character.
8. 必须将多个空格折叠为单个空格（“，ASCII代码32）字符。
9. All line endings MUST be converted into a single new line ("\n", ASCII code 10) character, (thus avoiding CR vs. CRLF differences).
9. 所有行尾必须转换为单个新行（“\n”，ASCII代码10）字符（从而避免CR与CRLF的差异）。
Given an RPSL object and corresponding certificate, in order to create the digital signature, the following steps MUST be performed:
给定RPSL对象和相应的证书，为了创建数字签名，必须执行以下步骤：
1. Create a list of attribute names referring to the attributes that will be signed (contents of the "a" field). The minimum set of these attributes is determined by the object type; the signer MAY select additional attributes.
1. 创建一个属性名称列表，引用将被签名的属性（“a”字段的内容）。这些属性的最小集合由对象类型决定；签名者可以选择其他属性。
2. Arrange the selected attributes according to the selection sequence specified in the "a" field as above, omitting all attributes that will not be signed.
2. 按照上述“a”字段中指定的选择顺序排列所选属性，忽略所有不会签名的属性。
3. Construct the new "signature" attribute, with all its fields, leaving the value of the "b" field empty.
3. 构造新的“signature”属性及其所有字段，将“b”字段的值留空。
4. Apply canonicalization rules to the result (including the "signature" attribute).
4. 将规范化规则应用于结果（包括“签名”属性）。
5. Create the signature over the results of the canonicalization process (according to the signature and hash algorithms specified in the "m" field of the signature attribute).
5. 在规范化过程的结果上创建签名（根据签名属性的“m”字段中指定的签名和哈希算法）。
6. Insert the base64-encoded value of the signature as the value of the "b" field.
6. 插入签名的base64编码值作为“b”字段的值。
7. Append the resulting "signature" attribute to the original object.
7. 将生成的“签名”属性附加到原始对象。
In order to validate a signature over such an object, the following steps MUST be performed:
为了验证此类对象上的签名，必须执行以下步骤：
1. Verify the syntax of the "signature" attribute (i.e., whether it contains the mandatory and optional components and the syntax of these fields matches the specification as described in Section 2.1).
1. 验证“签名”属性的语法（即，它是否包含强制和可选组件，以及这些字段的语法是否符合第2.1节所述的规范）。
2. Fetch the certificate referred to in the "c" field of the "signature" attribute, and check its validity using the steps described in [RFC6487].
2. 获取“签名”属性的“c”字段中提到的证书，并使用[RFC6487]中描述的步骤检查其有效性。
3. Extract the list of attributes that were signed using the signer from the "a" field of the "signature" attribute.
3. 从“签名”属性的“a”字段中提取使用签名者签名的属性列表。
4. Verify that the list of signed attributes includes the minimum set of attributes for that object type.
4. 验证签名属性列表是否包含该对象类型的最小属性集。
5. Arrange the selected attributes according to the selection sequence provided in the value of the "a" field, omitting all unsigned attributes.
5. 根据“a”字段的值中提供的选择顺序排列所选属性，忽略所有未签名属性。
6. Replace the value of the signature field "b" of the "signature" attribute with an empty string.
6. 将“signature”属性的签名字段“b”的值替换为空字符串。
7. Apply the canonicalization procedure to the selected attributes (including the "signature" attribute).
7. 将规范化过程应用于所选属性（包括“签名”属性）。
8. Check the validity of the signature using the signature algorithm specified in the "m" field of the signature attribute, the public key contained in the certificate mentioned in the "c" field of the signature, the signature value specified in the "b" field of the signature attribute, and the output of the canonicalization process.
8. 使用签名属性的“m”字段中指定的签名算法、签名的“c”字段中提到的证书中包含的公钥、签名属性的“b”字段中指定的签名值以及规范化过程的输出来检查签名的有效性。
This section describes a list of object types that MAY be signed using this approach. For each object type, the set of attributes that MUST be signed for these object types (the minimum set noted in Section 3.3 is enumerated.
本节介绍可以使用此方法签名的对象类型列表。对于每种对象类型，必须为这些对象类型签名的属性集（列举第3.3节中提到的最小属性集）。
This list generally excludes attributes that are used to maintain referential integrity in the databases that carry these objects, since these usually make sense only within the context of such a database, whereas the scope of the signatures is only one specific object. Since the attributes in the referred object (such as mnt-by, admin-c, tech-c, etc.) can change without any modifications to the signed object, signing such attributes could lead to a false sense of security in terms of the contents of the signed data; therefore, including such attributes should only be done in order to provide full integrity protection of the object itself.
此列表通常不包括用于在承载这些对象的数据库中保持引用完整性的属性，因为这些属性通常仅在此类数据库的上下文中才有意义，而签名的范围仅为一个特定对象。由于引用对象中的属性（例如mnt by、admin-c、tech-c等）可以在不修改签名对象的情况下更改，因此签名这些属性可能导致签名数据内容方面的错误安全感；因此，包含这样的属性只能是为了提供对象本身的完整性保护。
The newly constructed "signature" attribute is always included in the list. The signature under construction MUST NOT include signature attributes that are already present in the object.
新构造的“签名”属性始终包含在列表中。构造中的签名不得包含对象中已存在的签名属性。
as-block:
as块：
* as-block
* as块
* signature
* 签名
aut-num:
aut num：
* aut-num * as-name * member-of * import * mp-import * export * mp-export * default * mp-default * signature
* aut num*作为名称*导入*mp导入*导出*mp导出*默认*mp默认*签名的成员
inet[6]num:
inet[6]数量：
* inet[6]num * netname * country * status * signature
* inet[6]编号*网络名*国家/地区*状态*签名
route[6]:
路线[6]：
* route[6] * origin * holes * member-of * signature
* 路线[6]*起点*孔*成员*签名
It should be noted that the approach defined in this document has a limitation in signing route[6] objects. This document only supports a single signature per object. This means that it is not possible to properly sign route[6] objects where one resource holder possesses the Autonomous System Number (ASN) and another resource holder possesses the referenced prefix. A future version of this specification may resolve this limitation.
应该注意的是，本文档中定义的方法在签署route[6]对象方面存在限制。此文档仅支持每个对象的单个签名。这意味着，如果一个资源持有者拥有自治系统编号（ASN），而另一个资源持有者拥有引用的前缀，则不可能对路由[6]对象进行正确签名。本规范的未来版本可能会解决此限制。
For each signature, the extension described in RFC 3779 that appears in the certificate used to verify the signature MUST include a resource entry that is equivalent to, or covers (i.e., is "less specific" than) the following resources mentioned in the object the signature is attached to:
对于每个签名，用于验证签名的证书中出现的RFC 3779中描述的扩展必须包括一个资源条目，该资源条目等同于或覆盖（即“不太具体”）签名所附对象中提到的以下资源：
o For the as-block object type: the resource in the "as-block" attribute.
o 对于as block对象类型：“as block”属性中的资源。
o For the aut-num object type: the resource in the "aut-num" attribute.
o 对于aut num对象类型：“aut num”属性中的资源。
o For the inet[6]num object type: the resource in the "inet[6]num" attribute.
o 对于inet[6]num对象类型：“inet[6]num”属性中的资源。
o For the route[6] object type: the resource in the "route[6]" or "origin" (or both) attributes.
o 对于route[6]对象类型：“route[6]”或“origin”（或两者）属性中的资源。
The certificate that is referred to in the signature (in the "c" field):
签名中提及的证书（在“c”字段中）：
o MUST be an end-entity (i.e., non-CA) certificate
o 必须是最终实体（即非CA）证书
o MUST conform to the X.509 PKIX Resource Certificate profile [RFC6487]
o 必须符合X.509 PKIX资源证书配置文件[RFC6487]
o MUST have the extension described in RFC 3779 that covers the Internet number resource included in a signed attribute [RFC3779]
o 必须具有RFC 3779中描述的扩展名，该扩展名包含在签名属性[RFC3779]中的Internet号码资源
The certificate generated will omit the Subject Information Access (SIA) extension mandated by RFC 6487 as that extension requires an rsync URI for the accessLocation form and RPSL currently does not support database access via rsync.
生成的证书将省略RFC 6487强制要求的主题信息访问（SIA）扩展，因为该扩展需要accessLocation表单的rsync URI，并且RPSL当前不支持通过rsync访问数据库。
RPSL objects stored in the Internet Routing Registry (IRR) databases are public, and as such there is no need for confidentiality. Each signed RPSL object can have its integrity and authenticity verified using the supplied digital signature and the referenced certificate.
存储在Internet路由注册表（IRR）数据库中的RPSL对象是公共的，因此不需要保密。每个已签名的RPSL对象都可以使用提供的数字签名和引用的证书来验证其完整性和真实性。
Since the RPSL signature approach leverages X.509 extensions, the security considerations in [RFC3779] apply here as well. Additionally, implementers MUST follow the certificate validation steps described in RFC 6487.
由于RPSL签名方法利用X.509扩展，[RFC3779]中的安全注意事项也适用于此处。此外，实现者必须遵循RFC 6487中描述的证书验证步骤。
The maintainer of an object has the ability to include attributes in the signature that are not included in the resource certificate used to create the signature. Potentially, a maintainer may include attributes that reference resources the maintainer is not authorized to use.
对象的维护者能够在签名中包含用于创建签名的资源证书中未包含的属性。维护人员可能会包含引用未经授权使用的资源的属性。
It should be noted that this digital signature does not preclude monkey-in-the-middle attacks where the adversary either intercepts RPSL object transfers, deletes the signature attribute, modifies the contents, or intercepts the transfer and drops the objects destined for the requester.
应该注意的是，该数字签名并不排除中间猴攻击，即对手拦截RPSL对象传输、删除签名属性、修改内容或拦截传输并丢弃发送给请求者的对象。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, DOI 10.17487/RFC2622, June 1999, <http://www.rfc-editor.org/info/rfc2622>.
[RFC2622]Alaettinoglu，C.，Villamizar，C.，Gerich，E.，Kessens，D.，Meyer，D.，Bates，T.，Karrenberg，D.，和M.Terpstra，“路由策略规范语言（RPSL）”，RFC 2622，DOI 10.17487/RFC2622，1999年6月<http://www.rfc-editor.org/info/rfc2622>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，DOI 10.17487/RFC3339，2002年7月<http://www.rfc-editor.org/info/rfc3339>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <http://www.rfc-editor.org/info/rfc3779>.
[RFC3779]Lynn，C.，Kent，S.，和K.Seo，“IP地址和AS标识符的X.509扩展”，RFC 3779，DOI 10.17487/RFC3779，2004年6月<http://www.rfc-editor.org/info/rfc3779>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005, <http://www.rfc-editor.org/info/rfc4012>.
[RFC4012]Blunk，L.，Damas，J.，Parent，F.，和A.Robachevsky，“下一代路由策略规范语言（RPSLng）”，RFC 4012，DOI 10.17487/RFC4012，2005年3月<http://www.rfc-editor.org/info/rfc4012>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <http://www.rfc-editor.org/info/rfc4632>.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，DOI 10.17487/RFC4632，2006年8月<http://www.rfc-editor.org/info/rfc4632>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of Autonomous System (AS) Numbers", RFC 5396, DOI 10.17487/RFC5396, December 2008, <http://www.rfc-editor.org/info/rfc5396>.
[RFC5396]Huston，G.和G.Michaelson，“自治系统（AS）编号的文本表示”，RFC 5396，DOI 10.17487/RFC5396，2008年12月<http://www.rfc-editor.org/info/rfc5396>.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, <http://www.rfc-editor.org/info/rfc5781>.
[RFC5781]Weiler，S.，Ward，D.，和R.Housley，“rsync URI方案”，RFC 5781，DOI 10.17487/RFC5781，2010年2月<http://www.rfc-editor.org/info/rfc5781>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 5952，DOI 10.17487/RFC5952，2010年8月<http://www.rfc-editor.org/info/rfc5952>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <http://www.rfc-editor.org/info/rfc6481>.
[RFC6481]Huston，G.，Loomans，R.，和G.Michaelson，“资源证书存储库结构的配置文件”，RFC 6481，DOI 10.17487/RFC6481，2012年2月<http://www.rfc-editor.org/info/rfc6481>.
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, DOI 10.17487/RFC6485, February 2012, <http://www.rfc-editor.org/info/rfc6485>.
[RFC6485]Huston，G.“用于资源公钥基础设施（RPKI）的算法和密钥大小的配置文件”，RFC 6485，DOI 10.17487/RFC6485，2012年2月<http://www.rfc-editor.org/info/rfc6485>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <http://www.rfc-editor.org/info/rfc6487>.
[RFC6487]Huston，G.，Michaelson，G.，和R.Loomans，“X.509 PKIX资源证书的配置文件”，RFC 6487，DOI 10.17487/RFC6487，2012年2月<http://www.rfc-editor.org/info/rfc6487>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, "Routing Policy System Security", RFC 2725, DOI 10.17487/RFC2725, December 1999, <http://www.rfc-editor.org/info/rfc2725>.
[RFC2725]Villamizar，C.，Alaettinoglu，C.，Meyer，D.，和S.Murphy，“路由策略系统安全”，RFC 2725，DOI 10.17487/RFC27252999年12月<http://www.rfc-editor.org/info/rfc2725>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <http://www.rfc-editor.org/info/rfc6376>.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 6376，DOI 10.17487/RFC6376，2011年9月<http://www.rfc-editor.org/info/rfc6376>.
Acknowledgements
致谢
The authors would like to acknowledge the valued contributions from Jos Boumans, Tom Harrison, Steve Kent, Sandra Murphy, Magnus Nystrom, Alvaro Retana, Sean Turner, Geoff Huston, and Stephen Farrell in preparation of this document.
作者感谢Jos Boumans、Tom Harrison、Steve Kent、Sandra Murphy、Magnus Nystrom、Alvaro Retana、Sean Turner、Geoff Huston和Stephen Farrell在编写本文件过程中做出的宝贵贡献。
Authors' Addresses
作者地址
Robert Kisteleki RIPE NCC
罗伯特·基斯特莱基
Email: robert@ripe.net
URI: http://www.ripe.net
Email: robert@ripe.net
URI: http://www.ripe.net
Brian Haberman Johns Hopkins University Applied Physics Lab
约翰霍普金斯大学应用物理实验室
Email: brian@innovationslab.net
Email: brian@innovationslab.net