RFC 8332 - Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8332
タイトル : RFC 8332 - Secure Shell（SSH）プロトコルでのSHA-256およびSHA-512でのRSA鍵の使用
翻訳編集 : 自動生成

[要約] このRFCは、SSHプロトコルでSHA-256およびSHA-512とRSAキーを使用する方法について説明しています。目的は、より強力なセキュリティを提供するために、古いハッシュアルゴリズムからより強力なものへの移行を促進することです。

Internet Engineering Task Force (IETF)                          D. Bider
Request for Comments: 8332                               Bitvise Limited
Updates: 4252, 4253                                           March 2018
Category: Standards Track
ISSN: 2070-1721

Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol

Secure Shell（SSH）プロトコルでのSHA-256およびSHA-512でのRSA鍵の使用

Abstract

概要

This memo updates RFCs 4252 and 4253 to define new public key algorithms for use of RSA keys with SHA-256 and SHA-512 for server and client authentication in SSH connections.

このメモは、RFC 4252および4253を更新して、SSH接続でのサーバーおよびクライアント認証のためにSHA-256およびSHA-512でRSA鍵を使用するための新しい公開鍵アルゴリズムを定義します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、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/rfc8332.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8332で入手できます。

著作権表示

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. 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文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。

Table of Contents

   1.  Overview and Rationale  . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Terminology  . . . . . . . . . . . . . . . .   3
     1.2.  Wire Encoding Terminology . . . . . . . . . . . . . . . .   3
   2.  Public Key Format vs. Public Key Algorithm  . . . . . . . . .   3
   3.  New RSA Public Key Algorithms . . . . . . . . . . . . . . . .   4
     3.1.  Use for Server Authentication . . . . . . . . . . . . . .   5
     3.2.  Use for Client Authentication . . . . . . . . . . . . . .   5
     3.3.  Discovery of Public Key Algorithms Supported by Servers .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     5.1.  Key Size and Signature Hash . . . . . . . . . . . . . . .   7
     5.2.  Transition  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.3.  PKCS #1 v1.5 Padding and Signature Verification . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1. Overview and Rationale

1. 概要と根拠

Secure Shell (SSH) is a common protocol for secure communication on the Internet. In [RFC4253], SSH originally defined the public key algorithms "ssh-rsa" for server and client authentication using RSA with SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1. These algorithms are now considered deficient. For US government use, NIST has disallowed 1024-bit RSA and DSA, and use of SHA-1 for signing [NIST.800-131A].

Secure Shell（SSH）は、インターネット上の安全な通信のための一般的なプロトコルです。 [RFC4253]では、SSHは最初、SHA-1を使用したRSAを使用したサーバーおよびクライアント認証用の公開鍵アルゴリズム「ssh-rsa」と、1024ビットDSAおよびSHA-1を使用した「ssh-dss」を定義しました。これらのアルゴリズムは現在不十分であると考えられています。米国政府の使用については、NISTは1024ビットのRSAとDSA、および署名のためのSHA-1の使用を禁止しています[NIST.800-131A]。

This memo updates RFCs 4252 and 4253 to define new public key algorithms allowing for interoperable use of existing and new RSA keys with SHA-256 and SHA-512.

このメモは、RFC 4252および4253を更新して、新しい公開鍵アルゴリズムを定義し、SHA-256およびSHA-512で既存のRSA鍵と新しいRSA鍵を相互運用できるようにします。

1.1. Requirements Terminology

1.1. 要件の用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

1.2. Wire Encoding Terminology

1.2. ワイヤーエンコーディングの用語

The wire encoding types in this document -- "boolean", "byte", "string", "mpint" -- have meanings as described in [RFC4251].

このドキュメントのワイヤエンコーディングタイプ（「ブール」、「バイト」、「文字列」、「mpint」）は、[RFC4251]で説明されている意味を持っています。

2. Public Key Format vs. Public Key Algorithm

2. 公開鍵形式と公開鍵アルゴリズム

In [RFC4252], the concept "public key algorithm" is used to establish a relationship between one algorithm name, and:

