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)
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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）のアドレス空間の現在のリソース保有者およびAS番号の主張をサポートすることです。 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署名されたデータオブジェクトの（第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署名付きオブジェクトの新しいタイプを定義するために指定されなければならない付加的な部分を説明しています。また、署名されたオブジェクトの特定のタイプを指定するには、このテンプレートを使用して文書の例えば[RFC6482]を参照して、ルート発信許可（ROA）。
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アドレスとAS識別子のためのX.509拡張機能」で説明した用語と概念に精通していることを想定しています[ 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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署名されたオブジェクトは、RPKIオブジェクトはASN.1の識別符号化規則（DER）[X.509-88]を使用して符号化されなければならない署名された制限と、CMS [RFC5652]署名されたデータオブジェクトのプロファイルです。
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データ、すなわちID-たsignedData OID [RFC5652]、1.2.840.113549.1.7.2の署名されたデータ型です。
According to the CMS standard, the signed-data content type is the ASN.1 type SignedData:
CMSの標準によると、署名データのコンテンツタイプは、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オブジェクトを含まなければなりません。
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.
このフィールドは、このプロファイルで未定義のままにされます。 e-コンテンツは、署名されたオブジェクトのペイロードであり、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.
署名したオブジェクト・プロファイルが署名したオブジェクトのバージョン番号を提供しないことに注意してください。したがって、経時署名されたオブジェクトの新しいバージョンへの移行を容易にするためには、このプロファイルを使用して定義された署名されたオブジェクトの各タイプは、そのe-コンテンツ内のバージョン番号を含むことが推奨されます。
The certificates field MUST be included, and MUST contain exactly one certificate, the RPKI end-entity (EE) certificate needed to validate this signed object.
証明書フィールドが含まれなければならない、と正確に一つの証明書、この署名オブジェクトを検証するために必要なRPKIのエンドエンティティ（EE）証明書を含まなければなりません。
The crls field MUST be omitted.
CRLのフィールドは省略しなければなりません。
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.
バージョン番号は、SIDのSubjectKeyIdentifierの選択に対応する、3でなければなりません。
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証明書に表示されますSubjectKeyIdentifierでなければなりません。
The digestAlgorithm MUST consist of the OID of a digest algorithm that conforms to the RPKI Algorithms and Key Size Profile specification [RFC6485].
digestAlgorithmは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要素は、任意の特定の属性の単一のインスタンスだけを含まなければなりません。また、構文はAttributeValueのセットを可能にするにもかかわらず、RPKI署名付きオブジェクトに、attrValuesは、単一AttributeValueので構成しなければなりません。
The content-type attribute MUST be present. The attrType OID for the content-type attribute is 1.2.840.113549.1.9.3.
コンテンツ・タイプの属性が存在しなければなりません。コンテンツ・タイプの属性のATTRTYPEの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.
コンテンツ・タイプの属性のattrValuesはEncapsulatedContentInfoでのeContentTypeと一致しなければなりません。したがって、attrValuesは、データ構造に署名した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.
メッセージダイジェスト属性が存在しなければなりません。メッセージダイジェスト属性のATTRTYPE 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].
メッセージダイジェスト属性のattrValuesは、[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:
署名時の属性のattrValuesは、以下のように定義されています。
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.
time要素は、デジタル署名がコンテンツに適用されたときのローカルシステムクロックに基づいて、時間を指定します。
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バージョンで指定されたものと一致しました。 UTC時刻とGeneralizedTimeの使用に関する追加情報は、[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].
BinaryTime要素は、デジタル署名がコンテンツに適用されたときのローカルシステムクロックに基づいて、時間を指定します。 BinaryTime要素の正確な定義は、[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オブジェクト内のCRLフィールドが省略されています。
e. The version of the SignerInfo is 3.
電子。 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.
グラム。 SignerInfoオブジェクトでsignedAttrsフィールドには、次の4つ以外の属性が含まれていません：コンテンツ-type属性（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.
時間。 EncapsulatedContentInfo中のeContentTypeは、コンテンツ・タイプの属性にattrValuesと一致するOIDです。
i. The unsignedAttrs field in the SignerInfo object is omitted.
私。 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オブジェクトでdigestAlgorithmは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.
リットル。署名されたオブジェクトは、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.（CMS署名されたデータオブジェクト内に含まれる）EE証明書の公開鍵が正常に署名されたオブジェクトの署名を検証するために使用することができます。
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.
[RFC6487]で指定される3（CMS署名されたデータオブジェクト内に含まれる）EE証明書が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. e-コンテンツ：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 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.
RPKI署名オブジェクト内のデータの機密性のない仮定はありません。各署名されたオブジェクトの完全性及び真正性は、オブジェクトのデジタル署名の検証に基づいて、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.
著者は、彼らの助けと貢献のためにチャールズ・ガーディナー、ラスHousley、およびデレク・コングに感謝したいです。さらに、著者は彼らの慎重な口コミや有益なコメントのためにロブAusteinと、ロケガリアーノ、ダニー・マクファーソン、ショーン・ターナー、とサム・ワイラーに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]リン、C.、ケント、S.、およびK.ソ、 "IPアドレスとAS識別子のための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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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]ヒューストン、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]ヒューストン、G.、マイケルソン、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：抽象構文記法1（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.ケント、 "安全なインターネットルーティングをサポートするインフラストラクチャ"、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.、ケント、S.、およびD.コング、 "ルート起源権限のプロファイル（資産収益率）"、RFC 6482、2012年2月。
Authors' Addresses
著者のアドレス
Matt Lepinski BBN Technologies 10 Moulton Street Cambridge MA 02138
マット・Lepinski BBNテクノロジーズ10モールトンストリートケンブリッジMA 02138
EMail: mlepinski@bbn.com
メールアドレス：mlepinski@bbn.com
Andrew Chi BBN Technologies 10 Moulton Street Cambridge MA 02138
アンドリュー・チーBBNテクノロジーズ10モールトンストリートケンブリッジMA 02138
EMail: achi@bbn.com
メールアドレス：achi@bbn.com
Stephen Kent BBN Technologies 10 Moulton Street Cambridge MA 02138
スティーブン・ケントBBNテクノロジーズ10モールトンストリートケンブリッジMA 02138
EMail: kent@bbn.com
メールアドレス：kent@bbn.com