Network Working Group N. Mavrogiannopoulos
Request for Comments: 5081 Independent
Category: Experimental November 2007
Network Working Group N. Mavrogiannopoulos
Request for Comments: 5081 Independent
Category: Experimental November 2007
Using OpenPGP Keys for Transport Layer Security (TLS) Authentication
使用OpenPGP密钥进行传输层安全（TLS）身份验证
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol.
本备忘录建议对传输层安全（TLS）协议进行扩展，以支持OpenPGP密钥格式。这里讨论的扩展包括证书类型协商机制，以及对TLS握手协议所需的修改。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Changes to the Handshake Message Contents .......................2
3.1. Client Hello ...............................................2
3.2. Server Hello ...............................................3
3.3. Server Certificate .........................................3
3.4. Certificate Request ........................................4
3.5. Client Certificate .........................................5
3.6. Other Handshake Messages ...................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................6
6. Acknowledgements ................................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................7
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Changes to the Handshake Message Contents .......................2
3.1. Client Hello ...............................................2
3.2. Server Hello ...............................................3
3.3. Server Certificate .........................................3
3.4. Certificate Request ........................................4
3.5. Client Certificate .........................................5
3.6. Other Handshake Messages ...................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................6
6. Acknowledgements ................................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................7
The IETF has two sets of standards for public key certificates, one set for use of X.509 certificates [PKIX] and one for OpenPGP certificates [OpenPGP]. At the time of writing, TLS [TLS] standards are defined to use only X.509 certificates. This document specifies a way to negotiate use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. The proposed extensions are backward compatible with the current TLS specification, so that existing client and server implementations that make use of X.509 certificates are not affected.
IETF有两套公钥证书标准，一套用于使用X.509证书[PKIX]，另一套用于OpenPGP证书[OpenPGP]。在撰写本文时，TLS[TLS]标准定义为仅使用X.509证书。本文档指定了为TLS会话协商使用OpenPGP证书的方法，并指定了如何通过TLS传输OpenPGP证书。建议的扩展与当前的TLS规范向后兼容，因此使用X.509证书的现有客户端和服务器实现不会受到影响。
The term "OpenPGP key" is used in this document as in the OpenPGP specification [OpenPGP]. We use the term "OpenPGP certificate" to refer to OpenPGP keys that are enabled for authentication.
本文件中使用的术语“OpenPGP密钥”与OpenPGP规范[OpenPGP]中的术语相同。我们使用术语“OpenPGP证书”来指代启用身份验证的OpenPGP密钥。
This document uses the same notation and terminology used in the TLS Protocol specification [TLS].
本文件使用TLS协议规范[TLS]中使用的相同符号和术语。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section describes the changes to the TLS handshake message contents when OpenPGP certificates are to be used for authentication.
本节描述在使用OpenPGP证书进行身份验证时对TLS握手消息内容的更改。
In order to indicate the support of multiple certificate types, clients MUST include an extension of type "cert_type" (see Section 5) to the extended client hello message. The hello extension mechanism is described in [TLSEXT].
为了表明支持多种证书类型，客户端必须在扩展客户端hello消息中包含“cert_type”类型的扩展（参见第5节）。hello扩展机制在[TLSEXT]中有描述。
This extension carries a list of supported certificate types the client can use, sorted by client preference. This extension MUST be omitted if the client only supports X.509 certificates. The "extension_data" field of this extension contains a CertificateTypeExtension structure.
此扩展包含客户端可以使用的受支持证书类型列表，按客户端首选项排序。如果客户端仅支持X.509证书，则必须省略此扩展。此扩展的“extension_data”字段包含CertificateTypeExtension结构。
enum { client, server } ClientOrServerExtension;
enum { client, server } ClientOrServerExtension;
enum { X.509(0), OpenPGP(1), (255) } CertificateType;
enum { X.509(0), OpenPGP(1), (255) } CertificateType;
struct {
select(ClientOrServerExtension) {
case client:
CertificateType certificate_types<1..2^8-1>;
case server:
CertificateType certificate_type;
}
} CertificateTypeExtension;
struct {
select(ClientOrServerExtension) {
case client:
CertificateType certificate_types<1..2^8-1>;
case server:
CertificateType certificate_type;
}
} CertificateTypeExtension;
No new cipher suites are required to use OpenPGP certificates. All existing cipher suites that support a compatible, with the key, key exchange method can be used in combination with OpenPGP certificates.
使用OpenPGP证书不需要新的密码套件。所有支持兼容的密钥交换方法的现有密码套件都可以与OpenPGP证书结合使用。
If the server receives a client hello that contains the "cert_type" extension and chooses a cipher suite that requires a certificate, then two outcomes are possible. The server MUST either select a certificate type from the certificate_types field in the extended client hello or terminate the connection with a fatal alert of type "unsupported_certificate".
如果服务器接收到一个包含“cert_type”扩展名的客户机hello，并选择了一个需要证书的密码套件，则可能出现两种结果。服务器必须从扩展客户端hello中的certificate_types字段中选择证书类型，或者使用类型为“unsupported_certificate”的致命警报终止连接。
The certificate type selected by the server is encoded in a CertificateTypeExtension structure, which is included in the extended server hello message using an extension of type "cert_type". Servers that only support X.509 certificates MAY omit including the "cert_type" extension in the extended server hello.
服务器选择的证书类型编码在CertificateTypeExtension结构中，该结构使用类型为“cert_type”的扩展包含在扩展服务器hello消息中。仅支持X.509证书的服务器可能会忽略在扩展服务器hello中包含“cert_type”扩展。
The contents of the certificate message sent from server to client and vice versa are determined by the negotiated certificate type and the selected cipher suite's key exchange algorithm.
从服务器发送到客户端（反之亦然）的证书消息的内容由协商的证书类型和所选密码套件的密钥交换算法决定。
If the OpenPGP certificate type is negotiated, then it is required to present an OpenPGP certificate in the certificate message. The certificate must contain a public key that matches the selected key exchange algorithm, as shown below.
如果协商了OpenPGP证书类型，则需要在证书消息中提供OpenPGP证书。证书必须包含与所选密钥交换算法匹配的公钥，如下所示。
Key Exchange Algorithm OpenPGP Certificate Type
密钥交换算法OpenPGP证书类型
RSA RSA public key that can be used for encryption.
可用于加密的RSA公钥。
DHE_DSS DSS public key that can be used for authentication.
可用于身份验证的DHE_DSS DSS公钥。
DHE_RSA RSA public key that can be used for authentication.
可用于身份验证的DHE_RSA公钥。
An OpenPGP certificate appearing in the certificate message is sent using the binary OpenPGP format. The certificate MUST contain all the elements required by Section 11.1 of [OpenPGP].
证书消息中出现的OpenPGP证书使用二进制OpenPGP格式发送。证书必须包含[OpenPGP]第11.1节要求的所有元素。
The option is also available to send an OpenPGP fingerprint, instead of sending the entire certificate. The process of fingerprint generation is described in Section 12.2 of [OpenPGP]. The peer shall respond with a "certificate_unobtainable" fatal alert if the certificate with the given fingerprint cannot be found. The "certificate_unobtainable" fatal alert is defined in Section 4 of [TLSEXT].
该选项还可用于发送OpenPGP指纹，而不是发送整个证书。[OpenPGP]第12.2节描述了指纹生成过程。如果找不到具有给定指纹的证书，对等方应发出“证书不可获得”致命警报。[TLSEXT]第4节定义了“无法获得证书”致命警报。
enum {
cert_fingerprint (0), cert (1), (255)
} OpenPGPCertDescriptorType;
enum {
cert_fingerprint (0), cert (1), (255)
} OpenPGPCertDescriptorType;
opaque OpenPGPCertFingerprint<16..20>;
opaque OpenPGPCertFingerprint<16..20>;
opaque OpenPGPCert<0..2^24-1>;
opaque OpenPGPCert<0..2^24-1>;
struct {
OpenPGPCertDescriptorType descriptorType;
select (descriptorType) {
case cert_fingerprint: OpenPGPCertFingerprint;
case cert: OpenPGPCert;
}
} Certificate;
struct {
OpenPGPCertDescriptorType descriptorType;
select (descriptorType) {
case cert_fingerprint: OpenPGPCertFingerprint;
case cert: OpenPGPCert;
}
} Certificate;
The semantics of this message remain the same as in the TLS specification. However, if this message is sent, and the negotiated certificate type is OpenPGP, the "certificate_authorities" list MUST be empty.
此消息的语义与TLS规范中的相同。但是，如果发送此消息，并且协商的证书类型为OpenPGP，“证书颁发机构”列表必须为空。
This message is only sent in response to the certificate request message. The client certificate message is sent using the same formatting as the server certificate message, and it is also required to present a certificate that matches the negotiated certificate type. If OpenPGP certificates have been selected and no certificate is available from the client, then a certificate structure that contains an empty OpenPGPCert vector MUST be sent. The server SHOULD respond with a "handshake_failure" fatal alert if client authentication is required.
此消息仅在响应证书请求消息时发送。客户端证书消息使用与服务器证书消息相同的格式发送，并且还需要提供与协商的证书类型匹配的证书。如果已选择OpenPGP证书，但客户端没有可用的证书，则必须发送包含空OpenPGPCert向量的证书结构。如果需要客户端身份验证，服务器应发出“握手失败”致命警报。
All the other handshake messages are identical to the TLS specification.
所有其他握手消息都与TLS规范相同。
All security considerations discussed in [TLS], [TLSEXT], and [OpenPGP] apply to this document. Considerations about the use of the web of trust or identity and certificate verification procedure are outside the scope of this document. These are considered issues to be handled by the application layer protocols.
[TLS]、[TLSEXT]和[OpenPGP]中讨论的所有安全注意事项均适用于本文档。关于使用信任网或身份和证书验证程序的考虑不在本文件范围内。这些被认为是应用层协议要处理的问题。
The protocol for certificate type negotiation is identical in operation to ciphersuite negotiation of the [TLS] specification with the addition of default values when the extension is omitted. Since those omissions have a unique meaning and the same protection is applied to the values as with ciphersuites, it is believed that the security properties of this negotiation are the same as with ciphersuite negotiation.
证书类型协商的协议在操作上与[TLS]规范的ciphersuite协商相同，只是在省略扩展时添加了默认值。由于这些遗漏具有独特的含义，并且与ciphersuite协商的价值受到相同的保护，因此认为本次协商的安全属性与ciphersuite协商的安全属性相同。
When using OpenPGP fingerprints instead of the full certificates, the discussion in Section 6.3 of [TLSEXT] for "Client Certificate URLs" applies, especially when external servers are used to retrieve keys. However, a major difference is that although the "client_certificate_url" extension allows identifying certificates without including the certificate hashes, this is not possible in the protocol proposed here. In this protocol, the certificates, when not sent, are always identified by their fingerprint, which serves as a cryptographic hash of the certificate (see Section 12.2 of [OpenPGP]).
当使用OpenPGP指纹而不是完整证书时，[TLSEXT]第6.3节中关于“客户端证书URL”的讨论适用，特别是当使用外部服务器检索密钥时。然而，一个主要的区别是，尽管“client_certificate_url”扩展允许在不包含证书哈希的情况下识别证书，但在本文提出的协议中这是不可能的。在该协议中，未发送的证书始终由其指纹标识，指纹用作证书的加密散列（见[OpenPGP]第12.2节）。
The information that is available to participating parties and eavesdroppers (when confidentiality is not available through a previous handshake) is the number and the types of certificates they hold, plus the contents of certificates.
参与方和窃听者可获得的信息（当通过先前的握手无法获得机密性时）是他们持有的证书的数量和类型，以及证书的内容。
This document defines a new TLS extension, "cert_type", assigned a value of 9 from the TLS ExtensionType registry defined in [TLSEXT]. This value is used as the extension number for the extensions in both the client hello message and the server hello message. The new extension type is used for certificate type negotiation.
本文档定义了一个新的TLS扩展名“cert_type”，该扩展名从[TLSEXT]中定义的TLS ExtensionType注册表中分配了一个值9。此值用作客户端hello消息和服务器hello消息中扩展的扩展编号。新的扩展类型用于证书类型协商。
The "cert_type" extension contains an 8-bit CertificateType field, for which a new registry, named "TLS Certificate Types", is established in this document, to be maintained by IANA. The registry is segmented in the following way:
“cert_type”扩展包含一个8位CertificateType字段，在此文档中为该字段建立了一个名为“TLS Certificate Types”的新注册表，由IANA维护。注册表按以下方式分段：
1. Values 0 (X.509) and 1 (OpenPGP) are defined in this document.
1. 本文档中定义了值0（X.509）和1（OpenPGP）。
2. Values from 2 through 223 decimal inclusive are assigned via IETF Consensus [RFC2434].
2. 通过IETF共识[RFC2434]分配从2到223（含）十进制的值。
3. Values from 224 decimal through 255 decimal inclusive are reserved for Private Use [RFC2434].
3. 从224位小数到255位小数（含）的值保留供私人使用[RFC2434]。
This document was based on earlier work made by Will Price and Michael Elkins.
本文件基于Will Price和Michael Elkins的早期工作。
The author wishes to thank Werner Koch, David Taylor, Timo Schulz, Pasi Eronen, Jon Callas, Stephen Kent, Robert Sparks, and Hilarie Orman for their suggestions on improving this document.
作者希望感谢沃纳·科赫、大卫·泰勒、蒂莫·舒尔茨、帕西·埃隆、乔恩·卡拉斯、斯蒂芬·肯特、罗伯特·斯帕克斯和希拉里·奥曼对改进本文件提出的建议。
[TLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, April 2006.
[TLS]Dierks，T.和E.Rescorla，“TLS协议版本1.1”，RFC 4346，2006年4月。
[OpenPGP] Callas, J., Donnerhacke, L., Finey, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[OpenPGP]Callas，J.，Donnerhacke，L.，Finey，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 48802007年11月。
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[TLSEXT]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，RFC 2434，1998年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[PKIX] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIX]Housley，R.，Ford，W.，Polk，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
Author's Address
作者地址
Nikos Mavrogiannopoulos Independent Arkadias 8 Halandri, Attiki 15234 Greece
Nikos Mavrogiannopoulos Independent Arkadias 8 Halandri，希腊阿提基15234
EMail: nmav@gnutls.org
URI: http://www.gnutls.org/
EMail: nmav@gnutls.org
URI: http://www.gnutls.org/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.