Internet Engineering Task Force (IETF) P. Hallam-Baker
Request for Comments: 7633 Comodo Group Inc.
Category: Standards Track October 2015
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Hallam-Baker
Request for Comments: 7633 Comodo Group Inc.
Category: Standards Track October 2015
ISSN: 2070-1721
X.509v3 Transport Layer Security (TLS) Feature Extension
X.509v3传输层安全（TLS）功能扩展
Abstract
摘要
The purpose of the TLS feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol. In particular, the TLS feature extension may be used to mandate support for revocation checking features in the TLS protocol such as Online Certificate Status Protocol (OCSP) stapling. Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled. This in turn prevents a denial-of-service attack that might otherwise be possible.
TLS功能扩展的目的是防止TLS协议无法防止的降级攻击。具体地，TLS特性扩展可用于强制支持TLS协议中的撤销检查特性，例如在线证书状态协议（OCSP）装订。通知客户端OCSP状态响应将始终被钉住，允许在响应未被钉住的情况下立即失败。这反过来又可以防止可能发生的拒绝服务攻击。
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/rfc7633.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7633.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2.2. TLS Feature, X.509 Extension . . . . . . . . . . . . . . 3
3. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. TLS Feature . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Certificate Signing Request . . . . . . . . . . . . . 5
4.2.2. Certificate Signing Certificate . . . . . . . . . . . 5
4.2.3. End-Entity Certificate . . . . . . . . . . . . . . . 5
4.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 6
4.3.1. Certification Authority . . . . . . . . . . . . . . . 6
4.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5.1. Alternative Certificates and Certificate Issuers . . . . 7
5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 8
5.3. Cipher Suite Downgrade Attack . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 9
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2.2. TLS Feature, X.509 Extension . . . . . . . . . . . . . . 3
3. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. TLS Feature . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Certificate Signing Request . . . . . . . . . . . . . 5
4.2.2. Certificate Signing Certificate . . . . . . . . . . . 5
4.2.3. End-Entity Certificate . . . . . . . . . . . . . . . 5
4.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 6
4.3.1. Certification Authority . . . . . . . . . . . . . . . 6
4.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5.1. Alternative Certificates and Certificate Issuers . . . . 7
5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 8
5.3. Cipher Suite Downgrade Attack . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 9
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
The Transport Layer Security (TLS) feature extension provides a means of preventing downgrade attacks that are not otherwise prevented by the TLS protocol.
传输层安全（TLS）功能扩展提供了一种防止降级攻击的方法，而这些降级攻击是TLS协议无法阻止的。
Since the TLS protocol itself provides strong protection against most forms of downgrade attack including downgrade attacks against cipher suite choices offered and client credentials, the TLS feature extension is only relevant to the validation of TLS protocol credentials.
由于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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In order to avoid the confusion that would occur in attempting to specify an X.509 extension describing the use of TLS extensions, in this document the term "extension" is reserved to refer to X.509v3 extensions and the term "TLS feature extension" is used to refer to what the TLS specification [RFC5246] refers to as an "extension".
为了避免在试图指定描述TLS扩展使用的X.509扩展时出现混淆，在本文件中，术语“扩展”保留为指X.509v3扩展，术语“TLS功能扩展”用于指TLS规范[RFC5246]所指的“扩展”。
Currently, the only TLS feature extensions that are relevant to the revocation status of credentials are the Certificate Status Request extension (status_request) and the Multiple Certificate Status Extension (status_request_v2). These extensions are used to support in-band exchange of Online Certificate Status Protocol (OCSP) tokens, otherwise known as OCSP stapling. These extensions are described in [RFC6066] and [RFC6961].
目前，与凭据的吊销状态相关的TLS功能扩展只有证书状态请求扩展（status_Request）和多证书状态扩展（status_Request_v2）。这些扩展用于支持在线证书状态协议（OCSP）令牌的带内交换，也称为OCSP绑定。[RFC6066]和[RFC6961]中描述了这些扩展。
The OCSP stapling mechanism described in [RFC6066] permits a TLS server to provide evidence of valid certificate status in-band. When this information is provided in-band, the privacy, performance, and reliability concerns arising from the need to make a third-party connection during the TLS handshake are eliminated. However, a client cannot draw any conclusion from the absence of in-band status information unless it knows that the legitimate server would have provided it. The status information might have been omitted because the server does not support the extension or because the server is withholding the information intentionally, knowing the certificate to be invalid.
[RFC6066]中描述的OCSP装订机制允许TLS服务器提供带内有效证书状态的证据。当该信息在频带内提供时，由于TLS握手期间需要建立第三方连接而引起的隐私、性能和可靠性问题将被消除。但是，客户机无法从缺少带内状态信息中得出任何结论，除非它知道合法服务器会提供该信息。状态信息可能已被忽略，因为服务器不支持扩展，或者因为服务器在知道证书无效的情况下故意保留信息。
The inclusion of a TLS feature extension advertising the status_request feature in the server end-entity certificate permits a client to fail immediately if the certificate status information is not provided by the server. The need to query the OCSP responder is eliminated entirely. This improves client efficiency and, more importantly, prevents a denial-of-service attack against the client by either blocking the OCSP response or mounting a denial-of-service attack against the OCSP responder.
如果服务器未提供证书状态信息，则在服务器端实体证书中包含一个TLS功能扩展来宣传状态请求功能，从而允许客户端立即失败。完全不需要查询OCSP响应程序。这提高了客户端效率，更重要的是，通过阻止OCSP响应或对OCSP响应程序发起拒绝服务攻击，防止针对客户端的拒绝服务攻击。
Since the TLS feature extension is an option, it is not likely that an attacker attempting to obtain a certificate through fraud will choose to have a certificate issued with this extension. Such risks are more appropriately addressed by mechanisms such as Certification Authority Authorization DNS records [RFC6844] that are designed to prevent or mitigate mis-issue.
Since the TLS feature extension is an option, it is not likely that an attacker attempting to obtain a certificate through fraud will choose to have a certificate issued with this extension. Such risks are more appropriately addressed by mechanisms such as Certification Authority Authorization DNS records [RFC6844] that are designed to prevent or mitigate mis-issue.translate error, please retry
A server offering an end-entity certificate with a TLS feature extension MUST satisfy a client request for the specified feature unless this would be redundant as described below. Clients MAY refuse to accept the connection if the server does not accept a request for a specified feature.
提供具有TLS功能扩展的终端实体证书的服务器必须满足客户端对指定功能的请求，除非这是冗余的，如下所述。如果服务器不接受对指定功能的请求，客户端可能会拒绝接受连接。
A Certification Authority SHOULD NOT issue certificates that specify a TLS feature extension advertising features that the server does not support.
证书颁发机构不应颁发指定服务器不支持的TLS功能扩展广告功能的证书。
A server MAY advise a Certification Authority that it is capable of supporting a feature by including the corresponding TLS feature extension in a Certificate Signing Request [RFC2986]. A server SHOULD verify that its configuration supports the features advertised in the credentials presented to a client requesting connection.
服务器可以通过在证书签名请求中包含相应的TLS功能扩展来通知证书颁发机构它能够支持功能[RFC2986]。服务器应验证其配置是否支持向请求连接的客户端提供的凭据中公布的功能。
This document describes the use of the TLS feature in PKIX end-entity certificates and Certificate Signing Certificates. A mechanism that MAY be used to describe support for the specified features in-band for the most commonly used certificate registration protocol is also provided.
本文档介绍了TLS功能在PKIX终端实体证书和证书签名证书中的使用。还提供了一种机制，该机制可用于描述对最常用的证书注册协议的带内指定特征的支持。
See Appendix A for an ASN.1 module
ASN.1模块见附录A
The TLS feature extension has the following format:
TLS功能扩展具有以下格式：
id-pe-tlsfeature OBJECT IDENTIFIER ::= { id-pe 24 }
id-pe-tlsfeature OBJECT IDENTIFIER ::= { id-pe 24 }
Features ::= SEQUENCE OF INTEGER
Features ::= SEQUENCE OF INTEGER
The extnValue of the id-pe-tlsfeature extension is the ASN.1 DER encoding of the Features structure.
id pe tlsfeature扩展的extnValue是Features结构的ASN.1顺序编码。
The TLS feature extension SHOULD NOT be marked critical. RFC 5280 [RFC5280] requires that implementations that do not understand critical extensions MUST reject the certificate. Marking the TLS feature extension critical breaks backward compatibility and is not recommended unless this is the desired behavior.
TLS功能扩展不应标记为关键。RFC 5280[RFC5280]要求不理解关键扩展的实现必须拒绝证书。将TLS功能扩展标记为“关键”会破坏向后兼容性，除非这是所需的行为，否则不建议这样做。
The object member "Features" is a sequence of TLS extension identifiers (features, in this specification's terminology) as specified in the IANA Transport Layer Security (TLS) Extensions
对象成员“特性”是IANA传输层安全（TLS）扩展中指定的一系列TLS扩展标识符（本规范术语中的特性）
registry. If these features are requested by the client in its ClientHello message, then the server MUST return a ServerHello message that satisfies this request.
登记处。如果客户机在其ClientHello消息中请求了这些功能，则服务器必须返回满足此请求的ServerHello消息。
This specification does not require a TLS client to offer or support any TLS feature regardless of whether or not it is specified in the server certificate's TLS feature extension. In particular, a client MAY request and a server MAY support any TLS extension regardless of whether or not it is specified in a TLS feature extension.
本规范不要求TLS客户端提供或支持任何TLS功能，无论是否在服务器证书的TLS功能扩展中指定。特别是，客户机可以请求任何TLS扩展，而服务器可以支持任何TLS扩展，无论它是否在TLS功能扩展中指定。
A server that offers a certificate that contains a TLS feature extension MUST support the features specified and comply with the corresponding requirements.
提供包含TLS功能扩展的证书的服务器必须支持指定的功能并符合相应的要求。
If the certificate issue mechanism makes use of the PKCS #10 Certificate Signing Request (CSR) [RFC2986], the CSR MAY specify a TLS feature extension as a CSR Attribute as defined in Section 4.1 of [RFC2986]. A server or server administration tool should only generate key signing requests that it knows can be supported by the server for which the certificate is intended.
如果证书颁发机制使用PKCS#10证书签名请求（CSR）[RFC2986]，CSR可将TLS功能扩展指定为[RFC2986]第4.1节中定义的CSR属性。服务器或服务器管理工具应该只生成它知道证书所针对的服务器可以支持的密钥签名请求。
When present in a Certificate Signing Certificate (i.e., Certification Authority certificate with the key usage extension value set to keyCertSign), the TLS feature extension specifies a constraint on valid certificate chains. Specifically, a certificate that is signed by a Certificate Signing Certificate that contains a TLS feature extension MUST contain a TLS feature extension that offers the same set or a superset of the features advertised in the signing certificate.
当存在于证书签名证书（即密钥使用扩展值设置为keyCertSign的证书颁发机构证书）中时，TLS功能扩展指定对有效证书链的约束。具体而言，由包含TLS功能扩展的证书签名证书签名的证书必须包含提供签名证书中公布的相同功能集或超集的TLS功能扩展。
This behavior provides a means of requiring support for a particular set of features for certificates issued under a particular Certificate Signing Certificate without requiring TLS clients to verify compliance with TLS feature extensions in multiple certificates.
此行为提供了一种方法，要求支持在特定证书签名证书下颁发的证书的特定功能集，而无需TLS客户端验证多个证书中是否符合TLS功能扩展。
When specified in a server end-entity certificate (i.e., a certificate that specifies the id-kp-serverAuth Extended Key Usage (EKU)), the TLS feature extension specifies criteria that a server MUST meet to be compliant with the feature declaration.
当在服务器端实体证书（即，指定id kp serverAuth扩展密钥用法（EKU）的证书）中指定时，TLS功能扩展将指定服务器必须满足的标准，以符合功能声明。
In the case that a client determines that the server configuration is inconsistent with the specified feature declaration, it MAY reject the TLS configuration.
如果客户机确定服务器配置与指定的功能声明不一致，则可能会拒绝TLS配置。
In the case that a client determines that the server configuration is inconsistent with a feature declaration specifying support for the TLS status_request extension, it SHOULD reject the TLS configuration.
如果客户机确定服务器配置与指定支持TLS status_请求扩展的功能声明不一致，则应拒绝TLS配置。
A client MAY accept a TLS configuration despite it being inconsistent with the TLS feature declaration if the validity of the certificate chain presented can be established through other means (for example, by successfully obtaining the OCSP data from another source).
如果可以通过其他方式（例如，通过从另一个源成功获取OCSP数据）确定所提供证书链的有效性，则客户机可以接受TLS配置，尽管该配置与TLS功能声明不一致。
There are certain situations in which the alternative to establishing a connection with imperfect TLS security is to transmit the same information with no security controls whatsoever. Accordingly, a client MAY accept a TLS configuration despite it being inconsistent with the TLS feature declaration but MUST NOT distinguish that connection as secure.
在某些情况下，建立具有不完善TLS安全性的连接的替代方案是在没有任何安全控制的情况下传输相同的信息。因此，客户机可以接受TLS配置，尽管它与TLS功能声明不一致，但不能将该连接区分为安全连接。
Advertising a TLS feature extension may change the expectations of relying parties. If these expectations are not met, a valid certificate may be rejected as invalid. Particular attention is required at the start of a certificate lifecycle. A server will be unable to comply with a TLS feature extension if the certificate is issued and released to the subject before the corresponding status token is published.
宣传TLS功能扩展可能会改变依赖方的期望。如果未满足这些期望，有效证书可能会被视为无效而拒绝。在证书生命周期开始时需要特别注意。如果在发布相应的状态令牌之前向主体颁发并释放证书，则服务器将无法遵守TLS功能扩展。
A Certification Authority SHOULD NOT issue certificates with a TLS feature extension unless there is an affirmative statement to the effect that the end entity intends to support the specified features (for example, the use of a feature extension in the CSR or through an out-of-band communication).
认证机构不应颁发具有TLS功能扩展的证书，除非有肯定声明表明最终实体打算支持指定功能（例如，在CSR中使用功能扩展或通过带外通信）。
A Certification Authority SHOULD ensure that the certificate provisioning process for certificates containing a TLS feature extension permits the certificate subject to meet the requirements (for example, ensuring that OCSP tokens are published before the corresponding certificate is released to the subscriber).
证书颁发机构应确保包含TLS功能扩展的证书的证书设置过程允许证书主体满足要求（例如，确保在向订阅方发布相应证书之前发布OCSP令牌）。
A TLS server certificate containing a TLS feature extension MAY be used with any TLS server that supports the specified features. It is not necessary for the server to provide support for the TLS feature extension itself. Such support is nevertheless desirable as it can reduce the risk of administrative error.
包含TLS功能扩展的TLS服务器证书可用于支持指定功能的任何TLS服务器。服务器无需为TLS功能扩展本身提供支持。然而，这种支持是可取的，因为它可以减少行政失误的风险。
A server SHOULD verify that its configuration is compatible with the TLS feature extension expressed in a certificate it presents. When an existing certificate is to be replaced by a new one, the server SHOULD NOT begin using the new certificate until the necessary OCSP status token or tokens are available.
服务器应验证其配置是否与它提供的证书中表示的TLS功能扩展兼容。将现有证书替换为新证书时，服务器不应开始使用新证书，直到必要的OCSP状态令牌可用。
A server MAY override local configuration options if necessary to ensure consistency, but it SHOULD inform the administrator whenever such an inconsistency is discovered.
如有必要，服务器可以覆盖本地配置选项以确保一致性，但一旦发现此类不一致，服务器应通知管理员。
A server SHOULD support generation of the feature extension in CSRs if key generation is supported.
若支持密钥生成，服务器应该支持在CSR中生成特性扩展。
A client MUST treat a certificate with a TLS feature extension as an invalid certificate if the features offered by the server do not contain all features present in both the client's ClientHello message and the TLS feature extension.
如果服务器提供的功能不包含客户端ClientHello消息和TLS功能扩展中存在的所有功能，则客户端必须将具有TLS功能扩展的证书视为无效证书。
In the case that use of TLS with a valid certificate is mandated by explicit security policy, application protocol specification, or other means, the client MUST refuse the connection. If the use of TLS with a valid certificate is optional, a client MAY accept the connection but MUST NOT treat the certificate as valid.
如果明确的安全策略、应用程序协议规范或其他方式强制使用具有有效证书的TLS，则客户端必须拒绝连接。如果TLS与有效证书一起使用是可选的，则客户端可以接受连接，但不能将证书视为有效。
Use of the TLS feature extension to mandate support for a particular form of revocation checking is optional. This control can provide protection in the case that a certificate with a TLS feature is compromised after issue but not in the case that the attacker obtains an unmarked certificate from an issuer through fraud.
使用TLS功能扩展强制支持特定形式的撤销检查是可选的。此控件可在具有TLS功能的证书在颁发后受到损害的情况下提供保护，但在攻击者通过欺诈从颁发者处获得未标记证书的情况下则不提供保护。
The TLS feature extension is a post-issue security control. Such risks can only be addressed by security controls that take effect before issue.
TLS功能扩展是发布后安全控制。此类风险只能通过在发布前生效的安全控制措施来解决。
A certificate issuer could issue a certificate that intentionally specified a feature statement that they knew the server could not support.
证书颁发者可以颁发一个证书，该证书故意指定了他们知道服务器无法支持的功能语句。
The consequences of such refusal would appear to be limited since a Certification Authority could equally refuse to issue the certificate.
这种拒绝的后果似乎是有限的，因为证书颁发机构同样可以拒绝颁发证书。
The TLS feature extension does not provide protection against a cipher suite downgrade attack. This is left to the existing controls in the TLS protocol itself.
TLS功能扩展不提供针对密码套件降级攻击的保护。这由TLS协议本身中的现有控件决定。
IANA has added the following entry in the "SMI Security for PKIX Certificate Extension" (1.3.6.1.5.5.7.1) registry:
IANA在“SMI Security for PKIX证书扩展”（1.3.6.1.5.5.7.1）注册表中添加了以下条目：
Decimal Description References
------- ------------------------------ ---------------------
Decimal Description References
------- ------------------------------ ---------------------
24 id-pe-tlsfeature this document (RFC 7633)
24 id pe TLS特征本文件（RFC 7633）
IANA has added the following entry in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry:
IANA在“PKIX模块标识符的SMI安全性”（1.3.6.1.5.5.7.0）注册表中添加了以下条目：
Decimal Description References
------- ------------------------------ ---------------------
Decimal Description References
------- ------------------------------ ---------------------
86 id-mod-tls-feature-2015 this document (RFC 7633)
86 id-mod-tls-feature-2015本文件（RFC 7633）
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <http://www.rfc-editor.org/info/rfc2986>.
[RFC2986]Nystrom，M.和B.Kaliski，“PKCS#10：认证请求语法规范版本1.7”，RFC 2986，DOI 10.17487/RFC2986，2000年11月<http://www.rfc-editor.org/info/rfc2986>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[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, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<http://www.rfc-editor.org/info/rfc6066>.
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 6844, DOI 10.17487/RFC6844, January 2013, <http://www.rfc-editor.org/info/rfc6844>.
[RFC6844]Hallam Baker，P.和R.Stradling，“DNS认证机构授权（CAA）资源记录”，RFC 6844，DOI 10.17487/RFC6844，2013年1月<http://www.rfc-editor.org/info/rfc6844>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, <http://www.rfc-editor.org/info/rfc6961>.
[RFC6961]Pettersen，Y，“传输层安全性（TLS）多证书状态请求扩展”，RFC 6961，DOI 10.17487/RFC69611913年6月<http://www.rfc-editor.org/info/rfc6961>.
TLS-Feature-Module-2015 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-tls-feature-2015(86)}
TLS-Feature-Module-2015 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-tls-feature-2015(86)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS -- From RFC 5912
进口——来自RFC 5912
id-pe
FROM PKIX1Explicit-2009 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51)}
id-pe
FROM PKIX1Explicit-2009 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51)}
EXTENSION
FROM PKIX-CommonTypes-2009 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57)}
;
EXTENSION
FROM PKIX-CommonTypes-2009 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57)}
;
CertExtensions EXTENSION ::= {
ext-TLSFeatures, ... }
CertExtensions EXTENSION ::= {
ext-TLSFeatures, ... }
-- TLS Features Extension
--TLS功能扩展
ext-TLSFeatures EXTENSION ::= { SYNTAX
Features IDENTIFIED BY id-pe-tlsfeature }
ext-TLSFeatures EXTENSION ::= { SYNTAX
Features IDENTIFIED BY id-pe-tlsfeature }
id-pe-tlsfeature OBJECT IDENTIFIER ::= { id-pe 24 }
id-pe-tlsfeature OBJECT IDENTIFIER ::= { id-pe 24 }
Features ::= SEQUENCE OF INTEGER
Features ::= SEQUENCE OF INTEGER
END
终止
Acknowledgements
致谢
This proposal incorporates text and other contributions from participants in the IETF and CA-Browser forum -- in particular, Robin Alden, Richard Barnes, Viktor Dukhovni, Stephen Farrell, Gervase Markham, Yoav Nir, Tom Ritter, Jeremy Rowley, Stefan Santesson, Ryan Sleevi, Brian Smith, Rob Stradling, and Sean Turner.
该提案包含IETF和CA浏览器论坛参与者的文本和其他贡献，特别是Robin Alden、Richard Barnes、Viktor Dukhovni、Stephen Farrell、Gervase Markham、Yoav Nir、Tom Ritter、Jeremy Rowley、Stefan Santesson、Ryan Slovi、Brian Smith、Rob Stradling和Sean Turner。
Author's Address
作者地址
Phillip Hallam-Baker Comodo Group Inc.
菲利普·哈拉姆·贝克·科莫多集团公司。
Email: philliph@comodo.com
Email: philliph@comodo.com