[RFC4252]では、「公開鍵アルゴリズム」という概念を使用して、1つのアルゴリズム名と次の関係を確立しています。

A. procedures used to generate and validate a private/public keypair; B. a format used to encode a public key; and C. procedures used to calculate, encode, and verify a signature.

A.秘密/公開鍵ペアの生成と検証に使用される手順。 B.公開鍵のエンコードに使用されるフォーマット。 C.署名の計算、エンコード、および検証に使用される手順。

This document uses the term "public key format" to identify only A and B in isolation. The term "public key algorithm" continues to identify all three aspects -- A, B, and C.

このドキュメントでは、「公開キー形式」という用語を使用して、AとBのみを分離して識別します。「公開鍵アルゴリズム」という用語は、A、B、Cの3つすべての側面を識別し続けます。

3. New RSA Public Key Algorithms

3. 新しいRSA公開鍵アルゴリズム

This memo adopts the style and conventions of [RFC4253] in specifying how use of a public key algorithm is indicated in SSH.

このメモは、公開鍵アルゴリズムの使用がSSHでどのように示されるかを指定する際に、[RFC4253]のスタイルと規則を採用しています。

The following new public key algorithms are defined:

次の新しい公開鍵アルゴリズムが定義されています。

rsa-sha2-256 RECOMMENDED sign Raw RSA key rsa-sha2-512 OPTIONAL sign Raw RSA key

rsa-sha2-256推奨される未加工のRSAキーへの署名rsa-sha2-512オプションの未加工のRSAキーへの署名

These algorithms are suitable for use both in the SSH transport layer [RFC4253] for server authentication and in the authentication layer [RFC4252] for client authentication.

これらのアルゴリズムは、サーバー認証用のSSHトランスポート層[RFC4253]とクライアント認証用の認証層[RFC4252]の両方での使用に適しています。

Since RSA keys are not dependent on the choice of hash function, the new public key algorithms reuse the "ssh-rsa" public key format as defined in [RFC4253]:

RSA鍵はハッシュ関数の選択に依存しないため、新しい公開鍵アルゴリズムは、[RFC4253]で定義されている「ssh-rsa」公開鍵形式を再利用します。

string "ssh-rsa" mpint e mpint n

文字列 "ssh-rsa" mpint e mpint n

All aspects of the "ssh-rsa" format are kept, including the encoded string "ssh-rsa". This allows existing RSA keys to be used with the new public key algorithms, without requiring re-encoding or affecting already trusted key fingerprints.

エンコードされた文字列「ssh-rsa」を含む、「ssh-rsa」形式のすべての側面が保持されます。これにより、既存のRSAキーを新しい公開キーアルゴリズムで使用できるようになります。再エンコードしたり、すでに信頼されているキーフィンガープリントに影響を与えたりする必要はありません。

Signing and verifying using these algorithms is performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash.

これらのアルゴリズムを使用した署名と検証は、ハッシュとしてSHA-2 [SHS]を使用する[RFC8017]のRSASSA-PKCS1-v1_5スキームに従って実行されます。

For the algorithm "rsa-sha2-256", the hash used is SHA-256. For the algorithm "rsa-sha2-512", the hash used is SHA-512.

アルゴリズム「rsa-sha2-256」の場合、使用されるハッシュはSHA-256です。アルゴリズム「rsa-sha2-512」の場合、使用されるハッシュはSHA-512です。

The resulting signature is encoded as follows:

結果の署名は次のようにエンコードされます。

   string   "rsa-sha2-256" / "rsa-sha2-512"
   string    rsa_signature_blob

The value for 'rsa_signature_blob' is encoded as a string that contains an octet string S (which is the output of RSASSA-PKCS1-v1_5) and that has the same length (in octets) as the RSA modulus. When S contains leading zeros, there exist signers that will send a shorter encoding of S that omits them. A verifier MAY accept shorter encodings of S with one or more leading zeros omitted.

