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
                                                              T. Kivinen
                                                           INSIDE Secure
                                                               June 2014

Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)




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.


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


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 ( 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トラストの法的規定(の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、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
1. Introduction
1. はじめに

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.


Alternative methods are available that allow a TLS client/server to obtain the TLS server/client public key:


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.


2. Terminology
2. 用語

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.


3. Structure of the Raw Public Key Extension
3. 生の公開鍵拡張の構造

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.


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 {
            // 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


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


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].


   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. TLS Client and Server Handshake Behavior
4. TLSクライアントとサーバーのハンドシェイク動作

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.


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.


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


   Application Data        <------->     Application Data

Figure 5: Basic Raw Public Key TLS Exchange


4.1. Client Hello
4.1. こんにちは

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 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.


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.


4.2. Server Hello
4.2. サーバーこんにちは

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拡張では単一の値のみが許可されることに注意してください。

4.3. Client Authentication
4.3. クライアント認証

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.


4.4. Server Authentication
4.4. サーバー認証

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.


5. Examples
5. 例

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暗号スイートは、生の公開鍵で使用できますが、このドキュメントでは、そのレベルでの情報交換とその後のメッセージフローは示していません。

5.1. TLS Server Uses a Raw Public Key
5.1. 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).


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).


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.


  server_certificate_type=(RawPublicKey) // (1)
                         <- server_hello,
                            server_certificate_type=RawPublicKey, // (2)
                            certificate, // (3)

client_key_exchange, change_cipher_spec, finished ->


<- change_cipher_spec, finished


  Application Data       <-------> Application Data

Figure 6: Example with Raw Public Key Provided by the TLS Server


5.2. TLS Client and Server Use Raw Public Keys
5.2. 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_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)

certificate, // (6) client_key_exchange, change_cipher_spec, finished ->


<- change_cipher_spec, finished


Application Data        <------->     Application Data

Figure 7: Example with Raw Public Key provided by the TLS Server and the Client


5.3. Combined Usage of Raw Public Keys and X.509 Certificates
5.3. 生の公開鍵とX.509証明書の組み合わせ使用

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)で生の公開鍵を提供します。

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)
certificate, // (6)
finished                  ->

<- change_cipher_spec, finished


Application Data        <------->     Application Data

Figure 8: Hybrid Certificate Example


6. Security Considerations
6. セキュリティに関する考慮事項

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.


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がないと、攻撃者は完了メッセージを修復できないため、攻撃が発見されます。

7. IANA Considerations
7. IANAに関する考慮事項

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:


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証明書タイプ」サブレジストリから取得されます。

8. Acknowledgements
8. 謝辞

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氏のレビューコメントと提案に感謝します。

9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

[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", < tls-extensiontype-values>.

[TLS-Ext-Registry] IANA、「Transport Layer Security(TLS)Extensions」、< 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。

9.2. Informative References
9.2. 参考引用

[ASN.1-Dump] Gutmann, P., "ASN.1 Object Dump Program", February 2013, <>.

[ASN.1-Dump] Gutmann、P。、「ASN.1 Object Dump Program」、2013年2月、<>。

[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, < presentations/bh-dc-09/Marlinspike/ BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf>.

[Defeating-SSL] Marlinspike、M。、「実際にSSLを無効にするための新しいトリック」、2009年2月、< 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月。

Appendix A. Example Encoding

For example, the hex sequence shown in Figure 9 describes a SubjectPublicKeyInfo structure inside the certificate payload.


          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


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


Authors' Addresses


Paul Wouters (editor) Red Hat

Paul Wouters(編集者)Red Hat


Hannes Tschofenig (editor) ARM Ltd. 6060 Hall in Tirol Austria

Hannes Tschofenig(編集者)ARM Ltd. 6060 Hall in Tirolオーストリア


John Gilmore Electronic Frontier Foundation PO Box 170608 San Francisco, California 94117 USA


   Phone: +1 415 221 6524

Samuel Weiler Parsons 7110 Samuel Morse Drive Columbia, Maryland 21046 US



Tero Kivinen INSIDE Secure Eerikinkatu 28 Helsinki FI-00180 FI

Tero Kivinen INSIDE Secure Eerikinkatu 28 Helsinki FI-00180 FI