[要約] RFC 6488は、RPKI（Resource Public Key Infrastructure）のための署名付きオブジェクトテンプレートに関する規格です。このRFCの目的は、RPKIのセキュリティと信頼性を向上させるために、署名付きオブジェクトのテンプレートを定義することです。
Internet Engineering Task Force (IETF) M. Lepinski
Request for Comments: 6488 A. Chi
Category: Standards Track S. Kent
ISSN: 2070-1721 BBN
February 2012
Signed Object Template for the Resource Public Key Infrastructure (RPKI)
リソース公開キーインフラストラクチャ（RPKI）の署名されたオブジェクトテンプレート
Abstract
概要
This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format.
このドキュメントは、リソース公開キーインフラストラクチャ（RPKI）で使用される署名されたオブジェクトの汎用プロファイルを定義します。これらのRPKI署名されたオブジェクトは、標準のカプセル化形式として暗号化メッセージ構文（CMS）を使用します。
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション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/rfc6488.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6488で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Note on Algorithms .........................................3
2. Signed Object Syntax ............................................3
2.1. Signed-Data Content Type ...................................4
2.1.1. version .............................................4
2.1.2. digestAlgorithms ....................................4
2.1.3. encapContentInfo ....................................4
2.1.3.1. eContentType ...............................5
2.1.3.2. eContent ...................................5
2.1.4. certificates ........................................5
2.1.5. crls ................................................5
2.1.6. signerInfos .........................................5
2.1.6.1. version ....................................6
2.1.6.2. sid ........................................6
2.1.6.3. digestAlgorithm ............................6
2.1.6.4. signedAttrs ................................6
2.1.6.4.1. Content-Type Attribute ..........7
2.1.6.4.2. Message-Digest Attribute ........7
2.1.6.4.3. Signing-Time Attribute ..........7
2.1.6.4.4. Binary-Signing-Time Attribute ...8
2.1.6.5. signatureAlgorithm .........................8
2.1.6.6. signatureValue .............................8
2.1.6.7. unsigneAttrs ...............................8
3. Signed Object Validation ........................................8
4. Definition of Specific Signed Objects ..........................10
5. Security Considerations ........................................10
6. IANA Considerations ............................................11
7. Acknowledgements ...............................................11
8. Normative References ...........................................11
9. Informative References .........................................12
The purpose of the Resource Public Key Infrastructure (RPKI) is to support assertions by current resource holders of IP (v4 and v6) address space and AS numbers, based on the records of organizations that act as Certification Authorities (CAs). IP address and AS number resource information is carried in X.509 certificates via RFC 3779 extensions [RFC6487]. Other information assertions about resources are expressed via digitally signed, non-X.509 data structures that are referred to as "signed objects" in the RPKI context [RFC6480]. This document standardizes a template for specifying signed objects that can be validated using the RPKI.
リソース公開キーインフラストラクチャ（RPKI）の目的は、認定当局（CA）として機能する組織の記録に基づいて、現在のIP（V4およびV6）の対処スペースと数字としてのアサーションをサポートすることです。IPアドレスおよび番号ASリソース情報は、RFC 3779エクステンション[RFC6487]を介してX.509証明書で伝えられています。リソースに関するその他の情報アサーションは、RPKIコンテキスト[RFC6480]で「署名されたオブジェクト」と呼ばれるデジタル署名、非X.509データ構造を介して表現されます。このドキュメントは、RPKIを使用して検証できる署名済みオブジェクトを指定するためのテンプレートを標準化しています。
RPKI signed objects make use of Cryptographic Message Syntax (CMS) [RFC5652] as a standard encapsulation format. CMS was chosen to take advantage of existing open source software available for processing messages in this format. RPKI signed objects adhere to a profile (specified in Section 2) of the CMS signed-data object.
RPKI署名されたオブジェクトは、暗号化メッセージの構文（CMS）[RFC5652]を標準のカプセル化形式として使用します。CMSは、この形式でメッセージを処理できる既存のオープンソースソフトウェアを利用するために選択されました。RPKI署名されたオブジェクトは、CMS Signed-Dataオブジェクトのプロファイル（セクション2で指定）に付着します。
The template defined in this document for RPKI signed objects is not a complete specification for any particular type of signed object, and instead includes only the items that are common to all RPKI signed objects. That is, fully specifying a particular type of signed object requires an additional document that specifies the details specific to a particular type of signed object. Such details include Abstract Syntax Notation One (ASN.1) [X.208-88] for the object's payload and any additional steps required to validate the particular type of signed object. Section 4 describes in more detail the additional pieces that must be specified in order to define a new type of RPKI signed object that uses this template. Additionally, see [RFC6482] for an example of a document that uses this template to specify a particular type of signed object, the Route Origination Authorization (ROA).
RPKI署名されたオブジェクトのこのドキュメントで定義されているテンプレートは、特定のタイプの署名されたオブジェクトの完全な仕様ではなく、代わりにすべてのRPKI署名されたオブジェクトに共通するアイテムのみが含まれます。つまり、特定のタイプの署名されたオブジェクトを完全に指定するには、特定のタイプの署名されたオブジェクトに固有の詳細を指定する追加のドキュメントが必要です。このような詳細には、オブジェクトのペイロードのための抽象的構文表記1（asn.1）[x.208-88]と、特定のタイプの署名されたオブジェクトを検証するために必要な追加の手順が含まれます。セクション4では、このテンプレートを使用する新しいタイプのRPKI署名されたオブジェクトを定義するために指定する必要がある追加の部分を詳細に説明します。さらに、このテンプレートを使用して特定のタイプの署名されたオブジェクトであるRoute Origination Authorization（ROA）を指定するドキュメントの例については、[RFC6482]を参照してください。
It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and "Cryptographic Message Syntax (CMS)" [RFC5652].
読者は、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」[RFC5280]、「IPアドレスおよび識別子としてのX.509拡張機能」[RFC5280]に記載されている用語と概念に精通していると想定されています。RFC3779]、および「暗号化メッセージ構文（CMS）」[RFC5652]。
The 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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
CMS is a general format capable of accommodating a wide variety of signature and digest algorithms. The algorithms used in the RPKI (and associated key sizes) are specified in [RFC6485].
CMSは、さまざまな署名およびダイジェストアルゴリズムに対応できる一般的な形式です。RPKI（および関連するキーサイズ）で使用されるアルゴリズムは、[RFC6485]で指定されています。
The RPKI signed object is a profile of the CMS [RFC5652] signed-data object, with the restriction that RPKI signed objects MUST be encoded using the ASN.1 Distinguished Encoding Rules (DER) [X.509-88].
RPKI署名されたオブジェクトは、CMS [RFC5652]署名されたDATAオブジェクトのプロファイルであり、RPKI署名されたオブジェクトがASN.1識別エンコードルール（der）[x.509-88]を使用してエンコードする必要があります。
The general format of a CMS object is:
CMSオブジェクトの一般的な形式は次のとおりです。
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
The content-type is the signed-data type of id-data, namely the id-signedData OID [RFC5652], 1.2.840.113549.1.7.2.
コンテンツタイプは、ID-SignedData OID [RFC5652]、1.2.840.113549.1.7.2、つまりID-SignedData OID [RFC5652]、つまりID-DATAの署名付きDATAタイプです。
According to the CMS standard, the signed-data content type is the ASN.1 type SignedData:
CMS標準によると、署名されたDATAコンテンツタイプはASN.1タイプのsignedDataです。
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
Additionally, the SignerInfos set MUST contain only a single SignerInfo object.
さらに、SignerInfosセットには、SignerInfoオブジェクトが1つだけ含まれている必要があります。
The version is the syntax version number. It MUST be 3, corresponding to the signerInfo structure having version number 3.
バージョンは構文バージョン番号です。バージョン番号3を持つSignerinfo構造に対応する3でなければなりません。
The digestAlgorithms set contains the OIDs of the digest algorithm(s) used in signing the encapsulated content. This set MUST contain exactly one digest algorithm OID, and the OID MUST be selected from those specified in [RFC6485].
Digestalgorithmsセットには、カプセル化されたコンテンツの署名に使用されるダイジェストアルゴリズムのOIDが含まれています。このセットには、1つのダイジェストアルゴリズムOIDを正確に含める必要があり、OIDは[RFC6485]で指定されたものから選択する必要があります。
encapContentInfo is the signed content, consisting of a content type identifier and the content itself. The encapContentInfo represents the payload of the RPKI signed object.
EncapContentInfoは、コンテンツ型識別子とコンテンツ自体で構成される署名されたコンテンツです。EncapContentInfoは、RPKI署名されたオブジェクトのペイロードを表します。
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
This field is left undefined by this profile. The eContentType is an OID specifying the type of payload in this signed object and MUST be specified by the Internet Standards Track document that defines the object.
このフィールドは、このプロファイルによって未定義のままです。EcontentTypeは、この署名されたオブジェクトのペイロードのタイプを指定するOIDであり、オブジェクトを定義するインターネット標準トラックドキュメントで指定する必要があります。
This field is left undefined by this profile. The eContent is the payload of the signed object and MUST be specified by the Internet Standards Track document that defines the RPKI object.
このフィールドは、このプロファイルによって未定義のままです。econtentは署名されたオブジェクトのペイロードであり、RPKIオブジェクトを定義するインターネット標準トラックドキュメントで指定する必要があります。
Note that the signed object profile does not provide version numbers for signed objects. Therefore, in order to facilitate transition to new versions of the signed objects over time, it is RECOMMENDED that each type of signed object defined using this profile include a version number within its eContent.
署名されたオブジェクトプロファイルは、署名されたオブジェクトのバージョン番号を提供しないことに注意してください。したがって、時間の経過とともに署名されたオブジェクトの新しいバージョンへの移行を容易にするために、このプロファイルを使用して定義された各タイプの署名されたオブジェクトをそのecontent内のバージョン番号を含めることをお勧めします。
The certificates field MUST be included, and MUST contain exactly one certificate, the RPKI end-entity (EE) certificate needed to validate this signed object.
証明書フィールドを含める必要があり、正確に1つの証明書、この署名されたオブジェクトを検証するために必要なRPKIエンドエンティティ（EE）証明書を含める必要があります。
The crls field MUST be omitted.
CRLSフィールドは省略する必要があります。
SignerInfo is defined in CMS as:
SignerinfoはCMSで次のように定義されています。
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
The version number MUST be 3, corresponding with the choice of SubjectKeyIdentifier for the sid.
バージョン番号は3でなければならず、SIDのSubjectKeyIdentifierの選択に対応しています。
The sid is defined as:
SIDは次のように定義されています。
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
For RPKI signed objects, the sid MUST be the SubjectKeyIdentifier that appears in the EE certificate carried in the CMS certificates field.
RPKI署名されたオブジェクトの場合、SIDは、CMS証明書フィールドに掲載されたEE証明書に表示される件名Keyidentifierでなければなりません。
The digestAlgorithm MUST consist of the OID of a digest algorithm that conforms to the RPKI Algorithms and Key Size Profile specification [RFC6485].
消化器gorthmは、RPKIアルゴリズムとキーサイズプロファイルの仕様[RFC6485]に適合するダイジェストアルゴリズムのOIDで構成されている必要があります。
The signedAttrs is defined as:
SigneDattrsは次のように定義されています。
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
The signedAttrs element MUST be present and MUST include the content-type and message-digest attributes [RFC5652]. The signer MAY also include the signing-time attribute [RFC5652], the binary-signing-time attribute [RFC6019], or both attributes. Other signed attributes MUST NOT be included.
SigneDattrs要素が存在する必要があり、コンテンツタイプとメッセージダイジスト属性[RFC5652]を含める必要があります。署名者には、署名時の属性[RFC5652]、バイナリ署名時間属性[RFC6019]、または両方の属性も含まれます。その他の署名された属性を含める必要はありません。
The signedAttrs element MUST include only a single instance of any particular attribute. Additionally, even though the syntax allows for a SET OF AttributeValue, in an RPKI signed object, the attrValues MUST consist of only a single AttributeValue.
SigneDattrs要素には、特定の属性の単一インスタンスのみを含める必要があります。さらに、構文は一連の属性valueを許可しますが、RPKI署名されたオブジェクトでは、属性は単一の属性valueのみで構成されている必要があります。
The content-type attribute MUST be present. The attrType OID for the content-type attribute is 1.2.840.113549.1.9.3.
コンテンツタイプの属性が存在する必要があります。コンテンツタイプの属性のattrype OIDは1.2.840.113549.1.9.3です。
The attrValues for the content-type attribute MUST match the eContentType in the EncapsulatedContentInfo. Thus, attrValues MUST contain the OID that specifies the payload type of the specific RPKI signed object carried in the CMS signed data structure.
コンテンツタイプの属性の属性は、contulatedContentInfoのecontentTypeと一致する必要があります。したがって、アトラットは、CMS署名されたデータ構造で運ばれる特定のRPKI署名されたオブジェクトのペイロードタイプを指定するOIDを含める必要があります。
The message-digest attribute MUST be present. The attrType OID for the message-digest attribute is 1.2.840.113549.1.9.4.
メッセージダイジェスト属性が存在する必要があります。メッセージダイジェスト属性の属性oidは1.2.840.113549.1.9.4です。
The attrValues for the message-digest attribute contains the output of the digest algorithm applied to the content being signed, as specified in Section 5.4 of [RFC5652].
メッセージDigest属性の属性には、[RFC5652]のセクション5.4で指定されているように、署名されているコンテンツに適用されるダイジェストアルゴリズムの出力が含まれます。
The signing-time attribute MAY be present. Note that the presence or absence of the signing-time attribute MUST NOT affect the validity of the signed object (as specified in Section 3). The attrType OID for the signing-time attribute is 1.2.840.113549.1.9.5.
署名時の属性が存在する場合があります。署名時の属性の存在または不在は、署名されたオブジェクトの妥当性に影響してはならないことに注意してください（セクション3で指定）。署名時の属性のattrtype oidは1.2.840.113549.1.9.5です。
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
The attrValues for the signing-time attribute is defined as:
署名時の属性の属性は、次のように定義されます。
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
The Time element specifies the time, based on the local system clock, at which the digital signature was applied to the content.
タイム要素は、デジタル署名がコンテンツに適用されたローカルシステムクロックに基づいて、時間を指定します。
The definition of Time matches the one specified in the 1997 version of X.509. Additional information regarding the use of UTCTime and GeneralizedTime can be found in [RFC5652].
時間の定義は、X.509の1997バージョンで指定されたものと一致します。UTCTIMEおよび一般化された時間の使用に関する追加情報は、[RFC5652]に記載されています。
The binary-signing-time attribute MAY be present. Note that the presence or absence of the binary-signing-time attribute MUST NOT affect the validity of the signed object (as specified in Section 3). The attrType OID for the binary-signing-time attribute is 1.2.840.113549.1.9.16.2.46.
バイナリ署名時間属性が存在する場合があります。バイナリ署名時間属性の存在または不在は、署名されたオブジェクトの妥当性に影響してはならないことに注意してください（セクション3で指定されているように）。バイナリ署名時間属性のattrtype oidは1.2.840.113549.1.9.16.2.46です。
id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 46 }
The attrValues for the signing-time attribute is defined as:
BinarySigningTime ::= BinaryTime
BinaryTime ::= INTEGER (0..MAX)
The BinaryTime element specifies the time, based on the local system clock, at which the digital signature was applied to the content. The precise definition of the BinaryTime element can be found in [RFC6019].
バイナリタイム要素は、ローカルシステムクロックに基づいて、デジタル署名がコンテンツに適用された時間を指定します。バイナリタイム要素の正確な定義は[RFC6019]に記載されています。
The signatureAlgorithm MUST conform to the RPKI Algorithms and Key Size Profile specification [RFC6485].
SignatureAlgorithmは、RPKIアルゴリズムとキーサイズプロファイル仕様[RFC6485]に準拠する必要があります。
The signature value is defined as:
署名値は次のように定義されます。
SignatureValue ::= OCTET STRING
The signature characteristics are defined by the digest and signature algorithms.
署名特性は、ダイジェストおよび署名アルゴリズムによって定義されます。
unsignedAttrs MUST be omitted.
unsignedattrsを省略する必要があります。
Before a relying party can use a signed object, the relying party MUST validate the signed object by verifying that all of the following conditions hold. A relying party may perform these checks in any order. Note that these checks are necessary, but not sufficient. In general, further validation MUST be performed based on the specific type of signed object.
頼る当事者が署名されたオブジェクトを使用する前に、頼る当事者は、次のすべての条件が保持されていることを確認することにより、署名されたオブジェクトを検証する必要があります。頼る当事者は、これらのチェックを任意の順序で実行する場合があります。これらのチェックは必要ですが、十分ではないことに注意してください。一般に、特定のタイプの署名されたオブジェクトに基づいて、さらなる検証を実行する必要があります。
1. The signed object syntax complies with this specification. In particular, each of the following is true:
1. 署名されたオブジェクトの構文は、この仕様に準拠しています。特に、以下のそれぞれが真です。
a. The content-type of the CMS object is SignedData (OID 1.2.840.113549.1.7.2)
a. CMSオブジェクトのコンテンツタイプはSignedDataです（OID 1.2.840.113549.1.7.2）
b. The version of the SignedData object is 3.
b. SignedDataオブジェクトのバージョンは3です。
c. The certificates field in the SignedData object is present and contains one EE certificate, the SubjectKeyIdentifier field of which matches the sid field of the SignerInfo object.
c. SignedDataオブジェクトの証明書フィールドが存在し、1つのEE証明書が含まれています。これは、SignerINFOオブジェクトのSIDフィールドと一致するSubjectKeyIdentifierフィールドです。
d. The crls field in the SignedData object is omitted.
d. SignedDataオブジェクトのCRLSフィールドは省略されています。
e. The version of the SignerInfo is 3.
e. Signerinfoのバージョンは3です。
f. The signedAttrs field in the SignerInfo object is present and contains both the content-type attribute (OID 1.2.840.113549.1.9.3) and the message-digest attribute (OID 1.2.840.113549.1.9.4).
f. SignerINFOオブジェクトのSigneDattrsフィールドは存在し、コンテンツタイプの属性（OID 1.2.840.113549.1.9.3）とメッセージダイジェスト属性（OID 1.2.840.113549.1.9.4）の両方が含まれています。
g. The signedAttrs field in the SignerInfo object does not contain any attributes other than the following four: the content-type attribute (OID 1.2.840.113549.1.9.3), the message-digest attribute (OID 1.2.840.113549.1.9.4), the signing-time attribute (OID 1.2.840.113549.1.9.5), and the binary-signing-time attribute (OID 1.2.840.113549.1.9.16.2.46). Note that the signing-time and binary-signing-time attributes MAY be present, but they are not required.
g. SignerINFOオブジェクトのSigneDattrsフィールドには、次の4つ以外の属性は含まれていません。コンテンツタイプの属性（OID 1.2.840.113549.1.9.3）、メッセージダイジェスト属性（OID 1.2.840.113549.1.9.4）、署名時の属性（OID 1.2.840.113549.1.9.5）、およびバイナリ署名時間属性（OID 1.2.840.113549.1.9.16.2.46）。署名時間およびバイナリシグインタイム属性が存在する場合があるが、それらは必要ないことに注意してください。
h. The eContentType in the EncapsulatedContentInfo is an OID that matches the attrValues in the content-type attribute.
h. contulatedContentInfoのecontentTypeは、コンテンツタイプの属性の属性と一致するOIDです。
i. The unsignedAttrs field in the SignerInfo object is omitted.
i. SignerInfoオブジェクトのUnsignedattrsフィールドは省略されています。
j. The digestAlgorithm in the SignedData and SignerInfo objects conforms to the RPKI Algorithms and Key Size Profile specification [RFC6485].
j. SignedDataおよびSignerinfoオブジェクトの消化器gorithmは、RPKIアルゴリズムとキーサイズプロファイル仕様[RFC6485]に準拠しています。
k. The signatureAlgorithm in the SignerInfo object conforms to the RPKI Algorithms and Key Size Profile specification [RFC6485].
k. SignerINFOオブジェクトのSignatureAlgorithmは、RPKIアルゴリズムとキーサイズプロファイル仕様[RFC6485]に準拠しています。
l. The signed object is DER encoded.
l. 署名されたオブジェクトはderエンコードされています。
2. The public key of the EE certificate (contained within the CMS signed-data object) can be used to successfully verify the signature on the signed object.
2. EE証明書の公開鍵（CMS Signed-Dataオブジェクトに含まれる）を使用して、署名されたオブジェクトの署名を正常に確認できます。
3. The EE certificate (contained within the CMS signed-data object) is a valid EE certificate in the RPKI as specified by [RFC6487]. In particular, a valid certification path from a trust anchor to this EE certificate exists.
3. EE証明書（CMS署名DATAオブジェクトに含まれる）は、[RFC6487]で指定されているRPKIの有効なEE証明書です。特に、信頼のアンカーからこのEE証明書までの有効な認証パスが存在します。
If the above procedure indicates that the signed object is invalid, then the signed object MUST be discarded and treated as though no signed object were present. If all of the conditions above are true, then the signed object may be valid. The relying party MUST then perform any additional validation steps required for the particular type of signed object.
上記の手順が署名されたオブジェクトが無効であることを示している場合、署名されたオブジェクトを破棄し、署名されたオブジェクトが存在しないかのように処理する必要があります。上記のすべての条件が真である場合、署名されたオブジェクトが有効である可能性があります。頼る当事者は、特定のタイプの署名されたオブジェクトに必要な追加の検証手順を実行する必要があります。
Note that a previously valid signed object will cease to be valid when the associated EE certificate ceases to be valid (for example, when the end of the certificate's validity period is reached, or when the certificate is revoked by the authority that issued it). See [RFC6487] for a complete specification of resource certificate validity.
以前に有効な署名されたオブジェクトは、関連するEE証明書が有効になることを停止した場合（たとえば、証明書の有効性期間の終了に到達したとき、または証明書が発行した当局によって取り消されたときに有効であることを停止することに注意してください。リソース証明書の有効性の完全な仕様については、[RFC6487]を参照してください。
Each RPKI signed object MUST be defined in an Internet Standards Track document based on this profile, by specifying the following data elements and validation procedure:
各RPKI署名されたオブジェクトは、次のデータ要素と検証手順を指定することにより、このプロファイルに基づいてインターネット標準トラックドキュメントで定義する必要があります。
1. eContentType: A single OID to be used for both the eContentType field and the content-type attribute. This OID uniquely identifies the type of signed object.
1. EcontentType：EcontentTypeフィールドとコンテンツタイプの属性の両方に使用される単一のOID。このOIDは、署名されたオブジェクトのタイプを一意に識別します。
2. eContent: Define the syntax for the eContent field in encapContentInfo. This is the payload that contains the data specific to a given type of signed object.
2. econtent：encapcontentinfoのecontentフィールドの構文を定義します。これは、特定のタイプの署名されたオブジェクトに固有のデータを含むペイロードです。
3. Additional Validation: Define a set of additional validation steps for the specific signed object. Before using this specific signed object, a relying party MUST perform both the generic validation steps in Section 3 above, as well as these additional steps.
3. 追加の検証：特定の署名されたオブジェクトの追加の検証手順のセットを定義します。この特定の署名されたオブジェクトを使用する前に、頼る当事者は、上記のセクション3の一般的な検証手順と、これらの追加手順の両方を実行する必要があります。
There is no assumption of confidentiality for the data in an RPKI signed object. The integrity and authenticity of each signed object is based on the verification of the object's digital signature, and
RPKI署名されたオブジェクトのデータの機密性の仮定はありません。各署名されたオブジェクトの整合性と信頼性は、オブジェクトのデジタル署名の検証に基づいています。
the validation of the EE certificate used to perform that verification. It is anticipated that signed objects will be stored in repositories that will be publicly accessible.
その検証を実行するために使用されるEE証明書の検証。署名されたオブジェクトは、公開可能なリポジトリに保存されると予想されます。
Since RPKI signed objects make use of CMS as an encapsulation format, the security considerations for CMS apply [RFC5652].
RPKI署名されたオブジェクトはCMSをカプセル化形式として使用しているため、CMSのセキュリティ上の考慮事項が適用されます[RFC5652]。
IANA has created a registry of "RPKI Signed Objects" types that utilize the template defined in this document. This registry contains three fields: an informal name for the signed object, the OID for the eContentType of the signed object, and a specification pointer that references the RFC in which the signed object is specified. The entries in this registry are managed by IETF Standards Action.
IANAは、このドキュメントで定義されているテンプレートを利用する「RPKI署名されたオブジェクト」タイプのレジストリを作成しました。このレジストリには、署名されたオブジェクトの非公式名、署名されたオブジェクトのecontentTypeのOID、および署名されたオブジェクトが指定されているRFCを参照する仕様ポインターの3つのフィールドが含まれています。このレジストリのエントリは、IETF標準アクションによって管理されます。
The registry has been initially populated with the following two entries.
レジストリには当初、次の2つのエントリが入力されています。
Name | OID | Specification
----------------------------------------------------------------
ROA | 1.2.840.113549.1.9.16.1.24 | RFC 6482
Manifest | 1.2.840.113549.1.9.16.1.26 | RFC 6486
The authors wish to thank Charles Gardiner, Russ Housley, and Derek Kong for their help and contributions. Additionally, the authors would like to thank Rob Austein, Roque Gagliano, Danny McPherson, Sean Turner, and Sam Weiler for their careful reviews and helpful comments.
著者は、チャールズガーディナー、ラストヒューズリー、デレクコンの助けと貢献に感謝したいと考えています。さらに、著者は、慎重なレビューと有益なコメントをしてくれたロブ・オーステイン、ロケ・ガグリアーノ、ダニー・マクファーソン、ショーン・ターナー、サム・ワイラーに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779] Lynn、C.、Kent、S。、およびK. Seo、「IPアドレスおよび識別子としてのX.509拡張」、RFC 3779、2004年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012.
[RFC6485] Huston、G。、「リソース公開キーインフラストラクチャ（RPKI）で使用するアルゴリズムとキーサイズのプロファイル」、RFC 6485、2012年2月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、2012年2月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
[X.208-88] CCITT。推奨X.208：抽象的構文表記の仕様（ASN.1）、1988。
[X.509-88] CCITT. Recommendation X.509: The Directory Authentication Framework, 1988.
[X.509-88] CCITT。推奨X.509：ディレクトリ認証フレームワーク、1988。
[RFC6019] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 6019, September 2010.
[RFC6019] Housley、R。、「BinaryTime：ASN.1で日付と時刻を表すための代替形式」、RFC 6019、2010年9月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、2012年2月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482] Lepinski、M.、Kent、S。、およびD. Kong、「Route Origin Authorizations（ROAS）のプロファイル」、RFC 6482、2012年2月。
Authors' Addresses
著者のアドレス
Matt Lepinski BBN Technologies 10 Moulton Street Cambridge MA 02138
Matt Lepinski BBN Technologies 10 Moulton Street Cambridge MA 02138
EMail: mlepinski@bbn.com
Andrew Chi BBN Technologies 10 Moulton Street Cambridge MA 02138
Andrew Chi BBN Technologies 10 Moulton Street Cambridge MA 02138
EMail: achi@bbn.com
Stephen Kent BBN Technologies 10 Moulton Street Cambridge MA 02138
Stephen Kent BBN Technologies 10 Moulton Street Cambridge MA 02138
EMail: kent@bbn.com