'rsa_signature_blob'の値は、オクテット文字列S（RSASSA-PKCS1-v1_5の出力）を含み、RSAモジュラスと同じ長さ（オクテット単位）の文字列としてエンコードされます。 Sに先行ゼロが含まれる場合、省略されたSの短いエンコーディングを送信する署名者が存在します。ベリファイアは、1つ以上の先行ゼロが省略されたSのより短いエンコーディングを受け入れてもよい（MAY）。

3.1. Use for Server Authentication

3.1. サーバー認証に使用

To express support and preference for one or both of these algorithms for server authentication, the SSH client or server includes one or both algorithm names, "rsa-sha2-256" and/or "rsa-sha2-512", in the name-list field "server_host_key_algorithms" in the SSH_MSG_KEXINIT packet [RFC4253]. If one of the two host key algorithms is negotiated, the server sends an "ssh-rsa" public key as part of the negotiated key exchange method (e.g., in SSH_MSG_KEXDH_REPLY) and encodes a signature with the appropriate signature algorithm name -- either "rsa-sha2-256" or "rsa-sha2-512".

サーバー認証のこれらのアルゴリズムの1つまたは両方のサポートと設定を表現するために、SSHクライアントまたはサーバーには、名前に「rsa-sha2-256」または「rsa-sha2-512」、あるいはその両方のアルゴリズム名が含まれていますSSH_MSG_KEXINITパケット[RFC4253]のリストフィールド「server_host_key_algorithms」。 2つのホストキーアルゴリズムの1つがネゴシエートされると、サーバーは、ネゴシエートされたキー交換メソッドの一部として（たとえば、SSH_MSG_KEXDH_REPLYで）「ssh-rsa」公開キーを送信し、適切な署名アルゴリズム名で署名をエンコードします。 rsa-sha2-256 "または" rsa-sha2-512 "。

3.2. Use for Client Authentication

3.2. クライアント認証に使用

To use this algorithm for client authentication, the SSH client sends an SSH_MSG_USERAUTH_REQUEST message [RFC4252] encoding the "publickey" method and encoding the string field "public key algorithm name" with the value "rsa-sha2-256" or "rsa-sha2-512". The "public key blob" field encodes the RSA public key using the "ssh-rsa" public key format.

クライアント認証にこのアルゴリズムを使用するために、SSHクライアントは「publickey」メソッドをエンコードし、値「rsa-sha2-256」または「rsa-sha2」で文字列フィールド「公開鍵アルゴリズム名」をエンコードするSSH_MSG_USERAUTH_REQUESTメッセージ[RFC4252]を送信します-512 "。「公開鍵blob」フィールドは、「ssh-rsa」公開鍵形式を使用してRSA公開鍵をエンコードします。

For example, as defined in [RFC4252] and [RFC4253], an SSH "publickey" authentication request using an "rsa-sha2-512" signature would be properly encoded as follows:

たとえば、[RFC4252]と[RFC4253]で定義されているように、「rsa-sha2-512」署名を使用したSSH「公開鍵」認証リクエストは、次のように適切にエンコードされます。

byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string "rsa-sha2-512" string public key blob: string "ssh-rsa" mpint e mpint n string signature: string "rsa-sha2-512" string rsa_signature_blob

バイトSSH_MSG_USERAUTH_REQUEST文字列ユーザー名文字列サービス名文字列 "publickey"ブールTRUE文字列 "rsa-sha2-512"文字列公開鍵blob：文字列 "ssh-rsa" mpint e mpint n文字列署名：文字列 "rsa-sha2-512"文字列rsa_signature_blob

If the client includes the signature field, the client MUST encode the same algorithm name in the signature as in SSH_MSG_USERAUTH_REQUEST -- either "rsa-sha2-256" or "rsa-sha2-512". If a server receives a mismatching request, it MAY apply arbitrary authentication penalties, including but not limited to authentication failure or disconnect.

