[要約] RFC 9345 は、TLS および DTLS において、運用者が自身の資格情報を委任するメカニズムを提供し、認証局との組織的な分離による制約を克服することを目的としています。
Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 9345 Cisco
Category: Standards Track S. Iyengar
ISSN: 2070-1721 Facebook
N. Sullivan
Cloudflare
E. Rescorla
Windy Hill Systems, LLC
July 2023
The organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the Certification Authority (CA). This document describes a mechanism to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification.
TLSのオペレーターとDTLSエンドポイントと認証機関の間の組織的な分離は、制限を作成することができます。たとえば、証明書の寿命、それらの使用方法、およびそれらがサポートするアルゴリズムは、最終的に認証機関（CA）によって決定されます。このドキュメントでは、この仕様をサポートしていない仲間との互換性を破ることなく、オペレーターがTLSおよびDTLで使用するために独自の資格情報を委任できるようにすることにより、これらの制限のいくつかを克服するメカニズムについて説明します。
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 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9345.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9345で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Terminology
3. Solution Overview
3.1. Rationale
3.2. Related Work
4. Delegated Credentials
4.1. Client and Server Behavior
4.1.1. Server Authentication
4.1.2. Client Authentication
4.1.3. Validating a Delegated Credential
4.2. Certificate Requirements
5. Operational Considerations
5.1. Client Clock Skew
6. IANA Considerations
7. Security Considerations
7.1. Security of Delegated Credential's Private Key
7.2. Re-use of Delegated Credentials in Multiple Contexts
7.3. Revocation of Delegated Credentials
7.4. Interactions with Session Resumption
7.5. Privacy Considerations
7.6. The Impact of Signature Forgery Attacks
8. References
8.1. Normative References
8.2. Informative References
Appendix A. ASN.1 Module
Appendix B. Example Certificate
Acknowledgements
Authors' Addresses
Server operators often deploy (D)TLS termination to act as the server for inbound TLS connections. These termination services can be in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect compromises of private key material corresponding to TLS certificates. Short-lived certificates may be used to limit the exposure of keys in these cases.
サーバーオペレーターは、多くの場合、（d）TLS終了を展開して、インバウンドTLS接続のサーバーとして機能します。これらの終了サービスは、TLS証明書に対応する秘密キー資料の妥協を検出することが困難な場合があるリモートデータセンターやコンテンツ配信ネットワーク（CDN）などの場所にあります。短命の証明書は、これらの場合のキーの露出を制限するために使用できます。
However, short-lived certificates need to be renewed more frequently than long-lived certificates. If an external Certification Authority (CA) is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificate and therefore a higher risk that an outage at a CA will negatively affect the uptime of the TLS-fronted service.
ただし、短命の証明書は、長命の証明書よりも頻繁に更新する必要があります。外部認定機関（CA）が展開された証明書を交換するために時間内に証明書を発行できない場合、サーバーは有効な証明書をクライアントに提示することができなくなります。短命の証明書を使用すると、証明書を更新するための時間の短いウィンドウがあり、したがって、CAでの停止がTLSフロントサービスの稼働時間に悪影響を与えるというリスクが高くなります。
Typically, a (D)TLS server uses a certificate provided by some entity other than the operator of the server (a CA) [RFC8446] [RFC5280]. This organizational separation makes the (D)TLS server operator dependent on the CA for some aspects of its operations. For example:
通常、a（d）TLSサーバーは、サーバーのオペレーター（A CA）[RFC8446] [RFC5280]以外の一部のエンティティが提供する証明書を使用します。この組織的な分離により、（d）TLSサーバーオペレーターは、操作のいくつかの側面についてCAに依存します。例えば：
* Whenever the server operator wants to deploy a new certificate, it has to interact with the CA.
* サーバーオペレーターが新しい証明書を展開したいときはいつでも、CAと対話する必要があります。
* The CA might only issue credentials containing certain types of public keys, which can limit the set of (D)TLS signature schemes usable by the server operator.
* CAは、特定の種類のパブリックキーを含む資格情報のみを発行する場合があります。これにより、サーバーオペレーターが使用できる（d）TLS署名スキームのセットを制限できます。
To reduce the dependency on external CAs, this document specifies a limited delegation mechanism that allows a (D)TLS peer to issue its own credentials within the scope of a certificate issued by an external CA. These credentials only enable the recipient of the delegation to terminate connections for names that the CA has authorized. Furthermore, this mechanism allows the server to use modern signature algorithms such as Ed25519 [RFC8032] even if their CA does not support them.
外部CASへの依存を減らすために、このドキュメントは、外部CAによって発行された証明書の範囲内で（d）TLSピアが独自の資格情報を発行できるようにする限られた委任メカニズムを指定します。これらの資格情報は、代表団の受信者がCAが承認した名前の接続を終了することを可能にします。さらに、このメカニズムにより、サーバーは、CAがそれらをサポートしていなくても、ED25519 [RFC8032]などの最新の署名アルゴリズムを使用できます。
This document refers to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC".
このドキュメントは、CAが「証明書」または「委任証明書」として発行した証明書、およびオペレーターが「委任された資格情報」または「DC」として発行した証明書を指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
A delegated credential (DC) is a digitally signed data structure with two semantic fields: a validity interval and a public key (along with its associated signature algorithm). The signature on the delegated credential indicates a delegation from the certificate that is issued to the peer. The private key used to sign a credential corresponds to the public key of the peer's X.509 end-entity certificate [RFC5280]. Figure 1 shows the intended deployment architecture.
委任された資格情報（DC）は、2つのセマンティックフィールドを備えたデジタル署名されたデータ構造です。有効性間隔と公開キー（関連する署名アルゴリズムとともに）です。委任された資格情報の署名は、ピアに発行された証明書からの代表団を示します。資格情報に署名するために使用される秘密鍵は、ピアのX.509エンドエンティティ証明書[RFC5280]の公開鍵に対応しています。図1は、意図した展開アーキテクチャを示しています。
Client Front-End Back-End
| |<--DC distribution->|
|----ClientHello--->| |
|<---ServerHello----| |
|<---Certificate----| |
|<---CertVerify-----| |
| ... | |
Legend:
Client: (D)TLS client
Front-End: (D)TLS server (could be a TLS-termination service like a CDN)
Back-End: Service with access to a private key
Figure 1: Delegated Credentials Deployment Architecture
図1：委任された資格情報の展開アーキテクチャ
A (D)TLS handshake that uses delegated credentials differs from a standard handshake in a few important ways:
委任された資格情報を使用するTLSの握手は、いくつかの重要な方法で標準の握手とは異なります。
* The initiating peer provides an extension in its ClientHello or CertificateRequest that indicates support for this mechanism.
* 開始ピアは、このメカニズムのサポートを示すClientHelloまたはCertificateRequestの拡張機能を提供します。
* The peer sending the Certificate message provides both the certificate chain terminating in its certificate and the delegated credential.
* 証明書メッセージを送信するピアは、証明書で終了する証明書チェーンと委任された資格情報の両方を提供します。
* The initiator uses information from the peer's certificate to verify the delegated credential and that the peer is asserting an expected identity, determining an authentication result for the peer.
* イニシエーターは、ピアの証明書からの情報を使用して、委任された資格情報を確認し、ピアが予想される身元を主張していることを確認し、ピアの認証結果を決定します。
* Peers accepting the delegated credential use it as the certificate key for the (D)TLS handshake.
* 委任された資格情報を受け入れるピアは、それを（d）TLSハンドシェイクの証明書キーとして使用します。
As detailed in Section 4, the delegated credential is cryptographically bound to the end-entity certificate with which the credential may be used. This document specifies the use of delegated credentials in (D)TLS 1.3 or later; their use in prior versions of the protocol is not allowed.
セクション4で詳述されているように、委任された資格情報は、資格情報を使用する可能性のあるエンドエンティティ証明書に暗号化されています。このドキュメントは、（d）TLS 1.3以降の委任された資格情報の使用を指定しています。プロトコルの以前のバージョンでの使用は許可されていません。
Delegated credentials allow a peer to terminate (D)TLS connections on behalf of the certificate owner. If a credential is stolen, there is no mechanism for revoking it without revoking the certificate itself. To limit exposure in case of the compromise of a delegated credential's private key, delegated credentials have a maximum validity period. In the absence of an application profile standard specifying otherwise, the maximum validity period is set to 7 days. Peers MUST NOT issue credentials with a validity period longer than the maximum validity period or that extends beyond the validity period of the delegation certificate. This mechanism is described in detail in Section 4.1.
委任された資格情報により、ピアは証明書所有者に代わって（d）TLS接続を終了させることができます。資格が盗まれた場合、証明書自体を取り消すことなくそれを取り消すメカニズムはありません。委任された資格情報の秘密鍵の妥協の場合に露出を制限するために、委任された資格情報は最大の有効期間を持っています。それ以外の場合は、アプリケーションプロファイル標準がない場合、最大妥当性期間は7日間に設定されます。ピアは、最大妥当性期間よりも長い有効期間で資格情報を発行してはなりません。このメカニズムについては、セクション4.1で詳しく説明しています。
It was noted in [XPROT] that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage ([RFC5280], Section 4.2.1.3). In order to reduce the risk of cross-protocol attacks on certificates that are not intended to be used with DC-capable TLS stacks, we define a new DelegationUsage extension to X.509 that permits use of delegated credentials. (See Section 4.2.)
[XPROT]では、SSLV2などの時代遅れのプロトコルをサポートするサーバーが使用している証明書を使用して、Keyencipherment KeyUSAGE（[RFC5280]、セクション4.2.1.3）を含む証明書の署名を偽造できることが注目されました。DC対応TLSスタックで使用することを意図していない証明書に対するクロスプロトコル攻撃のリスクを減らすために、委任された資格情報の使用を許可するX.509への新しい代表団拡張を定義します。（セクション4.2を参照してください。）
Delegated credentials present a better alternative than other delegation mechanisms like proxy certificates [RFC3820] for several reasons:
委任された資格情報は、いくつかの理由で、プロキシ証明書[RFC3820]などの他の委任メカニズムよりも優れた代替手段を提示します。
* There is no change needed to certificate validation at the PKI layer.
* PKIレイヤーで検証を証明するために変更は必要ありません。
* X.509 semantics are very rich. This can cause unintended consequences if a service owner creates a proxy certificate where the properties differ from the leaf certificate. Proxy certificates can be useful in controlled environments, but remain a risk in scenarios where the additional flexibility they provide is not necessary. For this reason, delegated credentials have very restricted semantics that should not conflict with X.509 semantics.
* X.509セマンティクスは非常に豊富です。これにより、サービス所有者がプロパティが葉証明書と異なるプロキシ証明書を作成する場合、これは意図しない結果を引き起こす可能性があります。プロキシ証明書は、制御された環境では役立ちますが、提供する追加の柔軟性が必要ないシナリオではリスクのままです。このため、委任された資格情報には、X.509セマンティクスと矛盾するべきではない非常に制限されたセマンティクスがあります。
* Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the end-entity certificate. Since the certificate path building process is not cryptographically protected, it is possible that a proxy certificate could be bound to another certificate with the same public key, with different X.509 parameters. Delegated credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot.
* プロキシ証明書は、証明書パス構築プロセスに依存して、プロキシ証明書とエンドエンティティ証明書の間に拘束力を確立します。証明書パスの構築プロセスは暗号化されていないため、プロキシ証明書を同じ公開キーを持つ別の証明書に拘束する可能性があり、X.509パラメーターが異なります。証明書全体と委任された資格情報の間の暗号化の拘束力に依存する委任された資格情報は、できません。
* Each delegated credential is bound to a specific signature algorithm for use in the (D)TLS handshake ([RFC8446], Section 4.2.3). This prevents them from being used with other, perhaps unintended, signature algorithms. The signature algorithm bound to the delegated credential can be chosen independently of the set of signature algorithms supported by the end-entity certificate.
* 委任された各資格情報は、（d）TLSハンドシェイク（[RFC8446]、セクション4.2.3）で使用するための特定の署名アルゴリズムに縛られています。これにより、他の、おそらく意図しない署名アルゴリズムで使用されなくなります。委任された資格情報にバインドされた署名アルゴリズムは、エンドエンティティ証明書でサポートされる署名アルゴリズムのセットとは無関係に選択できます。
Many of the use cases for delegated credentials can also be addressed using purely server-side mechanisms that do not require changes to client behavior (e.g., a PKCS#11 interface or a remote signing mechanism, [KEYLESS] being one example). These mechanisms, however, incur per-transaction latency, since the front-end server has to interact with a back-end server that holds a private key. The mechanism proposed in this document allows the delegation to be done offline, with no per-transaction latency. The figure below compares the message flows for these two mechanisms with (D)TLS 1.3 [RFC8446] [RFC9147].
委任された資格情報のユースケースの多くは、クライアントの動作の変更を必要としない純粋にサーバー側のメカニズムを使用してアドレス指定することもできます（たとえば、PKCS＃11インターフェイスまたはリモート署名メカニズム、[キーレス]の例）。ただし、フロントエンドサーバーは秘密キーを保持するバックエンドサーバーと対話する必要があるため、これらのメカニズムはトランザクションごとの遅延が発生します。このドキュメントで提案されているメカニズムにより、代表団をオフラインで行うことができ、貿易ごとの遅延はありません。以下の図は、（d）TLS 1.3 [RFC8446] [RFC9147]を使用して、これら2つのメカニズムのメッセージフローを比較しています。
Remote key signing:
Client Front-End Back-End
|----ClientHello--->| |
|<---ServerHello----| |
|<---Certificate----| |
| |<---remote sign---->|
|<---CertVerify-----| |
| ... | |
Delegated Credential:
Client Front-End Back-End
| |<--DC distribution->|
|----ClientHello--->| |
|<---ServerHello----| |
|<---Certificate----| |
|<---CertVerify-----| |
| ... | |
Legend:
Client: (D)TLS client
Front-End: (D)TLS server (could be a TLS-termination service like a CDN)
Back-End: Service with access to a private key
These two mechanisms can be complementary. A server could use delegated credentials for clients that support them, while using a server-side mechanism to support legacy clients. Both mechanisms require a trusted relationship between the front-end and back-end -- the delegated credential can be used in place of a certificate private key.
これらの2つのメカニズムは補完的です。サーバーは、レガシークライアントをサポートするためにサーバー側のメカニズムを使用しながら、それらをサポートするクライアントに委任された資格情報を使用できます。両方のメカニズムには、フロントエンドとバックエンドの間の信頼できる関係が必要です。委任された資格情報は、証明書の秘密鍵の代わりに使用できます。
The use of short-lived certificates with automated certificate issuance, e.g., with the Automated Certificate Management Environment (ACME) [RFC8555], reduces the risk of key compromise but has several limitations. Specifically, it introduces an operationally critical dependency on an external party (the CA). It also limits the types of algorithms supported for (D)TLS authentication to those the CA is willing to issue a certificate for. Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning delegated credentials.
自動化された証明書の発行を伴う短命の証明書を使用すると、たとえば自動化された証明書管理環境（ACME）[RFC8555]を使用すると、重要な妥協のリスクが減りますが、いくつかの制限があります。具体的には、外部の当事者（CA）に運用上重要な依存関係を導入します。また、（d）TLS認証に対してサポートされているアルゴリズムの種類を、CAが証明書を発行する意思があるものに制限します。それにもかかわらず、ACMEのような既存の自動発行APIは、委任された資格情報のプロビジョニングに役立つ場合があります。
While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is valid to use them to issue other signed objects as long as the certificate contains the digitalSignature KeyUsage ([RFC5280], Section 4.2.1.3). (All certificates compatible with TLS 1.3 are required to contain the digitalSignature KeyUsage.) This document defines a new signed object format that encodes only the semantics that are needed for this application. The Credential has the following structure:
X.509は、エンドエンティティ証明書を他の証明書の発行者として使用することを禁止していますが、証明書にデジタル署名キーユーザー（[RFC5280]、セクション4.2.1.3）が含まれている限り、他の署名されたオブジェクトを使用することは有効です。（TLS 1.3と互換性のあるすべての証明書は、DigitalSignature KeyUSAGEを含むために必要です。）このドキュメントは、このアプリケーションに必要なセマンティクスのみをエンコードする新しい署名されたオブジェクト形式を定義します。資格情報には次の構造があります。
struct {
uint32 valid_time;
SignatureScheme dc_cert_verify_algorithm;
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
} Credential;
valid_time:
valid_time：
Time, in seconds relative to the delegation certificate's notBefore value, after which the delegated credential is no longer valid. By default, unless set to an alternative value by an application profile (see Section 3), endpoints will reject delegated credentials that expire more than 7 days from the current time (as described in Section 4.1.3).
時間、委任証明書の前の値に比べて数秒で、その後、委任された資格情報はもはや有効ではありません。デフォルトでは、アプリケーションプロファイル（セクション3を参照）によって代替値に設定されていない限り、エンドポイントは、現在から7日以上有効な委任された資格情報を拒否します（セクション4.1.3で説明します）。
dc_cert_verify_algorithm:
DC_CERT_VERIFY_ALGORITHM：
The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in [RFC8446]. This is expected to be the same as the sender's CertificateVerify.algorithm (as described in Section 4.1.3). When using RSA, the public key MUST NOT use the rsaEncryption OID. As a result, the following algorithms are not allowed for use with delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, and rsa_pss_rsae_sha512.
タイプSignatureSchemeは[RFC8446]で定義されているように、クレデンシャルキーペアの署名アルゴリズム。これは、送信者のCertifateverify.algorithm（セクション4.1.3で説明されている）と同じであると予想されます。RSAを使用する場合、公開キーはRSAECNACHRYPTION OIDを使用してはなりません。その結果、次のアルゴリズムは、委任された資格情報を使用して使用できません：RSA_PSS_RSAE_SHA256、RSA_PSS_RSAE_SHA384、およびRSA_PSS_RSAE_SHA512。
ASN1_subjectPublicKeyInfo:
asn1_subjectpublickeyinfo：
The Credential's public key, a DER-encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280].
資格情報の公開キー、[RFC5280]で定義されているDer-Encoded [X.690] SubjectPublicKeyInfo。
The DelegatedCredential has the following structure:
DelegatedCredentialには次の構造があります。
struct {
Credential cred;
SignatureScheme algorithm;
opaque signature<1..2^16-1>;
} DelegatedCredential;
cred:
信用：
The Credential structure as previously defined.
以前に定義された資格構造。
algorithm:
アルゴリズム：
The signature algorithm used to create DelegatedCredential.signature.
DelegatedCredential.signatureを作成するために使用される署名アルゴリズム。
signature:
サイン：
The delegation, a signature that binds the credential to the end-entity certificate's public key as specified below. The signature scheme is specified by DelegatedCredential.algorithm.
代表団は、以下に指定されているように、エンドエンティティ証明書の公開キーに資格情報をバインドする署名です。署名スキームは、DelegatedCredential.Algorithmによって指定されます。
The signature of the DelegatedCredential is computed over the concatenation of:
DelegatedCredentialの署名は、次のように連結して計算されます。
1. An octet stream that consists of octet 32 (0x20) repeated 64 times.
1. オクテット32（0x20）で構成されるオクテットストリームは、64回繰り返されます。
2. The non-null terminated context string "TLS, server delegated credentials" for server authentication and "TLS, client delegated credentials" for client authentication.
2. 非ヌル終了コンテキスト文字列「TLS」、サーバー認証のためのサーバー委任資格情報」および「TLS、クライアント認証用のクライアント委任資格情報」。
3. A single octet 0x00, which serves as the separator.
3. セパレーターとして機能する単一のオクテット0x00。
4. The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential.
4. DEREGATEDCREDENTIALに署名するために使用されるDER-ENCODED X.509エンドエンティティ証明書。
5. DelegatedCredential.cred.
5. 委任された資格情報。
6. DelegatedCredential.algorithm.
6. DelegatedCredential.Algorithm。
The signature is computed by using the private key of the peer's end-entity certificate, with the algorithm indicated by DelegatedCredential.algorithm.
署名は、ピアの終了証明書の秘密鍵を使用して計算され、アルゴリズムはDelegatedCredential.algorithmで示されます。
The signature effectively binds the credential to the parameters of the handshake in which it is used. In particular, it ensures that credentials are only used with the certificate and signature algorithm chosen by the delegator.
署名は、使用されているハンドシェイクのパラメーターに資格情報を効果的に結合します。特に、資格情報は、委任者が選択した証明書と署名アルゴリズムでのみ使用されることを保証します。
The code changes required in order to create and verify delegated credentials, and the implementation complexity this entails, are localized to the (D)TLS stack. This has the advantage of avoiding changes to the often-delicate security-critical PKI code.
委任された資格情報を作成および検証するために必要なコードの変更、およびこれに伴う実装の複雑さは、（d）TLSスタックにローカライズされます。これには、セキュリティが批判されることが多いPKIコードの変更を回避するという利点があります。
This document defines the following (D)TLS extension code point.
このドキュメントは、次の（d）TLS拡張コードポイントを定義します。
enum {
...
delegated_credential(34),
(65535)
} ExtensionType;
A client that is willing to use delegated credentials in a connection SHALL send a "delegated_credential" extension in its ClientHello. The body of the extension consists of a SignatureSchemeList (defined in [RFC8446]):
接続中に委任された資格情報を使用する意思のあるクライアントは、clienthelloに「Delegated_Credential」拡張機能を送信するものとします。拡張機能の本文は、SignatureSchemelist（[RFC8446]で定義）で構成されています。
struct {
SignatureScheme supported_signature_algorithms<2..2^16-2>;
} SignatureSchemeList;
If the client receives a delegated credential without having indicated support in its ClientHello, then the client MUST abort the handshake with an "unexpected_message" alert.
クライアントがclienthelloでサポートを示していない場合にクライアントが委任された資格情報を受け取った場合、クライアントは「rediced_message」アラートでハンドシェイクを中止する必要があります。
If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send a delegated credential. When a (D)TLS version negotiated is less than 1.3, the server MUST ignore this extension. An example of when a server could choose not to send a delegated credential is when the SignatureSchemes listed only contain signature schemes for which a corresponding delegated credential does not exist or are otherwise unsuitable for the connection.
拡張機能が存在する場合、サーバーは委任された資格情報を送信する場合があります。拡張機能が存在しない場合、サーバーは委任された資格情報を送信してはなりません。ネゴシエートされた（d）TLSバージョンが1.3未満の場合、サーバーはこの拡張機能を無視する必要があります。サーバーが委任された資格情報を送信しないことを選択できる場合の例は、リストされているSignatureSchemが対応する委任された資格情報が存在しないか、それ以外の場合は接続に適していない署名スキームのみを含む場合です。
The server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client MUST NOT use delegated credentials sent as extensions to any other certificate, and SHOULD ignore them, but MAY abort the handshake with an "illegal_parameter" alert. If the server sends multiple delegated credentials extensions in a single CertificateEntry, the client MUST abort the handshake with an "illegal_parameter" alert.
サーバーは、委任された資格情報を、その終了証明書の証明書の拡張機能として送信する必要があります。クライアントは、他の証明書に拡張機能として送信された委任された資格情報を使用してはなりません。また、それらを無視する必要がありますが、「Illegal_Parameter」アラートで握手を中止する場合があります。サーバーが単一のCertimateEntryで複数の委任された資格情報拡張機能を送信した場合、クライアントは「Illegal_Parameter」アラートでハンドシェイクを中止する必要があります。
The algorithm field MUST be of a type advertised by the client in the "signature_algorithms" extension of the ClientHello message, and the dc_cert_verify_algorithm field MUST be of a type advertised by the client in the SignatureSchemeList; otherwise, the credential is considered not valid. Clients that receive non-valid delegated credentials MUST terminate the connection with an "illegal_parameter" alert.
アルゴリズムフィールドは、clienthelloメッセージの「signature_algorithms」拡張機能でクライアントによって宣伝されているタイプである必要があり、dc_cert_verify_algorithmフィールドは、signatureschemelistのクライアントによって宣伝されているタイプでなければなりません。それ以外の場合、資格情報は無効と見なされます。Valid委任されていない資格情報を受け取ったクライアントは、「Illegal_Parameter」アラートとの接続を終了する必要があります。
A server that supports this specification SHALL send a "delegated_credential" extension in the CertificateRequest message when requesting client authentication. The body of the extension consists of a SignatureSchemeList. If the server receives a delegated credential without having indicated support in its CertificateRequest, then the server MUST abort with an "unexpected_message" alert.
この仕様をサポートするサーバーは、クライアント認証を要求する際に、cirtimateRequestメッセージに「delegated_credential」拡張機能を送信するものとします。拡張機能の本文は、SignatureSchemelistで構成されています。サーバーが証明書のサポートを示すことなく委任された資格情報を受信した場合、サーバーは「rediced_message」アラートで中止する必要があります。
If the extension is present, the client MAY send a delegated credential; if the extension is not present, the client MUST NOT send a delegated credential. When a (D)TLS version negotiated is less than 1.3, the client MUST ignore this extension.
拡張機能が存在する場合、クライアントは委任された資格情報を送信できます。拡張機能が存在しない場合、クライアントは委任された資格情報を送信してはなりません。（d）TLSバージョンのネゴシエートが1.3未満の場合、クライアントはこの拡張機能を無視する必要があります。
The client MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the server MUST NOT use delegated credentials sent as extensions to any other certificate, and SHOULD ignore them, but MAY abort the handshake with an "illegal_parameter" alert. If the client sends multiple delegated credentials extensions in a single CertificateEntry, the server MUST abort the handshake with an "illegal_parameter" alert.
クライアントは、委任された資格情報を、その最終施設証明書の証明書の拡張機能として送信する必要があります。サーバーは、他の証明書に拡張機能として送信された委任された資格情報を使用してはならず、それらを無視する必要がありますが、「Illegal_Parameter」アラートで握手を中止する場合があります。クライアントが単一のCertilementEntryで複数の委任された資格情報拡張機能を送信した場合、サーバーは「Illegal_Parameter」アラートでハンドシェイクを中止する必要があります。
The algorithm field MUST be of a type advertised by the server in the "signature_algorithms" extension of the CertificateRequest message, and the dc_cert_verify_algorithm field MUST be of a type advertised by the server in the SignatureSchemeList; otherwise, the credential is considered not valid. Servers that receive non-valid delegated credentials MUST terminate the connection with an "illegal_parameter" alert.
アルゴリズムフィールドは、「signature_algorithms」拡張子のサーバーによって宣伝されているタイプである必要があり、DC_CERT_VERIFY_ALGORITHMフィールドは、SignatureSchemelistのサーバーによって宣伝されているタイプでなければなりません。それ以外の場合、資格情報は無効と見なされます。非Valid委任された資格情報を受信するサーバーは、「Illegal_Parameter」アラートとの接続を終了する必要があります。
On receiving a delegated credential and certificate chain, the peer validates the certificate chain and matches the end-entity certificate to the peer's expected identity in the same way that it is done when delegated credentials are not in use. It then performs the following checks with expiry time set to the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time:
委任された資格情報と証明書チェーンを受信すると、ピアは証明書チェーンを検証し、委任された資格情報が使用されていないときに行われるのと同じように、エンドエンティティ証明書をピアの予想IDと一致させます。次に、委任証明書に設定された有効期限を備えた次のチェックを実行します。
1. Verify that the current time is within the validity interval of the credential. This is done by asserting that the current time does not exceed the expiry time. (The start time of the credential is implicitly validated as part of certificate validation.)
1. 現在の時刻が資格情報の有効性間隔内にあることを確認します。これは、現在の時間が有効期限を超えないと主張することによって行われます。（資格情報の開始時間は、証明書の検証の一部として暗黙的に検証されます。）
2. Verify that the delegated credential's remaining validity period is no more than the maximum validity period. This is done by asserting that the expiry time does not exceed the current time plus the maximum validity period (7 days by default) and that the expiry time is less than the certificate's expiry_time.
2. 委任された資格情報の残りの妥当性期間が最大妥当性期間にすぎないことを確認してください。これは、有効期限が現在の時間と最大妥当性の期間（デフォルトで7日間）を超えないこと、および有効期限が証明書の有効期間よりも短いことを主張することによって行われます。
3. Verify that dc_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the algorithm is allowed for use with delegated credentials.
3. DC_CERT_VERIFY_ALGORITHMが、PeerのCertimateVerifyメッセージに示されているスキームと一致し、アルゴリズムが委任された資格情報で使用できることを確認します。
4. Verify that the end-entity certificate satisfies the conditions described in Section 4.2.
4. エンティティ証明書がセクション4.2で説明されている条件を満たしていることを確認します。
5. Use the public key in the peer's end-entity certificate to verify the signature of the credential using the algorithm indicated by DelegatedCredential.algorithm.
5. Peerのエンドエンティティ証明書の公開キーを使用して、DelegatedCredential.algorithmで示されたアルゴリズムを使用して、資格情報の署名を確認します。
If one or more of these checks fail, then the delegated credential is deemed not valid. Clients and servers that receive non-valid delegated credentials MUST terminate the connection with an "illegal_parameter" alert.
これらのチェックの1つ以上が失敗した場合、委任された資格情報は無効とみなされます。非Valid委任された資格情報を受け取るクライアントとサーバーは、「Illegal_Parameter」アラートとの接続を終了する必要があります。
If successful, the participant receiving the Certificate message uses the public key in DelegatedCredential.cred to verify the signature in the peer's CertificateVerify message.
成功した場合、証明書メッセージを受信する参加者は、DelegatedCredential.creedの公開キーを使用して、PeerのCertimateVerifyメッセージの署名を確認します。
This document defines a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated credentials. What follows is the ASN.1 [X.680] for the DelegationUsage certificate extension.
このドキュメントでは、証明書が委任された資格情報の使用を許可する場合、証明書で使用される新しいX.509拡張機能であるDedegationUsageを定義します。以下は、委任証明書延長のasn.1 [x.680]です。
ext-delegationUsage EXTENSION ::= {
SYNTAX DelegationUsage IDENTIFIED BY id-pe-delegationUsage
}
DelegationUsage ::= NULL
id-pe-delegationUsage OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) id-cloudflare(44363) 44 }
The extension MUST be marked non-critical. (See Section 4.2 of [RFC5280].) An endpoint MUST NOT accept a delegated credential unless the peer's end-entity certificate satisfies the following criteria:
拡張機能は、非クリティカルにマークする必要があります。（[RFC5280]のセクション4.2を参照してください。）エンドポイントは、ピアの最終施設証明書が次の基準を満たしていない限り、委任された資格情報を受け入れてはなりません。
* It has the DelegationUsage extension.
* 委任拡張機能があります。
* It has the digitalSignature KeyUsage (see the KeyUsage extension defined in [RFC5280]).
* DigitalSignature KeyUSAGEがあります（[RFC5280]で定義されているKeyUSAGE拡張機能を参照）。
A new extension was chosen instead of adding a new Extended Key Usage (EKU) to be compatible with deployed (D)TLS and PKI software stacks without requiring CAs to issue new intermediate certificates.
新しい拡張機能は、新しい中級証明書を発行することなく、展開（D）TLSおよびPKIソフトウェアスタックと互換性がある新しい拡張キー使用量（EKU）を追加する代わりに選択されました。
The operational considerations documented in this section should be taken into consideration when using delegated credentials.
このセクションで文書化された運用上の考慮事項は、委任された資格情報を使用する際に考慮すべきです。
One of the risks of deploying a short-lived credential system based on absolute time is client clock skew. If a client's clock is sufficiently ahead of or behind the server's clock, then clients will reject delegated credentials that are valid from the server's perspective. Clock skew also affects the validity of the original certificates. The lifetime of the delegated credential should be set taking clock skew into account. Clock skew may affect a delegated credential at the beginning and end of its validity periods, which should also be taken into account.
絶対時間に基づいて短命の資格情報システムを展開するリスクの1つは、クライアントクロックスキューです。クライアントのクロックがサーバーのクロックよりも十分に先にある場合、クライアントはサーバーの観点から有効な委任された資格情報を拒否します。クロックスキューは、元の証明書の有効性にも影響します。委任された資格情報の寿命は、時計が歪んでいることを考慮して設定する必要があります。クロックスキューは、その有効期間の開始時と終了時に委任された資格情報に影響を与える可能性があり、これも考慮する必要があります。
This document registers the "delegated_credential" extension in the "TLS ExtensionType Values" registry. The "delegated_credential" extension has been assigned the ExtensionType value 34. The IANA registry lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in (D)TLS 1.3 [RFC8446] [RFC9147]. Additionally, the "DTLS-Only" column is assigned the value "N".
このドキュメントは、「TLS拡張タイプ値」レジストリの「Delegated_Credential」拡張機能を登録します。「Delegated_Credential」拡張機能には、extensionType値34が割り当てられています。IANAレジストリは、この拡張機能を「推奨」（つまり、「Y」）としてリストし、ClientHello（CH）、CertificateRequest（CR）、または証明書に表示される可能性があることを示します。（d）TLS 1.3 [RFC8446] [RFC9147]のメッセージ。さらに、「dtlsのみ」列に値「n」が割り当てられます。
This document also defines an ASN.1 module for the DelegationUsage certificate extension in Appendix A. IANA has registered value 95 for "id-mod-delegated-credential-extn" in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry. An OID for the DelegationUsage certificate extension is not needed, as it is already assigned to the extension from Cloudflare's IANA Private Enterprise Number (PEN) arc.
このドキュメントでは、付録Aの委任証明書延長のASN.1モジュールも定義しています。IANAは、「PKIXモジュール識別子のSMIセキュリティ」（1.3.6.1の「ID-Mod-Delegated-Credential-Extn」の値95を登録しています。5.5.7.0）レジストリ。CloudFlareのIANAプライベートエンタープライズ番号（PEN）アークから拡張機能に既に割り当てられているため、委任証明書拡張のOIDは必要ありません。
The security considerations documented in this section should be taken into consideration when using delegated credentials.
このセクションで文書化されたセキュリティ上の考慮事項は、委任された資格情報を使用する際に考慮すべきです。
Delegated credentials limit the exposure of the private key used in a (D)TLS connection by limiting its validity period. An attacker who compromises the private key of a delegated credential cannot create new delegated credentials, but they can impersonate the compromised party in new TLS connections until the delegated credential expires.
委任された資格情報は、その有効期間を制限することにより、（d）TLS接続で使用される秘密鍵の露出を制限します。委任された資格情報の秘密鍵を妥協する攻撃者は、新しい委任された資格情報を作成することはできませんが、委任された資格が期限切れになるまで、新しいTLS接続で侵害された当事者になりすまします。
Thus, delegated credentials should not be used to send a delegation to an untrusted party. Rather, they are meant to be used between parties that have some trust relationship with each other. The secrecy of the delegated credential's private key is thus important, and access control mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules.
したがって、委任された資格情報を使用して、信頼されていない当事者に代表団を送るべきではありません。むしろ、それらは互いに信頼関係を持つ当事者間で使用されることを意図しています。したがって、委任された資格情報の秘密鍵の秘密は重要であり、ファイルシステムコントロール、物理セキュリティ、またはハードウェアセキュリティモジュールなど、アクセス制御メカニズムを使用するために使用する必要があります。
It is not possible to use the same delegated credential for both client and server authentication because issuing parties compute the corresponding signature using a context string unique to the intended role (client or server).
発行者が意図した役割（クライアントまたはサーバー）に固有のコンテキスト文字列を使用して、対応する署名を計算するため、クライアントとサーバーの両方の認証に同じ委任された資格情報を使用することはできません。
Delegated credentials do not provide any additional form of early revocation. Since it is short-lived, the expiry of the delegated credential revokes the credential. Revocation of the long-term private key that signs the delegated credential (from the end-entity certificate) also implicitly revokes the delegated credential.
委任された資格情報は、早期取り消しの追加形式を提供しません。短命なので、委任された資格情報の有効期限は資格情報を取り消します。委任された資格情報（エンドエンティティ証明書から）に署名する長期的な秘密鍵の取り消しも、委任された資格情報を暗黙的に取り消す。
If a peer decides to cache the certificate chain and re-validate it when resuming a connection, they SHOULD also cache the associated delegated credential and re-validate it. Failing to do so may result in resuming connections for which the delegated credential has expired.
ピアが証明書チェーンをキャッシュし、接続を再開するときに再検証することを決定した場合、関連する委任された資格情報をキャッシュして再検証する必要があります。そうしないと、委任された資格が失効した接続が再開される可能性があります。
Delegated credentials can be valid for 7 days (by default), and it is much easier for a service to create delegated credentials than a certificate signed by a CA. A service could determine the client time and clock skew by creating several delegated credentials with different expiry timestamps and observing which credentials the client accepts. Since client time can be unique to a particular client, privacy-sensitive clients who do not trust the service, such as browsers in incognito mode, might not want to advertise support for delegated credentials, or might limit the number of probes that a server can perform.
委任された資格情報は7日間（デフォルトで）有効であり、サービスがCAによって署名された証明書よりも委任された資格情報を作成するのははるかに簡単です。サービスは、異なる有効期限のあるタイムスタンプを持ついくつかの委任された資格情報を作成し、クライアントが受け入れる資格情報を観察することにより、クライアントの時間とクロックを歪めることができます。クライアントの時間は特定のクライアントに固有のものである可能性があるため、Incognitoモードのブラウザなど、サービスを信頼していないプライバシーに敏感なクライアントは、委任された資格情報のサポートを宣伝したくないか、サーバーができるプローブの数を制限する可能性があります。実行する。
Delegated credentials are only used in (D)TLS 1.3 connections. However, the certificate that signs a delegated credential may be used in other contexts such as (D)TLS 1.2. Using a certificate in multiple contexts opens up a potential cross-protocol attack against delegated credentials in (D)TLS 1.3.
委任された資格情報は、（d）TLS 1.3接続でのみ使用されます。ただし、委任された資格情報に署名する証明書は、（d）TLS 1.2などの他のコンテキストで使用できます。複数のコンテキストで証明書を使用すると、（d）TLS 1.3の委任された資格情報に対する潜在的なクロスプロトコル攻撃が開かれます。
When (D)TLS 1.2 servers support RSA key exchange, they may be vulnerable to attacks that allow forging an RSA signature over an arbitrary message [BLEI]. The TLS 1.2 specification describes a strategy for preventing these attacks that requires careful implementation of timing-resistant countermeasures. (See Section 7.4.7.1 of [RFC5246].)
（d）TLS 1.2サーバーがRSAキー交換をサポートする場合、任意のメッセージ[BLEI]にRSA署名を鍛造できる攻撃に対して脆弱である可能性があります。TLS 1.2仕様は、タイミング耐性の対策を慎重に実施する必要があるこれらの攻撃を防ぐための戦略を説明しています。（[RFC5246]のセクション7.4.7.1を参照してください。）
Experience shows that, in practice, server implementations may fail to fully stop these attacks due to the complexity of this mitigation [ROBOT]. For (D)TLS 1.2 servers that support RSA key exchange using a DC-enabled end-entity certificate, a hypothetical signature forgery attack would allow forging a signature over a delegated credential. The forged delegated credential could then be used by the attacker as the equivalent of an on-path attacker, valid for a maximum of 7 days (if the default valid_time is used).
経験は、実際には、この緩和の複雑さのためにサーバーの実装がこれらの攻撃を完全に停止できない可能性があることを示しています[ロボット]。（d）DC対応のエンドエンティティ証明書を使用してRSAキーエクスチェンジをサポートするTLS 1.2サーバーの場合、仮説的な署名偽造攻撃により、委任された資格を介して署名を鍛造できます。攻撃者は、攻撃者が最大7日間有効なオンパス攻撃者に相当するものとして使用できます（デフォルトのvalid_timeが使用されている場合）。
Server operators should therefore minimize the risk of using DC-enabled end-entity certificates where a signature forgery oracle may be present. If possible, server operators may choose to use DC-enabled certificates only for signing credentials and not for serving non-DC (D)TLS traffic. Furthermore, server operators may use elliptic curve certificates for DC-enabled traffic, while using RSA certificates without the DelegationUsage certificate extension for non-DC traffic; this completely prevents such attacks.
したがって、サーバーオペレーターは、Signature Forgery Oracleが存在する可能性のあるDC対応エンドエンティティ証明書を使用するリスクを最小限に抑える必要があります。可能であれば、サーバーオペレーターは、非DC（D）TLSトラフィックを提供するためではなく、資格情報に署名するためにのみDC対応証明書を使用することを選択できます。さらに、サーバーオペレーターは、DC対応トラフィックにDC対応トラフィックに楕円曲線証明書を使用し、非DCトラフィックに委任証明書延長なしでRSA証明書を使用する場合があります。これにより、そのような攻撃が完全に防止されます。
Note that if a signature can be forged over an arbitrary credential, the attacker can choose any value for the valid_time field. Repeated signature forgeries therefore allow the attacker to create multiple delegated credentials that can cover the entire validity period of the certificate. Temporary exposure of the key or a signing oracle may allow the attacker to impersonate a server for the lifetime of the certificate.
署名を任意の資格情報に介して偽造できる場合、攻撃者はvalid_timeフィールドの任意の価値を選択できることに注意してください。したがって、繰り返される署名の偽造により、攻撃者は、証明書の有効期間全体をカバーできる複数の委任された資格情報を作成することができます。キーまたは署名のオラクルの一時的な露出により、攻撃者は証明書の寿命のためにサーバーになりすませることができます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[X.680] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ISO/
IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>.
[X.690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.690>.
[BLEI] Bleichenbacher, D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS #1",
Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462,
pages: 1-12, 1998,
<https://link.springer.com/chapter/10.1007/BFb0055716>.
[KEYLESS] Stebila, D. and N. Sullivan, "An Analysis of TLS Handshake
Proxying", IEEE Trustcom/BigDataSE/ISPA 2015, 2015,
<https://ieeexplore.ieee.org/document/7345293>.
[RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M.
Thompson, "Internet X.509 Public Key Infrastructure (PKI)
Proxy Certificate Profile", RFC 3820,
DOI 10.17487/RFC3820, June 2004,
<https://www.rfc-editor.org/info/rfc3820>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[ROBOT] Boeck, H., Somorovsky, J., and C. Young, "Return Of
Bleichenbacher's Oracle Threat (ROBOT)", 27th USENIX
Security Symposium, 2018,
<https://www.usenix.org/conference/usenixsecurity18/
presentation/bock>.
[XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the
Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1
v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC
Conference on Computer and Communications Security, 2015,
<https://dl.acm.org/doi/10.1145/2810103.2813657>.
The following ASN.1 module provides the complete definition of the DelegationUsage certificate extension. The ASN.1 module makes imports from [RFC5912].
次のASN.1モジュールは、委任証明書延長の完全な定義を提供します。ASN.1モジュールは[RFC5912]からインポートを行います。
DelegatedCredentialExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-delegated-credential-extn(95) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORT ALL
IMPORTS
EXTENSION
FROM PKIX-CommonTypes-2009 -- From RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ;
-- OID
id-cloudflare OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) private(4)
enterprise(1) 44363 }
-- EXTENSION
ext-delegationUsage EXTENSION ::=
{ SYNTAX DelegationUsage
IDENTIFIED BY id-pe-delegationUsage }
id-pe-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 }
DelegationUsage ::= NULL
END
The following is an example of a delegation certificate that satisfies the requirements described in Section 4.2 (i.e., uses the DelegationUsage extension and has the digitalSignature KeyUsage).
以下は、セクション4.2で説明されている要件を満たす委任証明書の例です（つまり、委任拡張機能を使用し、DigitalSignature KeyUSAGEがあります）。
-----BEGIN CERTIFICATE-----
MIIFRjCCBMugAwIBAgIQDGevB+lY0o/OecHFSJ6YnTAKBggqhkjOPQQDAzBMMQsw
CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp
Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xOTAzMjYwMDAwMDBaFw0yMTAz
MzAxMjAwMDBaMGoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYw
FAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJbmMu
MRMwEQYDVQQDEwprYzJrZG0uY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
d4azI83Bw0fcPgfoeiZpZZnwGuxjBjv++wzE0zAj8vNiUkKxOWSQiGNLn+xlWUpL
lw9djRN1rLmVmn2gb9GgdKOCA28wggNrMB8GA1UdIwQYMBaAFKOd5h/52jlPwG7o
kcuVpdox4gqfMB0GA1UdDgQWBBSfcb7fS3fUFAyB91fRcwoDPtgtJjAjBgNVHREE
HDAaggprYzJrZG0uY29tggwqLmtjMmtkbS5jb20wDgYDVR0PAQH/BAQDAgeAMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBpBgNVHR8EYjBgMC6gLKAqhiho
dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMC6gLKAqhiho
dHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMEwGA1UdIARF
MEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2lj
ZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMHsGCCsGAQUFBwEBBG8wbTAkBggrBgEFBQcw
AYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEUGCCsGAQUFBzAChjlodHRwOi8v
Y2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRFQ0NTZWN1cmVTZXJ2ZXJDQS5j
cnQwDAYDVR0TAQH/BAIwADAPBgkrBgEEAYLaSywEAgUAMIIBfgYKKwYBBAHWeQIE
AgSCAW4EggFqAWgAdgC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAA
AWm5hYJ5AAAEAwBHMEUCICiGfq+hSThRL2m8H0awoDR8OpnEHNkF0nI6nL5yYL/j
AiEAxwebGs/T6Es0YarPzoQJrVZqk+sHH/t+jrSrKd5TDjcAdgCHdb/nWXz4jEOZ
X73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAWm5hYNgAAAEAwBHMEUCIQD9OWA8KGL6
bxDKfgIleHJWB0iWieRs88VgJyfAg/aFDgIgQ/OsdSF9XOy1foqge0DTDM2FExuw
0JR0AGZWXoNtJzMAdgBElGUusO7Or8RAB9io/ijA2uaCvtjLMbU/0zOWtbaBqAAA
AWm5hYHgAAAEAwBHMEUCIQC4vua1n3BqthEqpA/VBTcsNwMtAwpCuac2IhJ9wx6X
/AIgb+o00k28JQo9TMpP4vzJ3BD3HXWSNc2Zizbq7mkUQYMwCgYIKoZIzj0EAwMD
aQAwZgIxAJsX7d0SuA8ddf/m7IWfNfs3MQfJyGkEezMJX1t6sRso5z50SS12LpXe
muGa1FE2ZgIxAL+CDUF5pz7mhrAEIjQ1MqlpF9tH40dJGvYZZQ3W23cMzSkDfvlt
y5S4RfWHIIPjbw==
-----END CERTIFICATE-----
Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh Ramachandran, Benjamin Kaduk, 奥 一穂 (Kazuho Oku), Daniel Kahn Gillmor, Watson Ladd, Robert Merget, Juraj Somorovsky, and Nimrod Aviram for their discussions, ideas, and bugs they have found.
デビッド・ベンジャミン、クリストファー・パットン、カイル・ネクリッツ、アニルド・ラマチャンドラン、ベンジャミン・カドゥク、奥（カズホ・オク）、ダニエル・カーン・ギルモール、ワトソン・ラッド、ロバート・メルゲット、ジュラジ・ソモロフスキー、ニムロッド・アビラムのおかげで見つかった。
Richard Barnes
Cisco
Email: rlb@ipv.sx
Subodh Iyengar
Facebook
Email: subodh@fb.com
Nick Sullivan
Cloudflare
Email: nick@cloudflare.com
Eric Rescorla
Windy Hill Systems, LLC
Email: ekr@rtfm.com