[要約] RFC 7250は、Transport Layer Security (TLS) および Datagram Transport Layer Security (DTLS) において、証明書の代わりに生の公開鍵（Raw Public Keys, RPKs）を使用する方法について定義しています。この文書の目的は、TLS/DTLSの認証プロセスを簡素化し、証明書基盤（PKI）に依存しない軽量な認証オプションを提供することです。利用場面としては、リソースが限られている環境や、証明書の管理が困難または不要な場合に適しています。関連するRFCには、RFC 5246（TLSのバージョン1.2の定義）、RFC 6347（DTLS 1.2の定義）などがあります。RFC 7250は、セキュリティと柔軟性のバランスを取りながら、TLS/DTLSの適用範囲を広げることを目指しています。
Internet Engineering Task Force (IETF) P. Wouters, Ed.
Request for Comments: 7250 Red Hat
Category: Standards Track H. Tschofenig, Ed.
ISSN: 2070-1721 ARM Ltd.
J. Gilmore
Electronic Frontier Foundation
S. Weiler
Parsons
T. Kivinen
INSIDE Secure
June 2014
Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）での生の公開鍵の使用
Abstract
概要
This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.
このドキュメントでは、トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）で未加工の公開鍵を交換するための新しい証明書タイプと2つのTLS拡張を指定します。新しい証明書タイプでは、生の公開鍵を認証に使用できます。
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/rfc7250.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7250で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Structure of the Raw Public Key Extension . . . . . . . . . . 4
4. TLS Client and Server Handshake Behavior . . . . . . . . . . 7
4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Client Authentication . . . . . . . . . . . . . . . . . . 9
4.4. Server Authentication . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. TLS Server Uses a Raw Public Key . . . . . . . . . . . . 10
5.2. TLS Client and Server Use Raw Public Keys . . . . . . . . 11
5.3. Combined Usage of Raw Public Keys and X.509 Certificates 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Example Encoding . . . . . . . . . . . . . . . . . . 17
Traditionally, TLS client and server public keys are obtained in PKIX containers in-band as part of the TLS handshake procedure and are validated using trust anchors based on a [PKIX] certification authority (CA). This method can add a complicated trust relationship that is difficult to validate. Examples of such complexity can be seen in [Defeating-SSL]. TLS is, however, also commonly used with self-signed certificates in smaller deployments where the self-signed certificates are distributed to all involved protocol endpoints out-of-band. This practice does, however, still require the overhead of the certificate generation even though none of the information found in the certificate is actually used.
従来、TLSクライアントとサーバーの公開鍵は、TLSハンドシェイク手順の一部としてインバンドのPKIXコンテナーで取得され、[PKIX]証明機関（CA）に基づくトラストアンカーを使用して検証されます。この方法では、検証が難しい複雑な信頼関係が追加される可能性があります。そのような複雑さの例は、[Defeating-SSL]で見ることができます。ただし、TLSは、自己署名証明書が関係するすべてのプロトコルエンドポイントの帯域外に配布される小規模な展開で、自己署名証明書と共に一般的に使用されます。ただし、この方法では、証明書で見つかった情報が実際に使用されていない場合でも、証明書生成のオーバーヘッドが依然として必要です。
Alternative methods are available that allow a TLS client/server to obtain the TLS server/client public key:
TLSクライアント/サーバーがTLSサーバー/クライアント公開鍵を取得できるようにする代替方法が利用可能です。
o The TLS client can obtain the TLS server public key from a DNSSEC-secured resource record using DNS-Based Authentication of Named Entities (DANE) [RFC6698].
o TLSクライアントは、名前付きエンティティのDNSベースの認証（DANE）[RFC6698]を使用して、DNSSECで保護されたリソースレコードからTLSサーバーの公開キーを取得できます。
o The TLS client or server public key is obtained from a [PKIX] certificate chain from a Lightweight Directory Access Protocol [LDAP] server or web page.
o TLSクライアントまたはサーバーの公開鍵は、ライトウェイトディレクトリアクセスプロトコル[LDAP]サーバーまたはWebページの[PKIX]証明書チェーンから取得されます。
o The TLS client and server public key is provisioned into the operating system firmware image and updated via software updates. For example:
o TLSクライアントとサーバーの公開鍵は、オペレーティングシステムのファームウェアイメージにプロビジョニングされ、ソフトウェアの更新によって更新されます。例えば：
Some smart objects use the UDP-based Constrained Application Protocol [CoAP] to interact with a Web server to upload sensor data at regular intervals, such as temperature readings. CoAP can utilize DTLS for securing the client-to-server communication. As part of the manufacturing process, the embedded device may be configured with the address and the public key of a dedicated CoAP server, as well as a public/private key pair for the client itself.
一部のスマートオブジェクトは、UDPベースのConstrained Application Protocol [CoAP]を使用してWebサーバーとやり取りし、温度測定値などの定期的な間隔でセンサーデータをアップロードします。 CoAPは、クライアントからサーバーへの通信を保護するためにDTLSを利用できます。製造プロセスの一部として、組み込みデバイスは、専用CoAPサーバーのアドレスと公開鍵、およびクライアント自体の公開/秘密鍵ペアで構成できます。
This document introduces the use of raw public keys in TLS/DTLS. With raw public keys, only a subset of the information found in typical certificates is utilized: namely, the SubjectPublicKeyInfo structure of a PKIX certificate that carries the parameters necessary to describe the public key. Other parameters found in PKIX certificates are omitted. By omitting various certificate-related structures, the resulting raw public key is kept fairly small in comparison to the original certificate, and the code to process the keys can be simpler. Only a minimalistic ASN.1 parser is needed; code for certificate path validation and other PKIX-related processing is not required. Note, however, the SubjectPublicKeyInfo structure is still in an ASN.1 format. To further reduce the size of the exchanged information, this specification can be combined with the TLS Cached Info extension [CACHED-INFO], which enables TLS peers to exchange just fingerprints of their public keys.
このドキュメントでは、TLS / DTLSでの生の公開鍵の使用について紹介します。生の公開鍵では、一般的な証明書で見つかった情報のサブセットのみが使用されます。つまり、公開鍵の記述に必要なパラメーターを運ぶPKIX証明書のSubjectPublicKeyInfo構造です。 PKIX証明書にあるその他のパラメーターは省略されます。証明書に関連するさまざまな構造を省略することにより、結果の生の公開鍵は元の証明書と比較してかなり小さく保たれ、鍵を処理するためのコードがより簡単になります。最小限のASN.1パーサーのみが必要です。証明書パス検証およびその他のPKIX関連処理のコードは不要です。ただし、SubjectPublicKeyInfo構造はASN.1形式のままです。交換される情報のサイズをさらに削減するために、この仕様をTLSキャッシュ情報拡張[CACHED-INFO]と組み合わせることができます。これにより、TLSピアは公開鍵のフィンガープリントのみを交換できます。
The mechanism defined herein only provides authentication when an out-of-band mechanism is also used to bind the public key to the entity presenting the key.
ここで定義されているメカニズムは、アウトオブバンドメカニズムが公開キーをキーを提示するエンティティにバインドするためにも使用される場合にのみ認証を提供します。
Section 3 defines the structure of the two new TLS extensions, client_certificate_type and server_certificate_type, which can be used as part of an extended TLS handshake when raw public keys are to be used. Section 4 defines the behavior of the TLS client and the TLS server. Example exchanges are described in Section 5. Section 6 describes security considerations with this approach. Finally, in Section 7 this document registers a new value to the IANA "TLS Certificate Types" subregistry for the support of raw public keys.
セクション3では、2つの新しいTLS拡張であるclient_certificate_typeとserver_certificate_typeの構造を定義します。これらは、生の公開鍵を使用する場合に拡張TLSハンドシェイクの一部として使用できます。セクション4では、TLSクライアントとTLSサーバーの動作を定義します。交換の例については、セクション5で説明します。セクション6では、このアプローチのセキュリティに関する考慮事項について説明します。最後に、セクション7で、このドキュメントは、未加工の公開鍵をサポートするために、IANAの「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]で説明されているように解釈されます。
We use the terms "TLS server" and "server" as well as "TLS client" and "client" interchangeably.
「TLSサーバー」と「サーバー」、および「TLSクライアント」と「クライアント」という用語は同じ意味で使用されます。
This section defines the two TLS extensions client_certificate_type and server_certificate_type, which can be used as part of an extended TLS handshake when raw public keys are used. Section 4 defines the behavior of the TLS client and the TLS server using these extensions.
このセクションでは、2つのTLS拡張client_certificate_typeとserver_certificate_typeを定義します。これらは、生の公開鍵が使用されるときに拡張TLSハンドシェイクの一部として使用できます。セクション4では、これらの拡張機能を使用したTLSクライアントとTLSサーバーの動作を定義します。
This specification uses raw public keys whereby the already available encoding used in a PKIX certificate in the form of a SubjectPublicKeyInfo structure is reused. To carry the raw public key within the TLS handshake, the Certificate payload is used as a container, as shown in Figure 1. The shown Certificate structure is an adaptation of its original form [RFC5246].
この仕様では、生の公開鍵を使用します。これにより、PKIX証明書でSubjectPublicKeyInfo構造体の形式で使用されているすでに利用可能なエンコーディングが再利用されます。 TLSハンドシェイク内で生の公開鍵を運ぶために、図1に示すように、証明書ペイロードがコンテナとして使用されます。示されている証明書の構造は、元の形式[RFC5246]の適応です。
opaque ASN.1Cert<1..2^24-1>;
struct {
select(certificate_type){
// certificate type defined in this document.
case RawPublicKey:
opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;
// X.509 certificate defined in RFC 5246
case X.509:
ASN.1Cert certificate_list<0..2^24-1>;
// Additional certificate type based on
// "TLS Certificate Types" subregistry
};
} Certificate;
Figure 1: Certificate Payload as a Container for the Raw Public Key
図1：生の公開鍵のコンテナとしての証明書ペイロード
The SubjectPublicKeyInfo structure is defined in Section 4.1 of RFC 5280 [PKIX] and not only contains the raw keys, such as the public exponent and the modulus of an RSA public key, but also an algorithm identifier. The algorithm identifier can also include parameters. The SubjectPublicKeyInfo value in the Certificate payload MUST contain the DER encoding [X.690] of the SubjectPublicKeyInfo. The structure, as shown in Figure 2, therefore also contains length information. An example is provided in Appendix A.
SubjectPublicKeyInfo構造はRFC 5280 [PKIX]のセクション4.1で定義されており、公開指数やRSA公開鍵の係数などの生の鍵だけでなく、アルゴリズム識別子も含まれています。アルゴリズム識別子にはパラメータを含めることもできます。証明書ペイロードのSubjectPublicKeyInfo値には、SubjectPublicKeyInfoのDERエンコード[X.690]が含まれている必要があります。したがって、図2に示す構造には、長さ情報も含まれています。例を付録Aに示します。
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
Figure 2: SubjectPublicKeyInfo ASN.1 Structure
図2：SubjectPublicKeyInfo ASN.1の構造
The algorithm identifiers are Object Identifiers (OIDs). RFC 3279 [RFC3279] and RFC 5480 [RFC5480], for example, define the OIDs shown in Figure 3. Note that this list is not exhaustive, and more OIDs may be defined in future RFCs.
アルゴリズム識別子はオブジェクト識別子（OID）です。たとえば、RFC 3279 [RFC3279]とRFC 5480 [RFC5480]は、図3に示すOIDを定義しています。このリストは完全なものではなく、将来のRFCでさらに多くのOIDが定義される可能性があることに注意してください。
Key Type | Document | OID
--------------------+----------------------------+-------------------
RSA | Section 2.3.1 of RFC 3279 | 1.2.840.113549.1.1
....................|............................|...................
Digital Signature | |
Algorithm (DSA) | Section 2.3.2 of RFC 3279 | 1.2.840.10040.4.1
....................|............................|...................
Elliptic Curve | |
Digital Signature | |
Algorithm (ECDSA) | Section 2 of RFC 5480 | 1.2.840.10045.2.1
--------------------+----------------------------+-------------------
Figure 3: Example Algorithm Object Identifiers
図3：アルゴリズムオブジェクト識別子の例
The extension format for extended client and server hellos, which uses the "extension_data" field, is used to carry the ClientCertTypeExtension and the ServerCertTypeExtension structures. These two structures are shown in Figure 4. The CertificateType structure is an enum with values taken from the "TLS Certificate Types" subregistry of the "Transport Layer Security (TLS) Extensions" registry [TLS-Ext-Registry].
「extension_data」フィールドを使用する拡張クライアントとサーバーのhelloの拡張形式は、ClientCertTypeExtensionおよびServerCertTypeExtension構造を運ぶために使用されます。これら2つの構造を図4に示します。CertificateType構造は、「トランスポート層セキュリティ（TLS）拡張」レジストリ[TLS-Ext-Registry]の「TLS証明書タイプ」サブレジストリから取得した値を持つ列挙型です。
struct {
select(ClientOrServerExtension) {
case client:
CertificateType client_certificate_types<1..2^8-1>;
case server:
CertificateType client_certificate_type;
}
} ClientCertTypeExtension;
struct {
select(ClientOrServerExtension) {
case client:
CertificateType server_certificate_types<1..2^8-1>;
case server:
CertificateType server_certificate_type;
}
} ServerCertTypeExtension;
Figure 4: CertTypeExtension Structure
図4：CertTypeExtension構造
This specification extends the ClientHello and the ServerHello messages, according to the extension procedures defined in [RFC5246]. It does not extend or modify any other TLS message.
この仕様は、[RFC5246]で定義されている拡張手順に従って、ClientHelloおよびServerHelloメッセージを拡張します。他のTLSメッセージを拡張または変更することはありません。
Note: No new cipher suites are required to use raw public keys. All existing cipher suites that support a key exchange method compatible with the defined extension can be used.
注：生の公開鍵を使用するために新しい暗号スイートは必要ありません。定義された拡張と互換性のある鍵交換方式をサポートする既存のすべての暗号スイートを使用できます。
The high-level message exchange in Figure 5 shows the client_certificate_type and server_certificate_type extensions added to the client and server hello messages.
図5の高レベルのメッセージ交換は、クライアントとサーバーのhelloメッセージに追加されたclient_certificate_typeおよびserver_certificate_type拡張を示しています。
client_hello, client_certificate_type, server_certificate_type ->
client_hello、client_certificate_type、server_certificate_type->
<- server_hello, client_certificate_type, server_certificate_type, certificate, server_key_exchange, certificate_request, server_hello_done certificate, client_key_exchange, certificate_verify, change_cipher_spec, finished ->
<-server_hello、client_certificate_type、server_certificate_type、certificate、server_key_exchange、certificate_request、server_hello_done certificate、client_key_exchange、certificate_verify、change_cipher_spec、finished->
<- change_cipher_spec, finished
<-change_cipher_spec、終了
Application Data <-------> Application Data
Figure 5: Basic Raw Public Key TLS Exchange
図5：基本的な未加工の公開鍵TLS交換
In order to indicate the support of raw public keys, clients include the client_certificate_type and/or the server_certificate_type extensions in an extended client hello message. The hello extension mechanism is described in Section 7.4.1.4 of TLS 1.2 [RFC5246].
生の公開鍵のサポートを示すために、クライアントは拡張されたクライアントハローメッセージにclient_certificate_typeまたはserver_certificate_type拡張を含める。 hello拡張メカニズムは、TLS 1.2 [RFC5246]のセクション7.4.1.4で説明されています。
The client_certificate_type extension in the client hello indicates the certificate types the client is able to provide to the server, when requested using a certificate_request message.
client helloのclient_certificate_type拡張は、certificate_requestメッセージを使用して要求されたときに、クライアントがサーバーに提供できる証明書タイプを示します。
The server_certificate_type extension in the client hello indicates the types of certificates the client is able to process when provided by the server in a subsequent certificate payload.
client helloのserver_certificate_type拡張は、後続の証明書ペイロードでサーバーから提供されたときにクライアントが処理できる証明書のタイプを示します。
The client_certificate_type and server_certificate_type extensions sent in the client hello each carry a list of supported certificate types, sorted by client preference. When the client supports only one certificate type, it is a list containing a single element.
client helloで送信されたclient_certificate_typeおよびserver_certificate_type拡張には、サポートされている証明書タイプのリストがあり、クライアントの設定でソートされています。クライアントが1つの証明書タイプのみをサポートする場合、それは単一の要素を含むリストです。
The TLS client MUST omit certificate types from the client_certificate_type extension in the client hello if it does not possess the corresponding raw public key or certificate that it can provide to the server when requested using a certificate_request message, or if it is not configured to use one with the given TLS server. If the client has no remaining certificate types to send in the client hello, other than the default X.509 type, it MUST omit the client_certificate_type extension in the client hello.
TLSクライアントは、certificate_requestメッセージを使用して要求されたときにサーバーに提供できる対応する生の公開鍵または証明書を所有していない場合、または証明書を使用するように構成されていない場合、クライアントのhelloのclient_certificate_type拡張から証明書タイプを省略しなければなりません（MUST）。指定されたTLSサーバーで。デフォルトのX.509タイプ以外に、クライアントがクライアントハローで送信する証明書タイプが残っていない場合は、クライアントハローでclient_certificate_type拡張を省略しなければなりません（MUST）。
The TLS client MUST omit certificate types from the server_certificate_type extension in the client hello if it is unable to process the corresponding raw public key or other certificate type. If the client has no remaining certificate types to send in the client hello, other than the default X.509 certificate type, it MUST omit the entire server_certificate_type extension from the client hello.
TLSクライアントは、対応する生の公開鍵または他の証明書タイプを処理できない場合、クライアントhelloのserver_certificate_type拡張から証明書タイプを省略しなければなりません（MUST）。デフォルトのX.509証明書タイプ以外に、クライアントがクライアントhelloで送信する証明書タイプが残っていない場合、クライアントhelloからserver_certificate_type拡張全体を省略しなければなりません（MUST）。
If the server receives a client hello that contains the client_certificate_type extension and/or the server_certificate_type extension, then three outcomes are possible:
サーバーがclient_certificate_type拡張機能またはserver_certificate_type拡張機能、あるいはその両方を含むclient helloを受信した場合、3つの結果が考えられます。
1. The server does not support the extension defined in this document. In this case, the server returns the server hello without the extensions defined in this document.
1. サーバーは、このドキュメントで定義されている拡張機能をサポートしていません。この場合、サーバーはこのドキュメントで定義されている拡張子なしでサーバーhelloを返します。
2. The server supports the extension defined in this document, but it does not have any certificate type in common with the client. Then, the server terminates the session with a fatal alert of type "unsupported_certificate".
2. サーバーはこのドキュメントで定義されている拡張機能をサポートしていますが、クライアントと共通の証明書タイプはありません。次に、サーバーは「unsupported_certificate」タイプの致命的なアラートでセッションを終了します。
3. The server supports the extensions defined in this document and has at least one certificate type in common with the client. In this case, the processing rules described below are followed.
3. サーバーは、このドキュメントで定義されている拡張機能をサポートし、クライアントと共通の証明書タイプを少なくとも1つ持っています。この場合、以下に説明する処理ルールに従います。
The client_certificate_type extension in the client hello indicates the certificate types the client is able to provide to the server, when requested using a certificate_request message. If the TLS server wants to request a certificate from the client (via the certificate_request message), it MUST include the client_certificate_type extension in the server hello. This client_certificate_type extension in the server hello then indicates the type of certificates the client is requested to provide in a subsequent certificate payload. The value conveyed in the client_certificate_type extension MUST be selected from one of the values provided in the client_certificate_type extension sent in the client hello. The server MUST also include a certificate_request payload in the server hello message.
client helloのclient_certificate_type拡張は、certificate_requestメッセージを使用して要求されたときに、クライアントがサーバーに提供できる証明書タイプを示します。 TLSサーバーが（certificate_requestメッセージを介して）クライアントに証明書を要求する場合、サーバーのhelloにclient_certificate_type拡張を含める必要があります。サーバーhelloのこのclient_certificate_type拡張は、クライアントが後続の証明書ペイロードで提供するように要求された証明書のタイプを示します。 client_certificate_type拡張機能で伝達される値は、client helloで送信されるclient_certificate_type拡張機能で提供される値の1つから選択する必要があります。サーバーは、サーバーのhelloメッセージにcertificate_requestペイロードも含める必要があります。
If the server does not send a certificate_request payload (for example, because client authentication happens at the application layer or no client authentication is required) or none of the certificates supported by the client (as indicated in the client_certificate_type extension in the client hello) match the server-supported certificate types, then the client_certificate_type payload in the server hello MUST be omitted.
サーバーがcertificate_requestペイロードを送信しない場合（たとえば、クライアント認証がアプリケーションレイヤーで発生するか、クライアント認証が不要であるため）、またはクライアントがサポートする証明書（client helloのclient_certificate_type拡張で示されている）が一致しない場合サーバーがサポートする証明書タイプ、サーバーhelloのclient_certificate_typeペイロードは省略しなければなりません。
The server_certificate_type extension in the client hello indicates the types of certificates the client is able to process when provided by the server in a subsequent certificate payload. If the client hello indicates support of raw public keys in the server_certificate_type extension and the server chooses to use raw public keys, then the TLS server MUST place the SubjectPublicKeyInfo structure into the Certificate payload. With the server_certificate_type extension in the server hello, the TLS server indicates the certificate type carried in the Certificate payload. This additional indication enables avoiding parsing ambiguities since the Certificate payload may contain either the X.509 certificate or a SubjectPublicKeyInfo structure. Note that only a single value is permitted in the server_certificate_type extension when carried in the server hello.
client helloのserver_certificate_type拡張は、後続の証明書ペイロードでサーバーから提供されたときにクライアントが処理できる証明書のタイプを示します。クライアントのhelloがserver_certificate_type拡張機能で未加工の公開鍵のサポートを示し、サーバーが未加工の公開鍵の使用を選択した場合、TLSサーバーはSubjectPublicKeyInfo構造を証明書ペイロードに配置する必要があります。 server helloにserver_certificate_type拡張を使用すると、TLSサーバーは証明書のペイロードで運ばれる証明書のタイプを示します。この追加の指示により、CertificateペイロードにX.509証明書またはSubjectPublicKeyInfo構造のいずれかが含まれる場合があるため、あいまいさの解析を回避できます。 server helloで運ばれる場合、server_certificate_type拡張では単一の値のみが許可されることに注意してください。
When the TLS server has specified RawPublicKey as the client_certificate_type, authentication of the TLS client to the TLS server is supported only through authentication of the received client SubjectPublicKeyInfo via an out-of-band method.
TLSサーバーがclient_certificate_typeとしてRawPublicKeyを指定している場合、TLSクライアントのTLSサーバーへの認証は、受信したクライアントSubjectPublicKeyInfoをアウトオブバンド方式で認証することによってのみサポートされます。
When the TLS server has specified RawPublicKey as the server_certificate_type, authentication of the TLS server to the TLS client is supported only through authentication of the received client SubjectPublicKeyInfo via an out-of-band method.
TLSサーバーがrawPublicKeyをserver_certificate_typeとして指定している場合、TLSクライアントのTLSサーバーの認証は、受信したクライアントSubjectPublicKeyInfoをアウトオブバンド方式で認証することによってのみサポートされます。
Figures 6, 7, and 8 illustrate example exchanges. Note that TLS ciphersuites using a Diffie-Hellman exchange offering forward secrecy can be used with a raw public key, although this document does not show the information exchange at that level with the subsequent message flows.
図6、7、および8は、交換の例を示しています。 Diffie-Hellman交換を提供するTLS暗号スイートは、生の公開鍵で使用できますが、このドキュメントでは、そのレベルでの情報交換とその後のメッセージフローは示していません。
This section shows an example where the TLS client indicates its ability to receive and validate a raw public key from the server. In this example, the client is quite restricted since it is unable to process other certificate types sent by the server. It also does not have credentials at the TLS layer it could send to the server and therefore omits the client_certificate_type extension. Hence, the client only populates the server_certificate_type extension with the raw public key type, as shown in (1).
このセクションでは、TLSクライアントがサーバーから生の公開鍵を受信して検証する機能を示す例を示します。この例では、サーバーから送信された他の種類の証明書を処理できないため、クライアントはかなり制限されています。また、サーバーに送信できるTLSレイヤーに資格情報がないため、client_certificate_type拡張が省略されます。したがって、（1）に示すように、クライアントはserver_certificate_type拡張に生の公開鍵タイプのみを入力します。
When the TLS server receives the client hello, it processes the extension. Since it has a raw public key, it indicates in (2) that it had chosen to place the SubjectPublicKeyInfo structure into the Certificate payload (3).
TLSサーバーは、クライアントのHelloを受信すると、拡張機能を処理します。生の公開鍵を持っているため、（2）でSubjectPublicKeyInfo構造を証明書ペイロードに配置することを選択したことを示しています（3）。
The client uses this raw public key in the TLS handshake together with an out-of-band validation technique, such as DANE, to verify it.
クライアントは、TLSハンドシェイクでこの未加工の公開鍵を、DANEなどの帯域外検証技術と一緒に使用して検証します。
client_hello,
server_certificate_type=(RawPublicKey) // (1)
->
<- server_hello,
server_certificate_type=RawPublicKey, // (2)
certificate, // (3)
server_key_exchange,
server_hello_done
client_key_exchange, change_cipher_spec, finished ->
client_key_exchange、change_cipher_spec、終了->
<- change_cipher_spec, finished
<-change_cipher_spec、終了
Application Data <-------> Application Data
Figure 6: Example with Raw Public Key Provided by the TLS Server
図6：TLSサーバーから提供された生の公開鍵の例
This section shows an example where the TLS client as well as the TLS server use raw public keys. This is one of the use cases envisioned for smart object networking. The TLS client in this case is an embedded device that is configured with a raw public key for use with TLS and is also able to process a raw public key sent by the server. Therefore, it indicates these capabilities in (1). As in the previously shown example, the server fulfills the client's request, indicates this via the RawPublicKey value in the server_certificate_type payload (2), and provides a raw public key in the Certificate payload back to the client (see (3)). The TLS server demands client authentication, and therefore includes a certificate_request (4). The client_certificate_type payload in (5) indicates that the TLS server accepts a raw public key. The TLS client, which has a raw public key pre-provisioned, returns it in the Certificate payload (6) to the server.
このセクションでは、TLSクライアントとTLSサーバーが生の公開鍵を使用する例を示します。これは、スマートオブジェクトネットワーキングで想定される使用例の1つです。この場合のTLSクライアントは、TLSで使用する未加工の公開鍵で構成され、サーバーから送信された未加工の公開鍵を処理することもできる組み込みデバイスです。したがって、（1）でこれらの機能を示します。前に示した例のように、サーバーはクライアントの要求を満たし、server_certificate_typeペイロードのRawPublicKey値を介してこれを示し（2）、Certificateペイロードの生の公開鍵をクライアントに返します（（3）を参照）。 TLSサーバーはクライアント認証を要求するため、certificate_request（4）が含まれています。 （5）のclient_certificate_typeペイロードは、TLSサーバーが未加工の公開鍵を受け入れることを示しています。事前にプロビジョニングされた生の公開鍵を持つTLSクライアントは、それを証明書ペイロード（6）でサーバーに返します。
client_hello,
client_certificate_type=(RawPublicKey) // (1)
server_certificate_type=(RawPublicKey) // (1)
->
<- server_hello,
server_certificate_type=RawPublicKey // (2)
certificate, // (3)
client_certificate_type=RawPublicKey // (5)
certificate_request, // (4)
server_key_exchange,
server_hello_done
certificate, // (6) client_key_exchange, change_cipher_spec, finished ->
証明書、//（6）client_key_exchange、change_cipher_spec、終了->
<- change_cipher_spec, finished
<-change_cipher_spec、終了
Application Data <-------> Application Data
Figure 7: Example with Raw Public Key provided by the TLS Server and the Client
図7：TLSサーバーとクライアントから提供された生の公開鍵の例
This section shows an example combining a raw public key and an X.509 certificate. The client uses a raw public key for client authentication, and the server provides an X.509 certificate. This exchange starts with the client indicating its ability to process an X.509 certificate, OpenPGP certificate, or a raw public key, if provided by the server. It prefers a raw public key, since the RawPublicKey value precedes the other values in the server_certificate_type vector. Additionally, the client indicates that it has a raw public key for client-side authentication (see (1)). The server chooses to provide its X.509 certificate in (3) and indicates that choice in (2). For client authentication, the server indicates in (4) that it has selected the raw public key format and requests a certificate from the client in (5). The TLS client provides a raw public key in (6) after receiving and processing the TLS server hello message.
このセクションでは、未加工の公開鍵とX.509証明書を組み合わせる例を示します。クライアントはクライアント認証に生の公開鍵を使用し、サーバーはX.509証明書を提供します。この交換は、X.509証明書、OpenPGP証明書、またはサーバーから提供された場合は生の公開鍵を処理する機能を示すクライアントから始まります。 RawPublicKey値はserver_certificate_typeベクトル内の他の値に先行するため、生の公開鍵を優先します。さらに、クライアントは、クライアント側認証用の生の公開鍵を持っていることを示します（（1）を参照）。サーバーは（3）でX.509証明書を提供することを選択し、（2）でその選択を示します。クライアント認証では、サーバーは（4）で生の公開鍵形式を選択したことを示し、（5）でクライアントに証明書を要求します。 TLSクライアントは、TLSサーバーのhelloメッセージを受信して処理した後、（6）で生の公開鍵を提供します。
client_hello,
server_certificate_type=(RawPublicKey, X.509, OpenPGP)
client_certificate_type=(RawPublicKey) // (1)
->
<- server_hello,
server_certificate_type=X.509 // (2)
certificate, // (3)
client_certificate_type=RawPublicKey // (4)
certificate_request, // (5)
server_key_exchange,
server_hello_done
certificate, // (6)
client_key_exchange,
change_cipher_spec,
finished ->
<- change_cipher_spec, finished
<-change_cipher_spec、終了
Application Data <-------> Application Data
Figure 8: Hybrid Certificate Example
図8：ハイブリッド証明書の例
The transmission of raw public keys, as described in this document, provides benefits by lowering the over-the-air transmission overhead since raw public keys are naturally smaller than an entire certificate. There are also advantages from a code-size point of view for parsing and processing these keys. The cryptographic procedures for associating the public key with the possession of a private key also follows standard procedures.
このドキュメントで説明されているように、未加工の公開鍵は証明書全体よりも小さいため、未加工の公開鍵を送信すると、無線送信のオーバーヘッドが少なくなるという利点があります。これらのキーを解析および処理するためのコードサイズの観点からの利点もあります。公開鍵を秘密鍵の所有と関連付けるための暗号化手順も、標準の手順に従います。
However, the main security challenge is how to associate the public key with a specific entity. Without a secure binding between identifier and key, the protocol will be vulnerable to man-in-the-middle attacks. This document assumes that such binding can be made out-of-band, and we list a few examples in Section 1. DANE [RFC6698] offers one such approach. In order to address these vulnerabilities, specifications that make use of the extension need to specify how the identifier and public key are bound. In addition to ensuring the binding is done out-of-band, an implementation also needs to check the status of that binding.
ただし、セキュリティ上の主な課題は、公開鍵を特定のエンティティに関連付ける方法です。識別子とキーの間に安全なバインディングがないと、プロトコルは中間者攻撃に対して脆弱になります。このドキュメントでは、このようなバインディングをアウトオブバンドで作成できることを前提としています。セクション1にいくつかの例を示します。DANE[RFC6698]は、そのようなアプローチの1つを提供しています。これらの脆弱性に対処するには、拡張機能を利用する仕様で、識別子と公開鍵のバインド方法を指定する必要があります。バインディングがアウトオブバンドで行われることを保証することに加えて、実装はそのバインディングのステータスをチェックする必要もあります。
If public keys are obtained using DANE, these public keys are authenticated via DNSSEC. Using pre-configured keys is another out-of-band method for authenticating raw public keys. While pre-configured keys are not suitable for a generic Web-based e-commerce environment, such keys are a reasonable approach for many smart object deployments where there is a close relationship between the software running on the device and the server-side communication endpoint. Regardless of the chosen mechanism for out-of-band public key validation, an assessment of the most suitable approach has to be made prior to the start of a deployment to ensure the security of the system.
DANEを使用して公開鍵を取得する場合、これらの公開鍵はDNSSECを介して認証されます。事前構成済みの鍵を使用することは、未加工の公開鍵を認証するためのもう1つの帯域外の方法です。事前構成されたキーは、一般的なWebベースのeコマース環境には適していませんが、デバイスで実行されているソフトウェアとサーバー側の通信エンドポイントとの間に密接な関係がある多くのスマートオブジェクト展開にとって、このようなキーは適切なアプローチです。 。アウトオブバンドの公開キー検証に選択したメカニズムに関係なく、システムのセキュリティを確保するために、展開を開始する前に、最も適切なアプローチの評価を行う必要があります。
An attacker might try to influence the handshake exchange to make the parties select different certificate types than they would normally choose.
攻撃者は、ハンドシェイク交換に影響を与え、当事者が通常選択するのとは異なる証明書タイプを選択させる可能性があります。
For this attack, an attacker must actively change one or more handshake messages. If this occurs, the client and server will compute different values for the handshake message hashes. As a result, the parties will not accept each others' Finished messages. Without the master_secret, the attacker cannot repair the Finished messages, so the attack will be discovered.
この攻撃では、攻撃者は1つ以上のハンドシェイクメッセージを積極的に変更する必要があります。これが発生した場合、クライアントとサーバーは、ハンドシェイクメッセージハッシュの異なる値を計算します。その結果、当事者はお互いの完了メッセージを受け入れません。 master_secretがないと、攻撃者は完了メッセージを修復できないため、攻撃が発見されます。
IANA has registered a new value in the "TLS Certificate Types" subregistry of the "Transport Layer Security (TLS) Extensions" registry [TLS-Ext-Registry], as follows:
IANAは、「トランスポート層セキュリティ（TLS）拡張」レジストリ[TLS-Ext-Registry]の「TLS証明書タイプ」サブレジストリに次のように新しい値を登録しました。
Value: 2 Description: Raw Public Key Reference: RFC 7250
値：2説明：未加工の公開鍵参照：RFC 7250
IANA has allocated two new TLS extensions, client_certificate_type and server_certificate_type, from the "TLS ExtensionType Values" subregistry defined in [RFC5246]. These extensions are used in both the client hello message and the server hello message. The new extension types are used for certificate type negotiation. The values carried in these extensions are taken from the "TLS Certificate Types" subregistry of the "Transport Layer Security (TLS) Extensions" registry [TLS-Ext-Registry].
IANAは、[RFC5246]で定義されている「TLS ExtensionType Values」サブレジストリから、2つの新しいTLS拡張client_certificate_typeおよびserver_certificate_typeを割り当てました。これらの拡張機能は、クライアントのhelloメッセージとサーバーのhelloメッセージの両方で使用されます。新しい拡張タイプは、証明書タイプのネゴシエーションに使用されます。これらの拡張に含まれる値は、「トランスポート層セキュリティ（TLS）拡張」レジストリ[TLS-Ext-Registry]の「TLS証明書タイプ」サブレジストリから取得されます。
The feedback from the TLS working group meeting at IETF 81 has substantially shaped the document, and we would like to thank the meeting participants for their input. The support for hashes of public keys has been moved to [CACHED-INFO] after the discussions at the IETF 82 meeting.
IETF 81でのTLSワーキンググループミーティングからのフィードバックは、ドキュメントを大幅に形作ったものであり、ミーティング参加者の意見に感謝します。 IETF 82ミーティングでの議論の後、公開鍵のハッシュのサポートは[CACHED-INFO]に移動しました。
We would like to thank the following persons for their review comments: Martin Rex, Bill Frantz, Zach Shelby, Carsten Bormann, Cullen Jennings, Rene Struik, Alper Yegin, Jim Schaad, Barry Leiba, Paul Hoffman, Robert Cragie, Nikos Mavrogiannopoulos, Phil Hunt, John Bradley, Klaus Hartke, Stefan Jucker, Kovatsch Matthias, Daniel Kahn Gillmor, Peter Sylvester, Hauke Mehrtens, Alexey Melnikov, Stephen Farrell, Richard Barnes, and James Manger. Nikos Mavrogiannopoulos contributed the design for reusing the certificate type registry. Barry Leiba contributed guidance for the IANA Considerations text. Stefan Jucker, Kovatsch Matthias, and Klaus Hartke provided implementation feedback regarding the SubjectPublicKeyInfo structure.
マーティンレックス、ビルフランツ、ザックシェルビー、カルステンボルマン、カレンジェニングス、ルネシュトルイク、アルパーイェギン、ジムシャード、バリーレイバ、ポールホフマン、ロバートクラギー、ニコスマブロジアンノプロス、フィルハント、ジョンブラッドリー、クラウスハートケ、ステファンジュッカー、コヴァッチマティアス、ダニエルカーンギルモア、ピーターシルヴェスター、ホークメアテンス、アレクセイメルニコフ、スティーブンファレル、リチャードバーンズ、ジェームズマンガー。 Nikos Mavrogiannopoulosは、証明書タイプレジストリを再利用するための設計に貢献しました。バリーレイバは、IANAの考慮事項に関するテキストのガイダンスを提供しました。 Stefan Jucker、Kovatsch Matthias、およびKlaus Hartkeは、SubjectPublicKeyInfo構造に関する実装フィードバックを提供しました。
Christer Holmberg provided the General Area (Gen-Art) review, Yaron Sheffer provided the Security Directorate (SecDir) review, Bert Greevenbosch provided the Applications Area Directorate review, and Linda Dunbar provided the Operations Directorate review.
Christer HolmbergはGeneral Area（Gen-Art）レビューを、Yaron ShefferはSecurity Directorate（SecDir）レビューを、Bert GreevenboschはApplications Area Directorateレビューを、Linda DunbarはOperations Directorateレビューを提供しました。
We would like to thank our TLS working group chairs, Eric Rescorla and Joe Salowey, for their guidance and support. Finally, we would like to thank Sean Turner, who is the responsible Security Area Director for this work, for his review comments and suggestions.
TLSワーキンググループの議長であるEric RescorlaとJoe Saloweyの指導と支援に感謝します。最後に、この作業のセキュリティエリアディレクターを務めるSean Turner氏のレビューコメントと提案に感謝します。
[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[PKIX] 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、2008年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279] Bassham、L.、Polk、W.、and R. Housley、 "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile"、RFC 3279、April 2002。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号サブジェクト公開鍵情報」、RFC 5480、2009年3月。
[TLS-Ext-Registry] IANA, "Transport Layer Security (TLS) Extensions", <http://www.iana.org/assignments/ tls-extensiontype-values>.
[TLS-Ext-Registry] IANA、「Transport Layer Security（TLS）Extensions」、<http://www.iana.org/assignments/ tls-extensiontype-values>。
[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)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2002, 2002.
[X.690] ITU-T、「情報技術-ASN.1エンコーディングルール：基本エンコーディングルール（BER）、正規エンコーディングルール（CER）およびDistinguished Encodingルール（DER）の仕様」、ITU-T勧告X.690 、ISO / IEC 8825-1：2002、2002。
[ASN.1-Dump] Gutmann, P., "ASN.1 Object Dump Program", February 2013, <http://www.cs.auckland.ac.nz/~pgut001/>.
[ASN.1-Dump] Gutmann、P。、「ASN.1 Object Dump Program」、2013年2月、<http://www.cs.auckland.ac.nz/~pgut001/>。
[CACHED-INFO] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", Work in Progress, February 2014.
[CACHED-INFO] Santesson、S。およびH. Tschofenig、「Transport Layer Security（TLS）Cached Information Extension」、Work in Progress、2014年2月。
[CoAP] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014.
[CoAP] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、2014年6月。
[Defeating-SSL] Marlinspike, M., "New Tricks for Defeating SSL in Practice", February 2009, <http://www.blackhat.com/ presentations/bh-dc-09/Marlinspike/ BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf>.
[Defeating-SSL] Marlinspike、M。、「実際にSSLを無効にするための新しいトリック」、2009年2月、<http://www.blackhat.com/ presentations / bh-dc-09 / Marlinspike / BlackHat-DC-09- Marlinspike-Defeating-SSL.pdf>。
[LDAP] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[LDAP] Sermersheim、J。、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、RFC 4511、2006年6月。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティの認証（DANE）トランスポート層セキュリティ（TLS）プロトコル：TLSA」、RFC 6698、2012年8月。
For example, the hex sequence shown in Figure 9 describes a SubjectPublicKeyInfo structure inside the certificate payload.
たとえば、図9に示す16進数シーケンスは、証明書ペイロード内のSubjectPublicKeyInfo構造を記述しています。
0 1 2 3 4 5 6 7 8 9
+------+-----+-----+-----+-----+-----+-----+-----+-----+-----
1 | 0x30, 0x81, 0x9f, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48,
2 | 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x01, 0x05, 0x00, 0x03, 0x81,
3 | 0x8d, 0x00, 0x30, 0x81, 0x89, 0x02, 0x81, 0x81, 0x00, 0xcd,
4 | 0xfd, 0x89, 0x48, 0xbe, 0x36, 0xb9, 0x95, 0x76, 0xd4, 0x13,
5 | 0x30, 0x0e, 0xbf, 0xb2, 0xed, 0x67, 0x0a, 0xc0, 0x16, 0x3f,
6 | 0x51, 0x09, 0x9d, 0x29, 0x2f, 0xb2, 0x6d, 0x3f, 0x3e, 0x6c,
7 | 0x2f, 0x90, 0x80, 0xa1, 0x71, 0xdf, 0xbe, 0x38, 0xc5, 0xcb,
8 | 0xa9, 0x9a, 0x40, 0x14, 0x90, 0x0a, 0xf9, 0xb7, 0x07, 0x0b,
9 | 0xe1, 0xda, 0xe7, 0x09, 0xbf, 0x0d, 0x57, 0x41, 0x86, 0x60,
10 | 0xa1, 0xc1, 0x27, 0x91, 0x5b, 0x0a, 0x98, 0x46, 0x1b, 0xf6,
11 | 0xa2, 0x84, 0xf8, 0x65, 0xc7, 0xce, 0x2d, 0x96, 0x17, 0xaa,
12 | 0x91, 0xf8, 0x61, 0x04, 0x50, 0x70, 0xeb, 0xb4, 0x43, 0xb7,
13 | 0xdc, 0x9a, 0xcc, 0x31, 0x01, 0x14, 0xd4, 0xcd, 0xcc, 0xc2,
14 | 0x37, 0x6d, 0x69, 0x82, 0xd6, 0xc6, 0xc4, 0xbe, 0xf2, 0x34,
15 | 0xa5, 0xc9, 0xa6, 0x19, 0x53, 0x32, 0x7a, 0x86, 0x0e, 0x91,
16 | 0x82, 0x0f, 0xa1, 0x42, 0x54, 0xaa, 0x01, 0x02, 0x03, 0x01,
17 | 0x00, 0x01
Figure 9: Example SubjectPublicKeyInfo Structure Byte Sequence
図9：SubjectPublicKeyInfo構造のバイトシーケンスの例
The decoded byte sequence shown in Figure 9 (for example, using Peter Gutmann's ASN.1 decoder [ASN.1-Dump]) illustrates the structure, as shown in Figure 10.
図9に示すデコードされたバイトシーケンス（たとえば、Peter GutmannのASN.1デコーダー[ASN.1-Dump]を使用）は、図10に示すような構造を示しています。
Offset Length Description
-------------------------------------------------------------------
0 3+159: SEQUENCE {
3 2+13: SEQUENCE {
5 2+9: OBJECT IDENTIFIER Value (1 2 840 113549 1 1 1)
: PKCS #1, rsaEncryption
16 2+0: NULL
: }
18 3+141: BIT STRING, encapsulates {
22 3+137: SEQUENCE {
25 3+129: INTEGER Value (1024 bit)
157 2+3: INTEGER Value (65537)
: }
: }
: }
Figure 10: Decoding of Example SubjectPublicKeyInfo Structure
図10：サンプルのSubjectPublicKeyInfo構造のデコード
Authors' Addresses
著者のアドレス
Paul Wouters (editor) Red Hat
Paul Wouters（編集者）Red Hat
EMail: pwouters@redhat.com
Hannes Tschofenig (editor) ARM Ltd. 6060 Hall in Tirol Austria
Hannes Tschofenig（編集者）ARM Ltd. 6060 Hall in Tirolオーストリア
EMail: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
John Gilmore Electronic Frontier Foundation PO Box 170608 San Francisco, California 94117 USA
ジョンギルモア電子フロンティア財団私書箱170608カリフォルニア州サンフランシスコ94117アメリカ
Phone: +1 415 221 6524
EMail: gnu@toad.com
URI: https://www.toad.com/
Samuel Weiler Parsons 7110 Samuel Morse Drive Columbia, Maryland 21046 US
サミュエルウェイラーパーソンズ7110サミュエルモースドライブコロンビア、メリーランド21046アメリカ
EMail: weiler@tislabs.com
Tero Kivinen INSIDE Secure Eerikinkatu 28 Helsinki FI-00180 FI
Tero Kivinen INSIDE Secure Eerikinkatu 28 Helsinki FI-00180 FI
EMail: kivinen@iki.fi