クライアントが署名フィールドを含む場合、クライアントは、SSH_MSG_USERAUTH_REQUESTの場合と同じアルゴリズム名を "rsa-sha2-256"または "rsa-sha2-512"のいずれかでエンコードする必要があります。サーバーが不一致のリクエストを受信した場合、認証の失敗や切断など、任意の認証ペナルティが適用される場合があります。

OpenSSH 7.2 (but not 7.2p2) incorrectly encodes the algorithm in the signature as "ssh-rsa" when the algorithm in SSH_MSG_USERAUTH_REQUEST is "rsa-sha2-256" or "rsa-sha2-512". In this case, the signature does actually use either SHA-256 or SHA-512. A server MAY, but is not required to, accept this variant or another variant that corresponds to a good-faith implementation and is considered safe to accept.

OpenSSH 7.2（7.2p2ではない）は、SSH_MSG_USERAUTH_REQUESTのアルゴリズムが「rsa-sha2-256」または「rsa-sha2-512」である場合、署名のアルゴリズムを「ssh-rsa」として誤ってエンコードします。この場合、署名は実際にはSHA-256またはSHA-512を使用します。サーバーは、このバリアントまたは善意の実装に対応し、安全に受け入れられると見なされる別のバリアントを受け入れることができます（必須ではありません）。

3.3. Discovery of Public Key Algorithms Supported by Servers

3.3. サーバーがサポートする公開鍵アルゴリズムの発見

Implementation experience has shown that there are servers that apply authentication penalties to clients attempting public key algorithms that the SSH server does not support.

実装の経験から、SSHサーバーがサポートしていない公開鍵アルゴリズムを試行するクライアントに認証ペナルティを適用するサーバーがあることがわかりました。

Servers that accept rsa-sha2-* signatures for client authentication SHOULD implement the extension negotiation mechanism defined in [RFC8308], including especially the "server-sig-algs" extension.

クライアント認証のためにrsa-sha2- *署名を受け入れるサーバーは、[server-sig-algs]拡張をはじめ、[RFC8308]で定義されている拡張ネゴシエーションメカニズムを実装する必要があります（SHOULD）。

When authenticating with an RSA key against a server that does not implement the "server-sig-algs" extension, clients MAY default to an "ssh-rsa" signature to avoid authentication penalties. When the new rsa-sha2-* algorithms have been sufficiently widely adopted to warrant disabling "ssh-rsa", clients MAY default to one of the new algorithms.

「server-sig-algs」拡張を実装していないサーバーに対してRSAキーで認証する場合、クライアントは認証ペナルティを回避するためにデフォルトで「ssh-rsa」署名を使用できます（MAY）。新しいrsa-sha2- *アルゴリズムが「ssh-rsa」の無効化を保証するのに十分広く採用されている場合、クライアントはデフォルトで新しいアルゴリズムの1つを使用できます（MAY）。

4. IANA Considerations

4. IANAに関する考慮事項

IANA has updated the "Secure Shell (SSH) Protocol Parameters" registry, established with [RFC4250], to extend the table "Public Key Algorithm Names" [IANA-PKA] as follows.

IANAは、[RFC4250]で確立された "Secure Shell（SSH）Protocol Parameters"レジストリを更新して、テーブル "Public Key Algorithm Names" [IANA-PKA]を次のように拡張しました。

- To the immediate right of the column "Public Key Algorithm Name", a new column has been added, titled "Public Key Format". For existing entries, the column "Public Key Format" has been assigned the same value as under "Public Key Algorithm Name".

- 「公開鍵アルゴリズム名」列のすぐ右に、「公開鍵形式」というタイトルの新しい列が追加されました。既存のエントリの場合、「公開キー形式」列には、「公開キーアルゴリズム名」と同じ値が割り当てられています。

- Immediately following the existing entry for "ssh-rsa", two sibling entries have been added:

- 「ssh-rsa」の既存のエントリーの直後に、2つの兄弟エントリーが追加されました。

P. K. Alg. Name P. K. Format Reference Note rsa-sha2-256 ssh-rsa RFC 8332 Section 3 rsa-sha2-512 ssh-rsa RFC 8332 Section 3

