メインコンテンツまでスキップ

2. TLSAリソースレコード (The TLSA Resource Record)

TLSA DNSリソースレコード(RR)は、TLSサーバー証明書または公開鍵をレコードが見つかったドメイン名に関連付けるために使用され、「TLSA証明書関連付け」を形成します。TLSA RRの解釈方法のセマンティクスは、本文書の後半で説明します。

TLSA RRタイプのタイプ値は、セクション7.1で定義されています。

TLSA RRはクラス非依存です。

TLSA RRには特別な生存時間(TTL)要件はありません。

2.1. TLSA RDATAワイヤ形式 (TLSA RDATA Wire Format)​

TLSA RRのRDATAは、1オクテットの証明書用途フィールド、1オクテットのセレクタフィールド、1オクテットのマッチングタイプフィールド、および証明書関連付けデータフィールドで構成されます。

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  証明書用途   |   セレクタ    | マッチング種別|               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
/                                                               /
/                 証明書関連付けデータ                          /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.1. 証明書用途フィールド (The Certificate Usage Field)​

「証明書用途」と呼ばれる1オクテット値は、TLSハンドシェイクで提示された証明書と照合するために使用される提供された関連付けを指定します。この値は、将来追加の証明書用途を追加しやすくするために、新しいIANAレジストリ(セクション7.2を参照)で定義されています。本文書で定義されている証明書用途は次のとおりです。

0 -- CA制約: 証明書用途0は、CA証明書、またはそのような証明書の公開鍵を指定するために使用されます。これは、サーバーがTLSで提供するエンドエンティティ証明書のPKIX認証パスのいずれかに含まれている必要があります。この証明書用途は、ホスト上の特定のサービスに対して証明書を発行できるCAを制限するため、「CA制約」と呼ばれることがあります。提示された証明書はPKIX認証パス検証に合格する必要があり、TLSAレコードと一致するCA証明書は有効な認証パスの一部として含まれている必要があります。この証明書用途はトラストアンカーとCA証明書の両方を許可するため、証明書にはbasicConstraints拡張が存在する場合と存在しない場合があります。

1 -- サービス証明書制約: 証明書用途1は、エンドエンティティ証明書、またはそのような証明書の公開鍵を指定するために使用されます。これは、サーバーがTLSで提供するエンドエンティティ証明書と一致する必要があります。この証明書用途は、ホスト上の特定のサービスで使用できるエンドエンティティ証明書を制限するため、「サービス証明書制約」と呼ばれることがあります。ターゲット証明書はPKIX認証パス検証に合格する必要があり、TLSAレコードと一致する必要があります。

2 -- トラストアンカーアサーション: 証明書用途2は、証明書、またはそのような証明書の公開鍵を指定するために使用されます。これは、サーバーがTLSで提供するエンドエンティティ証明書を検証する際にトラストアンカーとして使用する必要があります。この証明書用途は「トラストアンカーアサーション」と呼ばれることがあり、ドメイン名管理者が新しいトラストアンカーを指定できるようにします。例えば、ドメインがエンドユーザーのトラストアンカーコレクションに含まれることが期待されていない独自のCAの下で独自の証明書を発行する場合などです。ターゲット証明書はPKIX認証パス検証に合格する必要があり、TLSAレコードと一致する証明書は、この認証パス検証のトラストアンカーと見なされます。

3 -- ドメイン発行証明書: 証明書用途3は、証明書、またはそのような証明書の公開鍵を指定するために使用されます。これは、サーバーがTLSで提供するエンドエンティティ証明書と一致する必要があります。この証明書用途は、ドメイン名管理者がサードパーティCAを関与させることなくドメインの証明書を発行できるため、「ドメイン発行証明書」と呼ばれることがあります。ターゲット証明書はTLSAレコードと一致する必要があります。証明書用途1と証明書用途3の違いは、証明書用途1は証明書がPKIX検証に合格することを要求しますが、証明書用途3ではPKIX検証はテストされません。

