[要約] RFC 7633は、X.509v3証明書におけるTransport Layer Security (TLS) Feature Extensionに関するものです。この拡張機能の主な目的は、証明書の使用において特定のTLS機能を要求または指定することにより、セキュリティを強化することです。利用場面としては、特に証明書が特定のTLSプロトコル拡張や機能をサポートしていることを確認する必要がある場合に有用です。このRFCは、TLSプロトコルとそのセキュリティ機能を拡張するための基盤を提供し、関連するRFCにはTLSプロトコルを定義するRFC 5246やその他のセキュリティ拡張を扱うRFCが含まれます。
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機能拡張は、オンライン証明書ステータスプロトコル（OCSP）ステープリングなどのTLSプロトコルの失効確認機能のサポートを義務付けるために使用できます。 OCSPステータス応答が常にステープルされることをクライアントに通知すると、応答がステープルされていない場合に即時の失敗が許可されます。これにより、他の方法では可能である可能性があるサービス拒否攻撃を防ぐことができます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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.
サーバーのエンドエンティティ証明書にstatus_request機能をアドバタイズする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.
TLS機能拡張はオプションであるため、詐欺で証明書を取得しようとする攻撃者がこの拡張で証明書を発行することを選択することはほとんどありません。このようなリスクは、誤発行を防止または軽減するように設計された認証局承認DNSレコード[RFC6844]などのメカニズムによってより適切に対処されます。
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機能拡張を備えたエンドエンティティ証明書を提供するサーバーは、以下で説明するように冗長でない限り、指定された機能のクライアント要求を満たす必要があります。サーバーが指定された機能の要求を受け入れない場合、クライアントは接続の受け入れを拒否してもよい（MAY）。
A Certification Authority SHOULD NOT issue certificates that specify a TLS feature extension advertising features that the server does not support.
証明機関は、サーバーがサポートしていないTLS機能拡張のアドバタイズ機能を指定する証明書を発行してはなりません（SHOULD NOT）。
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.
サーバーは、証明書署名要求[RFC2986]に対応するTLS機能拡張を含めることにより、機能をサポートできることを証明機関に通知してもよい（MAY）。サーバーは、その構成が、接続を要求しているクライアントに提示された資格情報で通知されている機能をサポートしていることを確認する必要があります。
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.
このドキュメントでは、PKIXエンドエンティティ証明書と証明書署名証明書でのTLS機能の使用について説明します。最も一般的に使用される証明書登録プロトコルの帯域内の指定された機能のサポートを説明するために使用できるメカニズムも提供されます。
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 }
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 DERエンコーディングです。
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 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.
オブジェクトメンバーの「機能」は、IANAトランスポート層セキュリティ（TLS）拡張レジストリで指定されている一連のTLS拡張識別子（この仕様の用語では機能）です。これらの機能がClientHelloメッセージでクライアントによって要求された場合、サーバーはこの要求を満たすServerHelloメッセージを返さなければなりません（MUST）。
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拡張をサポートする場合があります。
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は[RFC2986]のセクション4.1で定義されているように、CSR機能としてTLS機能拡張を指定できます（MAY）。サーバーまたはサーバー管理ツールは、証明書の対象となるサーバーでサポートできることがわかっているキー署名要求のみを生成する必要があります。
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構成を拒否してもよい（MAY）。
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_request拡張のサポートを指定する機能宣言と矛盾していると判断した場合、クライアントはTLS構成を拒否する必要があります（SHOULD）。
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構成を受け入れることができます（MAY）。
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構成を受け入れることができますが、その接続を安全であると区別してはなりません（MUST NOT）。
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).
証明機関は、エンドエンティティが指定された機能（たとえば、CSRでの機能拡張の使用、またはout-ofによるサポート）をサポートすることを意図しているという肯定的な記述がない限り、TLS機能拡張で証明書を発行しないでください。バンド通信）。
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ステータストークンが利用可能になるまで、新しい証明書の使用を開始すべきではありません（SHOULD NOT）。
A server MAY override local configuration options if necessary to ensure consistency, but it SHOULD inform the administrator whenever such an inconsistency is discovered.
整合性を確保する必要がある場合、サーバーはローカル構成オプションをオーバーライドできますが、そのような不整合が検出された場合は常に管理者に通知する必要があります（SHOULD）。
A server SHOULD support generation of the feature extension in CSRs if key generation is supported.
キーの生成がサポートされている場合、サーバーはCSRの機能拡張の生成をサポートする必要があります（SHOULD）。
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の使用が明示的なセキュリティポリシー、アプリケーションプロトコル仕様、またはその他の手段によって義務付けられている場合、クライアントは接続を拒否する必要があります（MUST）。有効な証明書での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 Certificate Extension」（1.3.6.1.5.5.7.1）レジストリに次のエントリを追加しました。
Decimal Description References
------- ------------------------------ ---------------------
24 id-pe-tlsfeature this document (RFC 7633)
24 id-pe-tlsfeature this document（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は、「SMI Security for PKIX Module Identifier」（1.3.6.1.5.5.7.0）レジストリに次のエントリを追加しました。
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：Certification Request Syntax Specification Version 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、「The Transport Layer Security（TLS）Protocol Version 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 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、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。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、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 Certification Authority Authorization（CAA）Resource Record」、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。、「The Transport Layer Security（TLS）Multiple Certificate Status Request Extension」、RFC 6961、DOI 10.17487 / RFC6961、2013年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)}
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)}
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, ... }
-- TLS Features Extension
-TLS機能拡張
ext-TLSFeatures EXTENSION ::= { SYNTAX
Features IDENTIFIED BY id-pe-tlsfeature }
id-pe-tlsfeature OBJECT IDENTIFIER ::= { id-pe 24 }
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ブラウザーフォーラムの参加者からのテキストおよびその他の寄稿が組み込まれています。 Sleevi、Brian Smith、Rob Stradling、Sean Turner。
Author's Address
著者のアドレス
Phillip Hallam-Baker Comodo Group Inc.
Phillip Hallam-Baker Comodo Group Inc.
Email: philliph@comodo.com