[要約] RFC 6187は、SSH認証のためのX.509v3証明書に関する標準仕様です。このRFCの目的は、SSHプロトコルでのセキュアな認証を提供するために、X.509証明書を使用する方法を定義することです。
Internet Engineering Task Force (IETF) K. Igoe
Request for Comments: 6187 National Security Agency
Category: Standards Track D. Stebila
ISSN: 2070-1721 Queensland University of Technology
March 2011
X.509v3 Certificates for Secure Shell Authentication
X.509V3セキュアシェル認証のための証明書
Abstract
概要
X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity. This document specifies how to use X.509 version 3 public key certificates in public key algorithms in the Secure Shell protocol.
X.509公開キー証明書信頼できる認証機関による署名を使用して、特定の公開鍵を特定のデジタルIDに結合します。このドキュメントは、安全なシェルプロトコルの公開キーアルゴリズムでX.509バージョン3の公開キー証明書を使用する方法を指定しています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6187.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6187で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Public Key Algorithms Using X.509 Version 3 Certificates . . . 4
2.1. Public Key Format . . . . . . . . . . . . . . . . . . . . 4
2.2. Certificate Extensions . . . . . . . . . . . . . . . . . . 6
2.2.1. KeyUsage . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. ExtendedKeyUsage . . . . . . . . . . . . . . . . . . . 7
3. Signature Encoding . . . . . . . . . . . . . . . . . . . . . . 8
3.1. x509v3-ssh-dss . . . . . . . . . . . . . . . . . . . . . . 8
3.2. x509v3-ssh-rsa . . . . . . . . . . . . . . . . . . . . . . 8
3.3. x509v3-rsa2048-sha256 . . . . . . . . . . . . . . . . . . 9
3.4. x509v3-ecdsa-sha2-* . . . . . . . . . . . . . . . . . . . 9
4. Use in Public Key Algorithms . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15
There are two Secure Shell (SSH) protocols that use public key cryptography for authentication. The Transport Layer Protocol, described in [RFC4253], requires that a digital signature algorithm (called the "public key algorithm") MUST be used to authenticate the server to the client. Additionally, the User Authentication Protocol described in [RFC4252] allows for the use of a digital signature to authenticate the client to the server ("publickey" authentication).
認証に公開キー暗号化を使用する2つの安全なシェル（SSH）プロトコルがあります。[RFC4253]に記載されているトランスポート層プロトコルでは、デジタル署名アルゴリズム（「公開キーアルゴリズム」と呼ばれる）を使用して、サーバーをクライアントに認証する必要があります。さらに、[RFC4252]で説明されているユーザー認証プロトコルにより、デジタル署名を使用してクライアントをサーバーに認証することができます（「publicKey」認証）。
In both cases, the validity of the authentication depends upon the strength of the linkage between the public signing key and the identity of the signer. Digital certificates, such as those in X.509 version 3 (X.509v3) format [RFC5280], are used in many corporate and government environments to provide identity management. They use a chain of signatures by a trusted root certification authority and its intermediate certificate authorities to bind a given public signing key to a given digital identity.
どちらの場合も、認証の有効性は、公開署名キーと署名者の身元との間のリンケージの強度に依存します。X.509バージョン3（X.509V3）形式[RFC5280]などのデジタル証明書は、多くの企業および政府環境でアイデンティティ管理を提供するために使用されます。彼らは、信頼できるルート認証機関とその中間証明書当局による署名のチェーンを使用して、特定の公開署名キーを特定のデジタルIDに結合します。
The following public key authentication algorithms are currently available for use in SSH:
現在、次の公開キー認証アルゴリズムがSSHで使用できます。
+--------------+-----------+
| Algorithm | Reference |
+--------------+-----------+
| ssh-dss | [RFC4253] |
| | |
| ssh-rsa | [RFC4253] |
| | |
| pgp-sign-dss | [RFC4253] |
| | |
| pgp-sign-rsa | [RFC4253] |
| | |
| ecdsa-sha2-* | [RFC5656] |
+--------------+-----------+
Since Pretty Good Privacy (PGP) has its own method for binding a public key to a digital identity, this document focuses solely upon the non-PGP methods. In particular, this document defines the following public key algorithms, which differ from the above solely in their use of X.509v3 certificates to convey the signer's public key.
Pretty Good Privacy（PGP）には、公開鍵をデジタルIDに結合する独自の方法があるため、このドキュメントは非PGPメソッドのみに焦点を当てています。特に、このドキュメントでは、次の公開キーアルゴリズムを定義します。これは、署名者の公開鍵を伝えるためにX.509V3証明書の使用のみが上記とは異なります。
+-----------------------+
| Algorithm |
+-----------------------+
| x509v3-ssh-dss |
| |
| x509v3-ssh-rsa |
| |
| x509v3-rsa2048-sha256 |
| |
| x509v3-ecdsa-sha2-* |
+-----------------------+
Public keys conveyed using the x509v3-ecdsa-sha2-* public key algorithms can be used with the ecmqv-sha2 key exchange method.
X509V3-ECDSA-SHA2-*を使用して伝達されるパブリックキーは、ECMQV-Sha2キー交換法で使用できます。
Implementation of this specification requires familiarity with the Secure Shell protocol [RFC4251] [RFC4253] and X.509v3 certificates [RFC5280]. Data types used in describing protocol messages are defined in Section 5 of [RFC4251].
この仕様の実装には、安全なシェルプロトコル[RFC4251] [RFC4253]およびX.509V3証明書[RFC5280]に精通する必要があります。プロトコルメッセージの説明で使用されるデータ型は、[RFC4251]のセクション5で定義されています。
This document is concerned with SSH implementation details; specification of the underlying cryptographic algorithms and the handling and structure of X.509v3 certificates is left to other standards documents, particularly [RFC3447], [FIPS-186-3], [FIPS-180-2], [FIPS-180-3], [SEC1], and [RFC5280].
このドキュメントは、SSHの実装の詳細に関係しています。基礎となる暗号化アルゴリズムの仕様とX.509V3証明書の取り扱いと構造は、他の標準文書、特に[RFC3447]、[FIPS-186-3]、[FIPS-180-2]、[FIPS-180-3]、[Sec1]、および[RFC5280]。
An earlier proposal for the use of X.509v3 certificates in the Secure Shell protocol was introduced by O. Saarenmaa and J. Galbraith; while this document is informed in part by that earlier proposal, it does not maintain strict compatibility.
安全なシェルプロトコルでのX.509V3証明書の使用に関する以前の提案は、O。SaarenmaaとJ. Galbraithによって導入されました。このドキュメントはその以前の提案によって部分的に通知されていますが、厳格な互換性を維持していません。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This document defines the following new public key algorithms for use in the Secure Shell protocol: x509v3-ssh-dss, x509v3-ssh-rsa, x509v3-rsa2048-sha256, and the family of algorithms given by x509v3-ecdsa-sha2-*. In these algorithms, a public key is stored in an X.509v3 certificate. This certificate, a chain of certificates leading to a trusted certificate authority, and optional messages giving the revocation status of the certificates are sent as the public key data in the Secure Shell protocol according to the format in this section.
このドキュメントでは、安全なシェルプロトコルで使用する次の新しい公開キーアルゴリズム、X509V3-SSH-DSS、X509V3-SSH-RSA、X509V3-RSA2048-SHA256、およびX509V3-ECDSA-SHA2-*によって与えられたアルゴリズムのファミリーを定義します。これらのアルゴリズムでは、公開キーはX.509V3証明書に保存されます。この証明書、信頼できる証明書当局につながる証明書、および証明書の取り消しステータスを与えるオプションのメッセージは、このセクションの形式に従って、安全なシェルプロトコルの公開キーデータとして送信されます。
The reader is referred to [RFC5280] for a general description of X.509 version 3 certificates. For the purposes of this document, it suffices to know that in X.509 a chain or sequence of certificates (possibly of length one) allows a trusted root certificate authority and its intermediate certificate authorities to cryptographically bind a given public key to a given digital identity using public key signatures.
読者は、X.509バージョン3証明書の一般的な説明については、[RFC5280]に紹介されます。このドキュメントの目的のために、X.509では証明書または一連の証明書（おそらく長さ1の）が信頼できるルート証明書局とその中間証明書当局が特定の公開鍵を特定のデジタルに暗号化することを許可することを知るだけで十分です公開キーの署名を使用したID。
For all of the public key algorithms specified in this document, the key format consists of a sequence of one or more X.509v3 certificates followed by a sequence of 0 or more Online Certificate Status Protocol (OCSP) responses as in Section 4.2 of [RFC2560]. Providing OCSP responses directly in this data structure can reduce the number of communication rounds required (saving the implementation from needing to perform OCSP checking out-of-band) and can also allow a client outside of a private network to receive OCSP responses from a server behind a firewall. As with any use of OCSP data, implementations SHOULD check that the production time of the OCSP response is acceptable. It is RECOMMENDED, but not REQUIRED, that implementations reject certificates for which the certificate status is revoked.
このドキュメントで指定されたすべての公開キーアルゴリズムのすべてについて、キー形式は、[RFC2560のセクション4.2のように、1つ以上のx.509v3証明書のシーケンスと0以上のオンライン証明書ステータスプロトコル（OCSP）応答のシーケンスで構成されています。]。このデータ構造でOCSP応答を直接提供することで、必要な通信ラウンドの数を減らすことができます（実装をOCSPチェックアウトバンドを実行する必要があることから節約できます）。ファイアウォールの後ろ。OCSPデータの使用と同様に、実装はOCSP応答の生産時間が許容できることを確認する必要があります。実装が証明書のステータスが取り消される証明書を拒否することを推奨することは推奨されますが、必須ではありません。
The key format has the following specific encoding:
キー形式には、次の特定のエンコードがあります。
string "x509v3-ssh-dss" / "x509v3-ssh-rsa" /
"x509v3-rsa2048-sha256" / "x509v3-ecdsa-sha2-[identifier]"
uint32 certificate-count
string certificate[1..certificate-count]
uint32 ocsp-response-count
string ocsp-response[0..ocsp-response-count]
In the figure above, the string [identifier] is the identifier of the elliptic curve domain parameters. The format of this string is specified in Section 6.1 of [RFC5656]. Information on the REQUIRED and RECOMMENDED sets of elliptic curve domain parameters for use with this algorithm can be found in Section 10 of [RFC5656].
上の図では、文字列[識別子]は、楕円曲線ドメインパラメーターの識別子です。この文字列の形式は、[RFC5656]のセクション6.1で指定されています。このアルゴリズムで使用するための楕円曲線ドメインパラメーターの必要および推奨セットに関する情報は、[RFC5656]のセクション10に記載されています。
Each certificate and ocsp-response MUST be encoded as a string of octets using the Distinguished Encoding Rules (DER) encoding of Abstract Syntax Notation One (ASN.1) [ASN1]. An example of an SSH key exchange involving one of these public key algorithms is given in Appendix A.
各証明書とOCSP応答は、抽象的構文表記1（ASN.1）[ASN1]の著名なエンコードルール（der）エンコードを使用して、一連のオクテットとしてエンコードする必要があります。これらの公開キーアルゴリズムのいずれかを含むSSHキー交換の例は、付録Aに記載されています。
Additionally, the following constraints apply:
さらに、次の制約が適用されます。
o The sender's certificate MUST be the first certificate and the public key conveyed by this certificate MUST be consistent with the public key algorithm being employed to authenticate the sender.
o 送信者の証明書は最初の証明書でなければならず、この証明書によって伝えられる公開キーは、送信者を認証するために使用されている公開キーアルゴリズムと一致する必要があります。
o Each following certificate MUST certify the one preceding it.
o 次の各証明書は、前の証明書を証明する必要があります。
o The self-signed certificate specifying the root authority MAY be omitted. All other intermediate certificates in the chain leading to a root authority MUST be included.
o ルート当局を指定する自己署名証明書は省略できます。ルート当局につながるチェーン内の他のすべての中間証明書を含める必要があります。
o To improve the chances that a peer can verify certificate chains and OCSP responses, individual certificates and OCSP responses SHOULD be signed using only signature algorithms corresponding to public key algorithms supported by the peer, as indicated in the server_host_key_algorithms field of the SSH_MSG_KEXINIT packet (see Section 7.1 of [RFC4253]). However, other algorithms MAY be used. The choice of signature algorithm used by any given certificate or OCSP response is independent of the signature algorithms chosen by other elements in the chain.
o ピアが証明書チェーンとOCSP応答を検証できる可能性を改善するには、SSH_HOST_KEY_KKEXINITパケットのserver_key_key_algorithmsフィールドに示されているように、ピアによってサポートされている公開キーアルゴリズムに対応する署名アルゴリズムのみを使用して、個々の証明書とOCSP応答を署名する必要があります（セクションを参照してください（セクションを参照）[RFC4253]の7.1）。ただし、他のアルゴリズムを使用する場合があります。特定の証明書またはOCSP応答で使用される署名アルゴリズムの選択は、チェーン内の他の要素によって選択された署名アルゴリズムとは無関係です。
o Verifiers MUST be prepared to receive certificate chains and OCSP responses that use algorithms not listed in the server_host_key_algorithms field of the SSH_MSG_KEXINIT packet, including algorithms that potentially have no Secure Shell equivalent. However, peers sending such chains should recognize that such chains are more likely to be unverifiable than chains that use only algorithms listed in the server_host_key_algorithms field.
o 検証剤は、SSH_MSG_KEXINITパケットのserver_host_key_algorithmsフィールドにリストされていないアルゴリズムを使用する証明書チェーンとOCSP応答を受信するために準備する必要があります。ただし、そのようなチェーンを送信するピアは、そのようなチェーンは、server_host_key_algorithmsフィールドにリストされているアルゴリズムのみを使用するチェーンよりもバリフ化できない可能性が高いことを認識する必要があります。
o There is no requirement on the ordering of OCSP responses. The number of OCSP responses MUST NOT exceed the number of certificates.
o OCSP応答の順序付けには要件はありません。OCSP応答の数は、証明書の数を超えてはなりません。
Upon receipt of a certificate chain, implementations MUST verify the certificate chain according to Section 6.1 of [RFC5280] based on a root of trust configured by the system administrator or user.
証明書チェーンを受け取ると、実装は、システム管理者またはユーザーによって構成された信頼のルートに基づいて、[RFC5280]のセクション6.1に従って証明書チェーンを検証する必要があります。
Issues associated with the use of certificates (such as expiration of certificates and revocation of compromised certificates) are addressed in [RFC5280] and are outside the scope of this document. However, compliant implementations MUST comply with [RFC5280]. Implementations providing and processing OCSP responses MUST comply with [RFC2560].
証明書の使用に関連する問題（証明書の有効期限や侵害された証明書の取り消しなど）は[RFC5280]で対処され、このドキュメントの範囲外です。ただし、準拠した実装は[RFC5280]に準拠する必要があります。OCSP応答を提供および処理する実装[RFC2560]に準拠する必要があります。
When no OCSP responses are provided, it is up to the implementation and system administrator to decide whether or not to accept the certificate. It may be possible for the implementation to retrieve OCSP responses based on the id-ad-ocsp access description in the certificate's Authority Information Access data (Section 4.2.2.1 of [RFC5280]). However, if the id-ad-ocsp access description indicates that the certificate authority employs OCSP, and no OCSP response information is available, it is RECOMMENDED that the certificate be rejected.
OCSP応答が提供されていない場合、証明書を受け入れるかどうかを決定するのは実装およびシステム管理者次第です。証明書の権限情報アクセスデータ（[RFC5280]のセクション4.2.2.1）のID-AD-OCSPアクセス説明に基づいて、実装がOCSP応答を取得できる場合があります。ただし、ID-AD-OCSPアクセスの説明が、認証機関がOCSPを使用しており、OCSP応答情報が利用できないことを示している場合、証明書を拒否することをお勧めします。
[RFC5480] and [RFC5758] describe the structure of X.509v3 certificates to be used with Elliptic Curve Digital Signature Algorithm (ECDSA) public keys. [RFC3279] and [RFC5280] describe the structure of X.509v3 certificates to be used with RSA and Digital Signature Algorithm (DSA) public keys. [RFC5759] provides additional guidance for ECDSA keys in Suite B X.509v3 certificate and certificate revocation list profiles.
[RFC5480]および[RFC5758]は、Elliptic Curve Digital Signature Algorithm（ECDSA）パブリックキーで使用するX.509V3証明書の構造を説明しています。[RFC3279]および[RFC5280]は、RSAおよびデジタル署名アルゴリズム（DSA）パブリックキーで使用されるX.509V3証明書の構造を説明しています。[RFC5759]は、スイートB X.509V3証明書および証明書の取り消しリストプロファイルのECDSAキーの追加ガイダンスを提供します。
Certificate extensions allow for the specification of additional attributes associated with a public key in an X.509v3 certificate (see Section 4.2 of [RFC5280]). The KeyUsage and ExtendedKeyUsage extensions may be used to restrict the use of X.509v3 certificates in the context of the Secure Shell protocol as specified in the following sections.
証明書拡張機能では、X.509V3証明書の公開鍵に関連付けられた追加の属性の仕様を可能にします（[RFC5280]のセクション4.2を参照）。KeyUSAGEおよびExtendedKeyUsage拡張機能を使用して、次のセクションで指定されている安全なシェルプロトコルのコンテキストでX.509V3証明書の使用を制限できます。
The KeyUsage extension MAY be used to restrict a certificate's use. In accordance with Section 4.2.1.3 of [RFC5280], if the KeyUsage extension is present, then the certificate MUST be used only for one of the purposes indicated. There are two relevant keyUsage identifiers for the certificate corresponding to the public key algorithm in use:
KeyUSAGE拡張機能は、証明書の使用を制限するために使用できます。[RFC5280]のセクション4.2.1.3に従って、KeyUSAGE拡張が存在する場合、証明書は、指定された目的のいずれかに対してのみ使用する必要があります。使用中の公開キーアルゴリズムに対応する証明書には、次の2つの関連するkeyuSage識別子があります。
o If the KeyUsage extension is present in a certificate for the x509v3-ssh-dss, x509v3-ssh-rsa, x509v3-rsa2048-sha256, or x509v3- ecdsa-sha2-* public key algorithms, then the digitalSignature bit MUST be set.
o keyuSage拡張は、x509v3-ssh-dss、x509v3-ssh-rsa、x509v3-rsa2048-sha256、またはx509v3- ecdsa-sha2-*公開キーアルゴリズムの証明書に存在する場合、デジタルシグナチャビットは設定する必要があります。
o If the KeyUsage extension is present in a certificate for the ecmqv-sha2 key exchange method, then the keyAgreement bit MUST be set.
o KeyUSAGE拡張機能がECMQV-SHA2キー交換法の証明書に存在する場合、KeyAgreementビットを設定する必要があります。
For the remaining certificates in the certificate chain, implementations MUST comply with existing conventions on KeyUsage identifiers and certificates as in Section 4.2.1.3 of [RFC5280].
証明書チェーン内の残りの証明書の場合、実装は[RFC5280]のセクション4.2.1.3のように、KeyUSAGE識別子と証明書に関する既存の条約を遵守する必要があります。
This document defines two ExtendedKeyUsage key purpose IDs that MAY be used to restrict a certificate's use: id-kp-secureShellClient, which indicates that the key can be used for a Secure Shell client, and id-kp-secureShellServer, which indicates that the key can be used for a Secure Shell server. In accordance with Section 4.2.1.12 of [RFC5280], if the ExtendedKeyUsage extension is present, then the certificate MUST be used only for one of the purposes indicated. The object identifiers of the two key purpose IDs defined in this document are as follows:
このドキュメントでは、証明書の使用を制限するために使用できる2つの拡張KeyUSAGEキー目的IDを定義します。ID-KP-SecureshellClientは、キーを安全なシェルクライアントに使用できることを示します。安全なシェルサーバーに使用できます。[RFC5280]のセクション4.2.1.12に従って、拡張キーセージの拡張が存在する場合、証明書は示されている目的のいずれかに対してのみ使用する必要があります。このドキュメントで定義されている2つの重要な目的IDのオブジェクト識別子は次のとおりです。
o id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
o ID-PKIXオブジェクト識別子:: = {ISO（1）識別付き - 組織化（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）}
o id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } -- extended key purpose identifiers
o ID-kpオブジェクト識別子:: = {id-pkix 3} - 拡張キー目的識別子
o id-kp-secureShellClient OBJECT IDENTIFIER ::= { id-kp 21 }
o id-kp-secureshellclientオブジェクト識別子:: = {id-kp 21}
o id-kp-secureShellServer OBJECT IDENTIFIER ::= { id-kp 22 }
o id-kp-secureshellserverオブジェクト識別子:: = {id-kp 22}
Signing and verifying using the X.509v3-based public key algorithms specified in this document (x509v3-ssh-dss, x509v3-ssh-rsa, x509v3-ecdsa-sha2-*) is done in the analogous way for the corresponding non-X.509v3-based public key algorithms (ssh-dss, ssh-rsa, ecdsa-sha2-*, respectively); the x509v3-rsa2048-sha256 public key algorithm provides a new mechanism, similar to ssh-rsa, but has a different hash function and additional key size constraints. For concreteness, we specify this explicitly below.
このドキュメントで指定されたX.509V3ベースの公開キーアルゴリズム（X509V3-SSH-DSS、X509V3-SSH-RSA、X509V3-ECDSA-SHA2-*）で指定された署名と検証は、対応するNONXのために類似の方法で行われます.509V3ベースの公開キーアルゴリズム（SSH-DSS、SSH-RSA、ECDSA-SHA2-*、それぞれ）;X509V3-RSA2048-SHA256公開キーアルゴリズムは、SSH-RSAと同様の新しいメカニズムを提供しますが、異なるハッシュ関数と追加のキーサイズの制約があります。具体性については、これを以下に明示的に指定します。
Signing and verifying using the x509v3-ssh-dss key format is done according to the Digital Signature Standard [FIPS-186-3] using the SHA-1 hash [FIPS-180-2].
X509V3-SSH-DSSキー形式を使用して署名と検証は、SHA-1ハッシュ[FIPS-180-2]を使用したデジタル署名標準[FIPS-186-3]に従って行われます。
The resulting signature is encoded as follows:
結果の署名は次のようにエンコードされます。
string "ssh-dss" string dss_signature_blob
文字列「ssh-dss」文字列dss_signature_blob
The value for dss_signature_blob is encoded as a string containing r, followed by s (which are fixed-length 160-bit integers, without lengths or padding, unsigned, and in network byte order).
dss_signature_blobの値は、rを含む文字列としてエンコードされ、次にs（長さまたはパディングなし、符号なし、ネットワークバイトの順序で固定された160ビット整数です）。
This format is the same as for ssh-dss signatures in Section 6.6 of [RFC4253].
この形式は、[RFC4253]のセクション6.6のSSH-DSS署名の場合と同じです。
Signing and verifying using the x509v3-ssh-rsa key format is performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash [FIPS-180-2].
X509V3-SSH-RSAキー形式を使用した署名と検証は、SHA-1ハッシュ[FIPS-180-2]を使用して[RFC3447]のRSASSA-PKCS1-V1_5スキームに従って実行されます。
The resulting signature is encoded as follows:
結果の署名は次のようにエンコードされます。
string "ssh-rsa" string rsa_signature_blob
文字列「SSH-RSA」文字列RSA_SIGNATURE_BLOB
The value for rsa_signature_blob is encoded as a string containing s (which is an integer, without lengths or padding, unsigned, and in network byte order).
RSA_SIGNATURE_BLOBの値は、Sを含む文字列としてエンコードされます（これは整数であり、長さまたはパディングのない、署名なし、ネットワークバイトの順序です）。
This format is the same as for ssh-rsa signatures in Section 6.6 of [RFC4253].
この形式は、[RFC4253]のセクション6.6のSSH-RSA署名と同じです。
Signing and verifying using the x509v3-rsa2048-sha256 key format is performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-256 hash [FIPS-180-3]; RSA keys conveyed using this format MUST have a modulus of at least 2048 bits.
X509V3-RSA2048-SHA256キー形式を使用した署名と検証は、SHA-256ハッシュ[FIPS-180-3]を使用して[RFC3447]のRSASSA-PKCS1-V1_5スキームに従って実行されます。この形式を使用して伝達されるRSAキーには、少なくとも2048ビットのモジュラスが必要です。
The resulting signature is encoded as follows:
結果の署名は次のようにエンコードされます。
string "rsa2048-sha256" string rsa_signature_blob
string "rsa2048-sha256" string rsa_signature_blob
The value for rsa_signature_blob is encoded as a string containing s (which is an integer, without lengths or padding, unsigned, and in network byte order).
RSA_SIGNATURE_BLOBの値は、Sを含む文字列としてエンコードされます（これは整数であり、長さまたはパディングのない、署名なし、ネットワークバイトの順序です）。
Unlike the other public key formats specified in this document, the x509v3-rsa2048-sha256 public key format does not correspond to any previously existing SSH non-certificate public key format. The main purpose of introducing this public key format is to provide an RSA-based public key format that is compatible with current recommendations on key size and hash functions. For example, National Institute of Standards and Technology's (NIST's) draft recommendations on cryptographic algorithms and key lengths [SP-800-131] specify that digital signature generation using an RSA key with modulus less than 2048 bits or with the SHA-1 hash function is acceptable through 2010 and deprecated from 2011 through 2013, whereas an RSA key with modulus at least 2048 bits and SHA-256 is acceptable for the indefinite future. The introduction of other non-certificate-based SSH public key formats compatible with the above recommendations is outside the scope of this document.
このドキュメントで指定されている他の公開キー形式とは異なり、X509V3-RSA2048-SHA256公開キー形式は、以前に既存のSSH非認証公開キー形式に対応していません。この公開キー形式を導入する主な目的は、キーサイズとハッシュ関数に関する現在の推奨事項と互換性のあるRSAベースの公開キー形式を提供することです。たとえば、国立標準技術研究所（NISTの）暗号化アルゴリズムとキー長[SP-800-131]に関する推奨事項は、2048ビット未満またはSHA-1ハッシュ関数を使用して、モジュラスを使用してRSAキーを使用してデジタル署名生成を指定しています。2010年まで受け入れられ、2011年から2013年まで廃止されますが、少なくとも2048ビットとSHA-256の弾性率を持つRSAキーは、無期限の未来には許容されます。上記の推奨事項と互換性のある他の非認証ベースのSSH公開キー形式の導入は、このドキュメントの範囲外です。
Signing and verifying using the x509v3-ecdsa-sha2-* key formats is performed according to the ECDSA algorithm in [FIPS-186-3] using the SHA2 hash function family [FIPS-180-3]. The choice of hash function from the SHA2 hash function family is based on the key size of the ECDSA key as specified in Section 6.2.1 of [RFC5656].
X509V3-ECDSA-SHA2-*キーフォーマットを使用した署名と検証は、SHA2ハッシュ関数ファミリー[FIPS-180-3]を使用して[FIPS-186-3]のECDSAアルゴリズムに従って実行されます。SHA2ハッシュ関数ファミリーからのハッシュ関数の選択は、[RFC5656]のセクション6.2.1で指定されているECDSAキーのキーサイズに基づいています。
The resulting signature is encoded as follows:
結果の署名は次のようにエンコードされます。
string "ecdsa-sha2-[identifier]" string ecdsa_signature_blob
string "ecdsa-sha2- [識別子]" string ecdsa_signature_blob
The string [identifier] is the identifier of the elliptic curve domain parameters. The format of this string is specified in Section 6.1 of [RFC5656].
文字列[識別子]は、楕円曲線ドメインパラメーターの識別子です。この文字列の形式は、[RFC5656]のセクション6.1で指定されています。
The ecdsa_signature_blob value has the following specific encoding:
ECDSA_SIGNATURE_BLOB値には、次の特定のエンコードがあります。
mpint r mpint s
mpint r mpint s
The integers r and s are the output of the ECDSA algorithm.
整数RとSは、ECDSAアルゴリズムの出力です。
This format is the same as for ecdsa-sha2-* signatures in Section 3.1.2 of [RFC5656].
この形式は、[RFC5656]のセクション3.1.2のECDSA-SHA2-*署名と同じです。
The public key algorithms and encodings defined in this document SHOULD be accepted any place in the Secure Shell protocol suite where public keys are used, including, but not limited to, the following protocol messages for server authentication and user authentication:
このドキュメントで定義されている公開キーアルゴリズムとエンコーディングは、サーバー認証とユーザー認証のための以下のプロトコルメッセージを含むがこれらに限定されない、パブリックキーが使用される安全なシェルプロトコルスイートの任意の場所を受け入れる必要があります。
o in the SSH_MSG_USERAUTH_REQUEST message when "publickey" authentication is used [RFC4252]
o 「publickey」認証が使用されるときのssh_msg_userauth_requestメッセージ[RFC4252]
o in the SSH_MSG_USERAUTH_REQUEST message when "hostbased" authentication is used [RFC4252]
o 「ホストベース」認証が使用されるときのssh_msg_userauth_requestメッセージ[RFC4252]
o in the SSH_MSG_KEXDH_REPLY message [RFC4253]
o ssh_msg_kexdh_replyメッセージ[rfc4253]
o in the SSH_MSG_KEXRSA_PUBKEY message [RFC4432]
o ssh_msg_kexrsa_pubkeyメッセージ[rfc4432]
o in the SSH_MSG_KEXGSS_HOSTKEY message [RFC4462]
o ssh_msg_kexgss_hostkeyメッセージ[rfc4462]
o in the SSH_MSG_KEX_ECDH_REPLY message [RFC5656]
o ssh_msg_kex_ecdh_replyメッセージ[rfc5656]
o in the SSH_MSG_KEX_ECMQV_REPLY message [RFC5656]
o ssh_msg_kex_ecmqv_replyメッセージ[rfc5656]
When a public key from this specification is included in the input to a hash algorithm, the exact bytes that are transmitted on the wire must be used as input to the hash functions. In particular, implementations MUST NOT omit any of the chain certificates or OCSP responses that were included on the wire, nor change encoding of the certificate or OCSP data. Otherwise, hashes that are meant to be computed in parallel by both peers will have differing values.
この仕様の公開キーがハッシュアルゴリズムへの入力に含まれている場合、ワイヤに送信される正確なバイトをハッシュ関数への入力として使用する必要があります。特に、実装は、ワイヤーに含まれているチェーン証明書またはOCSP応答を省略したり、証明書またはOCSPデータのエンコードを変更してはなりません。それ以外の場合、両方のピアによって並行して計算されることを意図したハッシュには、値が異なります。
For the purposes of user authentication, the mapping between certificates and user names is left as an implementation and configuration issue for implementers and system administrators.
ユーザー認証の目的で、証明書とユーザー名のマッピングは、実装者とシステム管理者の実装および構成の問題として残されます。
For the purposes of server authentication, it is RECOMMENDED that implementations support the following mechanism mapping host names to certificates. However, local policy MAY disable the mechanism or MAY impose additional constraints before considering a matching successful. Furthermore, additional mechanisms mapping host names to certificates MAY be used and are left as implementation and configuration issues for implementers and system administrators.
サーバー認証の目的のために、実装がホスト名を証明書にマッピングするメカニズムをサポートすることをお勧めします。ただし、ローカルポリシーは、一致する成功を検討する前に、メカニズムを無効にしたり、追加の制約を課す場合があります。さらに、ホスト名を証明書にマッピングする追加のメカニズムが使用される場合があり、実装者とシステム管理者の実装および構成の問題として残されます。
The RECOMMENDED server authentication mechanism is as follows. The subjectAlternativeName X.509v3 extension, as described in Section 4.2.1.6 of [RFC5280], SHOULD be used to convey the server host name, using either dNSName entries or iPAddress entries to convey domain names or IP addresses as appropriate. Multiple entries MAY be specified. The following rules apply:
推奨されるサーバー認証メカニズムは次のとおりです。[RFC5280]のセクション4.2.1.6で説明されているように、dnsnameエントリまたはiPaddressエントリのいずれかを使用して、ドメイン名またはIPアドレスを必要に応じて伝達するためにサーバーホスト名を伝えるために、subjectalternativename x.509v3拡張機能を使用する必要があります。複数のエントリを指定できます。次のルールが適用されます。
o If the client's reference identifier (e.g., the host name typed by the client) is a DNS domain name, the server's identity SHOULD be checked using the rules specified in [RFC6125]. Support for the DNS-ID identifier type is RECOMMENDED in client and server software implementations. Certification authorities that issue certificates for use by Secure Shell servers SHOULD support the DNS-ID identifier type. Service providers SHOULD include the DNS-ID identifier type in certificate requests. The DNS-ID MAY contain the wildcard character '*' as the complete left-most label within the identifier.
o クライアントの参照識別子（クライアントによって入力されたホスト名など）がDNSドメイン名である場合、[RFC6125]で指定されたルールを使用してサーバーのIDを確認する必要があります。DNS-ID識別子タイプのサポートは、クライアントおよびサーバーソフトウェアの実装で推奨されます。Secure Shellサーバーで使用する証明書を発行する認証当局は、DNS-ID識別子タイプをサポートする必要があります。サービスプロバイダーは、証明書リクエストにDNS-ID識別子タイプを含める必要があります。dns-idには、識別子内の完全な左最大のラベルとしてワイルドカード文字 '*'が含まれる場合があります。
o If the client's reference identifier is an IP address as defined by [RFC0791] or [RFC2460], the client SHOULD convert that address to the "network byte order" octet string representation and compare it against a subjectAltName entry of type iPAddress. A match occurs if the octet strings are identical for the reference identifier and any presented identifier.
o クライアントの参照識別子が[RFC0791]または[RFC2460]で定義されているIPアドレスである場合、クライアントはそのアドレスを「ネットワークバイト」オクテット文字列表現に変換し、iPaddressのタイプのエントリと比較します。オクテット文字列が参照識別子と提示された識別子の場合に同一である場合、一致が発生します。
This document provides new public key algorithms for the Secure Shell protocol that convey public keys using X.509v3 certificates. For the most part, the security considerations involved in using the Secure Shell protocol apply, since all of the public key algorithms introduced in this document are based on existing algorithms in the Secure Shell protocol. However, implementers should be aware of security considerations specific to the use of X.509v3 certificates in a public key infrastructure, including considerations related to expired certificates and certificate revocation lists.
このドキュメントは、X.509V3証明書を使用してパブリックキーを伝える安全なシェルプロトコルの新しい公開キーアルゴリズムを提供します。このドキュメントで導入されたすべての公開キーアルゴリズムはすべて、安全なシェルプロトコルの既存のアルゴリズムに基づいているため、ほとんどの場合、Secure Shellプロトコルの使用に伴うセキュリティに関する考慮事項が適用されます。ただし、実装者は、期限切れの証明書や証明書の取り消しリストに関連する考慮事項を含む、公開キーインフラストラクチャでのX.509V3証明書の使用に固有のセキュリティ上の考慮事項を認識する必要があります。
The reader is directed to the security considerations sections of [RFC5280] for the use of X.509v3 certificates, [RFC2560] for the use of OCSP response, [RFC4253] for server authentication, and [RFC4252] for user authentication. Implementations SHOULD NOT use revoked certificates because many causes of certificate revocation mean that the critical authentication properties needed are no longer true.
読者は、X.509V3証明書を使用するために[RFC5280]のセキュリティに関する考慮事項セクション、[RFC2560]、OCSP応答を使用するための[RFC2560]、サーバー認証のための[RFC4253]、およびユーザー認証のための[RFC4252]に向けられています。証明書の取り消しの多くの原因は、必要な批判的認証プロパティがもはや真でないことを意味するため、実装は取り消された証明書を使用してはなりません。
For example, compromise of a certificate's private key or issuance of a certificate to the wrong party are common reasons to revoke a certificate.
たとえば、証明書の秘密鍵の妥協または間違った当事者への証明書の発行は、証明書を取り消す一般的な理由です。
If a party to the SSH exchange attempts to use a revoked X.509v3 certificate, this attempt along with the date, time, certificate identity, and apparent origin IP address of the attempt SHOULD be logged as a security event in the system's audit logs or the system's general event logs. Similarly, if a certificate indicates that OCSP is used and there is no response to the OCSP query, the absence of a response along with the details of the attempted certificate use (as before) SHOULD be logged.
SSH Exchangeの当事者が取り消されたX.509V3証明書を使用しようとした場合、この試みと、Time、Time、証明書ID、および試行の見かけのOrigin IPアドレスとともに、システムの監査ログのセキュリティイベントとして記録する必要があります。システムの一般的なイベントログ。同様に、証明書がOCSPが使用され、OCSPクエリへの応答がないことを示している場合、試行された証明書の使用の詳細とともに（前と同様に）応答がないことを記録する必要があります。
As with all specifications involving cryptographic algorithms, the quality of security provided by this specification depends on the strength of the cryptographic algorithms in use, the security of the keys, the correctness of the implementation, and the security of the public key infrastructure and the certificate authorities. Accordingly, implementers are encouraged to use high-assurance methods when implementing this specification and other parts of the Secure Shell protocol suite.
暗号化アルゴリズムを含むすべての仕様と同様に、この仕様によって提供されるセキュリティの品質は、使用中の暗号化アルゴリズムの強度、キーのセキュリティ、実装の正しさ、公開鍵インフラストラクチャのセキュリティと証明書に依存します。当局。したがって、実装者は、この仕様や安全なシェルプロトコルスイートの他の部分を実装する際に、高補助方法を使用することをお勧めします。
Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250], this document makes the following registrations:
[RFC4251]のセクション8および[RFC4250]のセクション4.6と一致して、このドキュメントは次の登録を作成します。
In the Public Key Algorithm Names registry:
公開キーアルゴリズム名レジストリ：
o The SSH public key algorithm "x509v3-ssh-dss".
o SSH公開キーアルゴリズム「X509V3-SSH-DSS」。
o The SSH public key algorithm "x509v3-ssh-rsa".
o SSH公開キーアルゴリズム「X509V3-SSH-RSA」。
o The SSH public key algorithm "x509v3-rsa2048-sha256".
o SSH公開キーアルゴリズム「X509V3-RSA2048-SHA256」。
o The family of SSH public key algorithm names beginning with "x509v3-ecdsa-sha2-" and not containing the at-sign ('@').
o SSH公開キーアルゴリズムのファミリーは、「x509v3-ecdsa-sha2-」で始まり、at-Sign（ '@'）を含んでいません。
The two object identifiers used in Section 2.2.2 were assigned from an arc delegated by IANA to the PKIX Working Group.
セクション2.2.2で使用されている2つのオブジェクト識別子は、IANAによってPKIXワーキンググループに委任されたアークから割り当てられました。
[ASN1] International Telecommunications Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", X.680, July 2002.
[ASN1] International Telecommunications Union、「Abstract Syntax Notation One（ASN.1）：基本表記の仕様」、X.680、2002年7月。
[FIPS-180-2] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, August 2002.
[FIPS-180-2]国立標準技術研究所、「Secure Hash Standard」、FIPS 180-2、2002年8月。
[FIPS-180-3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-3, October 2008.
[FIPS-180-3]国立標準技術研究所、「Secure Hash Standard」、FIPS 180-3、2008年10月。
[FIPS-186-3] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS 186-3, June 2009.
[FIPS-186-3]国立標準技術研究所、「デジタル署名標準（DSS）」、FIPS 186-3、2009年6月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラストラクチャオンライン証明書ステータスプロトコル」、RFC 2560、1999年6月。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279] Bassham、L.、Polk、W。、およびR. Housley、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイルのアルゴリズムと識別子」、RFC 3279、2002年4月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA暗号仕様バージョン2.1」、RFC 3447、2003年2月。
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4250] Lehtinen、S。およびC. Lonvick、「Secure Shell（SSH）プロトコルが割り当てられた数字」、RFC 4250、2006年1月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[RFC4252] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）認証プロトコル」、RFC 4252、2006年1月。
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）輸送層プロトコル」、RFC 4253、2006年1月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480] Turner、S.、Brown、D.、Yiu、K.、Housley、R。、およびT. Polk、「Elliptic Curve Cryptography Subject Public Key Information」、RFC 5480、2009年3月。
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, December 2009.
[RFC5656] Stebila、D。およびJ. Green、「安全なシェル輸送層における楕円曲線アルゴリズムの統合」、RFC 5656、2009年12月。
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", RFC 5758, January 2010.
[RFC5758] Dang、Q.、Santesson、S.、Moriarty、K.、Brown、D。、およびT. Polk、「Internet X.509公開キーインフラストラクチャ：DSAおよびECDSAの追加アルゴリズムと識別子」、RFC 5758、2010年1月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「輸送層のセキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開キーインフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、RFC 6125、2011年3月。
[SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", SEC 1, September 2000, <http://www.secg.org/download/aid-780/sec1-v2.pdf>.
[SEC1]効率的な暗号化グループの基準、「Elliptic Curve Cryptography」、Sec 1、2000年9月、<http://www.secg.org/download/aid-780/sec1-v2.pdf>。
[RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4432, March 2006.
[RFC4432] Harris、B。、「Secure Shell（SSH）輸送層プロトコルのRSAキーエクスチェンジ」、RFC 4432、2006年3月。
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, May 2006.
[RFC4462] Hutzelman、J.、Salowey、J.、Galbraith、J.、およびV. Welch、「ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）認証とセキュアシェル（SSH）プロトコルの主要な交換」、RFC4462、2006年5月。
[RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and Certificate Revocation List (CRL) Profile", RFC 5759, January 2010.
[RFC5759] Solinas、J。およびL. Zieglar、「Suite B証明書および証明書取消リスト（CRL）プロファイル」、RFC 5759、2010年1月。
[SP-800-131] Barker, E. and A. Roginsky, "DRAFT Recommendation for the Transitioning of Cryptographic Algorithms and Key Lengths", NIST Special Publication 800-131, June 2010.
[SP-800-131] Barker、E。およびA. Roginsky、「暗号化アルゴリズムとキー長の移行に関する推奨事項草案」、NIST Special Publication 800-131、2010年6月。
The following example illustrates the use of an X.509v3 certificate for a public key for the Digital Signature Algorithm when used in a Diffie-Hellman key exchange method. In the example, there is a chain of certificates of length 2, and a single OCSP response is provided.
次の例は、diffie-hellmanキー交換方法で使用された場合のデジタル署名アルゴリズムの公開キーにx.509v3証明書を使用することを示しています。この例では、長さ2の証明書のチェーンがあり、単一のOCSP応答が提供されています。
byte SSH_MSG_KEXDH_REPLY string 0x00 0x00 0xXX 0xXX -- length of the remaining data in this string 0x00 0x00 0x00 0x0D -- length of string "x509v3-ssh-dss" "x509v3-ssh-dss" 0x00 0x00 0x00 0x02 -- there are 2 certificates 0x00 0x00 0xXX 0xXX -- length of sender certificate DER-encoded sender certificate 0x00 0x00 0xXX 0xXX -- length of issuer certificate DER-encoded issuer certificate 0x00 0x00 0x00 0x01 -- there is 1 OCSP response 0x00 0x00 0xXX 0xXX -- length of OCSP response DER-encoded OCSP response mpint f string signature of H
byte ssh_msg_kexdh_reply string 0x00 0x00 0xxx 0xxx - この文字列の残りのデータの長さ0x00 0x00 0x00 0x0d-文字列の長さ "x509v3-ssh-dss" "x509v3-ssh-dss" 0x00 0x00 0x02-0x00 0x00 0xxx 0xxx-送信者証明書Der-Encoded Sender証明書の長さ0x00 0xx00 0xxx 0xxx-発行者証明書の長さDer-Encoded Issuer証明書0x00 0x00 0x00 0x00hの応答der-Encoded OCSP応答mpint f文字列署名
The authors gratefully acknowledge helpful comments from Ran Atkinson, Samuel Edoho-Eket, Joseph Galbraith, Russ Housley, Jeffrey Hutzelman, Jan Pechanec, Peter Saint-Andre, Sean Turner, and Nicolas Williams.
著者は、Ran Atkinson、Samuel Edoho-Eket、Joseph Galbraith、Russ Housley、Jeffrey Hutzelman、Jan Pechanec、Peter Saint-Andre、Sean Turner、Nicolas Williamsからの有益なコメントを感謝しています。
O. Saarenmaa and J. Galbraith previously drafted a document on a similar topic.
O. SaarenmaaとJ. Galbraithは以前、同様のトピックに関する文書を起草しました。
Authors' Addresses
著者のアドレス
Kevin M. Igoe National Security Agency NSA/CSS Commercial Solutions Center United States of America
Kevin M. Igoe国家安全保障局NSA/CSSコマーシャルソリューションセンターアメリカ合衆国
EMail: kmigoe@nsa.gov
Douglas Stebila Queensland University of Technology Information Security Institute Level 7, 126 Margaret St Brisbane, Queensland 4000 Australia
ダグラス・ステビラ・クイーンズランド大学技術情報情報セキュリティ研究所レベル7、126マーガレット・セント・ブリスベン、クイーンズランド4000オーストラリア
EMail: douglas@stebila.ca