Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 6492 R. Loomans
Category: Standards Track B. Ellacott
ISSN: 2070-1721 APNIC
R. Austein
ISC
February 2012
A Protocol for Provisioning Resource Certificates
Abstract
抽象
This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports. This protocol is intended to be limited to the application of Internet Number Resource Certificate management and is not intended to be used as part of a more general certificate management framework.
この文書は、二つの当事者間の相互作用のためのプロトコルの仕様を介してインターネット番号リソース発行者（「発行者」）およびインターネット番号リソースの受信者（「対象」）との間の証明書管理の相互作用のためのフレームワークを定義します。プロトコルは、証明書発行、証明書失効、および証明書ステータス情報報告のアクションを包含し、発行者から被写体からの要求、および対応する応答の送信をサポートしています。このプロトコルは、インターネット番号リソース証明書の管理のアプリケーションに限定されるものであると、より一般的な証明書管理フレームワークの一部として使用されるものではありません。
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/rfc6492.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6492で取得することができます。
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 ....................................................3
1.1. Terminology ................................................3
2. Scope ...........................................................4
3. Protocol Specification ..........................................4
3.1. CMS Profile ................................................5
3.1.1. SignedData Content Type .............................5
3.1.2. CMS Object Validation ..............................10
3.1.3. ASN.1 Specification of the CMS Signed Object .......12
3.2. Common Message Format .....................................14
3.3. Control - Resource Class Query ............................16
3.3.1. Resource Class List Query ..........................16
3.3.2. Resource Class List Response .......................17
3.4. CA - Certificate Issuance .................................21
3.4.1. Certificate Issuance Request .......................21
3.4.2. Certificate Issuance Response ......................24
3.5. Certificate Revocation ....................................24
3.5.1. Certificate Revocation Request .....................25
3.5.2. Certificate Revocation Response ....................26
3.6. Request-Not-Performed Response ............................26
3.7. XML Schema ................................................27
4. Security Considerations ........................................29
5. IANA Considerations ............................................30
5.1. application/rpki-updown ...................................30
6. Acknowledgements ...............................................30
7. References .....................................................31
7.1. Normative References ......................................31
7.2. Informative References ....................................32
This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports. This protocol is intended to be limited to the application of Internet Number Resource certificate management and is not intended to be used as part of a more general certificate management framework.
この文書は、二つの当事者間の相互作用のためのプロトコルの仕様を介してインターネット番号リソース発行者（「発行者」）およびインターネット番号リソースの受信者（「対象」）との間の証明書管理の相互作用のためのフレームワークを定義します。プロトコルは、証明書発行、証明書失効、および証明書ステータス情報報告のアクションを包含し、発行者から被写体からの要求、および対応する応答の送信をサポートしています。このプロトコルは、インターネット番号リソース証明書管理のアプリケーションに限定することを意図され、より一般的な証明書管理フレームワークの一部として使用されるものではありません。
Terms used in this document are:
このドキュメントで使用される用語は、次のとおりです。
"Internet Number Resource" (or "resource") used in the context of this document to refer to Autonomous System (AS) numbers, IP version 4 addresses, and IP version 6 addresses.
「インターネットナンバーリソース」（または「リソース」）自律システム（AS）番号、IPバージョン4つのアドレス、およびIPバージョン6つのアドレスを参照するために、この文書の文脈で使用。
"issuer" used in the context of this document as an entity undertaking the role of resource issuer. An "issuer" is a Certification Authority (CA), and can issue resource certificates.
リソースの発行者の役割を引き受けるエンティティとしてこの文書の文脈で使用される「発行者」。 「発行者は、」認証局（CA）で、リソース証明書を発行することができます。
"subject" used in the context of this document as an entity undertaking the role of resource recipient who is the subject of a resource certificate. A "subject" may be issued with a CA-enabled certificate, allowing the entity to also assume the role of an "issuer".
リソース証明書の対象であるリソースの受信者の役割を引き受けるエンティティとしてこの文書の文脈で使用される「対象」。 「対象」は実体も「発行者」の役割を引き受けることができ、CA-有効証明書を発行することができます。
"resource class" a resource class refers to a collection of resources that can be certified in a single resource certificate by an issuer.
「リソースクラスは、」リソースクラスは、発行者が単一のリソース証明書に認定することが可能なリソースの集合を指します。
"server" in the context of this client/server protocol specification, the issuer assumes the role of the "server".
このクライアント/サーバプロトコル仕様の文脈における「サーバ」、発行者は、「サーバー」の役割を前提としています。
"client" in the context of this client/server protocol specification, the subject assumes the role of the "client".
このクライアント/サーバプロトコル仕様の文脈における「クライアント」は、対象は、「クライアント」の役割を担っています。
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]に記載されているように解釈されます。
This Resource Public Key Infrastructure (RPKI) certificate provisioning protocol defines a basic set of interactions that allow a subject to request certificate issuance, revocation, and status information from the issuer, and for an issuer to maintain an issued certificate set that is aligned to the allocation records relating to each subject. The issuer's resource allocation database is the authoritative source of what resource allocations the issuer may certify for a subject.
このリソース公開鍵インフラストラクチャは、（RPKI）は、証明書のプロビジョニングプロトコルは、発行者からの要求証明書発行、失効、およびステータス情報の対象を許す相互作用の基本セットを定義し、発行者のために整列され発行された証明書のセットを維持するために、各被験者に関連する割り当てレコード。発行者のリソース割り当てデータベースは、発行者が被験者に対して証明できるものリソース割り当ての信頼できるソースです。
A resource recipient (subject) may also undertake the role of a resource issuer (issuer).
リソースの受信者（被験者）は、リソース発行者（発行者）の役割を引き受けることができます。
This protocol specification does not encompass:
このプロトコル仕様は含みません。
o signing of objects with keys that are certified by resource certificates, nor the issuance of end-entity certificates.
Oリソースの証明書によって認証されたキーを持つオブジェクトの署名、また、エンドエンティティ証明書を発行。
o the specification of interaction with the issuer's resource allocation database, nor the specification of a protocol to manage the publication repository.
発行者のリソース割り当てデータベースとの相互作用の仕様、また出版物リポジトリを管理するためのプロトコルの仕様O。
o the interactions between client and server that establish identities, or the exchange of the certificates and validation Public Key Infrastructure (PKI) contexts used in the Cryptographic Message Syntax (CMS) [RFC5652] message exchange.
アイデンティティを確立し、クライアントとサーバの間の相互作用、または証明書の交換と検証公開鍵インフラストラクチャ暗号メッセージ構文（CMS）[RFC5652]メッセージ交換に使用される（PKI）の文脈O。
o the interactions between client and server that allow respective local CMS signing time values to be reset to mutually recognized values.
それぞれのローカルCMS署名時間値が相互に認識されている値にリセットすることができ、クライアントとサーバの間の相互作用、O。
This RPKI certificate provisioning protocol is expressed as a simple request/response interaction, where the client passes a request to the server, and the server generates a corresponding response.
このRPKI証明書プロビジョニングプロトコルは、クライアントがサーバに要求を渡し、サーバは対応する応答を生成する簡単な要求/応答相互作用として表されます。
The protocol is implemented as an exchange of messages.
プロトコルは、メッセージの交換として実装されます。
Messages are passed over an HTTP [RFC2616] end-to-end connection. A message exchange commences with the client initiating an HTTP POST with content type of "application/rpki-updown" and the message object as the body. The server's response is similarly an HTTP response, with the message object carried as the body of the response and with a response content type of "application/rpki-updown". The content of the POST and the server's response are "well-formed" CMS [RFC5652] objects, encoded using the Distinguished Encoding Rules (DER) for
メッセージは、HTTP [RFC2616]のエンドツーエンド接続を介して渡されます。メッセージ交換は、クライアントが体として「アプリケーション/ RPKI-アップダウン」のコンテンツタイプ及びメッセージオブジェクトとHTTP POSTを開始すると開始します。サーバの応答は、応答の本体として運ばメッセージオブジェクトとおよび「アプリケーション/ RPKI-アップダウン」の応答コンテンツタイプと同様にHTTPレスポンスです。 POSTとサーバの応答の内容は、識別符号化規則（DER）のために使用して符号化、CMS [RFC5652]のオブジェクトを「整形」されています
ASN.1 [X.509-88], formatted in accordance with the CMS profile specified in the following section. CMS is used as the signing format to sign the message object. The CMS message includes an end-entity (EE) certificate that is to be used to validate the CMS digital signature (see Section 3.1.1.4); the certificate chain that is used to validate the EE certificate MAY be included in the CMS message, and if it is not present it is assumed to have been communicated between the two entities, through mechanisms not defined in this specification.
ASN.1は、[X.509-88]、次のセクションで指定されたCMSプロファイルに従ってフォーマットされました。 CMSは、メッセージオブジェクトに署名する署名フォーマットとして使用されています。 CMSメッセージがCMSデジタル署名を検証するために使用されるエンドエンティティ（EE）証明書を含む（セクション3.1.1.4を参照）。 EE証明書を検証するために使用される証明書チェーンは、CMSメッセージに含まれてもよく、それが存在しない場合、本明細書に定義されていないメカニズムを介して、2つのエンティティ間で通信されているものとします。
The protocol's request/response interaction is assumed to be reliable, in that all requests MUST generate a matching response. The protocol requires sequential operation for each distinct client, where the server MUST NOT accept a client's request unless it has generated and sent a response to the client's previous request. Attempts by the client to initiate multiple requests in parallel (i.e., multiple concurrent requests with a common sender attribute (see Section 3.2) in the request) MUST be detected by the server and rejected with an error response (i.e., an error code 1101 response).
プロトコルのリクエスト/レスポンス相互作用は、その中のすべての要求が一致するレスポンスを生成しなければならない、信頼性があると想定されます。プロトコルは、それが生成され、クライアントの以前の要求に対する応答を送信した場合を除き、サーバーがクライアントの要求を受け入れてはいけません、それぞれ個別のクライアントのための一連の動作を必要とします。パラレル（共通送信者の属性を持つ、すなわち、複数の同時要求（リクエストに3.2節）を参照）で複数の要求を開始するクライアントによる試みは、サーバによって検出され、エラー応答（すなわち、エラーコード1101応答を拒絶しなければなりません）。
The format of the 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 id-signedData, OID = 1.2.840.113549.1.7.2. [RFC5652]
コンテンツタイプは、IDデータ、すなわちID-たsignedData、OID = 1.2.840.113549.1.7.2の署名されたデータ型です。 [RFC5652]
According to the CMS standard [RFC5652], signed-data content types are the ASN.1 type SignedData:
CMS標準[RFC5652]によると、署名されたデータのコンテンツタイプは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 Object Identifiers (OID)s 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）Sを含んでいます。このセットは、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 certificate provisioning protocol.
encapContentInfoコンテンツタイプ識別子とコンテンツ自体からなる、署名されたコンテンツです。 encapContentInfoはRPKI証明書プロビジョニングプロトコルのペイロードを表します。
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
The eContentType for the RPKI Protocol Message object is defined as id-ct-xml, and has the numerical value of 1.2.840.113549.1.9.16.1.28.
RPKIプロトコルメッセージオブジェクトのためのeContentTypeは、ID-CT-XMLとして定義され、及び1.2.840.113549.1.9.16.1.28の数値を有しています。
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
The content of an RPKI XML Protocol Object consists of a single protocol message, structured according to a defined XML schema, as defined in subsequent sections of this document. The eContent field of the CMS object is formally defined using ASN.1 as:
RPKI XMLプロトコルオブジェクトの内容は、この文書の以降のセクションで定義されるように、定義されたXMLスキーマに従って構造化単一プロトコルメッセージ、から成ります。 ：CMSオブジェクトのフィールドe-コンテンツの正式としてASN.1を使用して定義されます
RPKIXMLProtocolObject ::= OCTET STRING -- XML encoded message
This field MUST be present and MUST contain the single EE certificate of the key pair whose private key value was used to sign the CMS. This MUST NOT be an RPKI certificate, and SHOULD be a certificate that is recognized to attest to the identity of the party that created the CMS object.
このフィールドが存在しなければならないと秘密鍵の値CMSの署名に使用された鍵ペアの単一EE証明書を含まなければなりません。これは、RPKI証明書はならず、CMSオブジェクトを作成した当事者の身元を証明するために認識されている証明書であるべきです。
This field MAY contain CA certificates that a relying party MAY use to validate the EE certificate.
このフィールドは、証明書利用者は、EE証明書を検証するために使用するかもしれCA証明書を含むかもしれません。
This field MUST be present. The contents of the field are specified in [RFC5652]. The current Certificate Revocation List (CRL) issued by the same CA that issued the EE certificate of the key pair whose private key value was used to sign the CMS MUST be present in this field. This field MAY contain CRLs issued by other CAs covering CA certificates included in the certificates field of the CMS object (see Section 3.1.1.4). This field MUST NOT contain any other CRLs.
このフィールドが存在しなければなりません。フィールドの内容は、[RFC5652]で指定されています。現在の証明書失効リスト（CRL）の秘密鍵値はCMSの署名に使用された、この分野で存在しなければならない鍵ペアのEE証明書を発行した同じCAによって発行されました。このフィールドは、CMSオブジェクトの証明書フィールドに含まれる他のCA覆っCA証明書（セクション3.1.1.4を参照）によって発行されたCRLを含むかもしれません。このフィールドは、他の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 }
In this profile, the sid MUST be the SubjectKeyIdentifier that appears in the EE certificate carried in the CMS certificates field.
このプロファイルでは、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 field is defined as:
signedAttrsフィールドは次のように定義されています。
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
The signedAttr element MUST be present and MUST include the content-type and message-digest attributes [RFC5652]. If either the signing-time [RFC5652] attribute or the binary-signing-time attribute [RFC6019], or both attributes, are present, they MUST also be included as the SignedAttributes. Other signed attributes MUST NOT be included.
signedAttr要素が存在しなければならないとコンテンツタイプとメッセージダイジェスト属性[RFC5652]を含まなければなりません。署名タイム[RFC5652]属性またはバイナリ署名時刻属性[RFC6019]、または両方の属性のいずれかが、存在する場合、それらはsignedAttributesのように含まれなければなりません。他の署名の属性を含んではいけません。
The signedAttr MUST include only a single instance of any particular attribute. Additionally, even though the syntax allows for a SET OF AttributeValue, in this profile, the attrValues MUST consist of only a single AttributeValue.
signedAttrは、特定の属性の単一のインスタンスだけを含まなければなりません。また、構文はAttributeValueのセットを可能にしていても、このプロファイルでは、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です。
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
ContentType ::= OBJECT IDENTIFIER
The attrValues for the content-type attribute MUST match the eContentType in the EncapsulatedContentInfo. This OID value is defined as id-ct-xml and has the numerical value of 1.2.840.113549.1.9.16.1.28.
コンテンツ・タイプの属性のattrValuesはEncapsulatedContentInfoでのeContentTypeと一致しなければなりません。このOID値は、ID-CT-XMLとして定義され、1.2.840.113549.1.9.16.1.28の数値を有しています。
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です。
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
MessageDigest ::= OCTET STRING
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. The attrType OID for the signing-time attribute is 1.2.840.113549.1.9.5.
署名時の属性が存在してもよいです。署名時の属性の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 }
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
The signing-time attribute specifies the time, based on the local system clock, when the digital signature was applied to the content.
署名時間属性は、デジタル署名がコンテンツに適用されたローカルシステムクロックに基づいて、時間を指定します。
Guidelines regarding the use of UTCTime and GeneralizedTime in the signing-time attribute can be found in Section 11.3 of [RFC5652].
署名時刻属性でUTC時刻とGeneralizedTimeのの使用に関するガイドラインは、[RFC5652]のセクション11.3で見つけることができます。
Either one of the signing-time attribute or the binary-signing-time attribute, or both attributes, MUST be present. If both the signing-time and binary-signing-time attributes are present, they MUST both represent the same underlying time value.
署名時刻属性またはバイナリ署名時刻属性の一つ、または両方の属性のいずれかが、存在しなければなりません。署名タイムとバイナリ署名時間属性の両方が存在する場合、それらは両方とも同じ基礎時間値を表現しなければなりません。
The binary-signing-time attribute MAY be present. The attrType OID for the binary-signing-time attribute is 1.2.840.113549.1.9.16.2.46.
バイナリ署名時の属性が存在してもよいです。バイナリ署名時刻属性の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 }
BinarySigningTime ::= BinaryTime
BinaryTime ::= INTEGER (0..MAX)
The binary-signing-time attribute specifies the time, based on the local system clock, when the digital signature was applied to the content. The precise definition of the binary-signing-time attribute can be found at [RFC6019].
バイナリ署名時刻属性は、デジタル署名がコンテンツに適用されたローカルシステムクロックに基づいて、時間を指定します。バイナリ署名時間属性の正確な定義は[RFC6019]で見ることができます。
Either one of the signing-time or the binary-signing-time attributes, or both attributes, MUST be present. If both the signing-time and binary-signing-time attributes are present, they MUST both represent the same underlying time value.
署名タイムまたはバイナリ署名時刻属性、または両方の属性のいずれか一方は、存在していなければなりません。署名タイムとバイナリ署名時間属性の両方が存在する場合、それらは両方とも同じ基礎時間値を表現しなければなりません。
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 recipient of a CMS signed object can use the content of the object, the recipient MUST validate the signed object by verifying that all of the following conditions hold. A recipient may perform these checks in any order.
CMSの受信者オブジェクトは、オブジェクトの内容を使用することができます署名する前に、受信者は、次の条件がすべて保持することを確認することにより、署名付きオブジェクトを検証する必要があります。受信者は、任意の順序でこれらのチェックを実行してもよいです。
1. The CMS object is well formed, such that the signed object syntax complies with this specification. In particular, that each of the following is true:
1. CMSオブジェクトは署名されたオブジェクトの構文は、この仕様に準拠するように、十分に形成されています。具体的には、以下のそれぞれが真実であること：
a. The content-type of the CMS object is 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 present.
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 one each of the content-type attribute (OID 1.2.840.113549.1.9.3), the message-digest attribute (OID 1.2.840.113549.1.9.4), and either or both of a single instance of 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), and no other attributes.
F。 SignerInfoオブジェクト内signedAttrsフィールドが存在し、一方をコンテンツタイプ属性（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）、およびno他の属性の単一インスタンス。
g. The eContentType in the EncapsulatedContentInfo is an OID that matches the attrValue in the content-type attribute and has the attrValue of id-ct-xml.
グラム。 EncapsulatedContentInfo中のeContentTypeは、コンテンツタイプ属性にATTRVALUEと一致し、ID-CT-XMLのATTRVALUEを有するOIDです。
h. The unsignedAttrs field in the SignerInfo object is omitted.
時間。 SignerInfoオブジェクトでunsignedAttrsフィールドが省略されています。
i. If both the signing-time attribute and the binary-signing-time attribute are present, then their values represent the same time.
私。署名時間属性とバイナリ署名時間属性の両方が存在する場合、それらの値が同じ時刻を表します。
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 particular, there exists a valid certification path from a trust anchor selected by the recipient to this EE certificate.
3.（CMS署名されたデータオブジェクト内に含まれる）EE証明書が有効EE証明書です。特に、このEE証明書の受領者が選択したトラストアンカーからの有効な証明書パスが存在します。
4. At the current time, the EE certificate is not revoked. This can be determined by confirming that the CRL contained in the crls field of the CMS signed data object is a current valid CRL, issued by the same CA that issued the EE certificate, and the CRL does not list the serial number of the EE certificate.
4.現在の時点では、EE証明書が取り消されていません。これは、CMSのCRLをフィールドに含まれるCRLは、データオブジェクトがEE証明書を発行した同じCAによって発行され、現在有効なCRL、ある署名したことを確認することにより決定することができ、およびCRLは、EE証明書のシリアル番号が表示されません。 。
5. The time represented by the signing-time attribute or the binary-signing-time attribute is greater than or equal to the time value passed in previously valid CMS objects that were passed from the same originator to this recipient. This signing time value MAY lie within the Validity Time of the EE certificate, but the EE certificate SHOULD NOT be considered invalid if this is not the case when all other checks listed here are passed.
5.署名時間属性またはバイナリ署名時刻属性によって表される時間は、この受信者に同じ発信元から渡された以前に有効なCMSオブジェクトに渡された時間値以上です。これは、ここに記載されている他のすべてのチェックに合格している場合ではない場合、値はEE証明書が、EE証明書の有効時間内に存在するかもしれない。この署名時間は無効とみなされるべきではありません。
The following is the ASN.1 specification of the CMS signed object used by the RPKI provisioning protocol.
以下は、RPKIプロビジョニングプロトコルによって使用されるCMS署名されたオブジェクトのASN.1仕様です。
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
RPKIXMLProtocolObject ::= OCTET STRING -- XML encoded message
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
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
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
SignatureValue ::= OCTET STRING
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
ContentType ::= OBJECT IDENTIFIER
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
MessageDigest ::= OCTET STRING
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }
id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 46 }
BinarySigningTime ::= BinaryTime
BinaryTime ::= INTEGER (0..MAX)
The XML template for all messages is informally described as follows (the RELAX NG compact form schema that formally describes the protocol message objects is contained in Section 3.7):
次のようにすべてのメッセージのためのXMLテンプレートは、非公式（正式プロトコルメッセージオブジェクトを記述するRELAX NGコンパクトスキーマは、セクション3.7に含まれる）に記載されています。
---------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?> <message xmlns="http://www.apnic.net/specs/rescerts/up-down/"
<？xml version = "1.0" エンコード= "UTF-8"？> <メッセージのxmlns = "http://www.apnic.net/specs/rescerts/up-down/"
version="1"
sender="sender name"
recipient="recipient name"
type="message type">
[payload]
[ペイロード]
</message>
</メッセージ>
---------------------------------------------------------------
version: the value of this attribute is the version of this protocol. This document describes version 1.
バージョン：この属性の値は、このプロトコルのバージョンです。このドキュメントでは、バージョン1を説明します。
sender: the value of this attribute is the agreed name of the message sender, as determined between the client and the server by prior arrangement.
送信者：事前の取り決めにより、クライアントとサーバーの間で決定され、この属性の値は、メッセージの送信者の合意名前です。
recipient: the value of this attribute is the agreed name of the message recipient, as determined between the client and the server by prior arrangement.
受信者：事前の取り決めにより、クライアントとサーバーの間で決定され、この属性の値は、メッセージ受信者の合意名前です。
type: the possible values of this attribute are "list", "list_response", "issue", "issue_response", "revoke", "revoke_response", and "error_response".
タイプ：この属性の可能な値は、「リスト」、「list_response」、「問題」、「issue_response」、「取り消し」、「revoke_response」であり、「error_response」。
Conforming parsers MUST reject any document with a version number they do not understand or with any elements or attributes they do not understand. Servers must generate an error response when receiving such a request. Clients should generate an error when receiving such a response.
パーサを準拠することは、彼らが理解していないバージョン番号または、彼らは理解していない任意の要素や属性を持つ任意の文書を拒絶しなければなりません。そのような要求を受信したときにサーバーがエラー応答を生成する必要があります。このような応答を受信したとき、クライアントは、エラーを生成する必要があります。
The encapsulated content of the CMS wrapping is an XML document. The remainder of this protocol specification omits this CMS wrapper and only discusses the XML document.
CMSの折り返しのカプセル化されたコンテンツは、XML文書です。このプロトコル仕様の残りの部分は、このCMSラッパーを省略のみXML文書を論じています。
Messages are checked using the following tests:
メッセージは、次のテストを使用してチェックされます。
3. Check that the XML sender and recipient attributes reference a known client and this server's system respectively for a query, and the previously addressed server and this client for a response.
XMLの送信者と受信者の属性は、クエリのために、それぞれ既知のクライアントとこのサーバーのシステムを参照し、以前に応答するサーバと、このクライアントを取り上げ3.チェックしていること。
4. Verify the digital signature using the public key provided in the certificate carried in the CMS wrapper (see test 2 of Section 3.1.2).
4. CMSラッパーで運ば証明書に提供された公開鍵を用いてデジタル署名を確認し（セクション3.1.2の試験2を参照のこと）。
5. Validate the CMS-provided certificate using the PKI that has been determined by prior arrangement between the client and server (see test 3 of Section 3.1.2).
5.クライアントとサーバとの間の事前の取り決めによって決定されたPKIを用いたCMS-提供証明書を検証し（3.1.2項の試験3を参照されたいです）。
6. Check that the signing time of the CMS is equal to or greater than the signing time provided in the most recent previous message that this recipient has received from this sender (see test 4 of Section 3.1.2).
6.チェックCMSの署名時間がこの受信者は、この送信者から受信した最も最近の前のメッセージに設けられた署名時間以上であること（セクション3.1.2の試験4を参照します）。
These checks SHOULD be applied in the order specified here.
これらのチェックは、ここで指定された順序で適用されるべきです。
Any errors encountered while checking items 1 through 7 MUST cause a server to generate an "HTTP 400 Bad Request" response to the HTTP POST operation. An error in step 7 MUST cause the server to generate a "Request-Not-Performed" error response. Any errors encountered in these tests by a client SHOULD cause the client to generate an error.
7を通じて項目1を確認しながら、発生したエラーは、サーバーがHTTPのPOST操作への「HTTP 400不正な要求」応答を生成させなければなりません。ステップ7でのエラーは、サーバーが「リクエスト-NOT-公演」エラー応答を生成させなければなりません。クライアントによってこれらの試験で発生したエラーは、クライアントがエラーを発生させる原因となるべきです。
A server MAY perform flow control on the rate of processed requests. Requests not processed due to such a flow control constraint MAY cause the server to generate an "HTTP 503 Service Unavailable" response. An HTTP 503 response MAY include an HTTP Retry-After: header as a hint to the client.
サーバーは処理要求のレートでフロー制御を行うことができます。このようなフロー制御の制約に処理されていない要求は、サーバーが「HTTP 503サービスは利用できません」応答を生成することがあります。クライアントへのヒントとしてヘッダ：HTTP 503応答は、再試行後、HTTPを含むかもしれません。
This query is used for a client to query a server for a list of all resources that have been allocated or assigned by the server to the client. In addition, the server's response will contain a copy of the current certificates issued by the server's CA where this client is the certificate's subject.
このクエリは、割り当てられたか、サーバからクライアントに割り当てられているすべてのリソースのリストをサーバーに照会するために、クライアントのために使用されています。また、サーバーの応答は、このクライアントは、証明書の対象となり、サーバのCAによって発行された現在の証明書のコピーが含まれています。
The value of the message "type" message attribute for this query is:
このクエリのメッセージ「タイプ」message属性の値は次のとおりです。
type="list"
タイプ=「リスト」
---------------------------------------------------------------
Payload:
ペイロード：
[No message payload is defined for this query]
[メッセージ・ペイロードは、このクエリのために定義されていません]
---------------------------------------------------------------
The value of the message "type" element for this response is:
この応答のメッセージ「タイプ」要素の値です。
type="list_response"
タイプは、= "list_response"
---------------------------------------------------------------
Payload:
ペイロード：
<class class_name="class name" cert_url="url" resource_set_as="as resource set" resource_set_ipv4="ipv4 resource set" resource_set_ipv6="ipv6 resource set" resource_set_notafter="datetime" suggested_sia_head="[directory uri]" > <certificate cert_url="url" req_resource_set_as="as resource set" req_resource_set_ipv4="ipv4 resource set" req_resource_set_ipv6="ipv6 resource set" > [certificate] </certificate>
<クラスCLASS_NAME = "クラス名" "リソースセットとして" cert_url = "URL" resource_set_asの= resource_set_ipv4 = "のIPv4リソースセット" resource_set_ipv6 = "IPv6のリソースセット" resource_set_notafter = "日時" suggested_sia_head = "[ディレクトリのURI]"> <証明書req_resource_set_ipv4 = "IPv4のリソースセット" req_resource_set_ipv6は= "IPv6のリソースセット">証明書</証明書> "リソース・セットとして" cert_url = "URL" req_resource_set_as =
...
。。。
(repeated for each current certificate where the client is the certificate's subject)
（クライアントが証明書の対象となり、各現在の証明書のために繰り返されます）
<issuer>[issuer's certificate]</issuer> </class>
<発行元> [発行者の証明書] </発行者> </クラス>
...
。。。
(repeated for each of the issuer's resource class where the client has been allocated resources)
（クライアントがリソースを割り当てられている発行者のリソースクラスごとに繰り返し）
---------------------------------------------------------------
Where the client has been allocated resources from multiple resource classes, the response MUST contain multiple class elements that correspond to the complete set of the issuer's resource classes where the client holds allocated resources. Those issuer's resource classes where the client holds no allocated resources MUST NOT be included in the response.
クライアントが複数のリソースクラスからリソースを割り当てられている場合は、応答は、クライアントが割り当てられたリソースを保持している発行者のリソースクラスの完全なセットに対応する複数のクラス要素を含まなければなりません。クライアントが何も割り当てられたリソースを保持していないこれらの発行者のリソースクラスは、応答に含まれてはなりません。
Where the issuer has issued multiple certificates in a resource class signed with different keys (as may occur during a staged issuer-key rollover), only the most recent certificate issued with the currently "active" issuer's key is to be listed in the response.
発行者は、（段階的な発行者キーロールオーバー時に発生する可能性がありますように）異なる鍵で署名されたリソースクラスに複数の証明書を発行した場合には、唯一の最新の証明書が発行され、現在「アクティブ」発行者のキーが反応して記載されていることがあると。
Each "class" element describes a set of resources that are certified within the scope of a single certificate, referring to a single resource class with a common validation path.
各「クラス」要素は、共通の検証パスで単一のリソース・クラスを参照して、単一の証明書の範囲内で認定されたリソースのセットを記述する。
class_name: the value of this attribute is the issuer-assigned name of the issuer's resource class.
CLASS_NAME：この属性の値は、発行者のリソースクラスの発行者が割り当てた名前です。
cert_url: in the context of a class element, the value of this attribute is a pointer to the issuer's CA certificate (i.e., a reference to the immediate superior certificate, being the CA-enabled certificate where the issuer is the certificate's subject). Its value is a comma-separated list of URIs, of which at least one MUST be an rsync URI [RFC5781]. Any comma values within a URI MUST be escaped ("%2C"). The ordering of the list may be interpreted by the client as a relative preference for access methods as expressed by the publisher of this certificate.
cert_url：クラス要素の文脈において、この属性の値は、発行者のCA証明書へのポインタである（すなわち、即時に優れた証明書を参照し、ある発行者は、証明書の対象となるCA証明書が有効）。その値は、少なくとも1つのrsyncのURI [RFC5781]でなければならないのURIのカンマ区切りリスト、です。 URI内の任意のカンマ値（「％2C」）エスケープする必要があります。リストの順序は、この証明書の発行元で表されるアクセス方法のための相対的な嗜好としてクライアントによって解釈されてもよいです。
resource_set_as: in the context of a class element, the value of this attribute is the set of AS numbers and AS number ranges that the issuer has allocated to the client within the scope of this resource class, presented in ASCII as a comma-separated list. The list elements are decimal integer values and ranges of decimal integers specified by the lowest and highest values of the range with a hyphen delimiter, using the canonical order as described in [RFC3779], without leading zeros, and with no white space or punctuation other than the comma and the hyphen range designator (e.g., resource_set_as="123,456-789,123456"). If there are no AS numbers in this resource class, then the empty AS set is represented by a null string value ("") for this attribute.
resource_set_as：クラス要素のコンテキストで、この属性の値は、AS番号の集合であるとAS番号は、カンマ区切りリストとしてASCIIに提示し、発行者は、このリソースクラスの範囲内でクライアントに割り当てられたことを範囲。リスト要素は、先行ゼロなしで、10進数の整数値と[RFC3779]に記載されているように標準的な順序を使用して、ハイフン区切り文字と範囲の最小値と最大値で指定された小数点整数の範囲であり、そして無空白または他の句読点とカンマやハイフンの範囲指定子（例えば、resource_set_as =「123,456-789,123456」）より。何がこのリソースクラスでのAS番号がある場合は、空のASセットは、この属性に空文字列（「」）値で表現されていません。
resource_set_ipv4: in the context of a class element, the value of this attribute is the set of IPv4 addresses that the issuer has allocated to the client within the scope of this resource class. The value is presented in ASCII as a comma-separated list of elements. Each element is either an address prefix using the notation of <dotted quad>/mask length, or a range specified as the lowest and highest values of the range in dotted quad notation with a hyphen delimiter. The list is presented in canonical order, as described in [RFC3779]. The dotted quad notation is without leading zeros, and the list contains no white space or punctuation other than the period, forward slash, hyphen, and comma (e.g., resource_set_ipv4="192.0.2.0/26,192.0.2.66-192.0.2.76"). If there are no IPv4 addresses in this resource class, the empty IPv4 address set is represented by a null string value ("") for this attribute.
resource_set_ipv4：クラス要素のコンテキストで、この属性の値は、IPv4のセットは、発行者が、このリソースクラスの範囲内でクライアントに割り当てられたことを対処しています。値は、要素のカンマ区切りリストとしてASCIIに提示されています。各要素は、<点線クワッド> /マスク長の表記法を使用して、アドレスプレフィックス、又はハイフン区切り文字が点在クワッド表記の範囲の最低および最高値として指定された範囲のいずれかです。 [RFC3779]に記載されているようにリストは、標準的な順序で提示されています。点線クワッド表記は、先行ゼロなしで、リストには、空白や句読点期間以外の、スラッシュ、ハイフン、およびコンマ（例えば、resource_set_ipv4 =「192.0.2.0/26,192.0.2.66-192.0.2.76」）を含みません。このリソースクラスにはIPv4のアドレスが存在しない場合は、空のIPv4アドレスセットは、この属性のヌル文字列値（「」）で表されます。
resource_set_ipv6: in the context of a class element, the value of this attribute is the set of IPv6 addresses that the issuer has allocated to the client within the scope of this resource class. The value is presented in ASCII as a comma-separated list of elements. Each element is either an address prefix using the notation of <hex nibble sequence>/mask length, or a range specified as lowest and highest values of the range in hex nibble notation with a hyphen delimiter. Trailing zero nibbles are truncated and represented by '::'. The list is presented in canonical order, as described in [RFC3779]. The hex nibble sequence notation is without leading zeros, and the list contains no white space or punctuation other than the colon, forward slash, hyphen, and comma, and conforms to the canonical format of [RFC5952] (e.g., resource_set_ipv6="2001:db8::/48,2001:db8:2::-2001:db8:5::"). The XML Schema data type is "http://www.w3.org/TR/xmlschema-2/#hexBinary" and the value is case insensitive, with the canonical form being lower case. If there are no IPv6 addresses in this resource class, the empty IPv6 address set is represented by a null string value ("") for this attribute.
resource_set_ipv6：クラス要素のコンテキストで、この属性の値は、IPv6のセットは、発行者が、このリソースクラスの範囲内でクライアントに割り当てられたことを対処しています。値は、要素のカンマ区切りリストとしてASCIIに提示されています。各要素は、<進ニブル配列> /マスク長の表記、または最小とハイフン区切り文字でヘクスニブル表記の範囲の最高値として指定された範囲を使用してアドレスのプレフィックスのいずれかです。末尾のゼロニブルは切り捨てとによって表現される「::」。 [RFC3779]に記載されているようにリストは、標準的な順序で提示されています。進ニブル配列表記は、先行ゼロなしで、リストには、空白や句読点結腸以外、スラッシュ、ハイフン、コンマを含まない、及び[RFC5952]（例えば、resource_set_ipv6 = "2001標準フォーマットに準拠しています。 DB8 :: / 48,2001：DB8：2 :: - 2001：DB8：5 :: "）。 XMLスキーマデータ型は、「http://www.w3.org/TR/xmlschema-2/#hexBinary」であり、値は正規の形式は小文字であると、大文字と小文字を区別しないです。このリソースクラスにはIPv6のアドレスが存在しない場合は、空のIPv6アドレスセットは、この属性のヌル文字列値（「」）で表されます。
resource_set_notafter: The value of this attribute specifies the date/time that would be set in the Validity notAfter field in any new certificate issued for this particular client within the scope of this resource class, should the client request a new certificate. The time format used for the value of this attribute is specified as defined in ISO 8601 [ISO.8601:2004], and MUST use UTC time represented as YYYY-MM-DDThh:mm:ssZ (e.g., 2007-11-29T04:40:00Z). If the client's certificate has a validity notAfter time that is different from this time, then the client SHOULD request a new certificate to be issued for this resource class.
resource_set_notafter：この属性の値は、新しい証明すべきクライアント要求をこのリソースクラスの範囲内で、この特定のクライアントのために発行された新しい証明書のフィールドnotAfterの妥当性に設定されます日付/時間を指定します。この属性の値のために使用される時間形式はISO 8601で定義されている[ISO.8601：2004]が指定されており、YYYY-MM-DDTHHとして表さUTC時間を使用しなければならない：MM：SSZ（例えば、2007-11-29T04： 40：00Z）。クライアントの証明書がこの時間と異なる時間notAfterの妥当性を持っている場合、クライアントは、このリソースクラスのために発行される新しい証明書を要求する必要があります。
suggested_sia_head: (OPTIONAL) If this field is present, then its value is a directory URI that indicates a repository publication point that the server has made available to the client to use for the client's collection of published products. This specification does not encompass the protocols that the client may use with the operator of the repository publication point in order to publish objects at this publication point.
suggested_sia_head：このフィールドが存在する場合（オプション）、その値は、サーバーが公開された製品のクライアントの収集のために使用するようにクライアントが利用できるようにしているリポジトリの公開ポイントを示すディレクトリURIです。この仕様では、クライアントは、この出版物の時点でオブジェクトを公開するために、リポジトリの公開ポイントのオペレータで使用可能なプロトコルを包含していません。
[issuer's certificate] value is the Base64 encoding of the DER-encoded issuer's CA certificate (the CA-enabled certificate where the issuer is the certificate's subject).
【発行者の証明書]の値は、DER符号化された発行者のCA証明書（発行者が証明書の主題であるCA-有効証明書）のBase64エンコードです。
Each certificate element describes the most recently issued current certificate where the certificate's subject refers to the client for each active client key pair. A "current" certificate is a non-expired, non-revoked certificate. If no current certificate has been issued, then no certificate element is to be included in the response.
各証明書の要素は、証明書のサブジェクトは、アクティブな各クライアントの鍵ペアのクライアントを指し、最も最近発行された現在の証明書について説明します。 「現在の」証明書が期限切れでない、非取り消された証明書です。何の現在の証明書が発行されていない場合は、何の証明書の要素は、応答に含まれるべきではありません。
cert_url: in the context of a certificate element, this is a pointer to the location where the certificate issuer has published this certificate. This field is the issuer's suggestion for the Authority Information Access (AIA) field for the subject to use in subordinate certificates that are issued by the subject. According to the Resource Certificate Profile [RFC6487], the AIA field is a non-empty (contains a minimum of 1 element) list of URI's, one of which MUST be an rsync URI [RFC5781]. The order of URI's in the AIA field may be interpreted as the publisher's relative preference for access methods for this certificate. The cert_url conforms to this AIA specification. Its value is a comma-separated list of URIs, one of which MUST be an rsync URI. Any comma values within a URI MUST be escaped ("%2C").
cert_url：証明書の要素との関連で、このことは、証明書発行者は、この証明書を発行していた場所へのポインタです。このフィールドには、対象によって発行された下位証明書で使用する対象のための機関情報アクセス（AIA）フィールドの発行者の提案です。リソース証明書プロファイル[RFC6487]によれば、AIAのフィールドが空である（1つの要素の最小値を含む）のURIのリスト、の一つはrsyncのURI [RFC5781]でなければなりません。 AIAフィールドのURIの順序は、この証明書のためのアクセス方法のために運営者の相対的な嗜好として解釈することができます。 cert_urlこのAIAの仕様に準拠しています。その値は、rsyncのURIでなければなりませんそのうちの一つのURIのカンマ区切りリスト、です。 URI内の任意のカンマ値（「％2C」）エスケープする必要があります。
req_resource_set_as: the set of AS numbers that were specified in the corresponding original certificate request that defined the maximal requested span of the certified AS number set, following the syntax described above. If this attribute was present in the certificate request, then the attribute MUST be present in this response; otherwise, it MUST NOT be present.
req_resource_set_as：上記の構文以下、数セットとして認定の最大の要求されたスパンを定義して対応する元の証明書の要求で指定されたAS番号のセット。この属性は、証明書の要求に存在していた場合、その属性は、この応答に存在する必要があります。そうでない場合は、それが存在してはなりません。
req_resource_set_ipv4: the set of IPv4 addresses that were specified in the corresponding original certificate request that defined the maximal requested span of the certified IPv4 address set, following the syntax described above. If this attribute was present in the certificate request, then the attribute MUST be present in this response; otherwise, it MUST NOT be present.
req_resource_set_ipv4：上記の構文以下、認定されたIPv4アドレスセットの最大の要求されたスパンを定義して対応する元の証明書の要求で指定されたIPv4アドレスのセット。この属性は、証明書の要求に存在していた場合、その属性は、この応答に存在する必要があります。そうでない場合は、それが存在してはなりません。
req_resource_set_ipv6: the set of IPv6 addresses that were specified in the corresponding original certificate request that defined the maximal requested span of the certified IPv6 address set, following the syntax described above. If this attribute was present in the certificate request, then the attribute MUST be present in this response; otherwise, it MUST NOT be present.
req_resource_set_ipv6：上記の構文に従って、認定されたIPv6アドレスセットの最大の要求されたスパンを定義し、対応する元の証明書の要求で指定されたIPv6アドレスのセット。この属性は、証明書の要求に存在していた場合、その属性は、この応答に存在する必要があります。そうでない場合は、それが存在してはなりません。
[certificate] value is the Base64 encoding of the DER-encoded certificate.
[証明書]の値は、DER符号化された証明書のBase64エンコーディングです。
This query is used by the client to request the server's CA to issue a resource certificate for the resources that have been allocated or assigned to the client. If the request can be successfully processed, then the server's response includes the issued certificate.
このクエリは、割り当てられたか、クライアントに割り当てられているリソースのリソース証明書を発行するために、サーバーのCAを要求するためにクライアントによって使用されます。要求が正常に処理することができた場合は、サーバーの応答が発行された証明書が含まれています。
The value of the message "type" element for this request is:
このリクエストのメッセージ「タイプ」要素の値は次のとおりです。
type="issue"
タイプ=「問題」
---------------------------------------------------------------
Payload:
ペイロード：
<request class_name="class name" req_resource_set_as="as resource set" req_resource_set_ipv4="ipv4 resource set" req_resource_set_ipv6="ipv6 resource set"> [Certificate request] </request>
<リクエストCLASS_NAME = "クラス名" req_resource_set_as = "リソースセットとして" req_resource_set_ipv4 = "IPv4のリソースセット" req_resource_set_ipv6は= "IPv6のリソースセット"> [証明書要求] </リクエスト>
---------------------------------------------------------------
The client MUST use different key pairs for each distinct resource class.
クライアントは、各個別のリソースクラスに異なる鍵のペアを使用しなければなりません。
The req_resource_set attributes are optional in the request.
req_resource_set属性はリクエストにオプションです。
If none of the req_resource_set attributes are specified, then the request signifies that the complete set of all resources that match the client's current resource allocation is to be included in the issued certificate.
req_resource_set属性のいずれも指定されていない場合、その要求は、クライアントの現在のリソース割り当てに一致するすべてのリソースの完全なセットが発行された証明書に含めることを意味します。
If any of the req_resource_set attributes are specified in the request, then any missing req_resource_set attributes are to be interpreted as specifying the complete set of the corresponding resource type that match the client's current resource allocation are to be included in the issued certificate.
req_resource_set属性のいずれかが要求に指定されている場合は、欠落しているreq_resource_set属性が発行された証明書に含まれているクライアントの現在のリソース割り当てに一致する対応するリソースタイプの完全なセットを指定すると解釈されるべきです。
If the value of any included req_resource_set attributes is the null value (""), then this indicates that no resources of that resource type are to be included in the issued certificate.
いずれかの値がNULL値（「」）である属性req_resource_set含まれている場合、これは、そのリソースタイプのないリソースが発行した証明書に含まれないことを示しています。
The requested resource set values are held as a local record by the issuer against the resource class and the client's public key. Any subsequent Certificate Issuance Requests that specify the same resource class and the same client's public key will (re)set the issuer's local record of the requested resource sets to the most recently specified values.
要求されたリソースの設定値は、リソースのクラスに対して、発行者とクライアントの公開鍵でローカルレコードとして保持されています。同じリソースクラスと同じクライアントの公開鍵を指定し、後続の証明書発行要求は、（再）します最近指定された値に要求されたリソースセットの発行者のローカルレコードを設定します。
class_name: value is the server's identifier of a resource class.
CLASS_NAME：値は、リソースクラスのサーバの識別子です。
req_resource_set_as: (OPTIONAL) the set of AS numbers that define the maximal requested span of the certified AS number set, formatted as per the resource_set_as attribute of the resource class list response.
req_resource_set_as：（オプション）リソースクラスリスト応答のresource_set_as属性に従ってフォーマットされた数値セット、AS認定の最大の要求されたスパンを定義するAS番号のセット。
req_resource_set_ipv4: (OPTIONAL) the set of IPv4 addresses that define the maximal requested span of the certified IPv4 address set, formatted as per the resource_set_ipv4 attribute of the resource class list response.
req_resource_set_ipv4：リソースクラスリスト応答のresource_set_ipv4属性ごとにフォーマットされた認定IPv4アドレスセットの最大の要求されたスパンを定義するIPv4アドレスのセット（オプション）。
req_resource_set_ipv6: (OPTIONAL) the set of IPv6 addresses that define the maximal requested span of the certified IPv6 address set, formatted as per the resource_set_ipv6 attribute of the resource class list response.
req_resource_set_ipv6：リソースクラスリスト応答のresource_set_ipv6属性ごとにフォーマットされた認定IPv6アドレスセットの最大の要求されたスパンを定義するIPv6アドレスのセット（オプション）。
[Certificate request] value is the certificate request. This is a Base64 encoded DER version of a request formatted using PKCS#10 [RFC2986]. The certificate request is signed using the private key part of the key pair whose public part is the subject key value in the certification request. The signing algorithm is specified in [RFC6485]. (This signature component is intended to demonstrate proof of possession of the private key.)
[証明書要求]の値は、証明書の要求です。これは、Base64は、PKCS＃10 [RFC2986]を使用してフォーマットされたリクエストのDERバージョンを符号化します。証明書要求は、公開部分証明要求におけるサブジェクトキー値である鍵ペアの秘密鍵部分を使用して署名されます。署名アルゴリズムは[RFC6485]で指定されています。 （この署名コンポーネントは、秘密鍵の所有の証拠を実証することを意図しています。）
The response to this request is a Certificate Issuance Response if the request can be processed online. If the request cannot be undertaken immediately, then the server MUST respond with a "Request-Not-Performed" message, using the appropriate error code:
要求は、オンライン処理できる場合は、この要求に対する応答は、証明書発行応答です。要求がすぐに着手することができない場合、サーバは適切なエラーコードを使用して、「要求-行われていない」メッセージで応じなければなりません：
o If the resource class is not defined by the server, then the server MUST return error code 1201.
リソースクラスは、サーバーで定義されていない場合は、O、サーバは、エラーコード1201を返さなければなりません。
o If the client holds no resources in a defined resource class, then the server MUST return error code 1202 and not proceed with the request.
クライアントが定義されたリソースクラスにはリソースを保持していない場合はO、サーバは、エラーコード1202を返さなければならないと要求を進めません。
o If the certificate request payload is badly formed, then the server MUST return error code 1203.
証明書要求ペイロードがひどく形成されている場合は、O、サーバは、エラーコード1203返さなければなりません。
o If the public key used in the certificate request implies that the client is attempting to use identical key pairs for multiple resource classes, then the server MUST respond with a 1204 error code.
証明書の要求に使用される公開鍵は、クライアントが複数のリソースクラスに対して同一の鍵ペアを使用しようとしていることを意味している場合、O、その後、サーバーは、1204のエラーコードで応じなければなりません。
o If the certificate issuer uses an off-line process to undertake certificate issuance, and the server cannot directly respond to the certificate issuance request with an issued certificate, then the certificate issuer MUST respond to the first instance of this request with an error code 1104 to indicate that the request is being processed asynchronously. Subsequent repetitions of this request while the off-line actions are being undertaken SHOULD cause a response with error code 1101. In this context, where off-line processes are invoked for certificate issuance, if the certificate issuer determines in processing the request that the issued certificate would be identical in all respects to the most recently issued certificate for this client, other than the certificate's serial number, were the certificate to be issued, the issuer may choose to respond with the most recently issued certificate and not initiate an off-line certificate issuance request.
証明書発行者が証明書発行に着手するオフラインプロセスを使用し、サーバが直接発行された証明書と証明書発行要求に応答できない場合は、O、その後、証明書発行者は、エラーコード1104でこの要求の最初のインスタンスに反応しなければなりません要求が非同期に処理されていることを示します。証明書発行者が発行した要求を処理する際に決定した場合に行われているオフラインのアクションは、オフラインプロセスは、証明書発行のために呼び出され、この文脈では、エラーコード1101で応答を引き起こすべきであるが、この要求のその後の繰り返し証明書は、証明書が発行されるようにして、発行者は、最近発行された証明書で応答することを選択するとオフラインを開始しないことがあり、証明書のシリアル番号以外のこのクライアントのための最も最近発行された証明書にすべての点で同一であります証明書発行要求。
Note that a client, when receiving a 1104 response to a certificate issuance request, MAY periodically resubmit the request, in which case the client MUST receive an error code 1101 response while the request is being processed, and a Certificate Issuance Response when the certificate issuance process has completed. In such circumstances, a client SHOULD limit the frequency of such repeated requests to no more than 1 request in each 24-hour interval.
要求が処理され、証明書発行応答場合、証明書発行されている間に、クライアントは、エラーコード1101応答を受信しなければならない場合、クライアントは、証明書発行要求に1104の応答を受信した場合、定期的にリクエストを再送信可能性がありますプロセスが完了しました。このような状況では、クライアントは、各24時間間隔でない1つの以上のリクエストにそのような繰り返し要求の頻度を制限する必要があります。
The value of the message "type" element for this response is:
この応答のメッセージ「タイプ」要素の値です。
type="issue_response"
タイプは、= "issue_response"
---------------------------------------------------------------
Payload:
ペイロード：
<class class_name="class name" cert_url="url" resource_set_as="as resource set" resource_set_ipv4="ipv4 resource set" resource_set_ipv6="ipv6 resource set" > <certificate cert_url="url" req_resource_set_as="as resource set" req_resource_set_ipv4="ipv4 resource set" req_resource_set_ipv6="ipv6 resource set" > [certificate] </certificate> <issuer>[issuer's certificate]</issuer> </class>
<クラスCLASS_NAME = "クラス名" cert_url = "URL" resource_set_as = "リソースセットとして" resource_set_ipv4 = "IPv4のリソースセット" resource_set_ipv6 = "IPv6のリソースセット"> <証明書cert_url = "URL" req_resource_set_as = "リソースセットとして" req_resource_set_ipv4 = "IPv4のリソースセット" req_resource_set_ipv6 = "IPv6のリソースセット">証明書</証明書> <発行者>発行者の証明書</発行者> </クラス>
---------------------------------------------------------------
If the certificate issuer determines that the issued certificate would be identical in all respects to the most recently issued certificate for this client, other than the certificate's serial number, were the certificate to be issued, the issuer may choose to respond with the most recently issued certificate and not issue a new certificate for this request.
証明書発行者が発行した証明書は、このクライアントのための最も最近発行された証明書にすべての点で同一であると判断した場合、証明書のシリアル番号以外に、発行される証明書をした、発行者は最も最近発行されたで応答することもできます証明書ではないが、この要求のための新しい証明書を発行します。
The definition of the attributes and syntax of the values is the same as the resource class list response, but the response only references the (single) named resource class, and the (single) certificate issued against the client's public key as provided in the corresponding certificate request.
値の属性と構文の定義は、リソースクラスリストの応答と同じですが、応答がのみ（シングル）という名前のリソースクラスを参照し、クライアントの公開鍵に対して発行された（シングル）証明書が対応に提供されます証明書の要求。
This request 'retires' a client's key pair by requesting that the server's CA revoke all certificates for this client (i.e., where this client is the subject) that contain the matching public key, within the scope of a named resource class. Individual certificates cannot be revoked within the scope of this protocol.
この要求は、サーバーのCAは、このクライアントのすべての証明書を失効することを要求することにより、クライアントの鍵ペアを「引退」（すなわち、このクライアントが対象です）という名前のリソースクラスの範囲内で、対応する公開鍵を含んでいます。個々の証明書は、このプロトコルの範囲内で取り消すことはできません。
The value of the message "type" element for this request is:
このリクエストのメッセージ「タイプ」要素の値は次のとおりです。
type="revoke"
=「取り消し」と入力
---------------------------------------------------------------
Payload:
ペイロード：
<key class_name="class name" ski="[encoded hash of the subject public key]" />
<キーCLASS_NAME =「クラス名」スキー=「[サブジェクトの公開鍵の符号化されたハッシュ]」/>
---------------------------------------------------------------
This command directs the server's CA to immediately mark all issued valid certificates issued by this issuer within the named resource class with this client's subject name and the provided SKI value to be marked as revoked, causing the issued certificates to be withdrawn from the publication repository and to be listed in the server's subsequent CRLs within this resource class. The issuer MUST ensure that all certificates to be revoked were issued with the requesting client as the certificate's subject.
このコマンドは、すぐに発行された証明書は、出版物リポジトリから引き出すことが原因と、このクライアントのサブジェクト名と取り消さとしてマークされて設けられSKI値で名前が付けられたリソースクラス内で、この発行者によって発行されたすべての発行された有効な証明書をマークするために、サーバーのCAを指示し、このリソースクラス内のサーバーのその後のCRLにリストされます。発行者は、失効するすべての証明書が証明書のサブジェクトとして要求しているクライアントに発行されたことを確認しなければなりません。
class_name: value is the issuer-assigned name of the issuer's resource class.
CLASS_NAME：値は、発行者のリソースクラスの発行者が割り当てた名前です。
ski: value is the encoded hash of the client's public key that is to be revoked. The algorithm for the encoding is to generate the 160-bit SHA-1 hash of the client's public key, as defined in method (1) of Section 4.2.1.2 of [RFC5280], and encode this value using the Base 64 encoding with URL and Filename Safe Alphabet, as defined in Section 5 of [RFC4648].
スキー：値が無効にするクライアントの公開鍵のエンコードされたハッシュです。 [RFC5280]のセクション4.2.1.2に記載の方法（1）で定義されるように符号化するためのアルゴリズムは、クライアントの公開鍵の160ビットSHA-1ハッシュを生成することであり、URLとベース64符号化を使用して、この値を符号化しますそして、ファイル名安全なアルファベット、[RFC4648]のセクション5で定義されています。
The value of the message "type" element for this response is:
この応答のメッセージ「タイプ」要素の値です。
type="revoke_response"
タイプは、= "revoke_response"
---------------------------------------------------------------
Payload:
ペイロード：
<key class_name="class name" ski="[encoded hash of the subject public key]" />
<キーCLASS_NAME =「クラス名」スキー=「[サブジェクトの公開鍵の符号化されたハッシュ]」/>
---------------------------------------------------------------
class_name: value is the issuer-assigned name of the server's resource class.
CLASS_NAME：値は、サーバのリソースクラスの発行者が割り当てた名前です。
ski: value is the encoded hash of the client's public key that is to be revoked. The algorithm for the encoding is to generate the 160-bit SHA-1 hash of the client's public key, as defined in method (1) of Section 4.2.1.2 of [RFC5280], and encode this value using the Base 64 encoding with URL and Filename Safe Alphabet, as defined in Section 5 of [RFC4648].
スキー：値が無効にするクライアントの公開鍵のエンコードされたハッシュです。 [RFC5280]のセクション4.2.1.2に記載の方法（1）で定義されるように符号化するためのアルゴリズムは、クライアントの公開鍵の160ビットSHA-1ハッシュを生成することであり、URLとベース64符号化を使用して、この値を符号化しますそして、ファイル名安全なアルファベット、[RFC4648]のセクション5で定義されています。
The value of the message "type" element for this response is:
この応答のメッセージ「タイプ」要素の値です。
type="error_response"
タイプは、= "error_response"
---------------------------------------------------------------
Payload:
ペイロード：
<status>[Code]</status> <description xml:lang="en-US">[Readable text]</description>
<状態> [コード] </ステータス> <説明XML：LANG = "EN-US"> [判読可能なテキスト] </記述>
---------------------------------------------------------------
All states where an error response if to be generated, either due to detected errors or inconsistencies in the content of the request or server-side states that prevent the request being performed, generate a Request-Not-Performed response.
検出されたエラーまたはリクエストを防ぐ要求またはサーバ側の状態の内容に不整合に起因するいずれかのエラー応答場合は、生成されるすべての状態は、要求-NOT-演奏応答を生成し、実行されます。
description: value is a text field. This element MAY be present. It's value has no defined meaning within the scope of this protocol, and implementations may assume that some form of human-readable text may be used here. If the HTTP request that triggered this error response includes an Accept-Language header as defined in Section 14.4 of the HTTP/1.1 specification [RFC2616], then the server MAY include a second description element using the highest ranked preferred language of the client. The en-US description MUST always be included if the element is present.
説明：値がテキストフィールドです。この要素が存在してもよいです。これは、このプロトコルの範囲内で全く意味を持たない値だし、実装は、人間が読めるテキストはここで使用することができる何らかの形のことを仮定してもよいです。 HTTP / 1.1仕様書[RFC2616]のセクション14.4で定義されるように、このエラー応答をトリガHTTP要求が受け入れ言語のヘッダが含まれている場合、サーバはクライアントの最高ランクの優先言語を使用して第2の記述要素を含んでいてもよいです。要素が存在する場合は、EN-USの説明は常に含まれなければなりません。
The error code set is:
エラーコードセットは次のとおりです。
Code Value Description
1101 already processing request
1102 version number error
1103 unrecognized request type
1104 request scheduled for processing
1201 request - no such resource class
1202 request - no resources allocated in resource class
1203 request - badly formed certificate request
1204 request - already used key in request
1301 revoke - no such resource class
1302 revoke - no such key
2001 Internal Server Error - Request not performed
The following is a RELAX NG compact form schema describing version 1 of this protocol.
以下は、このプロトコルのバージョン1を説明RELAX NGコンパクトスキーマです。
Note: As discussed in [XML], "the namespace name, to serve its intended purpose, SHOULD have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists)".
注：[XML]で説明したように、「名前空間名、その意図された目的を果たすために、一意性および持続性の特性を有するべきでは（任意の存在する場合）、それはスキーマの検索のために直接使用することが目標ではありません。」 。
default namespace = "http://www.apnic.net/specs/rescerts/up-down/"
デフォルトの名前空間=「http://www.apnic.net/specs/rescerts/up-down/」
grammar { resource_set_as = xsd:string { maxLength="512000" pattern="[\-,0-9]*" } resource_set_ip4 = xsd:string { maxLength="512000" pattern="[\-,/.0-9]*" } resource_set_ip6 = xsd:string { maxLength="512000" pattern="[\-,/:0-9a-fA-F]*" }
文法{resource_set_as = XSD：列{maxLengthの= "512000" パターン= "[\ - 、0-9] *"} resource_set_ip4 = XSD：列{maxLengthの= "512000" パターン= "[\ - 、/ 0-9 ] *」} resource_set_ip6 = XSD：列{maxLengthの= "512000" パターン= "[\ - 、/：0-9A-FA-F] *"}
class_name = xsd:token { minLength="1" maxLength="1024" } ski = xsd:token { minLength="27" maxLength="1024" } label = xsd:token { minLength="1" maxLength="1024" } cert_url = xsd:string { minLength="10" maxLength="4096" } base64_binary = xsd:base64Binary { minLength="4" maxLength="512000" }
CLASS_NAME = XSD：トークン{はminLength = "1" のmaxLength = "1024"}スキー= XSD：トークン{はminLength = "27" のmaxLength = "1024"}ラベル= XSD：トークン{はminLength = "1" のmaxLength = "1024" } cert_url = XSD：列{はminLength = "10" のmaxLength = "4096"} base64_binary =のxsd：base64Binaryの{はminLength = "4" のmaxLength = "512000"}
start = element message { attribute version { xsd:positiveInteger { maxInclusive="1" } }, attribute sender { label }, attribute recipient { label }, payload }
{：POSITIVEINTEGER {maxInclusiveを= "1"}}、{送信側ラベルを}属性、受信者{ラベル}属性、ペイロード属性バージョン{XSD} =エレメントメッセージが開始します
payload |= attribute type { "list" }, list_request payload |= attribute type { "list_response"}, list_response payload |= attribute type { "issue" }, issue_request payload |= attribute type { "issue_response"}, issue_response payload |= attribute type { "revoke" }, revoke_request payload |= attribute type { "revoke_response"}, revoke_response payload |= attribute type { "error_response"}, error_response
ペイロード| =属性タイプ{ "リスト"}、ペイロードlist_request | =属性タイプ{ "list_response"}、list_responseペイロード| =属性タイプ{ "問題"}、ペイロードissue_request | =属性タイプ{ "issue_response"}、issue_responseペイロード| = { "取り消す"}ペイロードrevoke_requestタイプ属性| =属性タイプ{ "revoke_response"}、revoke_responseペイロード| =属性タイプ{ "error_response"}、error_response
list_request = empty list_response = class*
list_request =空list_response =クラス*
class = element class { attribute class_name { class_name }, attribute cert_url { cert_url }, attribute resource_set_as { resource_set_as }, attribute resource_set_ipv4 { resource_set_ip4 }, attribute resource_set_ipv6 { resource_set_ip6 }, attribute resource_set_notafter { xsd:dateTime }, attribute suggested_sia_head { xsd:anyURI { maxLength="1024" pattern="rsync://.+"} }?, element certificate { attribute cert_url { cert_url }, attribute req_resource_set_as { resource_set_as }?, attribute req_resource_set_ipv4 { resource_set_ip4 }?, attribute req_resource_set_ipv6 { resource_set_ip6 }?, base64_binary }*, element issuer { base64_binary } }
クラス=要素クラス{属性CLASS_NAME {CLASS_NAME}、cert_url {cert_url属性}、resource_set_as {resource_set_as属性}、resource_set_notafter {XSD属性、resource_set_ipv6 {resource_set_ip6を}属性} resource_set_ipv4 {resource_set_ip4属性：suggested_sia_head属性、datetimeオブジェクトを{}のxsd：anyURIの{ maxLength = "1024" パターン= "rsyncを：//.+"}}？要素証明{属性cert_url {cert_urlは}、{req_resource_set_as resource_set_as}？属性req_resource_set_ipv4 {resource_set_ip4}？属性req_resource_set_ipv6 {resource_set_ip6}？base64_binary属性} *、素子発行{base64_binary}}
issue_request = element request { attribute class_name { class_name }, attribute req_resource_set_as { resource_set_as }?, attribute req_resource_set_ipv4 { resource_set_ip4 }?, attribute req_resource_set_ipv6 { resource_set_ip6 }?, base64_binary } issue_response = class
issue_request =エレメント要求{属性CLASS_NAME {CLASS_NAME}、{req_resource_set_as resource_set_as}？属性req_resource_set_ipv4 {resource_set_ip4}？属性req_resource_set_ipv6 {resource_set_ip6} ?, base64_binary属性} issue_response =クラス
revoke_request = revocation revoke_response = revocation
revoke_request =失効revoke_response =取り消し
revocation = element key { attribute class_name { class_name }, attribute ski { ski } }
失効=エレメント鍵{属性CLASS_NAME {CLASS_NAME}、属性スキー{スキー}}
error_response = element status { xsd:positiveInteger { maxInclusive="9999" } }, element description { attribute xml:lang { xsd:language }, xsd:string { maxLength="1024" } }* }
error_response =エレメントステータス{XSD：POSITIVEINTEGER {maxInclusiveを= "9999"}}、素子記述{属性xml：langの{XSD：言語}、XSD：列{maxLengthの= "1024"}}} *
This protocol supports the maintenance of resource certificates that the issuer issues for a subject in certifying resources that have been allocated or assigned by the issuer to the subject [RFC6480]. This protocol assumes that the issuer and subject are known to each other and have exchanged credentials so as to support the mutual recognition of the digital signatures used to sign the CMS messages. The mechanisms used to perform the associated credential exchange are not described in this specification.
このプロトコルは、被験者に、発行者によって割り当てまたは割り当てられているリソースを証明するには対象のための発行者の問題というリソース証明書のメンテナンスをサポートしています[RFC6480]。このプロトコルは、発行者と被写体とが知られており、CMSメッセージに署名するために使用されるデジタル署名の相互認証をサポートするように、認証情報を交換していることを前提としています。関連する資格情報交換を行うために使用されるメカニズムは、本明細書に記載されていません。
The protocol is a minimal query/response protocol that imposes strict serialization on each query/response transaction, reducing the potential for the subject and the issuer to lose synchronization over the issued certificate state.
プロトコルは、対象と発行された証明書の状態の上に同期を失う発行者の可能性を低減する、各クエリ/応答トランザクションに厳密なシリアライゼーションを課す最小照会/応答プロトコルです。
Validation of protocol objects (Section 3.1.2) requires that the CMS signing-time value be greater than or equal to the time value passed in the previously valid protocol objects that were passed from the same originator to the same recipient. If a party inadvertently sends a valid message (protocol object) with a signing time in the future, then subsequent messages from the party in the same client/server context can use signing-time value consistent with this validation constraint, such that the signing times contained in subsequent messages are greater than or equal to the signing-time value of the previous valid message. (Note that it is not a normative requirement that the signing time be precisely aligned to a time of day clock, thus permitting arbitrarily large clock skew values in the context of this protocol message exchange.) If the client and server wish to reset the signing time to a mutually agreed value, then, (as noted in Section 2) the interactions between the client and the server to achieve this outcome are not encompassed in this protocol.
プロトコルオブジェクト（セクション3.1.2）の検証は、CMS署名タイム値が同一の受信者に同じ発信元から渡された以前に有効なプロトコルオブジェクトに渡された時間値以上であることを必要とします。当事者が不注意将来の署名時に有効なメッセージ（プロトコルオブジェクト）を送信した場合、その後、同じクライアント/サーバーのコンテキスト内のパーティからの後続のメッセージは、この検証制約と一致し、署名・タイム値を使用することができ、そのような署名倍後続のメッセージに含まれているが、以前の有効なメッセージの署名時の値以上です。 （したがって、このプロトコルメッセージ交換のコンテキストで任意の大きさのクロックスキュー値を可能に、それは署名時刻を正確日のクロックの時刻に揃えることが規範的な要件ではないことに注意してください。）クライアントとサーバが署名をリセットしたい場合相互に合意した値までの時間は、その後、（第2節で述べたように）クライアントと、この結果を達成するために、サーバとの間の相互作用は、このプロトコルに含まれていません。
IANA has registered the following media type:
IANAは、次のメディアタイプを登録しています：
application/rpki-updown
アプリケーション/ RPKI、アップダウン
Type name: application Subtype name: rpki-updown Required parameters: None Optional parameters: None Encoding considerations: binary Security considerations: Carries an RPKI Provisioning Protocol Message, as defined in this document. Interoperability considerations: None Published specification: This document Applications that use this media type: HTTP [RFC5652] Additional information: Magic number(s): None File extension(s): Macintosh File Type Code(s): Person & email address to contact for further information: Geoff Huston <gih@apnic.net> Intended usage: COMMON Restrictions on usage: Only to be used as an RPKI Provisioning Protocol message object type, as defined in this document. Author: Geoff Huston <gih@apnic.net> Change controller: Geoff Huston <gih@apnic.net>
型名：アプリケーションのサブタイプ名：RPKI-アップダウンに必要なパラメータ：なしオプションのパラメータ：なしエンコードの考慮事項：バイナリセキュリティの考慮事項：この文書で定義されるように、RPKIプロビジョニングプロトコルメッセージを運びます。相互運用性に関する注意事項：なし公開された仕様：連絡する人とEメールアドレス：HTTP [RFC5652]追加情報：マジックナンバー（S）：なしファイルの拡張子（S）：Macintoshのファイルタイプコード（S）このメディアタイプを使用するこのドキュメントアプリケーションジェフ・ヒューストン<gih@apnic.net>意図している用法：使用上の共通制限：のみRPKIプロビジョニングプロトコルメッセージオブジェクトタイプとして使用される、本文書で定義されている更なる情報については。著者：ジェフ・ヒューストン<gih@apnic.net>変更コントローラ：ジェフ・ヒューストン<gih@apnic.net>
The authors would like to acknowledge the valued contributions from Russ Housley, Steve Kent, Randy Bush, George Michaelson, Robert Kisteleki, Tim Bruijnzeels, and Carsten Bormann in the preparation of the protocol described in this document.
著者は、この文書に記載されているプロトコルの準備中ラスHousley、スティーブ・ケント、ランディブッシュ、ジョージ・マイケルソン、ロバートKisteleki、ティムBruijnzeels、およびカルステンボルマンから大切な貢献を認めるしたいと思います。
[ISO.8601:2004] ISO, "ISO 8601:2004 Representation of dates and Times", 2004.
[ISO.8601：2004] ISO、 "ISO 8601：2004の日付の表現とタイムズ"、2004年。
[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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[RFC2986] Nystrom、M.とB. Kaliski、 "PKCS＃10：証明書要求の構文仕様バージョン1.7"、RFC 2986、2000年11月。
[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月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
[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月。
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.
[RFC5781]ワイラー、S.、ウォード、D.、およびR. Housley氏、 "rsyncのURIスキーム"、RFC 5781、2010年2月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]川村、S.とM.川島、RFC 5952、2010年8月、 "IPv6アドレスのテキスト表現のための勧告"。
[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月。
[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月。
[X.509-88] CCITT, "Recommendation X.509: The Directory-Authentication Framework", 1988.
[X.509-88] CCITT、 "勧告X.509：ディレクトリ - 認証フレームワーク"、1988年。
[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月。
[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月。
[XML] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thompson, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208, December 2009, <http://www.w3.org/TR/2009/REC-xml-names-20091208/>.
[XML]ブレイ、T.、オランダ、D.、素人、A.、トービン、R.、およびH.トンプソン、 "XML 1.0での名前空間（第3版）"、World Wide Web Consortium（W3C）の勧告REC-XML-names- 20091208、2009年12月、<http://www.w3.org/TR/2009/REC-xml-names-20091208/>。
Authors' Addresses
著者のアドレス
Geoff Huston APNIC
ジェフ・ヒューストンAPNIC
EMail: gih@apnic.net URI: http://www.apnic.net
電子メール：gih@apnic.net URI：http://www.apnic.net
Robert Loomans APNIC
ロバートLoomans APNIC
EMail: robertl@apnic.net URI: http://www.apnic.net
電子メール：robertl@apnic.net URI：http://www.apnic.net
Byron Ellacott APNIC
バイロンEllacott APNIC
EMail: bje@apnic.net URI: http://www.apnic.net
電子メール：bje@apnic.net URI：http://www.apnic.net
Rob Austein Internet Systems Consortium
ロブAusteinとインターネットシステムコンソーシアム
EMail: sra@hactrn.net
メールアドレス：sra@hactrn.net