本文書で定義されている証明書用途は、DERエンコーディング[X.690]のPKIX形式の証明書にのみ明示的に適用されます。TLSが後で他の形式を許可する場合、または証明書の他の形式を受け入れるこのRRtypeへの拡張が行われる場合、それらの証明書には独自の証明書用途値が必要になります。

2.1.2. セレクタフィールド (The Selector Field)​

「セレクタ」と呼ばれる1オクテット値は、サーバーが提示するTLS証明書のどの部分が関連付けデータと照合されるかを指定します。この値は新しいIANAレジストリ(セクション7.3を参照)で定義されています。本文書で定義されているセレクタは次のとおりです。

0 -- 完全な証明書: [RFC5280]で定義されている証明書バイナリ構造

1 -- SubjectPublicKeyInfo: [RFC5280]で定義されているDERエンコードされたバイナリ構造

(本文書における「セレクタ」の使用は、DomainKeys Identified Mail(DKIM)[RFC6376]における「セレクタ」の使用とは完全に無関係であることに注意してください。)

2.1.3. マッチングタイプフィールド (The Matching Type Field)​

「マッチングタイプ」と呼ばれる1オクテット値は、証明書関連付けの提示方法を指定します。この値は新しいIANAレジストリ(セクション7.4を参照)で定義されています。本文書で定義されているタイプは次のとおりです。

0 -- 完全一致選択されたコンテンツ

1 -- SHA-256ハッシュ選択されたコンテンツの[RFC6234]

2 -- SHA-512ハッシュ選択されたコンテンツの[RFC6234]

TLSAレコードのマッチングタイプがハッシュである場合、証明書の署名で使用されたものと同じハッシュアルゴリズムをレコードが使用する(可能であれば)と、少数のハッシュアルゴリズムをサポートするクライアントに役立ちます。

2.1.4. 証明書関連付けデータフィールド (The Certificate Association Data Field)​

このフィールドは、照合される「証明書関連付けデータ」を指定します。これらのバイトは、マッチングタイプ0の場合は生データ(つまり、セレクタに応じて完全な証明書またはそのSubjectPublicKeyInfo)、またはマッチングタイプ1および2の場合は生データのハッシュです。データは、TLS ASN.1証明書オブジェクトではなく、関連付け内の証明書を参照します。

2.2. TLSA RRプレゼンテーション形式 (TLSA RR Presentation Format)​

RDATA部分のプレゼンテーション形式([RFC1035]で定義)は次のとおりです。

  • 証明書用途フィールドは、8ビット符号なし整数として表現する必要があります。
  • セレクタフィールドは、8ビット符号なし整数として表現する必要があります。
  • マッチングタイプフィールドは、8ビット符号なし整数として表現する必要があります。
  • 証明書関連付けデータフィールドは、16進数文字列として表現する必要があります。[RFC1035]で説明されているように、16進数文字列内に空白を含めることができます。

2.3. TLSA RRの例 (TLSA RR Examples)​

次の例では、ドメイン名はセクション3のルールを使用して形成されています。

PKIX CA証明書のハッシュ(SHA-256)関連付けの例：

_443._tcp.www.example.com. IN TLSA (
   0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
         7983a1d16e8a410e4561cb106618e971 )

PKIXエンドエンティティ証明書のハッシュ(SHA-512)サブジェクト公開鍵関連付けの例：

_443._tcp.www.example.com. IN TLSA (
   1 1 2 92003ba34942dc74152e2f2c408d29ec
         a5a520e7f2e06bb944f4dca346baf63c
         1b177615d466f6c4b71c216a50292bd5
         8c9ebdd2f74e38fe51ffd48c43326cbc )

PKIXエンドエンティティ証明書の完全な証明書関連付けの例：

_443._tcp.www.example.com. IN TLSA (
   3 0 0 30820307308201efa003020102020... )
に最終更新