P. K. Alg。名前P. K.フォーマットリファレンスノートrsa-sha2-256 ssh-rsa RFC 8332 Section 3 rsa-sha2-512 ssh-rsa RFC 8332 Section 3

5. Security Considerations

5. セキュリティに関する考慮事項

The security considerations of [RFC4251] apply to this document.

[RFC4251]のセキュリティに関する考慮事項がこのドキュメントに適用されます。

5.1. Key Size and Signature Hash

5.1. 鍵サイズと署名ハッシュ

The National Institute of Standards and Technology (NIST) Special Publication 800-131A, Revision 1 [NIST.800-131A] disallows RSA and DSA keys shorter than 2048 bits for US government use. The same document disallows the SHA-1 hash function for digital signature generation, except under NIST's protocol-specific guidance.

米国連邦情報・技術局（NIST）Special Publication 800-131A、Revision 1 [NIST.800-131A]は、米国政府が使用するために2048ビットより短いRSAおよびDSAキーを許可していません。同じドキュメントでは、NISTのプロトコル固有のガイダンスの下を除いて、デジタル署名の生成にSHA-1ハッシュ関数を使用できません。

It is prudent to follow this advice also outside of US government use.

米国政府の使用以外でもこのアドバイスに従うことは賢明です。

5.2. Transition

5.2. 遷移

This document is based on the premise that RSA is used in environments where a gradual, compatible transition to improved algorithms will be better received than one that is abrupt and incompatible. It advises that SSH implementations add support for new RSA public key algorithms along with SSH_MSG_EXT_INFO and the "server-sig-algs" extension to allow coexistence of new deployments with older versions that support only "ssh-rsa". Nevertheless, implementations SHOULD start to disable "ssh-rsa" in their default configurations as soon as the implementers believe that new RSA signature algorithms have been widely adopted.

このドキュメントは、RSAが、改良されたアルゴリズムへの段階的で互換性のある移行が、突然で互換性のないものよりも良好に受け取られる環境で使用されるという前提に基づいています。 SSH実装は、SSH_MSG_EXT_INFOおよび「server-sig-algs」拡張とともに新しいRSA公開鍵アルゴリズムのサポートを追加し、「ssh-rsa」のみをサポートする古いバージョンとの新しいデプロイメントの共存を許可することをお勧めします。それにもかかわらず、実装は、新しいRSA署名アルゴリズムが広く採用されたと実装者が信じるやいなや、デフォルト設定で「ssh-rsa」を無効にすることを開始する必要があります。

5.3. PKCS #1 v1.5 Padding and Signature Verification

5.3. PKCS＃1 v1.5パディングと署名の検証

This document prescribes RSASSA-PKCS1-v1_5 signature padding because:

このドキュメントでは、RSASSA-PKCS1-v1_5署名パディングについて規定しています。

   (1)  RSASSA-PSS is not universally available to all implementations;
   (2)  PKCS #1 v1.5 is widely supported in existing SSH
        implementations;
   (3)  PKCS #1 v1.5 is not known to be insecure for use in this scheme.

Implementers are advised that a signature with RSASSA-PKCS1-v1_5 padding MUST NOT be verified by applying the RSA key to the signature, and then parsing the output to extract the hash. This may give an attacker opportunities to exploit flaws in the parsing and vary the encoding. Verifiers MUST instead apply RSASSA-PKCS1-v1_5 padding to the expected hash, then compare the encoded bytes with the output of the RSA operation.

実装者は、RSASSA-PKCS1-v1_5パディングを含む署名は、RSAキーを署名に適用し、出力を解析してハッシュを抽出することによって検証してはならないことに注意してください。これにより、攻撃者が解析の欠陥を悪用してエンコーディングを変更する機会が与えられる可能性があります。検証者は代わりにRSASSA-PKCS1-v1_5パディングを期待されるハッシュに適用してから、エンコードされたバイトをRSA操作の出力と比較する必要があります。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[SHS] NIST, "Secure Hash Standard (SHS)", FIPS Publication 180-4, August 2015, <http://dx.doi.org/10.6028/NIST.FIPS.180-4>.

