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
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
用于安全Shell身份验证的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公钥证书使用可信证书颁发机构的签名将给定公钥绑定到给定数字标识。本文档指定如何在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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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).
有两种安全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]的数字证书，在许多公司和政府环境中用于提供身份管理。它们使用可信根证书颁发机构及其中间证书颁发机构的签名链将给定的公共签名密钥绑定到给定的数字身份。
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] |
+--------------+-----------+
+--------------+-----------+
| 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）有自己的方法将公钥绑定到数字身份，因此本文档仅关注非PGP方法。特别是，本文档定义了以下公钥算法，它们与上述算法的不同之处在于使用X.509v3证书来传递签名者的公钥。
+-----------------------+
| Algorithm |
+-----------------------+
| x509v3-ssh-dss |
| |
| x509v3-ssh-rsa |
| |
| x509v3-rsa2048-sha256 |
| |
| x509v3-ecdsa-sha2-* |
+-----------------------+
+-----------------------+
| 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
本文档涉及SSH实现细节；底层加密算法的规范以及X.509v3证书的处理和结构留给其他人
standards documents, particularly [RFC3447], [FIPS-186-3], [FIPS-180-2], [FIPS-180-3], [SEC1], and [RFC5280].
标准文件，尤其是[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.
O.Saarenmaa和J.Galbraith提出了在安全Shell协议中使用X.509v3证书的早期建议；虽然本文件部分由先前的提案通知，但并未保持严格的兼容性。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
本文档定义了以下用于Secure Shell协议的新公钥算法：x509v3 ssh dss、x509v3 ssh rsa、x509v3-rsa2048-sha256，以及x509v3-ecdsa-sha2-*给出的算法系列。在这些算法中，公钥存储在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.
读者可参考[RFC5280]了解X.509版本3证书的一般说明。就本文档而言，只需知道，在X.509中，证书链或序列（可能长度为1）允许受信任的根证书颁发机构及其中间证书颁发机构使用公钥签名以加密方式将给定公钥绑定到给定的数字身份。
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.
对于本文件中规定的所有公钥算法，密钥格式包括一个或多个X.509v3证书序列，然后是[RFC2560]第4.2节中规定的0个或多个在线证书状态协议（OCSP）响应序列。直接在此数据结构中提供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]
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].
在上图中，字符串[identifier]是椭圆曲线域参数的标识符。[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.
必须使用抽象语法符号1（ASN.1）[ASN1]的可分辨编码规则（DER）编码将每个证书和ocsp响应编码为一个八进制字符串。附录A中给出了涉及这些公钥算法之一的SSH密钥交换示例。
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响应的机会，应仅使用与对等方支持的公钥算法相对应的签名算法对单个证书和OCSP响应进行签名，如SSH_MSG_KEXINIT数据包的server_host_key_algorithms字段所示（请参阅第7.1节）[RFC4253]）。但是，可以使用其他算法。任何给定证书或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
o 验证器必须准备好接收使用SSH_MSG_KEXINIT数据包的server_host_key_algorithms字段中未列出的算法的证书链和OCSP响应，包括可能没有安全外壳的算法
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 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]描述了用于椭圆曲线数字签名算法（ECDSA）公钥的X.509v3证书的结构。[RFC3279]和[RFC5280]描述了用于RSA和数字签名算法（DSA）公钥的X.509v3证书的结构。[RFC5759]为Suite 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证书在以下各节中指定的Secure Shell协议上下文中的使用。
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标识符：
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 如果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 如果ecmqv-sha2密钥交换方法的证书中存在KeyUsage扩展，则必须设置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节中关于密钥使用标识符和证书的现有约定。
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:
本文档定义了两个可用于限制证书使用的ExtendedKeyUsage密钥用途id：id kp secureShellClient（表示密钥可用于安全Shell客户端）和id kp secureShellServer（表示密钥可用于安全Shell服务器）。根据[RFC5280]第4.2.1.12节，如果存在ExtendedKeyUsage扩展，则证书必须仅用于指定用途之一。本文件中定义的两个关键用途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）国防部（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-*）进行签名和验证的方式与相应的基于非X.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].
根据数字签名标准[FIPS-186-3]，使用SHA-1散列[FIPS-180-2]，使用x509v3 ssh dss密钥格式进行签名和验证。
The resulting signature is encoded as follows:
生成的签名编码如下：
string "ssh-dss" string dss_signature_blob
字符串“ssh dss”字符串dss\u签名\u 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].
根据[RFC3447]中的RSASSA-PKCS1-v1_5方案，使用SHA-1散列[FIPS-180-2]执行使用x509v3 ssh rsa密钥格式的签名和验证。
The resulting signature is encoded as follows:
生成的签名编码如下：
string "ssh-rsa" string rsa_signature_blob
字符串“ssh rsa”字符串rsa\u签名\u 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的字符串（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.
根据[RFC3447]中的RSASSA-PKCS1-v1_5方案，使用x509v3-rsa2048-sha256密钥格式进行签名和验证，使用SHA-256哈希[FIPS-180-3]；使用此格式传输的RSA密钥的模数必须至少为2048位。
The resulting signature is encoded as follows:
生成的签名编码如下：
string "rsa2048-sha256" string rsa_signature_blob
字符串“rsa2048-sha256”字符串rsa\u签名\u 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的字符串（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位的RSA密钥或SHA-1哈希函数生成数字签名在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].
根据[FIPS-186-3]中的ecdsa算法，使用sha2哈希函数族[FIPS-180-3]执行使用x509v3-ecdsa-sha2-*密钥格式的签名和验证。根据[RFC5656]第6.2.1节中规定的ECDSA密钥的密钥大小，从SHA2哈希函数系列中选择哈希函数。
The resulting signature is encoded as follows:
生成的签名编码如下：
string "ecdsa-sha2-[identifier]" string ecdsa_signature_blob
字符串“ecdsa-sha2-[identifier]”字符串ecdsa\u签名\u 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].
字符串[identifier]是椭圆曲线域参数的标识符。[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:
本文件中定义的公钥算法和编码应在使用公钥的Secure Shell协议套件中的任何地方接受，包括但不限于以下用于服务器身份验证和用户身份验证的协议消息：
o in the SSH_MSG_USERAUTH_REQUEST message when "publickey" authentication is used [RFC4252]
o 使用“公钥”身份验证时，在SSH_MSG_USERAUTH_请求消息中[RFC4252]
o in the SSH_MSG_USERAUTH_REQUEST message when "hostbased" authentication is used [RFC4252]
o 使用“基于主机”身份验证时，在SSH_MSG_USERAUTH_请求消息中[RFC4252]
o in the SSH_MSG_KEXDH_REPLY message [RFC4253]
o 在SSH_MSG_KEXDH_回复消息[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_回复消息[RFC5656]中
o in the SSH_MSG_KEX_ECMQV_REPLY message [RFC5656]
o 在SSH_MSG_KEX_ECMQV_回复消息[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节所述的subjectAlternativeName X.509v3扩展名应用于传送服务器主机名，使用dNSName条目或iPAddress条目传送域名或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.
o 如果客户端的参考标识符（例如，客户端键入的主机名）是DNS域名，则应使用[RFC6125]中指定的规则检查服务器的标识。建议在客户端和服务器软件实现中支持DNS-ID标识符类型。颁发证书供安全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类型的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.
读者可参考[RFC5280]中关于使用X.509v3证书的安全注意事项部分，参考[RFC2560]中关于使用OCSP响应的安全注意事项部分，参考[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证书，则此尝试以及尝试的日期、时间、证书标识和明显的原始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符号（“@”）。
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节中使用的两个对象标识符由IANA委托给PKIX工作组的arc分配。
[ASN1] International Telecommunications Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", X.680, July 2002.
[ASN1]国际电信联盟，“抽象语法符号一（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]国家标准与技术研究所，“安全哈希标准”，FIPS 180-22002年8月。
[FIPS-180-3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-3, October 2008.
[FIPS-180-3]国家标准与技术研究所，“安全哈希标准”，FIPS 180-32008年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 7911981年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，“互联网协议，第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互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年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，“公钥密码标准（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，“安全外壳（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]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年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，“椭圆曲线加密主题公钥信息”，RFC 54802009年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 56562009年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，“互联网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）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年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]高效密码标准组，“椭圆曲线密码术”，第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.，“安全外壳（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，“安全壳（SSH）协议的通用安全服务应用程序接口（GSS-API）认证和密钥交换”，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.Zieglar，“套件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特别出版物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
字节SSH_MSG_KEXDH_回复字符串0x00 0x00 0xXX 0xXX--此字符串中剩余数据的长度0x00 0x00 0x00 0x0D--字符串“x509v3 SSH dss”“x509v3 SSH dss”的长度0x00 0x00 0x00 0x02--有2个证书0x00 0x00 0xXX 0xXX--发送方证书DER编码的发送方证书长度0x00 0x00 0xXX 0xXX--颁发方证书DER编码的颁发方证书长度0x00 0x00 0x01--有1个OCSP响应0x00 0x00 0xXX 0xXX--OCSP响应DER编码的OCSP响应长度mpint fH的字符串签名
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
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
EMail: douglas@stebila.ca