[要約] RFC 9152は、証明書、証明書失効リスト（CRL）、および対称鍵をクライアントに配信するためのNSAのプロファイルを定義するSecure Object Delivery Protocol（SODP）サーバーインターフェースに関するものです。このプロトコルは、セキュアな通信を確立し、維持するために必要な鍵材料を安全に配布することを目的としています。主に政府や大企業など、高度なセキュリティが求められる環境での利用が想定されています。

Independent Submission                                        M. Jenkins
Request for Comments: 9152                                           NSA
Category: Informational                                        S. Turner
ISSN: 2070-1721                                                    sn3rd
                                                              April 2022

Secure Object Delivery Protocol (SODP) Server Interfaces: NSA's Profile for Delivery of Certificates, Certificate Revocation Lists (CRLs), and Symmetric Keys to Clients

セキュアオブジェクト配信プロトコル（SODP）サーバーインターフェイス：証明書の配信のためのNSAのプロファイル、証明書取消リスト（CRL）、およびクライアントへの対称キー

Abstract

概要

This document specifies protocol interfaces profiled by the United States National Security Agency (NSA) for National Security System (NSS) servers that provide public key certificates, Certificate Revocation Lists (CRLs), and symmetric keys to NSS clients. Servers that support these interfaces are referred to as Secure Object Delivery Protocol (SODP) servers. The intended audience for this profile comprises developers of client devices that will obtain key management services from NSA-operated SODP servers. Interfaces supported by SODP servers include Enrollment over Secure Transport (EST) and its extensions as well as Certificate Management over CMS (CMC).

このドキュメントは、公開キー証明書、証明書取消リスト（CRLS）、およびNSSクライアントに対称キーを提供する国家安全保障システム（NSS）サーバー向けに米国国家安全保障局（NSA）がプロファイルするプロトコルインターフェイスを指定します。これらのインターフェイスをサポートするサーバーは、安全なオブジェクト配信プロトコル（SODP）サーバーと呼ばれます。このプロファイルの対象視聴者は、NSA操作のSODPサーバーから主要な管理サービスを取得するクライアントデバイスの開発者で構成されています。SODPサーバーでサポートされているインターフェイスには、セキュアートランスポート（EST）およびその拡張機能の登録、およびCMS（CMC）の証明書管理が含まれます。

This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (SP 800-59). It is also appropriate for other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

このプロファイルは、米国の国家安全保障システムのすべてのコンポーネントの機能、構成、および動作に適用されます（SP 800-59）。また、高価値情報を処理する他の米国政府システムにも適しています。これらおよびその他のシステムの展開の開発者やオペレーターが公開できるようになりました。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9152.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9152で取得できます。

Copyright Notice

著作権表示

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。

Table of Contents

目次 

   1.  Introduction
     1.1.  Documents to be Familiar With
     1.2.  Document Organization
     1.3.  Environment
   2.  Abstract Syntax Notation One
   3.  EST Interface
     3.1.  Hypertext Transfer Protocol Layer
     3.2.  Transport Layer Security
     3.3.  Eligibility
     3.4.  Authentication
     3.5.  Authorization
     3.6.  EST and EST Extensions
       3.6.1.  /pal
       3.6.2.  /cacerts
       3.6.3.  /simpleenroll
       3.6.4.  /simplereenroll
       3.6.5.  /fullcmc
       3.6.6.  /serverkeygen
       3.6.7.  /csrattrs
       3.6.8.  /crls
       3.6.9.  /symmetrickeys
       3.6.10. /eecerts, /firmware, /tamp
   4.  CMC Interface
     4.1.  RFC 5273 Transport Protocols
     4.2.  Eligibility
     4.3.  Authentication
     4.4.  Authorization
     4.5.  Full PKI Requests/Responses
   5.  Trust Anchor Profile
   6.  Non-Self-Signed Certification Authority Certificate Profile
   7.  End-Entity Certificate Profile
     7.1.  Source of Authority Certificate Profile
     7.2.  Client Certificate Profile
   8.  Relying Party Applications
   9.  CRL Profile
   10. IANA Considerations
   11. Security Considerations
   12. References
     12.1.  Normative References
     12.2.  Informative References
   Authors' Addresses
1. Introduction
1. はじめに

This document specifies protocol interfaces profiled by the United States National Security Agency (NSA) for National Security System (NSS) servers that provide public key certificates, Certificate Revocation Lists (CRLs), and symmetric keys to NSS clients. Servers that support these interfaces are referred to as Secure Object Delivery Protocol (SODP) servers. The purpose of this document is to indicate options from, and requirements in addition to, the base specifications listed in Section 1.1 that are necessary for client interoperability with NSA-operated SODP servers. Clients are always devices and need not implement all of the interfaces specified herein; clients are free to choose which interfaces to implement based on their operational requirements. Interfaces supported by SODP servers include:

このドキュメントは、公開キー証明書、証明書取消リスト（CRLS）、およびNSSクライアントに対称キーを提供する国家安全保障システム（NSS）サーバー向けに米国国家安全保障局（NSA）がプロファイルするプロトコルインターフェイスを指定します。これらのインターフェイスをサポートするサーバーは、安全なオブジェクト配信プロトコル（SODP）サーバーと呼ばれます。このドキュメントの目的は、NSA操作SODPサーバーとのクライアントの相互運用性に必要なセクション1.1にリストされているベース仕様からのオプションと要件を示すことです。クライアントは常にデバイスであり、ここで指定されているすべてのインターフェイスを実装する必要はありません。クライアントは、運用要件に基づいて実装するインターフェイスを自由に選択できます。SODPサーバーでサポートされているインターフェイスには次のものがあります。

* Enrollment over Secure Transport (EST) [RFC7030] and its extensions [RFC8295], and

* Secure Transport（EST）[RFC7030]およびその拡張[RFC8295]の登録[RFC8295]、および

