[要約] RFC 7076は、P6RのSecure Shell公開鍵サブシステムに関する仕様です。このRFCの目的は、SSHプロトコルの公開鍵認証のセキュリティと効率を向上させることです。
Independent Submission M. Joseph
Request for Comments: 7076 J. Susoy
Category: Informational P6R, Inc
ISSN: 2070-1721 November 2013
P6R's Secure Shell Public Key Subsystem
P6RのSecure Shell公開鍵サブシステム
Abstract
概要
The Secure Shell (SSH) Public Key Subsystem protocol defines a key distribution protocol that is limited to provisioning an SSH server with a user's public keys. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport.
セキュアシェル（SSH）公開鍵サブシステムプロトコルは、ユーザーの公開鍵を使用したSSHサーバーのプロビジョニングに限定される鍵配布プロトコルを定義します。このドキュメントでは、RFC 4819で定義されているプロトコルに基づいて構築された新しいプロトコルについて説明し、SSHトランスポートを使用してサーバーにキーと証明書をプロビジョニングできるようにします。
The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, Key Management Interoperability Protocol (KMIP), Simple Network Management Protocol (SNMP)).
新しいプロトコルにより、呼び出し側のクライアントは、サーバー上のさまざまな名前空間でキーと証明書を整理できます。これらの名前空間をサーバーで使用すると、クライアントはサーバーで実行されているアプリケーション（SSH、Key Management Interoperability Protocol（KMIP）、Simple Network Management Protocol（SNMP）など）を構成できます。
The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace).
新しいプロトコルは、クライアントがサーバーに依存しないメカニズムを提供して、クライアントが公開鍵の追加、公開鍵の削除、証明書の追加、証明書の削除を行い、サーバーが認識している鍵と証明書の現在のセットを名前空間ごとに一覧表示します（たとえば、 SSH名前空間）。
Rights to manage keys and certificates in a particular namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819.
特定のネームスペースでキーと証明書を管理する権限は、特定の権限を持つユーザーに限定されており、サーバーの実装の一部として定義されています。説明されているプロトコルは、RFC 4819で定義されているバージョン2と下位互換性があります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7076.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7076で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Overview of Extensions to the Public Key Subsystem ..............3
3.1. Extended Status Codes ......................................4
3.2. The Version Packet .........................................4
3.3. The Namespace Attribute ....................................4
4. New Operations ..................................................5
4.1. Adding a Certificate .......................................5
4.2. Removing a Certificate .....................................6
4.3. Listing Certificates .......................................6
4.4. Listing Namespaces .........................................7
5. Extending Public Key Operations .................................8
5.1. Adding a Public Key ........................................8
5.2. Removing a Public Key ......................................8
5.3. Listing Public Keys ........................................9
6. Security Considerations .........................................9
7. IANA Considerations ............................................10
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
This document describes a new protocol that builds on the protocol defined in RFC 4819 that can be used to configure public keys and certificates in an implementation-independent fashion. The concept of a namespace is added to the protocol's operations; it allows the client to organize keys and certificates by application or organizational structure.
このドキュメントでは、RFC 4819で定義されたプロトコルに基づいて構築された新しいプロトコルについて説明します。これは、実装に依存しない方法で公開鍵と証明書を構成するために使用できます。名前空間の概念がプロトコルの操作に追加されます。これにより、クライアントはアプリケーションまたは組織構造ごとにキーと証明書を整理できます。
P6R's Secure Shell Public Key Subsystem has been designed to run on top of the Secure Shell transport layer [3] and user authentication protocols [4]. It provides a simple mechanism for the client to manage the public keys and certificates on the server related to that client. These keys and certificates are normally used for authentication of the client to a service, but they can be used for encrypting results back to the client as well. Uploaded keys and certificates are meant to be able to configure all protocols running on a server (e.g., SSH, SSL, KMIP [8]) that use keys and certificates, as well as the applications that run on a server.
P6RのSecure Shell公開鍵サブシステムは、Secure Shellトランスポート層[3]およびユーザー認証プロトコル[4]の上で実行するように設計されています。これは、クライアントがクライアントに関連するサーバー上の公開鍵と証明書を管理するための簡単なメカニズムを提供します。これらのキーと証明書は通常、サービスに対するクライアントの認証に使用されますが、結果をクライアントに暗号化するためにも使用できます。アップロードされた鍵と証明書は、鍵と証明書を使用するサーバー上で実行されるすべてのプロトコル（SSH、SSL、KMIP [8]など）と、サーバー上で実行されるアプリケーションを構成できるようにするためのものです。
This document should be read only after reading the Secure Shell Public Key Subsystem [1] document. The new protocol described in this document builds on and is meant to be backwards compatible with the protocol described in [1].
このドキュメントは、Secure Shell Public Key Subsystem [1]ドキュメントを読んだ後にのみ読むべきです。このドキュメントで説明されている新しいプロトコルは、[1]で説明されているプロトコルに基づいて構築されており、下位互換性があることを意図しています。
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 RFC 2119 [2].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [2]で説明されているように解釈されます。
The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, list the current public keys known by the server, add certificates, remove certificates, and list the current set of certificates known by the server. This secure key distribution mechanism is implemented by a new SSH subsystem with the name of "publickey@p6r.com".
公開鍵サブシステムは、クライアントに公開鍵の追加、公開鍵の削除、サーバーが認識している現在の公開鍵の一覧表示、証明書の追加、証明書の削除、およびサーバーが認識している現在の一連の証明書の一覧表示を行うサーバーに依存しないメカニズムを提供します。この安全な鍵配布メカニズムは、「publickey@p6r.com」という名前の新しいSSHサブシステムによって実装されます。
The status code gives the status in a more machine-readable format (suitable for localization) and can have the following values:
ステータスコードは、より機械可読な形式（ローカライズに適した形式）でステータスを示し、次の値をとることができます。
SSH_PUBLICKEY_CERTIFICATE_NOT_FOUND 192 SSH_PUBLICKEY_CERTIFICATE_NOT_SUPPORTED 193 SSH_PUBLICKEY_CERTIFICATE_ALREADY_PRESENT 194 SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED 195 SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE 196
SSH_PUBLICKEY_CERTIFICATE_NOT_FOUND 192 SSH_PUBLICKEY_CERTIFICATE_NOT_SUPPORTED 193 SSH_PUBLICKEY_CERTIFICATE_ALREADY_PRESENT 194 SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED 195 SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE 196
The meaning of the failure codes is as implied by their names. See Security Considerations for the use of the failure code: SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED.
障害コードの意味は、その名前が示すとおりです。エラーコードの使用については、セキュリティに関する考慮事項をご覧ください：SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED。
Both sides MUST start a connection by sending a version packet that indicates the version of the protocol they are using.
両側は、使用しているプロトコルのバージョンを示すバージョンパケットを送信して、接続を開始する必要があります。
string "version" uint32 protocol-version-number
文字列 "version" uint32プロトコルバージョン番号
This document defines version 3 of the new protocol. We are using version 3 so that it can be backward compatible with the protocol defined by RFC 4819 [1].
このドキュメントでは、新しいプロトコルのバージョン3を定義しています。 RFC 4819 [1]で定義されているプロトコルとの下位互換性を保つために、バージョン3を使用しています。
The "namespace" attribute is added as an extension to what was described in RFC 4819. The purpose of this attribute is to be able to organize the uploaded keys and certificates into groups where each group represents an application or organization structure. This attribute is a string that should not be longer than 300 characters and MUST be specified in UTF-8 format [5].
「namespace」属性は、RFC 4819で説明されている内容の拡張として追加されます。この属性の目的は、アップロードされたキーと証明書をグループに編成し、各グループがアプリケーションまたは組織構造を表すことです。この属性は、300文字以下の文字列であり、UTF-8形式で指定する必要があります[5]。
This new protocol uses the "ssh" namespace for the manipulation of public keys in an SSH server and should be considered as the default namespace when none is provided.
この新しいプロトコルは、SSHサーバーで公開鍵を操作するために「ssh」名前空間を使用し、何も指定されていない場合はデフォルトの名前空間と見なす必要があります。
As a convention, namespaces used for protocols are lowercase strings of the protocol's standard abbreviation. For example, "ssl" should be the namespace used for the Secure Sockets Layer protocol. Namespaces for applications should contain the product and vendor's name. To help determine what namespaces already exist on a server, a new operation "list-namespaces" is defined in Section 4.
慣例として、プロトコルに使用される名前空間は、プロトコルの標準略語の小文字の文字列です。たとえば、「ssl」は、Secure Sockets Layerプロトコルに使用される名前空間である必要があります。アプリケーションの名前空間には、製品とベンダーの名前を含める必要があります。サーバーにすでに存在する名前空間を特定するために、セクション4で新しい操作「list-namespaces」が定義されています。
P6R's Public Key Subsystem extends the functionality defined in RFC 4819 with the following operations: add-certificate, remove-certificate, list-certificates, and list-namespaces.
P6Rの公開鍵サブシステムは、RFC 4819で定義されている機能を次の操作で拡張します：add-certificate、remove-certificate、list-certificates、およびlist-namespaces。
If the client wishes to add a certificate, the client sends:
クライアントが証明書を追加したい場合、クライアントは以下を送信します。
string "add-certificate" string certificate format name string certificate blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times
文字列 "add-certificate"文字列証明書の形式名文字列証明書blobブール値上書きuint32属性数文字列属性名文字列属性値bool重要な属性数の繰り返し
This request MUST include at least the "namespace" attribute so that the server knows where to save the certificate. Only one namespace attribute can be used per an add-certificate request. It is possible for the same user to save the same certificate into multiple namespaces, but this must be done with several separate add-certificate requests.
サーバーが証明書を保存する場所を認識できるように、この要求には少なくとも「namespace」属性を含める必要があります。証明書追加リクエストごとに使用できる名前空間属性は1つだけです。同じユーザーが同じ証明書を複数の名前空間に保存することは可能ですが、これは複数の個別の証明書追加要求で行う必要があります。
If the namespace appearing in an add-certificate request does not already exist on a server, then it is created by this operation. However, if the user is not authorized to create a namespace, the server MUST return SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE.
証明書の追加リクエストに表示されるネームスペースがサーバーにまだ存在しない場合は、この操作によって作成されます。ただし、ユーザーが名前空間の作成を許可されていない場合、サーバーはSSH_PUBLICKEY_CANNOT_CREATE_NAMESPACEを返す必要があります。
If the overwrite field is false and the specified certificate already exists in the given namespace, the server MUST return SSH_PUBLICKEY_CERTIFICATE_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the certificate. If the overwrite field is true and the specified key already exists in the given namespace but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED.
上書きフィールドがfalseで、指定された証明書が指定された名前空間にすでに存在する場合、サーバーはSSH_PUBLICKEY_CERTIFICATE_ALREADY_PRESENTを返さなければなりません（MUST）。サーバーがこれを返す場合、クライアントはユーザーに証明書を上書きするオプションを提供する必要があります（SHOULD）。 overwriteフィールドがtrueで、指定されたキーが所定の名前空間にすでに存在するが上書きできない場合、サーバーはSSH_PUBLICKEY_ACCESS_DENIEDを返さなければなりません（MUST）。
However, a user may not be authorized to add a certificate to the specified namespace. If the user does not have permission to add a certificate, then the server MUST return SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED.
ただし、指定された名前空間に証明書を追加する権限がユーザーにない場合があります。ユーザーが証明書を追加する権限を持っていない場合、サーバーはSSH_PUBLICKEY_ACTION_NOT_AUTHORIZEDを返す必要があります。
Examples of possible "certificate format names" are: "X509", "pgp-sign-rsa", and "pgp-sign-dss". The format of the public key and certificate blobs are detailed in Section 6.6, "Public Key
可能な「証明書フォーマット名」の例は、「X509」、「pgp-sign-rsa」、および「pgp-sign-dss」です。公開鍵と証明書blobの形式については、6.6項「公開鍵
Algorithms", of the SSH Transport Protocol document [3], where X.509 certificates are to be encoded using a DER format [6] [7] in a certificate blob.
SSHトランスポートプロトコルドキュメント[3]のアルゴリズム」では、X.509証明書はDERer形式[6] [7]を使用して証明書BLOBでエンコードされます。
If the client wishes to remove a certificate, the client sends:
クライアントが証明書を削除したい場合、クライアントは次のものを送信します。
string "remove-certificate" string certificate format name string certificate blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times
文字列 "remove-certificate"文字列証明書フォーマット名文字列証明書blob uint32属性カウント文字列属性名文字列属性値属性数を繰り返し
This request MUST include at least the "namespace" attribute so that the server knows from where to delete the certificate. Only one namespace attribute can be used per remove-certificate request. The server MUST attempt to remove the certificate from the appropriate location.
サーバーが証明書を削除する場所を認識できるように、この要求には少なくとも「namespace」属性を含める必要があります。 remove-certificateリクエストごとに使用できる名前空間属性は1つだけです。サーバーは、適切な場所から証明書を削除する必要があります。
However, a user may not be authorized to remove a certificate from the specified namespace. If the user does not have permission to remove the certificate, then the server MUST return SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED.
ただし、ユーザーは、指定された名前空間から証明書を削除することを許可されていない場合があります。ユーザーが証明書を削除する権限を持っていない場合、サーバーはSSH_PUBLICKEY_ACTION_NOT_AUTHORIZEDを返す必要があります。
Examples of possible "certificate format names" are: "X509", "pgp-sign-rsa", and "pgp-sign-dss".
可能な「証明書フォーマット名」の例は、「X509」、「pgp-sign-rsa」、および「pgp-sign-dss」です。
If the client wishes to list the known certificates, the client sends:
クライアントが既知の証明書をリストしたい場合、クライアントは以下を送信します。
string "list-certificates"
文字列「list-certificates」
The server will respond with zero or more of the following responses:
サーバーは次の応答の0個以上で応答します。
string "certificate" string certificate format name string certificate blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times
文字列 "certificate"文字列証明書の形式名文字列証明書blob uint32属性数文字列属性名文字列属性値属性数の繰り返し
There is no requirement that the responses be in any particular order. Whilst some server implementations may send the responses in some order, client implementations should not rely on responses being in any order.
応答が特定の順序である必要はありません。一部のサーバー実装は応答を特定の順序で送信する場合がありますが、クライアント実装は応答の順序に依存するべきではありません。
This response MUST include at least the "namespace" attribute so that a client can tell in which namespace the certificate resides. Only one namespace attribute can be used per list-certificate request.
この応答には、少なくとも「namespace」属性が含まれている必要があります。これにより、クライアントは、証明書が存在する名前空間を識別できます。リスト証明書要求ごとに使用できる名前空間属性は1つだけです。
Following the last "certificate" response, a status packet MUST be sent.
最後の「証明書」応答に続いて、ステータスパケットを送信する必要があります。
If the client wishes to know existing namespaces on the server, it sends:
クライアントがサーバー上の既存の名前空間を知りたい場合は、以下を送信します。
string "list-namespaces"
文字列「list-namespaces」
The server will respond with zero or more of the following responses:
サーバーは次の応答の0個以上で応答します。
string "namespace" string namespace name
string "namespace" string名前空間の名前
It is possible that not all namespaces will be visible to every authenticated user. In this case, the responding server will return a subset of existing namespaces. See Security Considerations below.
すべての名前空間がすべての認証済みユーザーに表示されるとは限りません。この場合、応答サーバーは既存の名前空間のサブセットを返します。以下のセキュリティに関する考慮事項を参照してください。
Following the last "namespace" response, a status packet MUST be sent.
最後の「名前空間」応答に続いて、ステータスパケットを送信する必要があります。
In addition to adding new operations, this document describes extensions to the operations defined in RFC 4819.
このドキュメントでは、新しい操作の追加に加えて、RFC 4819で定義されている操作の拡張について説明します。
If the client wishes to add a public key, the client sends:
クライアントが公開鍵を追加したい場合、クライアントは以下を送信します。
string "add" string public key algorithm name string public key blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times
文字列 "追加"文字列公開鍵アルゴリズム名文字列公開鍵blobブール値の上書きuint32属性数文字列属性名文字列属性値bool重要な属性数の繰り返し
This request MAY include one "namespace" attribute so that a client can save the public key into a specific namespace. It is possible for the same user to save the same key into multiple namespaces, but this requires multiple add requests.
このリクエストには、クライアントが公開鍵を特定の名前空間に保存できるように、1つの「名前空間」属性を含めることができます。同じユーザーが同じキーを複数の名前空間に保存することは可能ですが、これには複数の追加要求が必要です。
If the namespace appearing in an add public key request does not already exist on a server, then it is created by this operation. However, if the user is not authorized to create a namespace the server MUST return SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE,
公開鍵の追加リクエストに表示されるネームスペースがサーバーにまだ存在しない場合は、このオペレーションによって作成されます。ただし、ユーザーが名前空間の作成を許可されていない場合、サーバーはSSH_PUBLICKEY_CANNOT_CREATE_NAMESPACEを返す必要があります。
If the client wishes to remove a public key, the client sends:
クライアントが公開鍵を削除したい場合、クライアントは以下を送信します。
string "remove" string public key algorithm name string public key blob uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times
文字列 "remove"文字列公開キーアルゴリズム名文字列公開キーblob uint32属性数文字列属性名文字列属性値bool重要な属性数の繰り返し
This extension allows attributes to be added to a remove request. This request MAY include one "namespace" attribute so that a client can remove the public key from a specific namespace.
この拡張機能により、削除リクエストに属性を追加できます。このリクエストには、クライアントが特定の名前空間から公開鍵を削除できるように、1つの「名前空間」属性を含めることができます。
If the client wishes to list the known public keys, the client sends:
クライアントが既知の公開鍵を一覧表示したい場合、クライアントは以下を送信します。
string "list" uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times
string "list" uint32 attribute-count string attrib-name string attrib-value bool critical critical attribute-count times
This extension allows attributes to be added to a list request. This request MAY include one "namespace" attribute so that a client can list the public keys from a specific namespace.
この拡張機能を使用すると、リストリクエストに属性を追加できます。このリクエストには、クライアントが特定の名前空間の公開鍵をリストできるように、1つの「名前空間」属性を含めることができます。
The server will respond with zero or more of the following responses:
サーバーは次の応答の0個以上で応答します。
string "publickey" string public key algorithm name string public key blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times
文字列 "publickey"文字列公開鍵アルゴリズム名文字列公開鍵blob uint32属性数文字列属性名文字列属性値属性数の繰り返し
This response MAY include the "namespace" attribute so that a client can tell in which namespace the key resides.
この応答には、「名前空間」属性が含まれる場合があります。これにより、クライアントは、キーが存在する名前空間を識別できます。
This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks.
このプロトコルは、安全なチャネル上で実行され、チャネルのエンドポイントが認証されていることを前提としています。したがって、このプロトコルは、ネットワークレベルの攻撃から外部的に保護されていることを前提としています。
This protocol provides a mechanism that allows key and certificate material to be uploaded and manipulated into a server application. It is the responsibility of the server implementation to enforce access controls that may be required to limit any particular user's access to the data in a namespace. For example, one user may be allowed to list only the contents of a namespace but not add or remove keys or certificates to/from it. The server MUST return SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED when a user's action goes against its defined access controls.
このプロトコルは、キーと証明書の素材をサーバーアプリケーションにアップロードおよび操作できるようにするメカニズムを提供します。名前空間内のデータへの特定のユーザーのアクセスを制限するために必要なアクセス制御を実施するのは、サーバー実装の責任です。たとえば、1人のユーザーが名前空間の内容のみを一覧表示することを許可されていても、そこにキーや証明書を追加または削除することはできません。ユーザーのアクションがその定義されたアクセス制御に反する場合、サーバーはSSH_PUBLICKEY_ACTION_NOT_AUTHORIZEDを返す必要があります。
This protocol requires the client to assume that the server will correctly implement and observe attributes applied to keys. Implementation errors in the server could cause clients to authorize keys and certificates for access they were not intended to have, or to apply fewer restrictions than were intended.
このプロトコルでは、サーバーがキーに適用された属性を正しく実装および監視することをクライアントが想定する必要があります。サーバーの実装エラーにより、クライアントは、意図していないアクセスのためにキーと証明書を承認したり、意図したよりも少ない制限を適用したりする可能性があります。
Although Section 3.1 defines four new status codes, these are in the 'Private Use' range of IANA's Publickey Subsystem Status Codes registry as defined by Section 6.6.1 ("Conventions") in [1]. No IANA actions are required for this document.
セクション3.1では4つの新しいステータスコードが定義されていますが、これらは[1]のセクション6.6.1（「規約」）で定義されているIANAの公開鍵サブシステムステータスコードレジストリの「プライベート使用」の範囲にあります。このドキュメントにIANAのアクションは必要ありません。
[1] Galbraith, J., Van Dyke, J., and J. Bright, "Secure Shell Public Key Subsystem", RFC 4819, March 2007.
[1] Galbraith、J.、Van Dyke、J。、およびJ. Bright、「Secure Shell Public Key Subsystem」、RFC 4819、2007年3月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[3] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Transport Layer Protocol」、RFC 4253、2006年1月。
[4] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[4] Ylonen、T.およびC. Lonvick、Ed。、「The Secure Shell（SSH）Authentication Protocol」、RFC 4252、2006年1月。
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[5] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[6] 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.
[6] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile」、RFC 5280、2008年5月。
[7] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[7] ITU-T勧告X.690（2002）| ISO / IEC 8825-1：2002、情報技術-ASN.1エンコードルール：基本エンコードルール（BER）、正規エンコードルール（CER）、および識別エンコードルール（DER）の仕様。
[8] OASIS, "Key Management Interoperability Protocol (KMIP) 1.1", January 2013, <http://docs.oasis-open.org/kmip/spec/v1.1/os/ kmip-spec-v1.1-os.html>.
[8] OASIS、「Key Management Interoperability Protocol（KMIP）1.1」、2013年1月、<http://docs.oasis-open.org/kmip/spec/v1.1/os/ kmip-spec-v1.1-os.html >。
Authors' Addresses
著者のアドレス
Mark Joseph, PhD P6R, Inc 1840 41st Ave Suite 102-139 Capitola, CA 95010 US
マークジョセフ、PhD P6R、Inc 1840 41st Ave Suite 102-139 Capitola、CA 95010 US
Phone: +1 888 452 2580 (x702)
EMail: mark@p6r.com
Jim Susoy P6R, Inc 1840 41st Ave Suite 102-139 Capitola, CA 95010 US
Jim Susoy P6R、Inc 1840 41st Ave Suite 102-139 Capitola、CA 95010 US
Phone: +1 888 452 2580 (x701)
EMail: jim@p6r.com