2. 認可拡張タイプ

汎用拡張メカニズムにより、クライアントとサーバーは特定の拡張を使用するかどうか、およびその使用方法をネゴシエートできます。[TLS1.2] で規定されているように、拡張client helloメッセージおよび拡張server helloメッセージで使用される拡張形式は、便宜上ここで繰り返します。

struct {
   ExtensionType extension_type;
   opaque extension_data<0..2^16-1>;
} Extension;

extension_typeは特定の拡張タイプを識別し、extension_dataはその特定の拡張タイプに固有の情報を含みます。この文書では、2つの新しい拡張タイプの使用を規定します:client_authzとserver_authzです。これらの拡張タイプは、それぞれセクション2.1とセクション2.2で説明されています。この仕様は、ExtensionTypeに2つの新しいタイプを追加します。

enum {
   client_authz(7), server_authz(8), (65535)
} ExtensionType;

認可拡張は、TLSセッションが確立されている際に関連性があり、これらの拡張タイプは、対応するclient helloメッセージに同じ拡張タイプが現れない限り、拡張server helloメッセージに現れてはなりません。クライアントは、サーバーからの関連する認可情報を受け入れる準備ができていない限り、拡張client helloメッセージで拡張タイプを送信してはなりません。クライアントがclient_authz拡張を送信する場合、クライアントはserver_authz拡張も送信しなければなりません。

サーバーは、client helloメッセージ内のclient_authzおよびserver_authz拡張をチェックしなければならず、相互にサポートされている各認可データ型に対して拡張で応答しなければなりません。サーバーは、client_authz拡張で応答してserver_authz拡張でも応答しないということ、またはその逆をしてはなりません。

2.1. client_authzおよびserver_authz拡張

TLSサーバーに認可情報を提供するために、クライアントは拡張client helloメッセージに"client_authz"タイプの拡張を含めることができます。TLSサーバーから認可情報を要求するために、クライアントは拡張client helloメッセージに"server_authz"タイプの拡張を含めることができます。これらの拡張の"extension_data"フィールドには、以下に説明するClientAuthzFormatListを含める必要があります。

struct {
   AuthorizationDataFormat authz_format_list<1..2^8-1>;
} ClientAuthzFormatList;

AuthorizationDataFormatタイプは、SupplementalDataメッセージ内の認可情報を記述するために使用されます。AuthorizationDataFormatタイプは次のように定義されます。

enum {
   x509_attr_cert(0), saml_assertion(1),
   x509_attr_cert_url(2), saml_assertion_url(3), (255)
} AuthorizationDataFormat;

証明書および証明書URL認可データ型は、認可サーバーのURL位置を伴う必要があります。証明書および証明書URLタイプは、認可サーバーURLとともに、TLSクライアントおよびTLSサーバーとは別個である可能性がある第三者によって認可決定を行うことを可能にします。

authz_format_listの意味は次のとおりです。

x509_attr_certは、クライアント認可情報がX.509属性証明書 (AC) [ATTRCERT] であることを示します。
saml_assertionは、認可情報がSAMLアサーション [SAML1.1] [SAML2.0] であることを示します。
x509_attr_cert_urlは、認可情報がURI [HTTP] として提供されるX.509属性証明書 (AC) [ATTRCERT] であることを示します。
saml_assertion_urlは、認可情報がURI [HTTP] として提供されるSAMLアサーション [SAML1.1] [SAML2.0] であることを示します。

認可データはSupplementalDataメッセージ [TLSSUPP] で伝送されます。クライアントとサーバーは、拡張client helloメッセージおよび拡張server helloメッセージのClientAuthzFormatListおよびServerAuthzFormatListに基づいて、どのSupplementalDataメッセージが使用されているかを知ります。ClientAuthzFormatListおよびServerAuthzFormatList内の各認可形式のデータは、SupplementalDataメッセージ内に同じ順序で含める必要があります。

2.2. Client Hello

TLS client helloの形式は、認可拡張の配置を示すためにここに示されています。client helloメッセージの完全な仕様は、[TLS1.0]、[TLS1.1]、および [TLS1.2] にあります。

TLSサーバーへの認可情報のサポートを示すために、クライアントは拡張client helloメッセージにclient_authzおよびserver_authz拡張の一方または両方を含めることができます。

クライアントがclient_authz拡張を含める場合、クライアントがサーバーに提供する準備ができている認可データ型のセット (SupplementalDataハンドシェイクメッセージ [TLSSUPP] で伝送される) を示します。

クライアントがserver_authz拡張を含める場合、クライアントがサーバーから受信する準備ができている認可データ型のセット (SupplementalDataハンドシェイクメッセージ [TLSSUPP] で伝送される) を示します。

クライアントがセッション再開を開始している場合、client_authzおよびserver_authz拡張はclient helloメッセージから省略する必要があります。

拡張client helloメッセージの一般的な構造は [TLSEXT2] で定義されており、明確にするためにここで再現します。

struct {
   ProtocolVersion client_version;
   Random random;
   SessionID session_id;
   CipherSuite cipher_suites<2..2^16-2>;
   CompressionMethod compression_methods<1..2^8-1>;
   select (extensions_present) {
      case false:
         struct {};
      case true:
         Extension extensions<0..2^16-1>;
   };
} ClientHello;

2.1. client_authzおよびserver_authz拡張​

2.2. Client Hello​

2.1. client_authzおよびserver_authz拡張

2.2. Client Hello