* Certificate Management over CMS (CMC) [RFC5274] [RFC6402] for both Simple Public Key Infrastructure (PKI) requests and responses (i.e., PKCS#10 requests and PKCS#7 responses) and Full PKI requests and responses.

* CMS（CMC）の証明書管理（CMC）[RFC5274] [RFC6402]の両方の単純な公開インフラストラクチャ（PKI）リクエストと応答（つまり、PKCS＃10リクエストとPKCS＃7応答）および完全なPKIリクエストと応答。

This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems [SP-800-59]. It is also appropriate for other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

このプロファイルは、米国の国家安全保障システムのすべてのコンポーネントの機能、構成、および動作に適用されます[SP-800-59]。また、高価値情報を処理する他の米国政府システムにも適しています。これらおよびその他のシステムの展開の開発者やオペレーターが公開できるようになりました。

This profile conforms to the existing requirements of the NSA's Commercial National Security Algorithms (CNSAs). As operational needs evolve over time, this profile will be updated to incorporate new commercial algorithms and protocols as they are developed and approved for use.

このプロファイルは、NSAの商業国家安全保障アルゴリズム（CNSA）の既存の要件に準拠しています。運用上のニーズが時間の経過とともに進化するにつれて、このプロファイルは更新され、新しい商用アルゴリズムとプロトコルが開発され、使用が承認されます。

1.1. Documents to be Familiar With
1.1. よく知っているドキュメント

Familiarity with the follow specifications is assumed:

フォロー仕様に精通していることが想定されています。

* EST and EST extensions: [RFC7030] and [RFC8295]

* ESTおよびEST拡張機能：[RFC7030]および[RFC8295]

* PKI-related specifications: [RFC2986], [RFC3739], [RFC5274], [RFC5280], [RFC5912], [RFC5913], [RFC5916], [RFC5917], [RFC6010], and [RFC6402]

* PKI関連の仕様：[RFC2986]、[RFC3739]、[RFC5274]、[RFC5280]、[RFC5912]、[RFC5913]、[RFC5916]、[RFC5917]、[RFC5916]、[RFC6010]、[RFC6402]

* Key-format-related specifications: [RFC5915], [RFC5958], [RFC5959], [RFC6031], [RFC6032], [RFC6160], [RFC6161], [RFC6162], [RFC7191], [RFC7192], [RFC7292], and [RFC7906]

* キーフォーマット関連の仕様：[RFC5915]、[RFC5958]、[RFC5959]、[RFC6031]、[RFC6032]、[RFC6160]、[RFC6161]、[RFC6162]、[RFC6162]、[RFC7192]、[RFC7192]、[RFC6162]、[RFC6162]、[RFC6162]、および[RFC7906]

* CMS-related (Cryptographic Message Syntax) documents: [RFC5652] and [RFC6268]

* CMS関連（暗号化メッセージ構文）ドキュメント：[RFC5652]および[RFC6268]

* CNSA-related documents: [RFC8603], [RFC8755], [RFC8756], and [RFC9151]

* CNSA関連文書：[RFC8603]、[RFC8755]、[RFC8756]、および[RFC9151]

The requirements from RFCs apply throughout this profile and are generally not repeated here. This document is purposely written without using the requirements language described in [RFC2119] and [RFC8174].

RFCからの要件はこのプロファイル全体に適用され、通常はここでは繰り返されません。このドキュメントは、[RFC2119]および[RFC8174]で説明されている要件言語を使用せずに意図的に記述されています。

1.2. Document Organization
1.2. ドキュメント組織

The document is organized as follows:

ドキュメントは次のように編成されています。

* The remainder of this section describes the operational environment used by clients to retrieve secure objects.

* このセクションの残りの部分では、安全なオブジェクトを取得するためにクライアントが使用する運用環境について説明します。

* Section 2 specifies the Abstract Syntax Notation One (ASN.1) version used.

* セクション2では、使用される抽象的構文表記1（ASN.1）バージョンを指定します。

* Section 3 specifies SODP's EST interface.

* セクション3は、SODPのESTインターフェイスを指定しています。

* Section 4 specifies SODP's CMC interfaces.

* セクション4は、SODPのCMCインターフェイスを指定しています。

* Sections 5-7 specify Trust Anchor (TA), Certification Authority (CA), and End-Entity (EE) certificates, respectively.

* セクション5-7は、それぞれTrust Anchor（TA）、認定機関（CA）、およびエンドエンティティ（EE）証明書を指定します。

* Sections 8 and 9 specify Relying Party Applications and CRL Profile, respectively.

* セクション8と9は、それぞれ頼るパーティーアプリケーションとCRLプロファイルを指定します。

1.3. Environment
1.3. 環境

Clients obtain secure "objects" or "packages" from the client-server-based environment. Objects/packages vary based on the Source of Authority (SOA), but all objects are "secured" minimally through the use of one or more digital signatures and zero or more layers of encryption, as profiled in this document. An SOA is the authority for the creation of objects that the client will recognize as valid. An SOA can delegate its authority to other actors; delegation occurs through the issuance of certificates. An object or package is the generic term for certificates, certificate status information, and keys (both asymmetric and symmetric). All of the objects except for the certificates and certificate status information are directly encapsulated in and protected by CMS content types. CMS content types that provide security are referred to as "CMS-protecting content types". All others are simply referred to as "CMS content types". All secured objects are distributed either as CMS packages or as part of a CMS package.

クライアントは、クライアントサーバーベースの環境から安全な「オブジェクト」または「パッケージ」を取得します。オブジェクト/パッケージは権限のソース（SOA）に基づいて異なりますが、すべてのオブジェクトは、このドキュメントでプロファイルされているように、1つまたは複数のデジタル署名とゼロ以上の暗号化の使用を通じて最小限に「保護」されます。 SOAは、クライアントが有効であると認識するオブジェクトを作成するための権限です。 SOAは、その権限を他の俳優に委任できます。委任は、証明書の発行を通じて行われます。オブジェクトまたはパッケージは、証明書、証明書ステータス情報、キー（非対称および対称の両方）の汎用用語です。証明書と証明書のステータス情報を除くすべてのオブジェクトは、CMSコンテンツタイプに直接カプセル化され、保護されています。セキュリティを提供するCMSコンテンツタイプは、「CMS保護コンテンツタイプ」と呼ばれます。他のすべては、単に「CMSコンテンツタイプ」と呼ばれます。すべての安全なオブジェクトは、CMSパッケージとして、またはCMSパッケージの一部として配布されます。

In the example depicted in Figure 1, there are two SOAs: one for symmetric keys, as depicted by the Key Trust Anchor (KTA), and one for public key certificates, as depicted by the PKI Trust Anchor (TA). The KTA is responsible for the creation and distribution of symmetric keys. The KTA delegates the creation and distribution responsibilities to separate entities through the issuance of certificates to a Key Source Authority (KSA) and a Key Distribution Authority (KDA). The KSA generates the keys, digitally signs the keys, and encrypts the key for the end client using CMS content types for each step. The KDA distributes the KSA-generated and KSA-protected key to the client; the key may also be signed by the KDA. The resulting CMS package is provided to the client through the EST extension's /symmetrickey service. The PKI TA is responsible for the creation, distribution, and management of public key certificates. The PKI TA delegates these responsibilities to Certification Authorities (CAs), and CAs, in turn, are responsible for creating, distributing, and managing End-Entity (EE) certificates. CAs distribute PKI-related information through the /cacerts, /crls, /eecerts, /fullcmc, /simpleenroll, /simplereenroll, and /csrattrs EST and EST extension services.

図1に示す例には、2つのSOAがあります。1つは、キートラストアンカー（KTA）に描かれているように、PKIトラストアンカー（TA）に描かれているように、公開キー証明書に描かれているように、1つは対称キー用です。 KTAは、対称キーの作成と分布を担当します。 KTAは、主要なソース当局（KSA）および主要な流通当局（KDA）に証明書の発行を通じて、エンティティを分離するために、作成と配布の責任を委任します。 KSAはキーを生成し、キーにデジタルで署名し、各ステップのCMSコンテンツタイプを使用してエンドクライアントのキーを暗号化します。 KDAは、KSA生成およびKSA保護されたキーをクライアントに配布します。キーはKDAによって署名される場合もあります。結果のCMSパッケージは、EST拡張機能 /Symmetrickeyサービスを介してクライアントに提供されます。 PKI TAは、公開キー証明書の作成、配布、および管理を担当しています。 PKI TAは、これらの責任を認証当局（CAS）に委任し、CASは、エンドエンティティ（EE）証明書の作成、配布、および管理を担当します。 CASは、 /cacerts、 /crls、 /eecerts、 /fullcmc、 /simpleenroll、 /simpleerenroll、および /csrattrs estおよびEST拡張サービスを介してPKI関連情報を配布します。 

      +-----+                            +--------+
      | KTA |                            | PKI TA |
      +-----+                            +--------+
         |                                   |
         | Signs                             | Signs
         |                                   |
         +-------------+                     V
         |             |                   +----+
         V             V                   | CA |
      +-----+       +-----+                +----+
      | KSA |       | KDA |                   |
      +-----+       +-----+                   | Signs
         |           |                        |
         | Signs &   | Optionally             +---------------+
         | Encrypts  | Signs                  |               |
         |           |                        V               V
         |           |                +-------------+ +-------------+
         |           V                | Certificate | | Certificate |
     +---|-------------+              +-------------+ | Revocation  |
     |   V             | CMS Content                  | List        |
     | +-------------+ | Types                        +-------------+
     | | Key Package | |
     | +-------------+ |
     +-----------------+

Figure 1: Operating Environment (Key and PKI Sources of Authority)

図1：運用環境（キーおよびPKIの権限源）

For clients that support the CMC interface and not the EST interface, the environment includes only the PKI TAs.

ESTインターフェイスではなくCMCインターフェイスをサポートするクライアントの場合、環境にはPKI TAのみが含まれます。

2. Abstract Syntax Notation One
2. 抽象的な構文表記1

Implementations of this specification use the 2002/2008 ASN.1 version; 2002/2008 ASN.1 modules can be found in [RFC5911], [RFC5912], and [RFC6268] (use [RFC6268] for the CMS syntax), while other specifications already include the 2002/2008 ASN.1 along with the 1988 ASN.1. See Section 1.1 of [RFC6268] for a discussion about the differences between the 2002 and 2008 ASN.1 versions.

この仕様の実装は、2002/2008 ASN.1バージョンを使用します。2002/2008 ASN.1モジュールは[RFC5911]、[RFC5912]、および[RFC6268]（CMS構文に[RFC6268]を使用）にありますが、他の仕様には1988年とともに2002/2008 ASN.1がすでに含まれています。ASN.1。2002年と2008年のASN.1バージョンの違いについての議論については、[RFC6268]のセクション1.1を参照してください。

3. EST Interface
3. ESTインターフェイス

Client options for EST [RFC7030] and EST extensions [RFC8295] are specified in this section.

このセクションでは、EST [RFC7030]およびEST拡張機能[RFC8295]のクライアントオプションを指定します。

3.1. Hypertext Transfer Protocol Layer
3.1. ハイパーテキスト転送プロトコル層

Clients that receive redirection responses (3xx status codes) will terminate the connection ([RFC7030], Section 3.2.1).

リダイレクト応答（3XXステータスコード）を受け取るクライアントは、接続を終了します（[RFC7030]、セクション3.2.1）。

Per Section 2.2 of [RFC8295], clients indicate the format ("application/xml" or "application/json") of the PAL information ([RFC8295], Section 2.1.1) via the HTTP Accept header.

[RFC8295]のセクション2.2ごとに、クライアントは、HTTP Acceptヘッダーを介して、PAL情報（[RFC8295]、セクション2.1.1）の形式（「アプリケーション/XML」または「アプリケーション/JSON」）を示します。

3.2. Transport Layer Security
3.2. 輸送層のセキュリティ

TLS implementations are configured as specified in [RFC9151]; the notable exception is that only EC-based algorithms are used.

TLS実装は、[RFC9151]で指定されているように構成されています。注目すべき例外は、ECベースのアルゴリズムのみが使用されることです。

3.3. Eligibility
3.3. 資格

At the EST interface, servers only enroll clients that they have established a prior relationship with independently of the EST service. To accomplish this, client owners/operators interact in person with the human acting as the Registration Authority (RA) to ensure the information included in the transmitted certificate request, which is sometimes called a Certificate Signing Request (CSR), is associated with a client. The mechanism by which the owner/operator interacts with the RA as well as the information provided is beyond the scope of this document. The information exchanged by the owner/operator might be something as simple as the subject name included in the CSR to be sent or a copy of the certificate that will be used to verify the certificate request, which is provided out of band.

ESTインターフェイスでは、サーバーは、ESTサービスとは独立して以前の関係を確立したクライアントのみを登録しています。これを達成するために、クライアントの所有者/オペレーターは、登録機関（RA）として行動する人間と直接対話し、伝達された証明書リクエストに含まれる情報（CSR）と呼ばれることもあります。。所有者/オペレーターがRAと対話するメカニズムと、提供される情報は、このドキュメントの範囲を超えています。所有者/オペレーターによって交換される情報は、送信されるCSRに含まれる件名名と同じくらい簡単なものである可能性があります。これは、バンドから提供される証明書要求の確認に使用される証明書のコピーです。

3.4. Authentication
3.4. 認証

Mutual authentication occurs via "Certificate TLS Authentication" ([RFC7030], Section 2.2.1). Clients provide their certificate to servers in the TLS Certificate message, which is sent in response to the server's TLS Certificate Request message. Both servers and clients reject all attempts to authenticate based on certificates that cannot be validated back to an installed TA.

相互認証は、「証明書TLS認証」（[RFC7030]、セクション2.2.1）を介して行われます。クライアントは、サーバーのTLS証明書要求メッセージに応じて送信されるTLS証明書メッセージのサーバーに証明書を提供します。サーバーとクライアントの両方が、インストールされたTAに戻ることができない証明書に基づいて、認証のすべての試みを拒否します。

3.5. Authorization
3.5. 許可

Clients always use an explicit TA database ([RFC7030], Section 3.6.1). At a minimum, clients support two TAs: one for the PKI and one for symmetric keys.

クライアントは常に明示的なTAデータベース（[RFC7030]、セクション3.6.1）を使用します。少なくとも、クライアントは2つのTASをサポートします。1つはPKI用、もう1つは対称キー用です。

Clients check that the server's certificate includes the id-kp-cmcRA Extended Key Usage (EKU) value ([RFC6402], Section 2.10).

クライアントは、サーバーの証明書にID-KP-CMCRA拡張キー使用量（EKU）値（[RFC6402]、セクション2.10）が含まれていることを確認します。

Clients that support processing of the CMS Content Constraints extension [RFC6010] ensure returned CMS content is from an SOA or an entity authorized by an SOA for that CMS content; see Section 7.1 for SOA certificates.

CMSコンテンツの制約拡張の処理をサポートするクライアント[RFC6010]は、CMSコンテンツがSOAまたはそのCMSコンテンツの許可されたSOAまたはエンティティからのものであることを保証します。SOA証明書については、セクション7.1を参照してください。

3.6. EST and EST Extensions
3.6. ESTおよびEST拡張機能

This section profiles SODP's interfaces for EST [RFC7030] and EST extensions [RFC8295].

このセクションでは、SODPのEST [RFC7030]およびEST拡張[RFC8295]のインターフェイスをプロファイルします。

3.6.1. /pal
3.6.1. /pal

The Package Availability List (PAL) is limited to 32 entries, where the 32nd PAL entry links to an additional PAL (i.e., PAL Package Type 0001).

パッケージの可用性リスト（PAL）は32のエントリに制限されており、32番目のPALエントリは追加のPALにリンクします（つまり、PALパッケージタイプ0001）。

The PAL is XML [XML].

PALはXML [XML]です。

3.6.2. /cacerts
3.6.2. /cacerts

The CA certificates located in the explicit TA database are distributed to the client when it is registered. This TA distribution mechanism is out of scope.

明示的なTAデータベースにあるCA証明書は、登録時にクライアントに配布されます。このTA分布メカニズムは範囲外です。

CA certificates provided through this service are as specified in Sections 5 and 6 of this document.

このサービスを通じて提供されるCA証明書は、このドキュメントのセクション5および6で指定されているとおりです。

3.6.3. /simpleenroll
3.6.3. /simpleEnroll

CSRs follow the specifications in Section 4.2 of [RFC8756], except that the CMC-specific ChangeSubjectName and the POP Link Witness V2 attributes do not apply. Only EC-based algorithms are used.

CSRは、[RFC8756]のセクション4.2の仕様に従いますが、CMC固有のChangesumbjectNameおよびPop Link Within V2属性が適用されないことを除きます。ECベースのアルゴリズムのみが使用されます。

Client certificates provided through this service are as specified in Section 7 of this document.

このサービスを通じて提供されるクライアント証明書は、このドキュメントのセクション7で指定されているとおりです。

The HTTP content type of "text/plain" ([RFC2046], Section 4.1) is used to return human-readable errors.

「テキスト/プレーン」（[RFC2046]、セクション4.1）のHTTPコンテンツタイプは、人間の読み取り可能なエラーを返すために使用されます。

3.6.4. /simplereenroll
3.6.4. /simplereenroll

There are no additional requirements for requests beyond those specified in Sections 3.4 and 3.6.3 of this document.

このドキュメントのセクション3.4および3.6.3で指定されているものを超えるリクエストの追加要件はありません。

The HTTP content type of "text/plain" ([RFC2046], Section 4.1) is used to return human-readable errors.

「テキスト/プレーン」（[RFC2046]、セクション4.1）のHTTPコンテンツタイプは、人間の読み取り可能なエラーを返すために使用されます。

3.6.5. /fullcmc
3.6.5. /fullcmc

Requests are as specified in [RFC8756] with the notable exception that only EC-based algorithms are used.

リクエストは[RFC8756]で指定されているとおり、ECベースのアルゴリズムのみが使用されるという顕著な例外があります。

Additional attributes for returned CMS packages can be found in [RFC7906].

返されたCMSパッケージの追加属性は、[RFC7906]に記載されています。

Certificates provided through this service are as specified in Section 7 of this document.

このサービスを通じて提供される証明書は、このドキュメントのセクション7で指定されているとおりです。

3.6.6. /serverkeygen
3.6.6. /serverKeyGen

PKCS#12 [RFC7292] -- sometimes referred to as "PFX" (Personal Information Exchange) or "P12" -- is used to provide server-generated asymmetric private keys and the associated certificate to clients. This interface is a one-way interface as the RA requests these from the server.

PKCS＃12 [RFC7292] - 「PFX」（個人情報交換）または「P12」と呼ばれることもある - は、サーバーで生成された非対称のプライベートキーと関連する証明書をクライアントに提供するために使用されます。このインターフェイスは、RAがサーバーからこれらを要求するため、一方向のインターフェイスです。

PFXs [RFC7292] are exchanged using both password privacy mode and integrity password mode. The PRF algorithm for PBKDF2 (the KDF for PBES2 and PBMAC1) is HMAC-SHA-384, and the PBES2 encryption scheme is AES-256.

PFXS [RFC7292]は、パスワードプライバシーモードと整合性パスワードモードの両方を使用して交換されます。PBKDF2のPRFアルゴリズム（PBES2およびPBMAC1のKDF）はHMAC-SHA-384であり、PBES2暗号化スキームはAES-256です。

The HTTP content type of "text/plain" ([RFC2046], Section 4.1) is used to return human-readable errors.

「テキスト/プレーン」（[RFC2046]、セクション4.1）のHTTPコンテンツタイプは、人間の読み取り可能なエラーを返すために使用されます。

/serverkeygen/return is not supported at this time.

/serverKeyGen/RETURNは現時点ではサポートされていません。

3.6.7. /csrattrs
3.6.7. /csrattrs

Clients use this service to retrieve partially filled PKIRequests with no public key or proof-of-possession signature, i.e., their values are set to zero length, either a zero length BIT STRING or OCTET STRING. The pKCS7PDU attribute, defined in [RFC2985], includes the partially filled PKIRequest as the only element in the CsrAttrs sequence. Even though the CsrAttrs syntax is defined as a set, there is only ever exactly one instance of values present.

クライアントはこのサービスを使用して、公開キーまたはプルーフオブポッセッションの署名なしで部分的に満たされたpkirequestsを取得します。[RFC2985]で定義されているPKCS7PDU属性には、CSRATTRSシーケンスの唯一の要素として部分的に満たされたPKIREQUESTが含まれています。CSRATTRS構文はセットとして定義されていますが、値のインスタンスが1つしか存在しません。

3.6.8. /crls
3.6.8. /CRLS

CRLs provided through this service are as specified in Section 9 of this document.

このサービスを通じて提供されるCRLは、このドキュメントのセクション9で指定されているとおりです。

3.6.9. /symmetrickeys
3.6.9. /symmetrickeys

Clients that claim to support SODP interoperation will be able to process the following messages from an SODP server:

SODP相互操作をサポートすると主張するクライアントは、SODPサーバーから次のメッセージを処理できます。

* additional encryption and origin authentication ([RFC8295], Section 5); and

* 追加の暗号化と原点認証（[RFC8295]、セクション5）;と

* server-provided Symmetric Key Content Type [RFC6032] encapsulated in an Encrypted Key Content Type using the EnvelopedData choice [RFC6033] with an SOA certificate that includes the CMS Content Constraints extension (see Section 7.1).

* サーバーが提供する対称キーコンテンツタイプ[RFC6032]は、CMSコンテンツの制約拡張を含むSOA証明書を使用して、封筒の選択[RFC6033]を使用して暗号化されたキーコンテンツタイプにカプセル化されています（セクション7.1を参照）。

Client-supported algorithms to decrypt the server-returned symmetric key are as follows:

クライアントがサポートしているアルゴリズムは、サーバーが回復した対称キーを復号化することです。

* Message Digest: See Section 4 of [RFC8755].

* メッセージダイジェスト：[RFC8755]のセクション4を参照してください。

* Digital Signature Algorithm: See Section 5 of [RFC8755].

* デジタル署名アルゴリズム：[RFC8755]のセクション5を参照してください。

* Key Agreement: See Section 6.1 of [RFC8755].

* 主要な合意：[RFC8755]のセクション6.1を参照してください。

* Key Wrap: AES-256 Key Wrap with Padding [RFC6033] is used. AES-128 Key Wrap with Padding is not used.

* キーラップ：パディング付きのAES-256キーラップ[RFC6033]が使用されます。AES-128パディング付きキーラップは使用されていません。

* Content Encryption: AES-256 Key Wrap with Padding [RFC6033] is used. AES-128 Key Wrap with Padding is not used.

* コンテンツ暗号化：AES-256パディング付きキーラップ[RFC6033]が使用されます。AES-128パディング付きキーラップは使用されていません。

/symmetrickeys/return is not used at this time.

/symmetrickeys/returnは現時点では使用されていません。

3.6.10. /eecerts, /firmware, /tamp
3.6.10. /eecerts、 /firmware、 /tamp

/eecerts, /firmware, and /tamp are not used at this time.

/EECERTS、 /ファームウェア、および /TAMPは現時点では使用されていません。

4. CMC Interface
4. CMCインターフェイス

Client options for CMC [RFC5274] [RFC6402] are specified in this section.

このセクションでは、CMC [RFC5274] [RFC6402]のクライアントオプションを指定します。

4.1. RFC 5273 Transport Protocols
4.1. RFC 5273輸送プロトコル

Clients only use the HTTPS-based transport. The TLS implementation and configuration are as specified in [RFC9151], with the notable exception that only EC-based algorithms are used.

クライアントはHTTPSベースのトランスポートのみを使用します。TLSの実装と構成は[RFC9151]で指定されているとおりであり、ECベースのアルゴリズムのみが使用されるという顕著な例外があります。

Clients that receive HTTP redirection responses (3xx status codes) will terminate the connection ([RFC7030], Section 3.2.1).

HTTPリダイレクト応答（3XXステータスコード）を受け取るクライアントは、接続を終了します（[RFC7030]、セクション3.2.1）。

4.2. Eligibility
4.2. 資格

At the CMC interface, servers only enroll clients that they have established a prior relationship with independently of the EST service. To accomplish this, client owners/operators interact in person with the human acting as the Registration Authority (RA) to ensure the information included in the transmitted certificate request, which is sometimes called a Certificate Signing Request (CSR), is associated with a client. The mechanism by which the owner/operator interacts with the RA as well as the information provided is beyond the scope of this document. The information exchanged by the owner/operator might be something as simple as the subject name included in the CSR to be sent or a copy of the certificate that will be used to verify the certificate request, which is provided out of band.

CMCインターフェイスでは、サーバーは、ESTサービスとは独立して以前の関係を確立したクライアントのみを登録しています。これを達成するために、クライアントの所有者/オペレーターは、登録機関（RA）として行動する人間と直接対話し、伝達された証明書リクエストに含まれる情報（CSR）と呼ばれることもあります。。所有者/オペレーターがRAと対話するメカニズムと、提供される情報は、このドキュメントの範囲を超えています。所有者/オペレーターによって交換される情報は、送信されるCSRに含まれる件名名と同じくらい簡単なものである可能性があります。これは、バンドから提供される証明書要求の確認に使用される証明書のコピーです。

4.3. Authentication
4.3. 認証

Mutual authentication occurs via client and server signing of CMC protocol elements, as required by [RFC8756]. All such signatures are validated against an installed TA; any that fail validation are rejected.

相互認証は、[RFC8756]で要求されるように、CMCプロトコル要素のクライアントおよびサーバーの署名を介して行われます。そのような署名はすべて、インストールされたTAに対して検証されています。失敗した検証は拒否されます。

4.4. Authorization
4.4. 許可

Clients support the simultaneous presence of as many TAs as are required for all of the functions of the client, and only these TAs.

クライアントは、クライアントのすべての機能とこれらのTAのみに必要な数のTAの同時存在をサポートしています。

Clients check that the server's certificate includes the id-kp-cmcRA Extended Key Usage (EKU) value ([RFC6402], Section 2.10).

クライアントは、サーバーの証明書にID-KP-CMCRA拡張キー使用量（EKU）値（[RFC6402]、セクション2.10）が含まれていることを確認します。

Clients that support processing of the CMS Content Constraints extension [RFC6010] ensure returned CMS content is from an SOA or an entity authorized by an SOA for that CMS content; see Section 7.1 for SOA certificates.

CMSコンテンツの制約拡張の処理をサポートするクライアント[RFC6010]は、CMSコンテンツがSOAまたはそのCMSコンテンツの許可されたSOAまたはエンティティからのものであることを保証します。SOA証明書については、セクション7.1を参照してください。

4.5. Full PKI Requests/Responses
4.5. 完全なPKIリクエスト/応答

Requests are as specified in [RFC8756] with the notable exception that only EC-based algorithms are used.

リクエストは[RFC8756]で指定されているとおり、ECベースのアルゴリズムのみが使用されるという顕著な例外があります。

Additional attributes for returned CMS packages can be found in [RFC7906].

返されたCMSパッケージの追加属性は、[RFC7906]に記載されています。

Certificates provided through this service are as specified in Section 7 of this document.

このサービスを通じて提供される証明書は、このドキュメントのセクション7で指定されているとおりです。

5. Trust Anchor Profile
5. アンカープロファイルを信頼してください

Clients are free to store the TA in the format of their choosing; however, servers provide TA information in the form of self-signed CA certificates. This section documents requirements for self-signed certificates in addition to those specified in [RFC8603], which in turn specifies requirements in addition to those in [RFC5280].

クライアントは、TAを選択した形式で自由に保存できます。ただし、サーバーは、自己署名CA証明書の形でTA情報を提供します。このセクションでは、[RFC8603]で指定された証明書に加えて、自己署名証明書の要件を文書化します。これは、[RFC5280]の要件に加えて要件を指定します。

Only EC-based algorithms are used.

ECベースのアルゴリズムのみが使用されます。

Issuer and subject names are composed of only the following naming attributes: country name, domain component, organization name, organizational unit name, common name, state or province name, distinguished name qualifier, and serial number.

発行者と件名名は、次の命名属性のみで構成されています：国名、ドメインコンポーネント、組織名、組織単位名、共通名、州または州名、著名な名前予選、シリアル番号。

In the Subject Key Identifier extension, the keyIdentifier is the 64 low-order bits of the subject's subjectPublicKey field.

サブジェクトキー識別子拡張機能では、KeyIdentifierは被験者のSubjectPublickeyフィールドの64の低次ビットです。

In the Key Usage extension, the nonRepudiation bit is never set.

主要な使用法拡張では、非控除ビットが設定されません。

6. Non-Self-Signed Certification Authority Certificate Profile
6. 非自己署名認定機関証明書プロファイル

This section documents requirements for non-self-signed CA certificates in addition to those specified in [RFC8603], which in turn specifies requirements in addition to those in [RFC5280].

このセクションでは、[RFC8603]で指定されたものに加えて、非自己署名CA証明書の要件を文書化します。これは、[RFC5280]の要件に加えて要件を指定します。

Only EC-based algorithms are used.

ECベースのアルゴリズムのみが使用されます。

Subject names are composed of only the following naming attributes: country name, domain component, organization name, organizational unit name, common name, state or province name, distinguished name qualifier, and serial number.

件名は、次の命名属性のみで構成されています：国名、ドメインコンポーネント、組織名、組織単位名、共通名、州または州名、著名な名前予選、シリアル番号。

In the Authority Key Identifier extension, the keyIdentifier choice is always used. The keyIdentifier is the 64 low-order bits of the issuer's subjectPublicKey field.

Authority Key Identifier拡張機能では、KeyIdentifierの選択が常に使用されます。KeyIdentifierは、発行者のSubjectPublickeyフィールドの64の低次ビットです。

In the Subject Key Identifier extension, the keyIdentifier is the 64 low-order bits of the subject's subjectPublicKey field.

サブジェクトキー識別子拡張機能では、KeyIdentifierは被験者のSubjectPublickeyフィールドの64の低次ビットです。

In the Key Usage extension, the nonRepudiation bit is never set.

主要な使用法拡張では、非控除ビットが設定されません。

The Certificate Policies extension is always included, and policyQualifiers are never used.

証明書ポリシーの拡張は常に含まれており、ポリシー取得者は決して使用されません。

Non-self-signed CA certificates can also include the following:

非自己署名CA証明書には、以下を含めることもできます。

Name Constraints: permittedSubtrees constraints are included, and excludedSubstree constraints are not. Of the GeneralName choices, issuers support the following: rfc822Name, dNSName, uniformResourceIdentifier, and iPAddress (both IPv4 and IPv6) as well as hardwareModuleName, which is defined in [RFC4108]. Note that rfc822Name, dNSName, and uniformResourceIdentifier are defined as IA5 strings, and the character sets allowed are not uniform amongst these three name forms.

名前の制約：許可されたsubtreeの制約が含まれており、除外されたサブストリーの制約はありません。一般名の選択肢のうち、発行者は次のものをサポートします：RFC822Name、DNSNAME、UniformResourceIdentifier、およびiPaddress（IPv4とIPv6の両方）、および[RFC4108]で定義されているHardwareModulename。RFC822NAME、DNSNAME、およびUniformResourceIdentifierはIA5文字列として定義されており、許可されている文字セットはこれら3つの名前フォームの中で均一ではないことに注意してください。

CRL Distribution Points: A distributionPoint is always the fullName choice. The uniformResourceIdentifier GeneralName choice is always included, but others can also be used as long as the first element in the sequence of CRLDistributionPoints is the uniformResourceIdentifier choice. The reasons and cRLIssuer fields are never populated. This extension is never marked as critical.

CRL配信ポイント：配信ポイントは常にフル名の選択です。UniformResourceIdentifier GeneralNameの選択は常に含まれていますが、CrldistributionPointsのシーケンスの最初の要素がUniformResourceIdentidifierの選択である限り、他のものも使用できます。理由とcrlissuerフィールドは決して人口になりません。この拡張機能は、重要であるとマークされることはありません。

Authority Information Access: Only one instance of AccessDescription is included. accessMethod is id-caIssuers, and accessLocation's GeneralName is always the uniformResourceIdentifier choice.

権限情報アクセス：AccessDescriptionのインスタンスは1つだけ含まれています。AccessMethodはID-Caissuersであり、AccessLocationのGeneralNameは常にUniformResourceIdentifierの選択です。

Extended Key Usage: EST servers and RAs include the id-kp-cmcRA EKU, and the CAs include the id-kp-cmcCA, which are both specified in [RFC6402].

拡張キー使用量：ESTサーバーとRAにはID-KP-CMCRA EKUが含まれ、CASには[RFC6402]で指定されているID-KP-CMCCAが含まれます。

Issuers include the Authority Clearance Constraints extension [RFC5913] in non-self-signed CA certificates that are issued to non-SOAs; values for the Certificate Policy (CP) Object Identifier (OID) and the supported classList values are found in the issuer's CP. Criticality is determined by the issuer, and a securityCategories is never included. Only one instance of Clearance is generated in the AuthorityClearanceConstraints sequence.

発行者には、非SOAに発行される非自己署名CA証明書の権限クリアランス制約拡張[RFC5913]が含まれます。証明書ポリシー（CP）オブジェクト識別子（OID）とサポートされているクラスリスト値の値は、発行者のCPにあります。重要性は発行者によって決定され、セキュリティカテゴリは含まれません。AuthorityClearAnceConstraintsシーケンスでは、クリアランスの1つのインスタンスのみが生成されます。

Issuers include a critical CMS Content Constraints extension [RFC6010] in CA certificates used to issue SOA certificates; this is necessary to enable enforcement of scope of the SOA authority. The content types included depend on the packages the SOA sources but include key packages (i.e., Encrypted Key Packages, Symmetric Key Packages, and Asymmetric Key Packages).

発行者には、SOA証明書を発行するために使用されるCA証明書の重要なCMSコンテンツ制約拡張[RFC6010]が含まれます。これは、SOA当局の範囲の施行を可能にするために必要です。含まれるコンテンツタイプは、パッケージにSOAソースに依存しますが、キーパッケージ（つまり、暗号化されたキーパッケージ、対称キーパッケージ、非対称キーパッケージ）が含まれます。

7. End-Entity Certificate Profile
7. エンティティ証明書プロファイル

This section documents requirements for EE signature and key establishment certificates in addition to those listed in [RFC8603], which in turn specifies requirements in addition to those in [RFC5280].

このセクションでは、[RFC8603]にリストされているものに加えて、EE署名および主要な確立証明書の要件を文書化します。これは、[RFC5280]の要件に加えて要件を指定します。

Only EC-based algorithms are used.

ECベースのアルゴリズムのみが使用されます。

Subject names are composed of the following naming attributes: country name, domain component, organization name, organizational unit name, common name, state or province name, distinguished name qualifier, and serial number.

サブジェクト名は、次の命名属性で構成されています：国名、ドメインコンポーネント、組織名、組織単位名、共通名、州または州名、著名な名前予選、シリアル番号。

In the Authority Key Identifier extension, the keyIdentifier choice is always used. The keyIdentifier is the 64 low-order bits of the issuer's subjectPublicKey field.

Authority Key Identifier拡張機能では、KeyIdentifierの選択が常に使用されます。KeyIdentifierは、発行者のSubjectPublickeyフィールドの64の低次ビットです。

In the Subject Key Identifier extension, the keyIdentifier is the 64 low-order bits of the subject's subjectPublicKey field.

サブジェクトキー識別子拡張機能では、KeyIdentifierは被験者のSubjectPublickeyフィールドの64の低次ビットです。

In the Key Usage extension, signature certificates only assert digitalSignature, and key establishment certificates only assert keyAgreement.

主要な使用法拡張では、署名証明書のみがDigitalSignatureのみを主張し、主要な確立証明書はKeyAgreementのみを主張します。

The Certificate Policies extension is always included, and policyQualifiers are never used.

証明書ポリシーの拡張は常に含まれており、ポリシー取得者は決して使用されません。

When included, the non-critical CRL Distribution Point extension's distributionPoint is always identified by the fullName choice. The uniformResourceIdentifier GeneralName choice is always included, but others can also be used as long as the first element in the sequence of distribution points is the URI choice and it is an HTTP/HTTPS scheme. The reasons and cRLIssuer fields are never populated.

含まれている場合、非批判的なCRL配布点拡張ポイントの分布ポイントは、常にフル名の選択によって識別されます。UniformResourceIdentifier GeneralNameの選択は常に含まれていますが、分布ポイントのシーケンスの最初の要素がURI選択であり、HTTP/HTTPSスキームである限り、他のものも使用できます。理由とcrlissuerフィールドは決して人口になりません。

The following subsections provide additional requirements for the different types of EE certificates.

以下のサブセクションは、さまざまなタイプのEE証明書の追加要件を提供します。

7.1. Source of Authority Certificate Profile
7.1. 権限証明書プロファイルのソース

This section specifies the format for SOA certificates, i.e., certificates issued to those entities that are authorized to create, digitally sign, encrypt, and distribute packages; these certificates are issued by non-PKI TAs.

このセクションでは、SOA証明書の形式、つまり、パッケージの作成、デジタル署名、暗号化、および配布を許可されたエンティティに発行された証明書を指定します。これらの証明書は、非PKI TASによって発行されます。

The Subject Alternative Name extension is always included. The following choices are supported: rfc822Name, dNSName, ediPartyName, uniformResourceIdentifier, or iPAddress (both IPv4 and IPv6). This extension is never critical.

主題の代替名拡張子は常に含まれています。次の選択肢がサポートされています：RFC822Name、DNSName、Edipartyname、UniformResourceIdentifier、またはiPaddress（IPv4とIPv6の両方）。この拡張機能は決して重要ではありません。

A critical CMS Content Constraints extension [RFC6010] is included in SOA signature certificates. The content types included depend on the packages the SOA sources (e.g., Encrypted Key Packages, Symmetric Key Packages, and Asymmetric Key Packages).

重要なCMSコンテンツ制約拡張[RFC6010]は、SOA署名証明書に含まれています。含まれるコンテンツタイプは、SOAソース（例えば、暗号化されたキーパッケージ、対称キーパッケージ、非対称キーパッケージなど）に依存します。

7.2. Client Certificate Profile
7.2. クライアント証明書プロファイル

This section specifies the format for certificates issued to clients.

このセクションでは、クライアントに発行された証明書の形式を指定します。

A non-critical Subject Directory Attributes extension is always included with the following attributes:

非クリティカルなサブジェクトディレクトリ属性拡張機能は、常に次の属性に含まれます。

* Device Owner [RFC5916]

* デバイス所有者[RFC5916]

* Clearance Sponsor [RFC5917]

* クリアランススポンサー[RFC5917]

* Clearance [RFC5913]

* クリアランス[RFC5913]

The following extensions are also included at the discretion of the CA:

CAの裁量で、次の拡張機能も含まれています。

* The Authority Information Access extension with only one instance of AccessDescription included. accessMethod is id-caIssuers, and accessLocation's GeneralName is always the uniformResourceIdentifier choice.

* AccessDescriptionの1つのインスタンスのみを含む権限情報アクセス拡張機能が含まれています。AccessMethodはID-Caissuersであり、AccessLocationのGeneralNameは常にUniformResourceIdentifierの選択です。

* A non-critical Subject Alternative Name extension that includes the hardwareModuleName form [RFC4108], rfc822Name, or uniformResourceIdentifier.

* HardwareModulenameフォーム[RFC4108]、RFC822NAME、またはUniformResourceIdentidifierを含む非クリティカルな対象者拡張機能。

* A critical Subject Alternative Name extension that includes dNSName, rfc822Name, ediPartyName, uniformResourceIdentifier, or iPAddress (both IPv4 and IPv6).

* DNSNAME、RFC822Name、EdipartyName、UniformResourceIdentifier、またはiPaddress（IPv4とIPv6の両方）を含む重要な件名代替名拡張機能。

8. Relying Party Applications
8. 依存パーティーアプリケーション

This section documents requirements for Relying Parties (RPs) in addition to those listed in [RFC8603], which in turn specifies requirements in addition to those in [RFC5280].

このセクションでは、[RFC8603]にリストされているものに加えて、依存関係者（RPS）の要件を文書化します。これは、[RFC5280]の要件に加えて要件を指定します。

Only EC-based algorithms are used.

ECベースのアルゴリズムのみが使用されます。

RPs support the Authority Key Identifier and the Subject Key Identifier extensions.

RPSは、権限のキー識別子とサブジェクトキー識別子拡張機能をサポートします。

RPs should support the following extensions: CRL Distribution Points, Authority Information Access, Subject Directory Attribute, Authority Clearance Constraints, and CMS Content Constraints.

RPSは、次の拡張機能をサポートする必要があります。CRL配布ポイント、権限情報アクセス、サブジェクトディレクトリ属性、権限のクリアランスの制約、CMSコンテンツの制約。

Within the Subject Directory Attribute extension, RPs should support the Clearance Sponsor, Clearance, and Device Owner attributes.

件名ディレクトリ属性拡張機能内で、RPSはクリアランススポンサー、クリアランス、およびデバイスの所有者属性をサポートする必要があります。

RPs support the id-kp-cmcRA and id-kp-cmcCA EKUs.

RPSはID-KP-CMCRAおよびID-KP-CMCCA EKUSをサポートしています。

Failure to support extensions in this section might limit the suitability of a device for certain applications.

このセクションで拡張機能をサポートしないと、特定のアプリケーションに対するデバイスの適合性が制限される場合があります。

9. CRL Profile
9. CRLプロファイル

This section documents requirements for CRLs in addition to those listed in [RFC8603], which in turn specifies requirements in addition to those in [RFC5280].

このセクションでは、[RFC8603]にリストされているものに加えて、CRLの要件を文書化します。これは、[RFC5280]の要件に加えて要件を指定します。

Only EC-based algorithms are used.

ECベースのアルゴリズムのみが使用されます。

Two types of CRLs are produced: complete base CRLs and partitioned base CRLs.

2種類のCRLが生成されます：完全なベースCRLとパーティション化されたベースCRL。

crlEntryExtensions are never included, and the reasons and cRLIssuer fields are never populated.

crlentryextensionsは含まれておらず、理由とcrlissuerフィールドが人口計算されません。

All CRLs include the following CRL extensions:

すべてのCRLには、次のCRL拡張機能が含まれます。

* The Authority Key Identifier extension: The keyIdentifier is the 64 low-order bits of the issuer's subjectPublicKey field.

* Authority Key Identifier Extension：KeyIdentifierは、発行者のSubjectPublickeyフィールドの64の低次ビットです。

* As per [RFC5280], the CRL Number extension.

* [RFC5280]によると、CRL番号拡張。

The only other extension included in partitioned base CRLs is the Issuing Distribution Point extension. The distributionPoint is always identified by the fullName choice. The uniformResourceIdentifier GeneralName choice is always included, but others can also be used as long as the first element in the sequence of distribution points is the uniformResourceIdentifier choice and the scheme is an HTTP/HTTPS scheme. All other fields are omitted.

パーティション化されたベースCRLに含まれる他の唯一の拡張機能は、発行分布ポイント拡張です。配布ポイントは、常にフルネームの選択によって識別されます。UniformResourceIdentifier GeneralNameの選択肢は常に含まれていますが、分布ポイントのシーケンスの最初の要素がUniformResourceIdentidifierの選択であり、スキームがHTTP/HTTPSスキームである限り、他のものも使用できます。他のすべてのフィールドは省略されています。

10. IANA Considerations
10. IANAの考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションがありません。

11. Security Considerations
11. セキュリティ上の考慮事項

This entire document is about security. This document profiles the use of many protocols and services: EST, CMC, and PKCS#10/#7/#12 as well as certificates, CRLs, and their extensions [RFC5280]. These have been cited throughout this document, and the specifications identified by those citations should be consulted for security considerations related to implemented protocols and services.

このドキュメント全体はセキュリティに関するものです。このドキュメントは、EST、CMC、およびPKCS＃10/＃7/＃12の多くのプロトコルとサービスの使用、および証明書、CRLS、およびその拡張[RFC5280]の使用を紹介しています。これらはこのドキュメント全体で引用されており、それらの引用によって特定された仕様は、実装されたプロトコルとサービスに関連するセキュリティに関する考慮事項について参照する必要があります。

12. References
12. 参考文献
12.1. Normative References
12.1. 引用文献

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.

[RFC2046] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、DOI 10.17487/RFC2046、1996年11月、<https://www.rfc-editor.orgg/info/rfc2046>。

[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, DOI 10.17487/RFC2985, November 2000, <https://www.rfc-editor.org/info/rfc2985>.

[RFC2985] Nystrom、M。およびB. Kaliski、 "PKCS＃9：選択されたオブジェクトクラスと属性タイプバージョン2.0"、RFC 2985、DOI 10.17487/RFC2985、2000年11月、<https：//www.rfc-editor.org/info/rfc2985>。

[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/info/rfc2986>.

[RFC2986] Nystrom、M。and B. Kaliski、 "PKCS＃10：認定要求構文仕様バージョン1.7"、RFC 2986、DOI 10.17487/RFC2986、2000年11月、<https：//www.rfc-editor.org/info/rfc2986>。

[RFC3739] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 Public Key Infrastructure: Qualified Certificates Profile", RFC 3739, DOI 10.17487/RFC3739, March 2004, <https://www.rfc-editor.org/info/rfc3739>.

[RFC3739] Santesson、S.、Nystrom、M。、およびT. Polk、「インターネットX.509公開キーインフラストラクチャ：資格のある証明書プロファイル」、RFC 3739、DOI 10.17487/RFC3739、2004年3月、<https：// www。rfc-editor.org/info/rfc3739>。

[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, August 2005, <https://www.rfc-editor.org/info/rfc4108>.

[RFC4108] Housley、R。、「暗号化メッセージ構文（CMS）を使用してファームウェアパッケージを保護する」、RFC 4108、DOI 10.17487/RFC4108、2005年8月、<https://www.rfc-editor.org/info/rfc4108>。

[RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, DOI 10.17487/RFC5274, June 2008, <https://www.rfc-editor.org/info/rfc5274>.

[RFC5274] Schaad、J。and M. Myers、「CMS（CMC）上の証明書管理メッセージ：コンプライアンス要件」、RFC 5274、DOI 10.17487/RFC5274、2008年6月、<https://www.rfc-editor.org/情報/RFC5274>。

[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, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509 Public Key Infrastructure Certificate and Certificate Recocation List（CRL）プロファイル"、RFC 5280、DOI 10.17487/RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.

[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 5652、DOI 10.17487/RFC5652、2009年9月、<https://www.rfc-editor.org/info/rfc5652>

[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, DOI 10.17487/RFC5911, June 2010, <https://www.rfc-editor.org/info/rfc5911>.

[RFC5911] Hoffman、P。and J. Schaad、「暗号化メッセージ構文（CMS）およびS/MIMEの新しいASN.1モジュール」、RFC 5911、DOI 10.17487/RFC5911、2010年6月、<https：//www.rfcc-editor.org/info/rfc5911>。

[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.

[RFC5912] Hoffman、P。and J. Schaad、「X.509（PKIX）を使用した公開キーインフラストラクチャの新しいASN.1モジュール」、RFC 5912、DOI 10.17487/RFC5912、2010年6月、<https：// ww。rfc-editor.org/info/rfc5912>。

[RFC5913] Turner, S. and S. Chokhani, "Clearance Attribute and Authority Clearance Constraints Certificate Extension", RFC 5913, DOI 10.17487/RFC5913, June 2010, <https://www.rfc-editor.org/info/rfc5913>.

[RFC5913] Turner、S。およびS. Chokhani、「クリアランス属性および権限のクリアランス制約証明書拡張」、RFC 5913、DOI 10.17487/RFC5913、2010年6月、<https://www.rfc-editor.org/info/RFC5991333>。

[RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, <https://www.rfc-editor.org/info/rfc5915>.

[RFC5915] Turner、S。およびD. Brown、「楕円曲線秘密キー構造」、RFC 5915、DOI 10.17487/RFC5915、2010年6月、<https://www.rfc-editor.org/info/rfc5915>。

[RFC5916] Turner, S., "Device Owner Attribute", RFC 5916, DOI 10.17487/RFC5916, June 2010, <https://www.rfc-editor.org/info/rfc5916>.

[RFC5916]ターナー、S。、「デバイス所有者属性」、RFC 5916、DOI 10.17487/RFC5916、2010年6月、<https://www.rfc-editor.org/info/rfc5916>。

[RFC5917] Turner, S., "Clearance Sponsor Attribute", RFC 5917, DOI 10.17487/RFC5917, June 2010, <https://www.rfc-editor.org/info/rfc5917>.

[RFC5917]ターナー、S。、「クリアランススポンサー属性」、RFC 5917、DOI 10.17487/RFC5917、2010年6月、<https://www.rfc-editor.org/info/rfc5917>

[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, <https://www.rfc-editor.org/info/rfc5958>.

[RFC5958] Turner、S。、「非対称キーパッケージ」、RFC 5958、DOI 10.17487/RFC5958、2010年8月、<https://www.rfc-editor.org/info/rfc5958>

[RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content Type", RFC 5959, DOI 10.17487/RFC5959, August 2010, <https://www.rfc-editor.org/info/rfc5959>.

[RFC5959] Turner、S。、「非対称キーパッケージコンテンツタイプのアルゴリズム」、RFC 5959、DOI 10.17487/RFC5959、2010年8月、<https://www.rfc-editor.org/info/rfc5959>

[RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic Message Syntax (CMS) Content Constraints Extension", RFC 6010, DOI 10.17487/RFC6010, September 2010, <https://www.rfc-editor.org/info/rfc6010>.

[RFC6010] Housley、R.、Ashmore、S。、およびC. Wallace、「暗号化メッセージ構文（CMS）コンテンツ制約拡張」、RFC 6010、DOI 10.17487/RFC6010、2010年9月、<https：//www.rfc-editor.org/info/rfc6010>。

[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type", RFC 6031, DOI 10.17487/RFC6031, December 2010, <https://www.rfc-editor.org/info/rfc6031>.

[RFC6031] Turner、S。およびR. Housley、「暗号化メッセージ構文（CMS）対称キーパッケージコンテンツタイプ」、RFC 6031、DOI 10.17487/RFC6031、2010年12月、<https://www.rfc-editor.org/情報/RFC6031>。

[RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6032, DOI 10.17487/RFC6032, December 2010, <https://www.rfc-editor.org/info/rfc6032>.

[RFC6032] Turner、S。およびR. Housley、「暗号化メッセージ構文（CMS）暗号化されたキーパッケージコンテンツタイプ」、RFC 6032、DOI 10.17487/RFC6032、2010年12月<https://www.rfc-editor.org/g/情報/RFC6032>。

[RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6033, DOI 10.17487/RFC6033, December 2010, <https://www.rfc-editor.org/info/rfc6033>.

[RFC6033] Turner、S。、「暗号化メッセージ構文（CMS）暗号化されたキーパッケージコンテンツタイプのアルゴリズム」、RFC 6033、DOI 10.17487/RFC6033、<https://www.rfc-editor.org/info/RFC6033>。

[RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types", RFC 6160, DOI 10.17487/RFC6160, April 2011, <https://www.rfc-editor.org/info/rfc6160>.

[RFC6160] Turner、S。、「暗号化メッセージ構文のアルゴリズム（CMS）対称キーパッケージコンテンツタイプの保護」、RFC 6160、DOI 10.17487/RFC6160、<https：//www.rfc-editor.org/情報/RFC6160>。

[RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6161, DOI 10.17487/RFC6161, April 2011, <https://www.rfc-editor.org/info/rfc6161>.

[RFC6161] Turner、S。、「暗号化メッセージ構文の楕円曲線アルゴリズム（CMS）暗号化されたキーパッケージコンテンツタイプ」、RFC 6161、DOI 10.17487/RFC6161、2011年4月、<https://www.rfc-editor.org/情報/RFC6161>。

[RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type", RFC 6162, DOI 10.17487/RFC6162, April 2011, <https://www.rfc-editor.org/info/rfc6162>.

[RFC6162] Turner、S。、「暗号化メッセージ構文（CMS）非対称キーパッケージコンテンツタイプの楕円曲線アルゴリズム」、RFC 6162、DOI 10.17487/RFC6162、2011年4月、<https://www.rfc-editor.org/情報/RFC6162>。

[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>.

[RFC6268] Schaad、J。およびS. Turner、「X.509（PKIX）を使用した暗号化メッセージ構文（CMS）および公開キーインフラストラクチャの追加の新しいASN.1モジュール」、RFC 6268、DOI 10.17487/RFC6268、7月2011、<https://www.rfc-editor.org/info/rfc6268>。

[RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, <https://www.rfc-editor.org/info/rfc6402>.

[RFC6402] Schaad、J。、「CMS（CMC）更新上の証明書管理」、RFC 6402、DOI 10.17487/RFC6402、2011年11月、<https://www.rfc-editor.org/info/rfc6402>

[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.

[RFC7030] Pritikin、M.、ed。、Yee、P.、ed。、およびD. Harkins、ed。、「Secure Transportの登録」、RFC 7030、DOI 10.17487/RFC7030、2013年10月、<https：//www.rfc-editor.org/info/rfc7030>。

[RFC7191] Housley, R., "Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types", RFC 7191, DOI 10.17487/RFC7191, April 2014, <https://www.rfc-editor.org/info/rfc7191>.

[RFC7191] Housley、R。、「暗号化メッセージ構文（CMS）キーパッケージ受領およびエラーコンテンツタイプ」、RFC 7191、DOI 10.17487/RFC7191、2014年4月、<https://www.rfc-editor.org/info/RFC7191>。

[RFC7192] Turner, S., "Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types", RFC 7192, DOI 10.17487/RFC7192, April 2014, <https://www.rfc-editor.org/info/rfc7192>.

[RFC7192] Turner、S。、「暗号化メッセージ構文のアルゴリズム（CMS）キーパッケージ受領およびエラーコンテンツタイプ」、RFC 7192、DOI 10.17487/RFC7192、<https://www.rfc-editor.org/情報/RFC7192>。

[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, <https://www.rfc-editor.org/info/rfc7292>.

[RFC7292] Moriarty、K.、Ed。、Nystrom、M.、Parkinson、S.、Rusch、A.、およびM. Scott、「PKCS＃12：個人情報交換Syntax V1.1」、RFC 7292、DOI 10.17487/RFC7292、2014年7月、<https://www.rfc-editor.org/info/rfc7292>。

[RFC7906] Timmel, P., Housley, R., and S. Turner, "NSA's Cryptographic Message Syntax (CMS) Key Management Attributes", RFC 7906, DOI 10.17487/RFC7906, June 2016, <https://www.rfc-editor.org/info/rfc7906>.

[RFC7906] Timmel、P.、Housley、R。、およびS. Turner、「NSAの暗号化メッセージ構文（CMS）キー管理属性」、RFC 7906、DOI 10.17487/RFC7906、2016年6月、<https：//ww.rfc-editor.org/info/rfc7906>。

[RFC8295] Turner, S., "EST (Enrollment over Secure Transport) Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018, <https://www.rfc-editor.org/info/rfc8295>.

[RFC8295] Turner、S。、「EST（Secure Transports Over Secure Transports）拡張機能」、RFC 8295、DOI 10.17487/RFC8295、2018年1月、<https://www.rfc-editor.org/info/rfc8295>

[RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile", RFC 8603, DOI 10.17487/RFC8603, May 2019, <https://www.rfc-editor.org/info/rfc8603>.

[RFC8603] Jenkins、M。and L. Zieglar、「商業国家安全保障アルゴリズム（CNSA）スイート証明書および証明書取消リスト（CRL）プロファイル」、RFC 8603、DOI 10.17487/RFC8603、2019年5月、<https：// www。rfc-editor.org/info/rfc8603>。

[RFC8755] Jenkins, M., "Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions", RFC 8755, DOI 10.17487/RFC8755, March 2020, <https://www.rfc-editor.org/info/rfc8755>.

[RFC8755] Jenkins、M。、「安全/多目的インターネットメールエクステンションで商業国家安全保障アルゴリズムスイートアルゴリズムを使用する」、RFC 8755、DOI 10.17487/RFC8755、2020年3月、<https://www.rfc-editor.org/fo/fo/rfc8755>。

[RFC8756] Jenkins, M. and L. Zieglar, "Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS", RFC 8756, DOI 10.17487/RFC8756, March 2020, <https://www.rfc-editor.org/info/rfc8756>.

[RFC8756] Jenkins、M。and L. Zieglar、「CMS上の証明書管理の商業国家安全保障アルゴリズム（CNSA）スイートプロファイル」、RFC 8756、DOI 10.17487/RFC8756、2020年3月、<https：//ww.rfc-editor.org/info/rfc8756>。

[RFC9151] Cooley, D., "Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3", RFC 9151, DOI 10.17487/RFC9151, April 2022, <https://www.rfc-editor.org/info/rfc9151>.

[RFC9151] Cooley、D。、「TLSおよびDTLS 1.2および1.3の商業国家安全保障アルゴリズム（CNSA）スイートプロファイル」、RFC 9151、DOI 10.17487/RFC9151、2022年4月、<https://www.rfc-editor.org/info/rfc9151>。

[SP-800-59] National Institute of Standards and Technology, "Guideline for Identifying an Information System as a National Security System", DOI 10.6028/NIST.SP.800-59, NIST Special Publication 800-59, August 2003, <https://csrc.nist.gov/publications/detail/sp/800-59/ final>.

[SP-800-59]国立標準技術研究所、「情報システムを国家安全保障システムとして特定するためのガイドライン」、DOI 10.6028/nist.sp.800-59、NIST Special Publication 800-59、2003年8月、<<https://csrc.nist.gov/publications/detail/sp/800-59/ final>。

[XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126/>.

[XML] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C.M.、Maler、E。、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第5版）」、World Wide Web Consortiumの推奨Rec-XML-20081126、2008年11月、<https://www.w3.org/tr/2008/rec-xml-20081126/>。

12.2. Informative References
12.2. 参考引用

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。

Authors' Addresses

著者のアドレス

Michael Jenkins National Security Agency Email: mjjenki@cyber.nsa.gov

マイケルジェンキンス国家安全保障局のメール：mjjenki@cyber.nsa.gov

Sean Turner sn3rd Email: sean@sn3rd.com

Sean Turner SN3RDメール：sean@sn3rd.com