1. Introduction (はじめに)

1. Introduction (はじめに)

従来、TLS クライアントとサーバーの公開鍵は、TLS ハンドシェイク手順の一部として帯域内で PKIX コンテナで取得され、[PKIX] 認証局 (CA) に基づくトラストアンカー (trust anchors) を使用して検証されます。この方法は、検証が困難な複雑な信頼関係を追加する可能性があります。このような複雑さの例は、[Defeating-SSL] で見ることができます。ただし、TLS は、自己署名証明書 (self-signed certificates) がすべての関係するプロトコルエンドポイントに帯域外で配布される小規模な展開で、自己署名証明書とともに一般的に使用されています。ただし、この慣行では、証明書に含まれる情報が実際には使用されていないにもかかわらず、証明書生成のオーバーヘッドが依然として必要です。

TLS クライアント/サーバーが TLS サーバー/クライアントの公開鍵を取得できるようにする代替方法があります。

• TLS クライアントは、DNS ベースの命名エンティティ認証 (DANE) [RFC6698] を使用して、DNSSEC で保護されたリソースレコードから TLS サーバーの公開鍵を取得できます。

• TLS クライアントまたはサーバーの公開鍵は、ライトウェイトディレクトリアクセスプロトコル [LDAP] サーバーまたは Web ページからの [PKIX] 証明書チェーンから取得されます。

• TLS クライアントとサーバーの公開鍵は、オペレーティングシステムのファームウェアイメージにプロビジョニングされ、ソフトウェア更新によって更新されます。例えば：

  一部のスマートオブジェクト (smart objects) は、UDP ベースの制約付きアプリケーションプロトコル [CoAP] を使用して Web サーバーと対話し、温度の読み取り値などのセンサーデータを定期的にアップロードします。CoAP は、クライアントからサーバーへの通信を保護するために DTLS を利用できます。製造プロセスの一環として、組み込みデバイスは、専用 CoAP サーバーのアドレスと公開鍵、およびクライアント自体の公開鍵と秘密鍵のペアで構成される場合があります。

このドキュメントでは、TLS/DTLS での生の公開鍵 (raw public keys) の使用について説明します。生の公開鍵を使用すると、一般的な証明書にある情報のサブセットのみが利用されます。つまり、公開鍵を記述するために必要なパラメータを運ぶ PKIX 証明書の SubjectPublicKeyInfo 構造体です。PKIX 証明書にあるその他のパラメータは省略されます。さまざまな証明書関連の構造を省略することにより、結果として得られる生の公開鍵は元の証明書に比べてかなり小さく保たれ、鍵を処理するコードはより単純になります。最小限の ASN.1 パーサーのみが必要です。証明書パス検証やその他の PKIX 関連の処理のためのコードは必要ありません。ただし、SubjectPublicKeyInfo 構造体は依然として ASN.1 形式であることに注意してください。交換される情報のサイズをさらに削減するために、この仕様は TLS Cached Info 拡張 [CACHED-INFO] と組み合わせることができます。これにより、TLS ピアは公開鍵のフィンガープリントのみを交換できます。

ここで定義されるメカニズムは、公開鍵を鍵を提示するエンティティにバインドするために帯域外メカニズムも使用される場合にのみ認証を提供します。

Section 3 は、生の公開鍵が使用される場合に拡張 TLS ハンドシェイクの一部として使用できる2つの新しい TLS 拡張 client_certificate_type および server_certificate_type の構造を定義します。Section 4 は、TLS クライアントと TLS サーバーの動作を定義します。交換例は Section 5 で説明されています。Section 6 は、このアプローチに関するセキュリティの考慮事項を説明します。最後に、Section 7 で、このドキュメントは生の公開鍵をサポートするために IANA "TLS Certificate Types" (TLS 証明書タイプ) サブレジストリに新しい値を登録します。