[要約] RFC 6492は、リソース証明書の提供に関するプロトコルであり、インターネット上のリソースの認証と管理を目的としています。要約：リソース証明書のプロビジョニングに関するプロトコルで、インターネット上のリソースの認証と管理を目的とする。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
o アイデンティティを確立するクライアントとサーバーの間の相互作用、または証明書の交換と検証公開キーインフラストラクチャ（PKI）コンテキスは、暗号化メッセージ構文（CMS）[RFC5652]メッセージ交換で使用されます。
o the interactions between client and server that allow respective local CMS signing time values to be reset to mutually recognized values.
o クライアントとサーバーの間の相互作用により、それぞれのローカルCMS署名時間値を相互に認識された値にリセットすることができます。
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-Updown」を使用してHTTP投稿を開始し、メッセージオブジェクトを本文として開始するクライアントから開始されます。サーバーの応答も同様にHTTP応答であり、メッセージオブジェクトは応答の本文として、「アプリケーション/RPKI-Updown」の応答コンテンツタイプを使用します。投稿のコンテンツとサーバーの応答は、「よく形成された」CMS [RFC5652]オブジェクトであり、著名なエンコードルール（der）を使用してエンコードされています。
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]
コンテンツタイプは、署名されたDATAタイプのID-DATA、つまり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 Standard [RFC5652]によると、署名されたDATAコンテンツタイプはASN.1タイプSignedDataです。
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
Additionally, the SignerInfos set MUST contain only a single SignerInfo object.
さらに、SignerInfosセットには、SignerInfoオブジェクトが1つだけ含まれている必要があります。
The version is the syntax version number. It MUST be 3, corresponding to the signerInfo structure having version number 3.
バージョンは構文バージョン番号です。バージョン番号3を持つSignerinfo構造に対応する3でなければなりません。
The digestAlgorithms set contains the 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）が含まれています。このセットには、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オブジェクトのecontentフィールドは、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]で指定されています。秘密のキー値がCMSに署名するために使用されたキーペアのEE証明書を発行した同じCAによって発行された現在の証明書取消リスト（CRL）は、このフィールドに存在する必要があります。このフィールドには、CMSオブジェクトの証明書フィールドに含まれるCA証明書をカバーする他のCASによって発行されたCRLが含まれている場合があります（セクション3.1.1.4を参照）。このフィールドには、他の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.
バージョン番号は3でなければならず、SIDのSubjectKeyIdentifierの選択に対応しています。
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証明書に表示される件名Keyidentifierでなければなりません。
The digestAlgorithm MUST consist of the OID of a digest algorithm that conforms to the RPKI Algorithms and Key Size Profile specification [RFC6485].
消化器gorthmは、RPKIアルゴリズムとキーサイズプロファイルの仕様[RFC6485]に適合するダイジェストアルゴリズムのOIDで構成されている必要があります。
The signedAttrs 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]、または両方の属性のいずれかが存在する場合、それらを署名済みの属性として含める必要があります。その他の署名された属性を含める必要はありません。
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には、特定の属性の単一インスタンスのみを含める必要があります。さらに、このプロファイルでは、構文が一連の属性valueを許可している場合でも、属性は単一の属性のみで構成されている必要があります。
The content-type attribute MUST be present. The attrType OID for the content-type attribute is 1.2.840.113549.1.9.3.
コンテンツタイプの属性が存在する必要があります。コンテンツタイプの属性のattrype OIDは1.2.840.113549.1.9.3です。
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.
コンテンツタイプの属性の属性は、contulatedContentInfoの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.
メッセージダイジェスト属性が存在する必要があります。メッセージダイジェスト属性の属性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].
メッセージDigest属性の属性には、[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].
署名時の属性でのUTCTIMEおよび一般化された時間の使用に関するガイドラインは、[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)
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 present.
d. SignedDataオブジェクトのCRLSフィールドが存在します。
e. The version of the SignerInfo is 3.
e. Signerinfoのバージョンは3です。
f. The signedAttrs field in the SignerInfo object is present and contains 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）の単一のインスタンスの単一インスタンス、および他の属性はありません。
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.
g. contulatedContentInfoのecontentTypeは、コンテンツタイプの属性の属性と一致するOIDであり、ID-CT-XMLの属性を持っています。
h. The unsignedAttrs field in the SignerInfo object is omitted.
h. SignerInfoオブジェクトのUnsignedattrsフィールドは省略されています。
i. If both the signing-time attribute and the binary-signing-time attribute are present, then their values represent the same time.
i. 署名時の属性とバイナリ - 署名時間属性の両方が存在する場合、それらの値は同じ時間を表します。
j. The digestAlgorithm in the SignedData and SignerInfo objects conforms to the RPKI Algorithms and Key Size Profile specification [RFC6485].
j. SignedDataおよびSignerinfoオブジェクトの消化器gorithmは、RPKIアルゴリズムとキーサイズプロファイル仕様[RFC6485]に準拠しています。
k. The signatureAlgorithm in the SignerInfo object conforms to the RPKI Algorithms and Key Size Profile specification [RFC6485].
k. SignerINFOオブジェクトのSignatureAlgorithmは、RPKIアルゴリズムとキーサイズプロファイル仕様[RFC6485]に準拠しています。
l. The signed object is DER encoded.
l. 署名されたオブジェクトはderエンコードされています。
2. The public key of the EE certificate (contained within the CMS signed-data object) can be used to successfully verify the signature on the signed object.
2. EE証明書の公開鍵（CMS Signed-Dataオブジェクトに含まれる）を使用して、署名されたオブジェクトの署名を正常に確認できます。
3. The EE certificate (contained within the CMS signed-data object) is a valid EE certificate. In particular, there exists a valid certification path from a trust anchor selected by the recipient to this EE certificate.
3. EE証明書（CMS署名DATAオブジェクトに含まれる）は、有効な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署名データオブジェクトのCRLSフィールドに含まれる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テンプレートは、次のように非公式に説明されています（プロトコルメッセージオブジェクトを正式に記述するリラックスNGコンパクトフォームスキーマはセクション3.7に含まれています）：
---------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<message xmlns="http://www.apnic.net/specs/rescerts/up-down/"
version="1" sender="sender name" recipient="recipient name" type="message type">
version = "1" sender = "sender name"受信者= "受信者名" 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」、「list_response」、「issue "、" result_response "、" reboke "、" reboke_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:
メッセージは、次のテストを使用してチェックされます。
1. Check that the CMS is well-formed (see test 1 of Section 3.1.2).
1. CMSがよく形成されていることを確認します（セクション3.1.2のテスト1を参照）。
2. Check that the XML is well-formed.
2. XMLがよく形成されていることを確認してください。
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.
3. XML送信者とレシピエント属性が、クエリに対してそれぞれ既知のクライアントとこのサーバーのシステムを参照し、以前にアドレス指定されたサーバーとこのクライアントを参照していることを確認します。
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を参照）。
7. Check that the value of the version number of the message is 1.
7. メッセージのバージョン番号の値が1であることを確認してください。
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.
アイテム1から7のチェック中に遭遇したエラーは、サーバーがHTTPポスト操作への「HTTP 400不良要求」応答を生成する必要があります。ステップ7のエラーでは、サーバーが「リクエストのパフォーマンスのない」エラー応答を生成する必要があります。クライアントがこれらのテストで遭遇したエラーが発生した場合、クライアントはエラーを生成します。
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 Retry-After：Headerが含まれる場合があります。
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:
このクエリのメッセージ「タイプ」メッセージ属性の値は次のとおりです。
type="list"
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"
type = "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>
...
...
(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対応証明書である即時の優れた証明書への参照）。その価値はURIのコンマ区切りのリストであり、そのうち少なくとも1つはrsync uri [rfc5781]でなければなりません。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でカンマ分離リストとして提示されます。リスト要素は、[RFC3779]に記載されている標準的な順序を使用して、主要なゼロや句読点なしで、標準的な順序を使用して、ハイフンデリミッターを使用して、範囲の最低値と最高値で指定された小数の整数値と小数整数の範囲であり、その他の範囲です。コンマとハイフンの範囲指定子よりも（例：Resource_set_as = "123,456-789,123456"）。このリソースクラスに数字がない場合、空のASセットは、この属性のnull文字列値（ ""）で表されます。
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：クラス要素のコンテキストでは、この属性の値は、このリソースクラスの範囲内で発行者がクライアントに割り当てたIPv4アドレスのセットです。値は、ASCIIで、コンマ分離された要素リストとして表示されます。各要素は、<ドットドクアッド>/マスク長の表記を使用したアドレスプレフィックス、またはハイフンデリミッターを使用した点線のクアッド表記の範囲の最低値と最高値として指定された範囲のいずれかです。リストは、[RFC3779]で説明されているように、標準的な順序で提示されます。点線のクワッド表記には、主要なゼロがありません。リストには、期間、フォワードスラッシュ、ハイフン、コンマ以外の空白や句読点が含まれていません（例えば、
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 = "192.0.2.0/26,192.0.2.66-192.0.2.76"）。このリソースクラスにIPv4アドレスがない場合、空のIPv4アドレスセットは、この属性のnull文字列値（ ""）で表されます。
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]で説明されているように、標準的な順序で提示されます。 HEXニブルシーケンス表記は主要なゼロがありません。リストには、コロン、フォワードスラッシュ、ハイフン、コンマ以外の空白や句読点が含まれておらず、[RFC5952]の標準形式に適合します（例えば、Resource_Set_Ipv6 = "2001： db8 ::/48,2001：db8：2 ::-2001：db8：5 :: "）。 XMLスキーマデータ型は「http://www.w3.org/tr/xmlschema-2/#hexbinary」であり、値はケースではなく、標準形式は小文字です。このリソースクラスにIPv6アドレスがない場合、空のIPv6アドレスセットは、この属性のnull文字列値（ ""）で表されます。
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：mm：sszとして表されるUTC時間を使用する必要があります（例：2007-11-29T04：40：00Z）。クライアントの証明書に、この時間とは異なる時間の有効性がある場合、クライアントはこのリソースクラスに発行される新しい証明書を要求する必要があります。
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.
Prossived_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-Encoded発行者の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フィールドはURIの空白のない（最低1つの要素が含まれている）リストであり、そのうちの1つはRsync URI [RFC5781]でなければなりません。AIAフィールドのURIの順序は、この証明書のアクセス方法に対する出版社の相対的な選好として解釈される場合があります。CERT_URLは、このAIA仕様に準拠しています。その価値は、URIのコンマ分離されたリストであり、その1つはRsync 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番号の最大スパンを数字セットとして定義した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
req_resource_set_ipv6：上記の構文に従って、認定されたIPv6アドレスセットの最大要求スパンを定義する対応する元の証明書要求で指定されたIPv6アドレスのセット。この属性が証明書に存在する場合
request, then the attribute MUST be present in this response; otherwise, it MUST NOT be present.
要求、次に、この応答に属性が存在する必要があります。そうでなければ、存在してはなりません。
[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にクライアントに割り当てられた、または割り当てられたリソースのリソース証明書を発行するようにサーバーのCAに要求するために使用されます。リクエストを正常に処理できる場合、サーバーの応答には発行された証明書が含まれます。
The value of the message "type" element for this request is:
このリクエストのメッセージ「タイプ」要素の値は次のとおりです。
type="issue"
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>
---------------------------------------------------------------
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
req_resource_set属性のいずれかがリクエストで指定されている場合、欠落しているreq_resource_set属性は、対応するものの完全なセットを指定するものとして解釈されます。
resource type that match the client's current resource allocation are to be included in the issued certificate.
クライアントの現在のリソース割り当てに一致するリソースタイプは、発行された証明書に含まれます。
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.
含まれるreq_resource_set属性の値がnull値（ ""）である場合、これは、そのリソースタイプのリソースが発行された証明書に含まれていないことを示します。
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：valueは、リソースクラスのサーバーの識別子です。
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 ：（オプション）リソースクラスリスト応答の属性に従ってフォーマットされた、認定されたas as as as as as as as as as setの最大要求スパンを定義する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.)
[証明書リクエスト]値は証明書要求です。これは、PKCS＃10 [RFC2986]を使用してフォーマットされたリクエストのBase64エンコード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.
クライアントは、証明書の発行要求に対する1104の応答を受信した場合、リクエストを定期的に再提出することができることに注意してください。この場合、クライアントはリクエストの処理中にエラーコード1101応答を受け取る必要があり、証明書発行の場合の証明書発行回答が必要です。プロセスが完了しました。このような状況では、クライアントは、そのような繰り返しの要求の頻度を、24時間の各間隔で1回以下の要求に制限する必要があります。
The value of the message "type" element for this response is:
この応答のメッセージ「タイプ」要素の値は次のとおりです。
type="issue_response"
type = "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>
---------------------------------------------------------------
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.
このリクエストは、このクライアントのすべての証明書（つまり、このクライアントが主題である場合）のすべての証明書を、名前付きリソースクラスの範囲内で、このクライアントのすべての証明書（つまり、このクライアントが主題である場合）を要求することにより、クライアントのキーペアを「退職」します。このプロトコルの範囲内で個々の証明書を取り消すことはできません。
The value of the message "type" element for this request is:
このリクエストのメッセージ「タイプ」要素の値は次のとおりです。
type="revoke"
type = "evoke"
---------------------------------------------------------------
Payload:
ペイロード：
<key class_name="class name"
ski="[encoded hash of the subject public key]" />
---------------------------------------------------------------
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.
このコマンドは、このクライアントのサブジェクト名と装備されたスキー価値を備えた名前付きリソースクラス内でこの発行者によって発行されたすべての有効な証明書をすぐにマークするようにサーバーのCAに指示します。このリソースクラス内のサーバーの後続のCRLにリストされます。発行者は、取り消されるすべての証明書が、証明書の主題として要求クライアントで発行されたことを確認する必要があります。
class_name: value is the issuer-assigned name of the issuer's resource class.
class_name：valueは、発行者のリソースクラスの発行者に割り当てられた名前です。
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で定義されているように、ファイル名Safe Alphabet。
The value of the message "type" element for this response is:
この応答のメッセージ「タイプ」要素の値は次のとおりです。
type="revoke_response"
type = "revoke_response"
---------------------------------------------------------------
Payload:
ペイロード：
<key class_name="class name"
ski="[encoded hash of the subject public key]" />
---------------------------------------------------------------
class_name: value is the issuer-assigned name of the server's resource class.
class_name：valueは、サーバーのリソースクラスの発行者に割り当てられた名前です。
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で定義されているように、ファイル名Safe Alphabet。
The value of the message "type" element for this response is:
この応答のメッセージ「タイプ」要素の値は次のとおりです。
type="error_response"
type = "error_response"
---------------------------------------------------------------
Payload:
ペイロード：
<status>[Code]</status>
<description xml:lang="en-US">[Readable text]</description>
---------------------------------------------------------------
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.
リクエストの実行を妨げるリクエストまたはサーバー側のコンテンツのエラーまたは不一致の検出または不一致のいずれかにより、エラー応答が生成される場合、すべての状態は、リクエストなしの応答を生成します。
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要求に、HTTP/1.1仕様[RFC2616]のセクション14.4で定義されている受け入れ言語ヘッダーが含まれている場合、サーバーには、クライアントの最高ランクの優先言語を使用して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
コード値の説明1101既に処理リクエスト1102バージョン番号エラー1103未認識要求タイプ1104リクエスト1201リクエストがスケジュールされたリクエスト - そのようなリソースクラス1202リクエストはありません - リソースクラス1203リクエストに割り当てられないリソースはありません - リクエスト1301 Recoke-そのようなリソースクラス1302の取り消し - そのようなキー2001内部サーバーエラー - リクエストは実行されていません
The following is a RELAX NG compact form schema describing version 1 of this protocol.
以下は、このプロトコルのバージョン1を説明するリラックス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/"
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]*" }
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" }
start = element message {
attribute version { xsd:positiveInteger {
maxInclusive="1" } },
attribute sender { label },
attribute recipient { label },
payload
}
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 = empty list_response = class*
list_request = empty list_response = class*
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 }
}
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 }?,
rsuce_request = element request {aTtribute class_name {class_name}、属性req_resource_set_as {resource_set_as}？、属性req_resource_set_ipv4 {resource_set_ip4}？
base64_binary } issue_response = class
base64_binary} rsuce_response = class
revoke_request = revocation revoke_response = revocation
Revoke_Request = Regoke_Response = Regocation
revocation = element key {
attribute class_name { class_name },
attribute ski { ski }
}
error_response =
element status { xsd:positiveInteger { maxInclusive="9999" } },
element description { attribute xml:lang { xsd:language },
xsd:string { 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
プロトコルオブジェクトの検証（セクション3.1.2）では、CMSの署名時間値を、同じ発信者から同じ受信者に渡された以前に有効なプロトコルオブジェクトで渡された時間値以上であることが必要です。当事者が不注意に有効なメッセージ（プロトコルオブジェクト）を将来の署名時間とともに送信する場合、同じクライアント/サーバーコンテキストの当事者からの後続のメッセージは、この検証制約と一致する署名時間値を使用して、署名時間が後続のメッセージに含まれることは、以前の有効なメッセージの署名時間値以上です。（署名時間が時刻時計に正確に整列することは規範的要件ではないことに注意してください。したがって、このプロトコルメッセージ交換のコンテキストで任意の大きなクロックスキュー値を許可します。）クライアントとサーバーが署名のリセットを希望する場合相互に合意された時間
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.
値、（セクション2に記載されているように）この結果を達成するためのクライアントとサーバーの間の相互作用は、このプロトコルには含まれていません。
IANA has registered the following media type:
IANAは次のメディアタイプを登録しています。
application/rpki-updown
アプリケーション/rpki-updown
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>
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.
著者は、この文書に記載されているプロトコルの準備において、ラス・ヒューズリー、スティーブ・ケント、ランディ・ブッシュ、ジョージ・マイケルソン、ロバート・キステレキ、ティム・ブルーイゼル、カルステン・ボルマンからの大切な貢献を認めたいと思います。
[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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] Lynn、C.、Kent、S。、およびK. Seo、「IPアドレスおよび識別子としての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] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.
[RFC5781] Weiler、S.、Ward、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] Kawamura、S。およびM. Kawashima、「IPv6アドレステキスト表現の推奨」、RFC 5952、2010年8月。
[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] Huston、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. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、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] Huston、G.、Michaelson、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] Bray、T.、Hollander、D.、Layman、A.、Tobin、R.、およびH. Thompson、「XML 1.0の名前空間（第3版）」、World Wide Web Consortiumの推奨REC-XML-NAMES-20091208、2009年12月、<http://www.w3.org/tr/2009/rec-xml-names-20091208/>。
Authors' Addresses
著者のアドレス
Geoff Huston APNIC
Geoff Huston Apnic
EMail: gih@apnic.net
URI: http://www.apnic.net
Robert Loomans APNIC
ロバートルーマンズアペニック
EMail: robertl@apnic.net
URI: http://www.apnic.net
Byron Ellacott APNIC
バイロン・エラコット・アペニック
EMail: bje@apnic.net
URI: http://www.apnic.net
Rob Austein Internet Systems Consortium
Rob Austein Internet Systems Consortium
EMail: sra@hactrn.net