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
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に指定された公開鍵をバインドするために、信頼できる認証局によって署名を使用しています。この文書では、Secure Shellプロトコルに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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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つのSecure Shell（SSH）プロトコルがあります。トランスポート層プロトコル、[RFC4253]で説明したが、（「公開鍵アルゴリズム」と呼ばれる）は、デジタル署名アルゴリズムがクライアントにサーバーを認証するために使用されなければならないことが必要です。また、ユーザ認証プロトコル[RFC4252]に記載のサーバ（「公開」認証）にクライアントを認証するデジタル署名の使用を可能にします。
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管理を提供するために、多くの企業や政府機関の環境で使用されています。彼らは、信頼されたルート証明機関によって署名のチェーンを使用し、その中間認証局は、与えられたデジタル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.
プリティグッドプライバシー（PGP）は、デジタルアイデンティティに公開鍵を結合するための独自の方法を持っているので、この文書は、単に非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.
公開鍵はECMQV-SHA2鍵交換方式で使用することができ書X509v3-ECDSA-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.
Secure ShellプロトコルでのX.509v3証明書を使用するための以前の提案は、O. Saarenmaa及びJ.ガルブレイスによって導入されました。この文書はその先に提案によって部分的に知らされている間、それは厳格な互換性を維持しません。
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-によって与えられたアルゴリズムの家族*：この文書では、Secure Shellプロトコルで使用するため、次の新しい公開鍵アルゴリズムを定義します。これらのアルゴリズムでは、公開鍵は、X.509v3証明書に格納されます。この証明書は、信頼できる認証局につながる証明書のチェーン、および証明書の失効ステータスを与えるオプションのメッセージは、このセクションのフォーマットに従って、Secure Shellプロトコルにおける公開鍵データとして送信されます。
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節のように0以上のオンライン証明書状態プロトコル（OCSP）応答のシーケンスが続く一の以上のX.509v3証明書のシーケンスで構成します]。このデータ構造に直接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]
文字列 "書X509v3-SSH-DSS" / "書X509v3-SSH-RSA" / "書X509v3-rsa2048-SHA256" / "書X509v3-ECDSA-sha2- [識別子" UINT32証明書数の文字列証明書[1..certificateカウント] UINT32 OCSP応答カウント文字列OCSP応答[0..ocsp応答カウント]
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で指定されています。 REQUIREDこのアルゴリズムで使用するための楕円曲線ドメインパラメータの推奨設定の情報は、[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応答は、識別符号化規則（DER）抽象構文記法1（ASN.1）のエンコーディング[ASN1]を使用して、オクテットのストリングとしてコード化されなければなりません。これらの公開鍵アルゴリズムのいずれかを含む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 root権限を指定して、自己署名証明書を省略することができます。 root権限につながるチェーン内の他のすべての中間証明書を含まなければなりません。
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.
SSH_MSG_KEXINITパケットのserver_host_key_algorithmsフィールドに示されているように、ピアは、証明書チェーンとOCSP応答、個々の証明書及びOCSP応答を検証することができる可能性を向上させるために、Oは、ピアによってサポートされている公開鍵アルゴリズムに対応する唯一の署名アルゴリズムを使用して署名されるべきである（参照[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レスポンスが提供されていない場合は、証明書を受け入れるかどうかを決定するために実装し、システム管理者に任されています。実装は、証明書の機関情報アクセスデータのid-広告OCSPアクセス記述に基づいて、OCSP応答を取得することは可能かもしれない（[RFC5280]のセクション4.2.2.1）。 ID-広告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]は楕円曲線デジタル署名アルゴリズム（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.
証明書拡張は、（[RFC5280]のセクション4.2を参照）のX.509v3証明書の公開鍵に関連した追加属性の指定が可能になります。 KeyUsageとextendedKeyUsageの拡張は、以下のセクションで指定されているSecure Shellプロトコルの文脈での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エクステンションは、証明書の使用を制限するために使用されるかもしれません。 KeyUsage拡張が存在する場合、[RFC5280]のセクション4.2.1.3によれば、その後、証明書のみ示さ目的のために使用されなければなりません。使用されている公開鍵アルゴリズムに対応する証明書のための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.
KeyUsage拡張が書X509v3-SSH-DSS、書X509v3-SSH-RSA、書X509v3-rsa2048-SHA256、またはx509v3- ECDSA-sha2- *公開鍵アルゴリズムのための証明書の中に存在する場合、O、次いでデジタル署名ビットを設定しなければなりません。
o If the KeyUsage extension is present in a certificate for the ecmqv-sha2 key exchange method, then the keyAgreement bit MUST be set.
KeyUsage拡張がECMQV-SHA2鍵交換方式の証明書内に存在する場合にO、次いでする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:
キーことを示しているキーは、Secure Shellクライアントのために使用することができることを示しているID-KP-secureShellClient、及びID-KP-secureShellServer、このドキュメントでは、証明書の使用を制限するために使用可能な2つのextendedKeyUsageの主要な目的のIDを定義しますセキュア・シェル・サーバー用に使用することができます。 extendedKeyUsageの拡張子が存在する場合、[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-kp OBJECT IDENTIFIER ::= { id-pkix 3 } -- extended key purpose
identifiers
o id-kp-secureShellClient OBJECT IDENTIFIER ::= { id-kp 21 }
o id-kp-secureShellServer OBJECT IDENTIFIER ::= { 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のために類似の方法で行われ、この文書（書X509v3-SSH-DSS、書X509v3-SSH-RSA、書X509v3-ECDSA-sha2- *）で指定のX.509v3ベースの公開鍵アルゴリズムを使用して検証.509v3ベースの公開鍵アルゴリズム（それぞれ、SSH-DSS、SSH-RSA、ECDSA-sha2- *）。書X509v3-rsa2048-SHA256公開鍵アルゴリズムは、RSAをSSHで接続するには同様の新しいメカニズムを、提供していますが、異なるハッシュ関数と追加のキーサイズの制約があります。具体性のために、私たちは、明示的に以下にこれを指定します。
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キーの形式を使用して検証[FIPS-186-3] SHA-1ハッシュを使用して、[FIPS-180-2]。
The resulting signature is encoded as follows:
次のように得られた署名は、コードされます。
string "ssh-dss" string dss_signature_blob
文字列dss_signature_blob "のssh-DSS"
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の値はS続いRを含む文字列（長さまたはパディングなしの固定長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].
署名とSHA-1ハッシュを使用して、[RFC3447]にRSASSA-PKCS1-v1_5のスキームに従って実行さ書X509v3-SSH-RSAキーの形式を使用して検証[FIPS-180-2]。
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キーフォーマットを使用して検証することは、[RFC3447] SHA-256ハッシュを使用してRSASSA-PKCS1-v1_5のスキームに従って行われる[FIPS-180-3]。 RSAキーは、少なくとも2048ビットの係数を持たなければならないこの形式を使用して搬送されます。
The resulting signature is encoded as follows:
次のように得られた署名は、コードされます。
string "rsa2048-sha256" string rsa_signature_blob
文字列 "rsa2048-SHA256" の文字列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年まで非推奨、弾性率を有するRSA鍵に対し少なくとも2048ビットおよびSHA-256は、不定将来のために許容可能です。上記勧告に適合する他の非証明書ベースの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].
署名し、[FIPS-186-3] SHA2ハッシュ関数のファミリを使用してECDSAアルゴリズムに従って実行される書X509v3-ECDSA-sha2- *キーフォーマットを使用して検証[FIPS-180-3]。 [RFC5656]のセクション6.2.1に指定されているSHA2ハッシュ関数族からハッシュ関数の選択は、ECDSAキーのキーサイズに基づいています。
The resulting signature is encoded as follows:
次のように得られた署名は、コードされます。
string "ecdsa-sha2-[identifier]" string ecdsa_signature_blob
文字列 "ECDSA-sha2- [識別子]" 文字列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秒
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:
この文書で定義された公開鍵アルゴリズムとエンコーディングは、公開鍵を含めて、使用されているSecure Shellプロトコルスイート内の任意の場所を受け入れたが、サーバー認証とユーザー認証のための以下のプロトコルメッセージ、これらに限定されないする必要があります。
o in the SSH_MSG_USERAUTH_REQUEST message when "publickey" authentication is used [RFC4252]
「公開」の認証が使用されているSSH_MSG_USERAUTH_REQUESTメッセージ[RFC4252]でO
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]
SSH_MSG_KEXDH_REPLYメッセージ中のO [RFC4253]
o in the SSH_MSG_KEXRSA_PUBKEY message [RFC4432]
SSH_MSG_KEXRSA_PUBKEYメッセージ中のO [RFC4432]
o in the SSH_MSG_KEXGSS_HOSTKEY message [RFC4462]
SSH_MSG_KEXGSS_HOSTKEYメッセージ中のO [RFC4462]
o in the SSH_MSG_KEX_ECDH_REPLY message [RFC5656]
SSH2_MSG_KEX_ECDH_REPLYメッセージ中のO [RFC 5656]
o in the SSH_MSG_KEX_ECMQV_REPLY message [RFC5656]
SSH_MSG_KEX_ECMQV_REPLYメッセージ中のO [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:
次のように推奨サーバー認証メカニズムがあります。 SubjectAlternativeNameののX.509v3拡張機能は、[RFC5280]のセクション4.2.1.6で説明したように、必要に応じてドメイン名またはIPアドレスを伝えるためのdNSNameエントリまたはIPアドレスのエントリのいずれかを使用して、サーバーのホスト名を伝えるために使用されるべきです。複数のエントリを指定することができます。次の規則が適用されます。
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.
クライアントの参照識別子（例えば、クライアントが入力したホスト名が）DNSドメイン名である場合には、O、サーバーのIDは、[RFC6125]で指定されたルールを使用してチェックする必要があります。 DNS-IDの識別子タイプのサポートは、クライアントとサーバソフトウェアの実装で推奨されています。セキュアシェルサーバで使用するために発行する証明書は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.
[RFC0791]または[RFC2460]で定義されるように、クライアントの参照識別子はIPアドレスである場合、O、クライアントは「ネットワークバイト順」オクテットストリング表現にそのアドレスを変換し、タイプIPアドレスののsubjectAltNameエントリに対してそれを比較する必要があります。オクテットストリングが参照識別子及び任意の提示された識別子のために同一である場合、一致が起こります。
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プロトコルのための新しい公開鍵アルゴリズムを提供します。本書で紹介した公開鍵アルゴリズムの全てがSecure Shellプロトコルの既存のアルゴリズムに基づいているため、ほとんどの部分については、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]、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交換の当事者が失効したX.509v3証明書を使用しようとすると、この日付、時刻、証明書IDと一緒にしよう、と試みの見かけの起点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.
すべての仕様は、暗号化アルゴリズムを含むと同じように、この仕様によって提供されるセキュリティの品質は、使用中の暗号アルゴリズムの強さに依存し、キーのセキュリティ、実装の正確さ、および公開鍵インフラストラクチャのセキュリティと証明書当局。したがって、実装は、本明細書とSecure Shellプロトコルスイートの他の部品を実装する際に高保証の方法を使用することが奨励されます。
Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250], this document makes the following registrations:
[RFC4251]と[RFC4250]の4.6節の第8節と一致して、このドキュメントは以下の登録を行います
In the Public Key Algorithm Names registry:
公開鍵アルゴリズム名のレジストリで：
o The SSH public key algorithm "x509v3-ssh-dss".
SSH公開鍵アルゴリズム "書X509v3-のssh-DSS" O。
o The SSH public key algorithm "x509v3-ssh-rsa".
SSH公開鍵アルゴリズム "書X509v3-SSH-RSA" O。
o The SSH public key algorithm "x509v3-rsa2048-sha256".
SSH公開鍵アルゴリズム "書X509v3-rsa2048-SHA256" O。
o The family of SSH public key algorithm names beginning with "x509v3-ecdsa-sha2-" and not containing the at-sign ('@').
SSH公開鍵アルゴリズム名の家族が「書X509v3-ECDSA-sha2-」で始まるとアットマーク（「@」）を含有しない、O。
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つのオブジェクト識別子は、PKIXワーキンググループにIANAによって委任アークから割り当てられました。
[ASN1] International Telecommunications Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", X.680, July 2002.
[ASN1]国際電気通信連合は、 "抽象構文記法1（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]アメリカ国立標準技術研究所、 "ハッシュ標準セキュア"、2002年8月、180-2をFIPS。
[FIPS-180-3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-3, October 2008.
[FIPS-180-3]アメリカ国立標準技術研究所、 "ハッシュ標準セキュア"、2008年10月、180-3をFIPS。
[FIPS-186-3] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS 186-3, June 2009.
[FIPS-186-3]アメリカ国立標準技術研究所、 "デジタル署名標準（DSS）は、" 2009年6月、186-3をFIPS。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン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]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、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.、ポーク、W.、およびR. Housley氏、RFC 3279、2002年4月 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールのためのアルゴリズムと識別子"。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]ジョンソン、J.とB. Kaliski、 "公開鍵暗号規格（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]レーティネン、S.とC. Lonvick、 "セキュアシェル（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、 "セキュアシェル（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、 "セキュアシェル（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、 "セキュアシェル（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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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]ターナー、S.、ブラウン、D.、耀輝、K.、Housley氏、R.、およびT.ポーク、 "楕円曲線暗号件名公開鍵情報"、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.グリーン、 "セキュアシェルトランスポート層での楕円曲線アルゴリズムの統合"、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]ダン、Q.、Santesson、S.、モリアーティ、K.、ブラウン、D.、およびT.ポーク、 "インターネット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]サンアンドレ、P.およびJ.ホッジス、「表現およびTransport Layer Security（TLS）の文脈でインターネット公開鍵インフラストラクチャの使用X.509内のドメインベースのアプリケーションサービスのアイデンティティの検証（PKIX）証明書」、 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]効率的な暗号化グループのための基準、 "楕円曲線暗号"、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]ハリス、B.、 "セキュアシェル（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.、ガルブレイス、J.、およびV.ウェルチ、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェース（GSS-API）の認証とセキュアシェル（SSH）プロトコルのための鍵交換"、RFC 4462、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.チーグラー、 "スイート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]バーカー、E.、およびA. Roginsky、、は、NIST Special Publication 800から131 2010年6月、「暗号アルゴリズムや鍵長の移行するため勧告案」。
Appendix A. Example
付録A.例
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.
次の例は、ディフィー・ヘルマン鍵共有法で使用されるデジタル署名アルゴリズムのための公開鍵の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
バイトSSH_MSG_KEXDH_REPLY列は0x00 0x00の0XXX 0XXX - この文字列に残っているデータの長さは0x00 0x00には0x00 0x0Dの - 文字列の長さ "書X509v3-SSH-DSS" "は0x00 0x00には0x00 0x02の" 書X509v3-SSH-DSS - 2つの証明書が存在します0x00には0x00 0XXX 0XXX - 送信者証明書のDER符号化された送信者証明書は0x00 0x00の0XXX 0XXXの長さ - 発行者証明書のDER符号化された発行者証明書の長さは0x00 0x00には0x00が0x01 - OCSPの長さ - 1つのOCSP応答は0x00 0x00の0XXX 0XXXがありますHの応答DER符号化されたOCSP応答mpint F列署名
Appendix B. Acknowledgements
付録B.謝辞
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.
作者は感謝蘭アトキンソン、サミュエルEdoho-Eket、ジョセフ・ガルブレイス、ラスHousley、ジェフリーHutzelman、ヤンPechanec、ピーター・サン・アンドレ、ショーン・ターナー、そしてニコラス・ウィリアムズから有益なコメントを認めます。
O. Saarenmaa and J. Galbraith previously drafted a document on a similar topic.
O. SaarenmaaとJ.ガルブレイスは、以前と同様のトピックに関する文書を起草しました。
Authors' Addresses
著者のアドレス
Kevin M. Igoe National Security Agency NSA/CSS Commercial Solutions Center United States of America
ケビンM. Igoe国家安全保障局（NSA）NSA / CSSコマーシャル・ソリューションズ・センターアメリカ合衆国
EMail: kmigoe@nsa.gov
メールアドレス：kmigoe@nsa.gov
Douglas Stebila Queensland University of Technology Information Security Institute Level 7, 126 Margaret St Brisbane, Queensland 4000 Australia
ダグラスStebilaクイーンズランド工科大学の情報セキュリティ研究所レベル7、126マーガレットセントブリスベン、クイーンズランド4000オーストラリア
EMail: douglas@stebila.ca
メールアドレス：douglas@stebila.ca