[要約] RFC 9323 は、RPKI Signed Checklists (RSCs) のためのCMS保護コンテンツタイプを定義し、インターネットリソース保持者が特定のインターネット番号リソースで署名されたファイルのチェックサムを含む「RPKI Signed Checklist (RSC)」を作成することを目的としています。
Internet Engineering Task Force (IETF) J. Snijders
Request for Comments: 9323 Fastly
Category: Standards Track T. Harrison
ISSN: 2070-1721 APNIC
B. Maddison
Workonline
November 2022
A Profile for RPKI Signed Checklists (RSCs)
RPKI署名されたチェックリスト（RSC）のプロファイル
Abstract
概要
This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry a general-purpose listing of checksums (a 'checklist'). The objective is to allow for the creation of an attestation, termed an "RPKI Signed Checklist (RSC)", which contains one or more checksums of arbitrary digital objects (files) that are signed with a specific set of Internet Number Resources. When validated, an RSC confirms that the respective Internet resource holder produced the RSC.
このドキュメントでは、リソース公開キーインフラストラクチャ（RPKI）で使用するための暗号化メッセージの構文（CMS）保護されたコンテンツタイプを定義して、チェックサム（「チェックリスト」）の汎用リストを掲載します。目的は、「RPKI署名チェックリスト（RSC）」と呼ばれる証明の作成を可能にすることです。これには、特定のインターネット番号リソースのセットで署名された任意のデジタルオブジェクト（ファイル）の1つ以上のチェックサムが含まれています。検証された場合、RSCは、それぞれのインターネットリソースホルダーがRSCを生産したことを確認します。
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 https://www.rfc-editor.org/info/rfc9323.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9323で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. RSC Profile and Distribution
2.1. RSC EE Certificates
3. The RSC eContentType
4. The RSC eContent
4.1. Version
4.2. Resources
4.2.1. ConstrainedASIdentifiers Type
4.2.2. ConstrainedIPAddrBlocks Type
4.3. digestAlgorithm
4.4. checkList
4.4.1. FileNameAndHash
5. RSC Validation
6. Verifying Files or Data Using RSC
7. Operational Considerations
8. Security Considerations
9. IANA Considerations
9.1. SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1)
9.2. RPKI Signed Objects
9.3. RPKI Repository Name Schemes
9.4. SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0)
9.5. Media Types
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses
This document defines a Cryptographic Message Syntax (CMS) [RFC5652] [RFC6268] protected content type for a general-purpose listing of checksums (a 'checklist'), for use with the Resource Public Key Infrastructure (RPKI) [RFC6480]. The CMS protected content type is intended to provide for the creation and validation of an RPKI Signed Checklist (RSC), a checksum listing signed with a specific set of Internet Number Resources. The objective is to allow for the creation of an attestation that, when validated, provides a means to confirm a given Internet resource holder produced the RSC.
このドキュメントでは、リソース公開キーインフラストラクチャ（RPKI）[RFC6480]で使用するために、チェックサムの汎用リスト（「チェックリスト」）のコンテンツタイプの保護されたコンテンツタイプの暗号化メッセージの構文（CMS）[RFC5652] [RFC6268]を定義します。CMS保護されたコンテンツタイプは、特定のインターネット番号リソースのセットで署名されたチェックサムリストであるRPKI署名チェックリスト（RSC）の作成と検証を提供することを目的としています。目的は、検証されたときに、特定のインターネットリソースホルダーがRSCを生成したことを確認する手段を提供することを認めることを可能にすることです。
RPKI Signed Checklists are expected to facilitate inter-domain business use cases that depend on an ability to verify resource holdership. RPKI-based validation processes are expected to become the industry norm for automated Bring Your Own IP (BYOIP) on-boarding or establishment of physical interconnections between Autonomous Systems (ASes).
RPKI署名されたチェックリストは、リソース保有を検証する能力に依存するドメイン間のビジネスユースケースを促進することが期待されています。RPKIベースの検証プロセスは、自動システム（ASES）間の物理的相互接続のオンボーディングまたは確立または確立を自動化するための業界規範になると予想されます。
The RSC concept borrows heavily from Resource Tagged Attestation (RTA) [RPKI-RTA], Manifests [RFC9286], and OpenBSD's signify utility [signify]. The main difference between an RSC and RTA is that the RTA profile allows multiple signers to attest a single digital object through a checksum of its content, while the RSC profile allows a single signer to attest the content of multiple digital objects. A single signer profile is considered a simplification for both implementers and operators.
RSCコンセプトは、リソースタグ付きの認証（RTA）[RPKI-RTA]、マニフェスト[RFC9286]、およびOpenBSDの主なユーティリティ[Signify]から大きく借用しています。RSCとRTAの主な違いは、RTAプロファイルにより、複数の署名者がコンテンツのチェックサムを介して単一のデジタルオブジェクトを証明できるようにすることです。一方、RSCプロファイルは、単一の署名者が複数のデジタルオブジェクトのコンテンツを証明できるようにすることです。単一の署名者プロファイルは、実装者とオペレーターの両方の単純化と見なされます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
RSC follows the Signed Object Template for the RPKI [RFC6488] with one exception: because RSCs MUST NOT be distributed through the global RPKI repository system, the Subject Information Access (SIA) extension MUST be omitted from the RSC's X.509 End-Entity (EE) certificate.
RSCは、1つの例外を除いて、RPKI [RFC6488]の署名されたオブジェクトテンプレートに従います。RSCはグローバルRPKIリポジトリシステムを介して分散する必要はないため、サブジェクト情報アクセス（SIA）拡張はRSCのX.509エンドエンティティ（EE）証明書。
What constitutes suitable transport for RSC files is deliberately unspecified. For example, it might be a USB stick, a web interface secured with HTTPS, an email signed with Pretty Good Privacy (PGP), a T-shirt printed with a QR code, or a carrier pigeon.
RSCファイルに適したトランスポートを構成するものは、意図的に特定されていません。たとえば、それはUSBスティック、HTTPSで固定されたWebインターフェイス、かなり良いプライバシー（PGP）で署名された電子メール、QRコードで印刷されたTシャツ、またはキャリアピジョンなどです。
The Certification Authority (CA) MUST only sign one RSC with each EE certificate and MUST generate a new key pair for each new RSC. This type of EE certificate is termed a "one-time-use" EE certificate (see Section 3 of [RFC6487]).
認証機関（CA）は、各EE証明書で1つのRSCのみに署名する必要があり、新しいRSCごとに新しいキーペアを生成する必要があります。このタイプのEE証明書は、「1回限りの使用」EE証明書と呼ばれます（[RFC6487]のセクション3を参照）。
The eContentType for an RSC is defined as id-ct-signedChecklist, with Object Identifier (OID) 1.2.840.113549.1.9.16.1.48.
RSCのecontentTypeは、Object Identifier（OID）1.2.840.113549.1.9.16.1.48を使用して、ID-CT-SignedCheckListとして定義されます。
This OID MUST appear within both the eContentType in the encapContentInfo object and the ContentType signed attribute in the signerInfo object (see [RFC6488]).
このoidは、encapcontentinfoオブジェクトのecontentTypeと、SignerInfoオブジェクトのcontentType signed属性の両方に表示する必要があります（[rfc6488]を参照）。
The content of an RSC indicates that a checklist for arbitrary digital objects has been signed with a specific set of Internet Number Resources. An RSC is formally defined as follows:
RSCのコンテンツは、任意のデジタルオブジェクトのチェックリストが特定のインターネット番号リソースセットで署名されていることを示しています。RSCは、次のように正式に定義されています。
RpkiSignedChecklist-2022
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) mod(0)
id-mod-rpkiSignedChecklist-2022(73) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
CONTENT-TYPE, Digest, DigestAlgorithmIdentifier
FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
IPAddressOrRange, ASIdOrRange
FROM IPAddrAndASCertExtn -- in [RFC3779]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident(30) } ;
ct-rpkiSignedChecklist CONTENT-TYPE ::=
{ TYPE RpkiSignedChecklist
IDENTIFIED BY id-ct-signedChecklist }
id-ct-signedChecklist OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) id-smime(16) id-ct(1) 48 }
RpkiSignedChecklist ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
resources ResourceBlock,
digestAlgorithm DigestAlgorithmIdentifier,
checkList SEQUENCE (SIZE(1..MAX)) OF FileNameAndHash }
FileNameAndHash ::= SEQUENCE {
fileName PortableFilename OPTIONAL,
hash Digest }
PortableFilename ::=
IA5String (FROM("a".."z" | "A".."Z" | "0".."9" | "." | "_" | "-"))
ResourceBlock ::= SEQUENCE {
asID [0] ConstrainedASIdentifiers OPTIONAL,
ipAddrBlocks [1] ConstrainedIPAddrBlocks OPTIONAL }
-- at least one of asID or ipAddrBlocks MUST be present
( WITH COMPONENTS { ..., asID PRESENT} |
WITH COMPONENTS { ..., ipAddrBlocks PRESENT } )
ConstrainedIPAddrBlocks ::=
SEQUENCE (SIZE(1..MAX)) OF ConstrainedIPAddressFamily
ConstrainedIPAddressFamily ::= SEQUENCE {
addressFamily OCTET STRING (SIZE(2)),
addressesOrRanges SEQUENCE (SIZE(1..MAX)) OF IPAddressOrRange }
ConstrainedASIdentifiers ::= SEQUENCE {
asnum [0] SEQUENCE (SIZE(1..MAX)) OF ASIdOrRange }
END
終わり
The version number of the RpkiSignedChecklist MUST be 0.
rpkisignedchecklistのバージョン番号は0でなければなりません。
The resources contained here are the resources used to mark the attestation and MUST be a subset of the set of resources listed by the EE certificate carried in the CMS certificates field.
ここに含まれるリソースは、認証をマークするために使用されるリソースであり、CMS証明書フィールドに掲載されたEE証明書によってリストされているリソースのセットのサブセットでなければなりません。
If the asID field is present, it MUST contain an instance of ConstrainedASIdentifiers.
ASIDフィールドが存在する場合、制約されている範囲内のインスタンスを含める必要があります。
If the ipAddrBlocks field is present, it MUST contain an instance of ConstrainedIPAddrBlocks.
iPaddrblocksフィールドが存在している場合、Constaredipaddrblocksのインスタンスを含める必要があります。
At least one of asID or ipAddrBlocks MUST be present.
ASIDまたはiPaddrblocksの少なくとも1つが存在する必要があります。
ConstrainedASIdentifiers and ConstrainedIPAddrBlocks are specified such that the resulting DER-encoded data instances are binary compatible with ASIdentifiers and IPAddrBlocks (defined in [RFC3779]), respectively.
制約済みのIndidifiersおよび制約済みのddrblocksは、結果のderエンコードされたデータインスタンスが、それぞれ[RFC3779]で定義されている）と互換性のあるバイナリと互換性があるように指定されています。
Implementations encountering decoding errors whilst attempting to read DER-encoded data using this specification should be aware of the possibility that the data may have been encoded using an implementation intended for use with [RFC3779]. Such data may contain elements prohibited by the current specification.
この仕様を使用してDERエンコードされたデータを読み取ろうとする際にデコードエラーに遭遇する実装は、[RFC3779]で使用することを目的とした実装を使用してデータがエンコードされている可能性があることを認識する必要があります。このようなデータには、現在の仕様によって禁止されている要素が含まれる場合があります。
Attempting to decode the errored data using the more permissive specification contained in [RFC3779] may enable implementors to gather additional context for use when reporting errors to the user.
[RFC3779]に含まれるより寛容な仕様を使用してエラーデータをデコードしようとすると、ユーザーにエラーを報告する際に使用するために追加のコンテキストを収集できるようになります。
However, implementations MUST NOT ignore errors resulting from the more restrictive definitions contained herein; in particular, such errors MUST cause the validation procedure described in Section 5 to fail.
ただし、実装は、ここに含まれるより制限的な定義に起因するエラーを無視してはなりません。特に、このようなエラーは、セクション5で説明されている検証手順を失敗させる必要があります。
ConstrainedASIdentifiers is a SEQUENCE consisting of a single field, asnum, which in turn contains a SEQUENCE OF one or more ASIdOrRange instances as defined in [RFC3779].
Constradedasidedidentifiersは、[RFC3779]で定義されているように、1つ以上のアシダランジインスタンスのシーケンスを含む単一のフィールドAsnumで構成されるシーケンスです。
ConstrainedASIdentifiers is defined such that the resulting DER-encoded data are binary compatible with ASIdentifiers defined in [RFC3779].
constradedasidasidentifiersは、結果のderエンコードデータが[rfc3779]で定義されたasidentifiersと互換性があるように定義されます。
ConstrainedIPAddrBlocks is a SEQUENCE OF one or more instances of ConstrainedIPAddressFamily.
Constaredipaddrblocksは、ConstaredipAddressfamilyの1つ以上のインスタンスのシーケンスです。
There MUST be only one instance of ConstrainedIPAddressFamily per unique Address Family Identifier (AFI).
一意のアドレスファミリ識別子（AFI）ごとに、制約中paddressfamilyのインスタンスが1つだけ存在する必要があります。
The elements of ConstrainedIPAddressFamily MUST be ordered by ascending addressFamily values (treating the octets as unsigned numbers). Thus, when both IPv4 and IPv6 addresses are specified, the IPv4 addresses MUST precede the IPv6 addresses (since the IPv4 AFI of 0001 is less than the IPv6 AFI of 0002).
ConstradedipAddressfamilyの要素は、昇順の住所ファミリー値（オクテットを符号なしの数字として扱う）によって順序付けられる必要があります。したがって、IPv4アドレスとIPv6アドレスの両方が指定されている場合、IPv4アドレスはIPv6アドレスの前になければなりません（0001のIPv4 AFIは0002のIPv6 AFIよりも少ないため）。
ConstrainedIPAddrBlocks is defined such that the resulting DER-encoded data are binary compatible with IPAddrBlocks defined in [RFC3779].
constreadedipaddrblocksは、結果のderエンコードデータが[rfc3779]で定義されたiPaddrblocksと互換性があるように定義されています。
The addressFamily field is an OCTET STRING containing a 2-octet AFI, in network byte order. Unlike IPAddrBlocks [RFC3779], a third octet containing a Subsequent Address Family Identifier (SAFI) MUST NOT be present. AFIs are specified in the "Address Family Numbers" registry [IANA.ADDRESS-FAMILY-NUMBERS] maintained by IANA.
アドレスファミリーフィールドは、ネットワークバイトの順序で2-OCTET AFIを含むオクテット文字列です。iPaddrblocks [RFC3779]とは異なり、後続のアドレスファミリ識別子（SAFI）を含む3番目のオクテットが存在してはなりません。AFIは、IANAによって維持されている「Family番号」レジストリ[IANA.Address-Family-Numbers]で指定されています。
The addressesOrRanges element is a SEQUENCE OF one or more IPAddressOrRange values, as defined in [RFC3779]. The rules for canonicalization and encoding defined in Section 2.2.3.6 of [RFC3779] apply to the value of addressesOrRanges.
AddressOranges要素は、[RFC3779]で定義されているように、1つ以上のiPaddressorrange値のシーケンスです。[RFC3779]のセクション2.2.3.6で定義されている標準化とエンコーディングの規則は、AddressOrrangesの値に適用されます。
The digest algorithm is used to create the message digest of the attested digital object(s). This algorithm MUST be a hashing algorithm defined in [RFC7935].
ダイジェストアルゴリズムは、証明されたデジタルオブジェクトのメッセージダイジェストを作成するために使用されます。このアルゴリズムは、[RFC7935]で定義されたハッシュアルゴリズムでなければなりません。
This field is a SEQUENCE OF one or more FileNameAndHash values. There is one FileNameAndHash entry for each digital object referenced on the RSC.
このフィールドは、1つまたは複数のFilenameandHash値のシーケンスです。RSCで参照されている各デジタルオブジェクトには、1つのFilenAMENDHASHエントリがあります。
Each FileNameAndHash is an ordered pair of the name of the directory entry containing the digital object and the message digest of the digital object.
各filenameandhashは、デジタルオブジェクトとデジタルオブジェクトのメッセージダイジェストを含むディレクトリエントリの名前の順序付けられたペアです。
The hash field is mandatory. The value of the hash field is the calculated message digest of the digital object. The hashing algorithm is specified in the digestAlgorithm field.
ハッシュフィールドは必須です。ハッシュフィールドの値は、デジタルオブジェクトの計算されたメッセージダイジェストです。ハッシュアルゴリズムは、消化器gorthmフィールドで指定されています。
The fileName field is OPTIONAL. This is to allow RSCs to be used in a "stand-alone" fashion in which nameless digital objects are addressed directly through their respective message digest rather than through a file system abstraction.
ファイル名フィールドはオプションです。これは、RSCをファイルシステムの抽象化ではなく、それぞれのメッセージダイジェストを介して直接扱われる「スタンドアロン」の方法で使用できるようにするためです。
If the fileName field is present, then its value:
ファイル名フィールドが存在する場合、その値：
* MUST contain only characters specified in the Portable Filename Character Set as defined in [POSIX].
* [POSIX]で定義されているように、ポータブルファイル名セットで指定された文字のみを含める必要があります。
* MUST be unique with respect to the other FileNameAndHash elements of checkList for which the fileName field is also present.
* Filenameフィールドが存在するチェックリストの他のFilenAmeandHash要素に関しては、ユニークでなければなりません。
Conversely, if the fileName field is omitted, then the value of the hash field MUST be unique with respect to the other FileNameAndHash elements of checkList for which the fileName field is also omitted.
逆に、ファイル名フィールドが省略されている場合、ハッシュフィールドの値は、ファイル名フィールドも省略されているチェックリストの他のfilenameandhash要素に関して一意でなければなりません。
Before a Relying Party (RP) can use an RSC to validate a set of digital objects, the RP MUST first validate the RSC. To validate an RSC, the RP MUST perform all the validation checks specified in [RFC6488], except for checking for the presence of an SIA extension, which MUST NOT be present in the EE certificate (see Section 2). In addition, the RP MUST perform the following RSC-specific validation steps:
依存関係者（RP）がRSCを使用してデジタルオブジェクトのセットを検証する前に、RPは最初にRSCを検証する必要があります。RSCを検証するには、RPは[RFC6488]で指定されたすべての検証チェックを実行する必要があります。ただし、EE証明書に存在してはなりません（セクション2を参照）。さらに、RPは次のRSC固有の検証手順を実行する必要があります。
1. The contents of the CMS eContent field MUST conform to all of the constraints described in Section 4, including the constraints described in Section 4.4.1.
1. CMSエコネントフィールドの内容は、セクション4.4.1で説明されている制約を含め、セクション4で説明されているすべての制約に準拠する必要があります。
2. If the asID field is present within the contents of the resources field, then the AS identifier delegation extension [RFC3779] MUST be present in the EE certificate contained in the CMS certificates field. The AS identifiers present in the eContent resources field MUST be a subset of those present in the certificate extension. The EE certificate's AS identifier delegation extension MUST NOT contain "inherit" elements.
2. ASIDフィールドがリソースフィールドの内容内に存在する場合、As Identifier Delegation Extension [RFC3779]がCMS証明書フィールドに含まれるEE証明書に存在する必要があります。Econtent Resourcesフィールドに存在するAS識別子は、証明書拡張に存在するもののサブセットでなければなりません。EE証明書As Identifier Delegation Extensionは、「継承」要素を含めてはなりません。
3. If the ipAddrBlocks field is present within the contents of the resources field, then the IP address delegation extension [RFC3779] MUST be present in the EE certificate contained in the CMS certificates field. The IP addresses present in the eContent resources field MUST be a subset of those present in the certificate extension. The EE certificate's IP address delegation extension MUST NOT contain "inherit" elements.
3. iPaddrblocksフィールドがリソースフィールドの内容内に存在する場合、IPアドレス委任拡張[RFC3779]は、CMS証明書フィールドに含まれるEE証明書に存在する必要があります。Econtent Resourcesフィールドに存在するIPアドレスは、証明書延長に存在するもののサブセットでなければなりません。EE証明書のIPアドレス委任拡張機能には、「継承」要素が含まれてはなりません。
To verify a set of digital objects with an RSC:
RSCでデジタルオブジェクトのセットを確認するには：
* The RSC MUST be validated according to the procedure described in Section 5. If the RSC cannot be validated, verification MUST fail. This error SHOULD be reported to the user.
* RSCは、セクション5で説明されている手順に従って検証する必要があります。RSCを検証できない場合、検証が失敗する必要があります。このエラーはユーザーに報告する必要があります。
* For every digital object to be verified:
* すべてのデジタルオブジェクトが検証されるために：
1. If the verification procedure is provided with a filename for the object being verified (e.g., because the user has provided a file system path from which to read the object), then verification SHOULD proceed in "filename-aware" mode. Otherwise, verification SHOULD proceed in "filename-unaware" mode.
1. 検証手順に、検証されているオブジェクトのファイル名が提供されている場合（たとえば、ユーザーがオブジェクトを読み取るためのファイルシステムパスを提供しているため）、検証は「Filename-Aware」モードで進行する必要があります。それ以外の場合、検証は「filename-unaware」モードで続行する必要があります。
Implementations MAY provide an option to override the verification mode, for example, to ignore the fact that the object is to be read from a file.
実装は、たとえば、オブジェクトがファイルから読み取られるという事実を無視するために、検証モードをオーバーライドするオプションを提供する場合があります。
2. The message digest MUST be computed from the file contents or data using the digest algorithm specified in the digestAlgorithm field of the RSC.
2. Message Digestは、RSCのDigestalgorithmフィールドで指定されたDigestアルゴリズムを使用して、ファイルの内容またはデータから計算する必要があります。
3. The digest computed in Step 2 MUST be compared to the value appearing in the hash field of all FileNameAndHash elements of the checkList field of the RSC.
3. ステップ2で計算されたダイジェストは、RSCのチェックリストフィールドのすべてのfilenameandhash要素のハッシュフィールドに表示される値と比較する必要があります。
One or more FileNameAndHash elements MUST be found with a matching hash value; otherwise, verification MUST fail, and the error SHOULD be reported to the user.
一致するハッシュ値で1つ以上のFilenAmeandHash要素を見つける必要があります。それ以外の場合、検証が失敗する必要があり、エラーをユーザーに報告する必要があります。
4. If the mode selected in Step 1 is "filename-aware", then exactly one of the FileNameAndHash elements matched in Step 3 MUST contain a fileName field value exactly matching the filename of the object being verified.
4. ステップ1で選択されたモードが「Filename-Aware」である場合、ステップ3で一致するFilenAmeandHash要素の1つが、検証されているオブジェクトのファイル名と正確に一致するファイル名フィールド値を含める必要があります。
Alternatively, if the mode selected in Step 1 is "filename-unaware", then exactly one of the FileNameAndHash elements matched in Step 3 MUST have the fileName field omitted.
あるいは、ステップ1で選択されたモードが「Filename-Unaware」である場合、ステップ3で一致するFilenAmeandhash要素の1つがFilenameフィールドを省略する必要があります。
Otherwise, verification MUST fail, and the error SHOULD be reported to the user.
それ以外の場合、検証が失敗する必要があり、エラーをユーザーに報告する必要があります。
Note that in the above procedure, not all elements of checkList necessarily need be used. That is, it is not an error if the length of checkList is greater than the size of the set of digital objects to be verified. However, in this situation, implementations SHOULD issue a warning to the user, allowing for corrective action to be taken if necessary.
上記の手順では、チェックリストのすべての要素を必ずしも使用する必要はないことに注意してください。つまり、チェックリストの長さが検証するデジタルオブジェクトのセットのサイズよりも大きい場合、エラーではありません。ただし、この状況では、実装はユーザーに警告を発行し、必要に応じて是正措置を講じることができます。
When creating digital objects of a plain-text nature (such as ASCII, UTF-8, HTML, Javascript, and XML), converting such objects into a lossless compressed form is RECOMMENDED. Distributing plain-text objects within a compression envelope (such as GZIP [RFC1952]) might help avoid unexpected canonicalization at intermediate systems (which in turn would lead to checksum verification errors). Validator implementations are expected to treat a checksummed digital object as a string of arbitrary single octets.
プレーンテキストの性質（ASCII、UTF-8、HTML、JavaScript、XMLなど）のデジタルオブジェクトを作成する場合、そのようなオブジェクトをロスレス圧縮フォームに変換することをお勧めします。圧縮エンベロープ内でプレーンテキストオブジェクトを分散する（GZIP [RFC1952]など）を分散すると、中間システムでの予期しない標準化を回避するのに役立つ可能性があります（これにより、チェックサム検証エラーにつながります）。バリデーターの実装は、チェックサムのデジタルオブジェクトを任意の単一オクテットの文字列として扱うことが期待されています。
If a fileName field is present, but no digital object within the set of to-be-verified digital objects has a filename that matches the content of that field, a validator implementation SHOULD compare the message digest of each digital object to the value from the hash field of the associated FileNameAndHash and report matches to the user for further consideration.
ファイル名フィールドが存在しますが、検証されたデジタルオブジェクトのセット内にデジタルオブジェクトがない場合、そのフィールドのコンテンツに一致するファイル名がありません。関連するfilenameandhashのハッシュフィールドとレポートは、さらに検討するためにユーザーに一致します。
RPs are hereby warned that the data in an RSC is self-asserted. When determining the meaning of any data contained in an RSC, RPs MUST NOT make any assumptions about the signer beyond the fact that it had sufficient control of the issuing CA to create the object. These data have not been verified by the Certificate Authority (CA) that issued the CA certificate to the entity that issued the EE certificate used to validate the RSC.
RPSは、RSCのデータが自己攻撃されていると警告されています。RSCに含まれるデータの意味を決定する場合、RPSは、オブジェクトを作成するために発行CAの十分な制御があるという事実を超えて、署名者について仮定してはなりません。これらのデータは、RSCの検証に使用されたEE証明書を発行したエンティティにCA証明書を発行した証明書当局（CA）によって検証されていません。
RPKI certificates are not bound to real-world identities; see [RFC9255] for an elaboration. RPs can only associate real-world entities to Internet Number Resources by additionally consulting an exogenous authority. RSCs are a tool to communicate assertions signed with Internet Number Resources and do not communicate any other aspect of the resource holder's business operations, such as the identity of the resource holder itself.
RPKI証明書は、実際のアイデンティティに拘束されません。詳細については[RFC9255]を参照してください。RPSは、外生の権限をさらに相談することにより、実際のエンティティをインターネット番号リソースに関連付けることができます。RSCは、インターネット番号リソースで署名されたアサーションを伝えるツールであり、リソースホルダー自体のIDなど、リソースホルダーの事業運営の他の側面を伝えません。
RSC objects are not distributed through the RPKI repository system. From this, it follows that third parties who do not have a copy of a given RSC may not be aware of the existence of that RSC. Since RSC objects use EE certificates but all other currently defined types of RPKI object profiles are published in public CA repositories, an observer may infer from discrepancies in the repository that RSC object(s) may exist. For example, if a CA does not use random serial numbers for certificates, an observer could detect gaps between the serial numbers of the published EE certificates. Similarly, if the CA includes a serial number on a Certificate Revocation List (CRL) that does not match any published object, an observer could postulate that an RSC EE certificate was revoked.
RSCオブジェクトは、RPKIリポジトリシステムを介して配布されません。これから、特定のRSCのコピーを持っていない第三者がそのRSCの存在を認識していない可能性があります。RSCオブジェクトはEE証明書を使用しているが、現在定義されている他のすべてのタイプのRPKIオブジェクトプロファイルは公共のCAリポジトリで公開されているため、オブザーバーはRSCオブジェクトが存在する可能性があることをリポジトリの不一致から推測する可能性があります。たとえば、CAが証明書にランダムなシリアル番号を使用しない場合、オブザーバーは公開されているEE証明書のシリアル番号間のギャップを検出できます。同様に、CAに公開されたオブジェクトと一致しない証明書取消リスト（CRL）にシリアル番号が含まれている場合、オブザーバーはRSC EE証明書が取り消されたことを仮定することができます。
Conversely, a gap in serial numbers does not imply that an RSC exists. Nor does the presence in a CRL of a serial number unknown to the RP imply an RSC object exists: the implicitly referenced object might not be an RSC, it might have never been published, or it may have been revoked before it was visible to RPs. In general, it is not possible to confidently infer the existence or non-existence of RSCs from the repository state without access to a given RSC.
逆に、シリアル数のギャップは、RSCが存在することを意味するものではありません。また、RPに知られていないシリアル番号のCRLに存在することは、RSCオブジェクトが存在することを意味しません。暗黙的に参照されたオブジェクトはRSCではなく、公開されていないか、RPSに表示される前に取り消された可能性があります。。一般に、特定のRSCにアクセスすることなく、リポジトリ状態からRSCの存在または非存在を自信を持って推測することはできません。
While a one-time-use EE certificate must only be used to generate and sign a single RSC object, CAs technically are not restricted from generating and signing multiple different RSC objects with a single key pair. Any RSC objects sharing the same EE certificate cannot be revoked individually.
1回限りのEE証明書は、単一のRSCオブジェクトを生成および署名するためにのみ使用する必要がありますが、CASは技術的には、単一のキーペアで複数の異なるRSCオブジェクトを生成および署名することを制限されていません。同じEE証明書を共有するRSCオブジェクトは、個別に取り消すことはできません。
IANA has allocated the following in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry:
IANAは、「S/MIME CMSコンテンツタイプのSMIセキュリティ（1.2.840.113549.1.9.16.1）」で以下を割り当てました。
+=========+=======================+============+
| Decimal | Description | References |
+=========+=======================+============+
| 48 | id-ct-signedChecklist | RFC 9323 |
+---------+-----------------------+------------+
Table 1
表1
IANA has registered the OID for the RSC in the "RPKI Signed Objects" registry [RFC6488] as follows:
IANAは、次のように、「RPKI署名されたオブジェクト」レジストリ[RFC6488]にRSCのOIDを登録しました。
+==================+============================+===========+
| Name | OID | Reference |
+==================+============================+===========+
| Signed Checklist | 1.2.840.113549.1.9.16.1.48 | RFC 9323 |
+------------------+----------------------------+-----------+
Table 2
表2
IANA has added the Signed Checklist file extension to the "RPKI Repository Name Schemes" registry [RFC6481] as follows:
IANAは、次のように、「RPKIリポジトリ名スキーム」レジストリ[RFC6481]に署名されたチェックリストファイル拡張子を追加しました。
+====================+==================+===========+
| Filename Extension | RPKI Object | Reference |
+====================+==================+===========+
| .sig | Signed Checklist | RFC 9323 |
+--------------------+------------------+-----------+
Table 3
表3
9.4. SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)
9.4. S/MIMEモジュール識別子のSMIセキュリティ（1.2.840.113549.1.9.16.0）
IANA has allocated the following in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:
IANAは、「S/MIMEモジュール識別子のSMIセキュリティ（1.2.840.113549.1.9.16.0）」で以下を割り当てました。
+=========+=================================+============+
| Decimal | Description | References |
+=========+=================================+============+
| 73 | id-mod-rpkiSignedChecklist-2022 | RFC 9323 |
+---------+---------------------------------+------------+
Table 4
表4
IANA has registered the media type "application/rpki-checklist" in the "Media Types" registry as follows:
IANAは、「メディアタイプ」レジストリにメディアタイプ「アプリケーション/RPKI-Checklist」を次のように登録しています。
Type name: application
タイプ名：アプリケーション
Subtype name: rpki-checklist
サブタイプ名：rpki-checklist
Required parameters: N/A
必要なパラメーター：n/a
Optional parameters: N/A
オプションのパラメーター：n/a
Encoding considerations: binary
考慮事項のエンコード：バイナリ
Security considerations: Carries an RPKI Signed Checklist. This media type contains no active content. See Section 5 of RFC 9323 for further information.
セキュリティ上の考慮事項：RPKI署名されたチェックリストを搭載しています。このメディアタイプには、アクティブなコンテンツが含まれていません。詳細については、RFC 9323のセクション5を参照してください。
Interoperability considerations: N/A
相互運用性の考慮事項：n/a
Published specification: RFC 9323
公開された仕様：RFC 9323
Applications that use this media type: RPKI operators
このメディアタイプを使用するアプリケーション：RPKIオペレーター
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：n/a
Additional information:
追加情報：
Content: This media type is a signed object, as defined in [RFC6488], which contains a payload of a list of checksums as defined in RFC 9323. Magic number(s): N/A File extension(s): .sig Macintosh file type code(s): N/A
コンテンツ：このメディアタイプは、[RFC6488]で定義されているように署名されたオブジェクトです。これには、RFC9323で定義されているチェックサムのリストのペイロードが含まれています。ファイルタイプコード：n/a
Person & email address to contact for further information: Job Snijders (job@fastly.com)
連絡先への個人およびメールアドレス詳細については、Job Snijders（job@fastly.com）
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: N/A
使用に関する制限：n/a
Author: Job Snijders (job@fastly.com)
著者：jobsnijders（job@fastly.com）
Change controller: IETF
Change Controller：IETF
[POSIX] IEEE and The Open Group, "Base Specifications", Issue 7, DOI 10.1109/IEEESTD.2016.7582338, 2016, <https://publications.opengroup.org/standards/unix/c165>.
[POSIX] IEEEおよびOPENグループ、「基本仕様」、第7号、DOI 10.1109/IEEESTD.2016.7582338、2016、<https://publications.opengroup.org/standards/unix/c165>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[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, <https://www.rfc-editor.org/info/rfc3779>.
[RFC3779] Lynn、C.、Kent、S。、およびK. Seo、「IPアドレスおよび識別子のX.509拡張剤」、RFC 3779、DOI 10.17487/RFC3779、2004年6月、<https：//www.rfcc-editor.org/info/rfc3779>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 5652、DOI 10.17487/RFC5652、2009年9月、<https://www.rfc-editor.org/info/rfc5652>
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.
[RFC6481] Huston、G.、Loomans、R。、およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、DOI 10.17487/RFC6481、2012年2月、<https：//www.rfc-editor。org/info/rfc6481>。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.
[RFC6487] Huston、G.、Michaelson、G.、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、DOI 10.17487/RFC6487、2012年2月、<https：//www.rfc-editor.org/info/rfc6487>。
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, <https://www.rfc-editor.org/info/rfc6488>.
[RFC6488] Lepinski、M.、Chi、A。、およびS. Kent、「リソース公開キーインフラストラクチャ（RPKI）の署名されたオブジェクトテンプレート」、RFC 6488、DOI 10.17487/RFC6488、2012年2月、<https：//.rfc-editor.org/info/rfc6488>。
[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, <https://www.rfc-editor.org/info/rfc7935>.
[RFC7935] Huston、G。およびG. Michaelson、ed。、「リソース公開キーインフラストラクチャで使用するアルゴリズムとキーサイズのプロファイル」、RFC 7935、DOI 10.17487/RFC7935、2016年8月、<https：//.rfc-editor.org/info/rfc7935>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022, <https://www.rfc-editor.org/info/rfc9286>.
[RFC9286] Austein、R.、Huston、G.、Kent、S。、およびM. Lepinski、「リソース公開キーインフラストラクチャ（RPKI）のマニフェスト」、RFC 9286、DOI 10.17487/RFC9286、2022年6月、<HTTPS：//www.rfc-editor.org/info/rfc9286>。
[IANA.ADDRESS-FAMILY-NUMBERS] IANA, "Address Family Numbers", <https://www.iana.org/assignments/address-family-numbers>.
[iana.address-family-numbers] iana、 "adstress family numbers"、<https://www.iana.org/assignments/address-family-numbers>。
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, <https://www.rfc-editor.org/info/rfc1952>.
[RFC1952] Deutsch、P。、「GZIPファイル形式の仕様バージョン4.3」、RFC 1952、DOI 10.17487/RFC1952、1996年5月、<https://www.rfc-editor.org/info/rfc1952>。
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>.
[RFC6268] Schaad、J。およびS. Turner、「X.509（PKIX）を使用した暗号化メッセージ構文（CMS）および公開キーインフラストラクチャの追加の新しいASN.1モジュール」、RFC 6268、DOI 10.17487/RFC6268、7月2011、<https://www.rfc-editor.org/info/rfc6268>。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、DOI 10.17487/RFC6480、2012年2月、<https://www.rfc-editor.org/info/rfc6480>。
[RFC9255] Bush, R. and R. Housley, "The 'I' in RPKI Does Not Stand for Identity", RFC 9255, DOI 10.17487/RFC9255, June 2022, <https://www.rfc-editor.org/info/rfc9255>.
[RFC9255] Bush、R。and R. Housley、「RPKIの「I」はアイデンティティを表していません」、RFC 9255、DOI 10.17487/RFC9255、2022年6月、<https://www.rfc-editor.org/情報/RFC9255>。
[RPKI-RTA] Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T., and M. Hoffman, "A profile for Resource Tagged Attestations (RTAs)", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki-rta-00, 17 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rta-00>.
[RPKI-RTA] Michaelson、G.、Huston、G.、Harrison、T.、Bruijnzeels、T.、およびM. Hoffman、「リソースタグ付き証明（RTA）のプロファイル」、進行中の作業、インターネットドラフト、ドラフト-ITETF-SIDROPS-RPKI-RTA-00、2021年1月17日、<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rta-00>。
[signify] Unangst, T. and M. Espie, "signify - cryptographically sign and verify files", <https://man.openbsd.org/signify>.
[signify] unangst、T。and M. espie、「signify-暗号化的にファイルに署名して検証する」、<https://man.openbsd.org/signify>。
Acknowledgements
謝辞
The authors wish to thank George Michaelson, Geoff Huston, Randy Bush, Stephen Kent, Matt Lepinski, Rob Austein, Ted Unangst, and Marc Espie for prior art. The authors thank Russ Housley for reviewing the ASN.1 notation and providing suggestions. The authors would like to thank Nimrod Levy, Tim Bruijnzeels, Alberto Leiva, Ties de Kock, Peter Peele, Claudio Jeker, Theo Buehler, Donald Eastlake 3rd, Erik Kline, Robert Wilton, Roman Danyliw, Éric Vyncke, Lars Eggert, Paul Wouters, and Murray S. Kucherawy for document review and suggestions.
著者は、ジョージ・マイケルソン、ジェフ・ヒューストン、ランディ・ブッシュ、スティーブン・ケント、マット・レピンスキー、ロブ・オーストイン、テッド・ウナングスト、マーク・エスピーに以前の芸術に感謝したいと考えています。著者は、ASN.1表記をレビューし、提案を提供してくれたRuss Housleyに感謝します。著者は、ニムロッド・レヴィ、ティム・ブルージュンゼル、アルベルト・レイヴァ、ティーズ・デ・コック、ピーター・ピール、クラウディオ・ジェーカー、テオ・ビューラー、ドナルド・イーストレイク3、エリック・クライン、ロバート・ウィルトン、ローマ・ダニルイ、エリック・ヴィンケ、ラース・エガート、ポール・ウーターズドキュメントのレビューと提案については、Murray S. Kucherawy。
Authors' Addresses
著者のアドレス
Job Snijders Fastly Amsterdam Netherlands Email: job@fastly.com
Job Snijders早くアムステルダムオランダメールメール：job@fastly.com
Tom Harrison Asia Pacific Network Information Centre 6 Cordelia St South Brisbane QLD 4101 Australia Email: tomh@apnic.net
トムハリソンアジアパシフィックネットワーク情報センター6コーデリアセントサウスブリスベンQLD 4101オーストラリアメール：tomh@apnic.net
Ben Maddison Workonline Communications Cape Town South Africa Email: benm@workonline.africa
ベンマディソンワークオンラインコミュニケーションケープタウン南アフリカメール：benm@workonline.africa