[SHS] NIST、「Secure Hash Standard（SHS）」、FIPS Publication 180-4、2015年8月、<http://dx.doi.org/10.6028/NIST.FIPS.180-4>。

[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>。

[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, <https://www.rfc-editor.org/info/rfc4251>.

[RFC4251] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Protocol Architecture」、RFC 4251、DOI 10.17487 / RFC4251、2006年1月、<https://www.rfc-editor.org/ info / rfc4251>。

[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, <https://www.rfc-editor.org/info/rfc4252>.

[RFC4252] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Authentication Protocol」、RFC 4252、DOI 10.17487 / RFC4252、2006年1月、<https://www.rfc-editor.org/ info / rfc4252>。

[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.

[RFC4253] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Transport Layer Protocol」、RFC 4253、DOI 10.17487 / RFC4253、2006年1月、<https://www.rfc-editor.org / info / rfc4253>。

[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>。

[RFC8308] Bider, D., "Extension Negotiation in the Secure Shell (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March 2018, <https://www.rfc-editor.org/info/rfc8308>.

[RFC8308] Bider、D。、「Secure Shell（SSH）Protocolの拡張ネゴシエーション」、RFC 8308、DOI 10.17487 / RFC8308、2018年3月、<https://www.rfc-editor.org/info/rfc8308>。

6.2. Informative References

6.2. 参考引用

[NIST.800-131A] NIST, "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths", NIST Special Publication 800-131A, Revision 1, DOI 10.6028/NIST.SP.800-131Ar1, November 2015, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-131Ar1.pdf>.

[NIST.800-131A] NIST、「移行：暗号化アルゴリズムとキーの長さの使用を移行するための推奨事項」、NIST Special Publication 800-131A、Revision 1、DOI 10.6028 / NIST.SP.800-131Ar1、2015年11月、< http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-131Ar1.pdf>。

[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, <https://www.rfc-editor.org/info/rfc4250>.

[RFC4250] Lehtinen、S。およびC. Lonvick、編、「The Secure Shell（SSH）Protocol Assigned Numbers」、RFC 4250、DOI 10.17487 / RFC4250、2006年1月、<https://www.rfc-editor.org / info / rfc4250>。

[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.

[RFC8017] Moriarty、K.、Ed。、Kaliski、B.、Jonsson、J.、and A. Rusch、 "PKCS＃1：RSA Cryptography Specifications Version 2.2"、RFC 8017、DOI 10.17487 / RFC8017、November 2016、< https://www.rfc-editor.org/info/rfc8017>。

[IANA-PKA] IANA, "Secure Shell (SSH) Protocol Parameters", <https://www.iana.org/assignments/ssh-parameters/>.

[IANA-PKA] IANA、「Secure Shell（SSH）Protocol Parameters」、<https://www.iana.org/assignments/ssh-parameters/>。

Acknowledgments

謝辞

Thanks to Jon Bright, Niels Moeller, Stephen Farrell, Mark D. Baushke, Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, Damien Miller, Mat Berchtold, Roumen Petrov, Daniel Migault, Eric Rescorla, Russ Housley, Alissa Cooper, Adam Roach, and Ben Campbell for reviews, comments, and suggestions.

Jon Bright、Niels Moeller、Stephen Farrell、Mark D. Baushke、Jeffrey Hutzelman、Hanno Boeck、Peter Gutmann、Damien Miller、Mat Berchtold、Roumen Petrov、Daniel Migault、Eric Rescorla、Russ Housley、Alissa Cooper、Adam Roach、レビュー、コメント、提案についてはベンキャンベル。

Author's Address

著者のアドレス

Denis Bider Bitvise Limited 4105 Lombardy Court Colleyville, Texas 76034 United States of America

Denis Bider Bitvise Limited 4105ロンバーディコートコリービル、テキサス76034アメリカ合衆国

   Email: ietf-ssh3@denisbider.com
   URI:   https://www.bitvise.com/