[要約] RFC 7909は、ルーティングポリシー仕様言語（RPSL）オブジェクトをリソース公開鍵基盤（RPKI）の署名で保護するためのガイドラインです。目的は、RPSLオブジェクトの信頼性とセキュリティを向上させ、インターネットルーティングの安全性を確保することです。
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
Resource Public Key Infrastructure（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.
このドキュメントでは、当事者がルーティングポリシー仕様言語オブジェクトに電子的に署名し、そのような電子署名を検証できるようにする方法について説明します。これにより、依存パーティは、そのようなオブジェクトの偶発的または悪意のある変更を検出できます。また、インターネットルーティングレジストリまたは類似のデータベースを実行しているが、特定のオブジェクトのメンテナーの認証（ルーティングポリシーシステムセキュリティに基づく）をまだ持っていない当事者が、そのようなデータベースオブジェクトの追加または変更が正当なものによって行われたことを確認できます。これらのオブジェクトで言及されているインターネットリソースの所有者。このドキュメントでは、サポートされているRPSLオブジェクトに署名属性を追加するようにRFC 2622および4012を更新しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
RIPE DBのようなリソースデータベースに格納されているオブジェクトは、通常、認証メカニズムによって保護されています。データベース内のオブジェクトを作成または変更するユーザーは、適切な権限を持っている必要があるため、認証手順を実行する必要があります（パスワードを提供します） 、証明書、メール署名など）。ただし、リソースデータベース間で転送されるオブジェクトの場合、認証は保証されません。つまり、ルーティングポリシー仕様言語（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]などの方法の代わりにオブジェクトのコンテンツにデジタル署名を適用することにより、そのような（インポートとダウンロードの両方の）データベースオブジェクトを保護するために使用することです。このような署名されたデータベースオブジェクトの署名者は、インターネット番号リソースの正当な所有者であることを示す関連リソース証明書を所有している必要があります。このメカニズムにより、そのようなデータベースオブジェクトのユーザーは、コンテンツが実際にそれらのオブジェクトで言及されているインターネットリソースの正当な所有者によって作成されていることを確認できます。また、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.
このドキュメントで概説されているアプローチでは、証明書の配布にResource Public Key Infrastructure（RPKI）を使用することが義務付けられていますが、正しい機能はRPKIに依存していません。同等の機能は、証明書内の[RFC3779]で説明されている拡張機能と、デジタル署名を検証するための適切なトラストアンカー資料を使用して、より伝統的な認証局（CA）で実現できます。
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].
このドキュメントの大文字のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」 [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文字列で、その内容はフィールドタイプによって異なります。必須フィールドは正確に1回出現する必要がありますが、オプションフィールドは最大1回出現する必要があります。
Mandatory fields of the "signature" attribute:
「signature」属性の必須フィールド：
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でなければなりません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]で定義されたアルゴリズムに従います。アルゴリズムは、アルゴリズムの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"）：このフィールドの値の形式は、インターネット日付/時刻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 "+"文字で区切られた属性名のリストです（複数の属性が列挙されている場合）。リストには属性を最大で1つ含める必要があります。
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:
「signature」属性のオプションのフィールド：
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"）：このフィールドの値の形式は、インターネット日付/時刻形式[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:
署名メカニズムを1回適用した結果は、オブジェクトの1つの新しい属性になります。例として、署名付き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>
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]拡張に存在するインターネット番号リソースは、オブジェクトの主キーのリソースをカバーする必要があります（たとえば、「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」フィールドで指定された「not before」時間、およびオプションで指定された「not after」時間の交差部分です。署名の「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:
正規化の概念は、署名者と1つ以上の署名検証者の間でデータ表現が変更される可能性がある場合は常に、デジタル署名の生成と検証に不可欠です。正規化は、データの表現を署名の生成と検証のために一連のビットに変換する方法を定義します。正規化のタスクは、同じオブジェクトの表現に無関係な違いを作ることです。そうしないと、署名の検証が失敗します。この例は次のとおりです。
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.
* すべての行を1行に連結します。
* Replacing the trailing blank space with a single new line ("\n", ASCII code 10).
* 末尾の空白スペースを1つの新しい行に置き換えます（ "\ 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に変換する必要があり、インターネットの日付/時刻形式[RFC3339]で表す必要があります。
* AS numbers MUST be converted to ASPLAIN syntax [RFC5396].
* AS番号はASPLAIN構文[RFC5396]に変換する必要があります。
* IPv6 addresses MUST be canonicalized as defined in [RFC5952].
* [RFC5952]で定義されているように、IPv6アドレスを正規化する必要があります。
* IPv4 addresses MUST be represented as the ipv4-address type defined by RPSL [RFC2622].
* IPv4アドレスは、RPSL [RFC2622]で定義されているipv4-addressタイプとして表現する必要があります。
* 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」フィールドの内容）を参照する属性名のリストを作成します。これらの属性の最小セットは、オブジェクトタイプによって決定されます。署名者は追加の属性を選択してもよい（MAY）。
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. 結果に正規化ルールを適用します（「signature」属性を含む）。
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. 「b」フィールドの値として、署名のbase64エンコード値を挿入します。
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. 「signature」属性の構文を確認します（つまり、必須およびオプションのコンポーネントを含み、これらのフィールドの構文がセクション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. 「signature」属性の「c」フィールドで参照される証明書を取得し、[RFC6487]で説明されている手順を使用して、その有効性を確認します。
3. Extract the list of attributes that were signed using the signer from the "a" field of the "signature" attribute.
3. 「signature」属性の「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.
これらのオブジェクトは、これらのオブジェクトを運ぶデータベースで参照整合性を維持するために使用される属性は通常除外されます。これらの属性は通常、そのようなデータベースのコンテキスト内でのみ意味があるのに対し、署名のスコープは特定の1つのオブジェクトのみです。参照されるオブジェクト（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.
新しく作成された「署名」属性は常にリストに含まれます。作成中の署名には、オブジェクトにすでに存在する署名属性を含めてはなりません（MUST NOT）。
as-block:
as-block：
* as-block
* ブロックとして
* signature
* 署名
aut-num:
またはnum;
* aut-num * as-name * member-of * import * mp-import * export * mp-export * default * mp-default * signature
* aut-num * as-name * member-of * import * mp-import * export * mp-export * default * mp-default * signature
inet[6]num:
inst [6]かどうか：
* inet[6]num * netname * country * status * signature route[6]:
* inet [6] num * netname *国*ステータス*署名ルート[6]：
* route[6] * origin * holes * member-of * signature
* route [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]オブジェクトへの署名に制限があることに注意してください。このドキュメントでは、オブジェクトごとに1つの署名のみがサポートされています。つまり、あるリソースホルダーが自律システム番号（ASN）を所有し、別のリソースホルダーが参照されたプレフィックスを所有する場合、route [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]
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.
インターネットルーティングレジストリ（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.、and M. Terpstra、 "Routing Policy Specification Language（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、「X.509 Extensions for IP Addresses and AS Identifiers」、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、「Uniform Resource Identifier（URI）：Generic Syntax」、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、「Routing Policy Specification Language next generation（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、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、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。、「The 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、「The rsync URI Scheme」、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. 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> 。
[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。、「Resource Public Key Infrastructure（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]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、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 / RFC2725、1999年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。、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>。
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
ロバートキステレキRIPE NCC
Email: robert@ripe.net
URI: http://www.ripe.net
Brian Haberman Johns Hopkins University Applied Physics Lab
ブライアンハーバーマンジョンズホプキンス大学応用物理学研究所
Email: brian@innovationslab.net