[要約] RFC 4985は、サービス名の表現に関するX.509公開鍵基盤のSubject Alternative Nameを定義しています。このRFCの目的は、証明書のサブジェクト名に複数のサービス名を含めるための標準化を提供することです。
Network Working Group S. Santesson
Request for Comments: 4985 Microsoft
Category: Standards Track August 2007
Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name
インターネットX.509公開キーインフラストラクチャの件名サービス名の表現の代替名
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record.
このドキュメントでは、X.509の件名フィールドに含めるための新しい名前フォームを定義します。これにより、証明書がDNSサービスリソースレコードのサービス名とドメイン名コンポーネントに関連付けられることを許可します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. Name Definitions ................................................2
3. Internationalized Domain Names ..................................4
4. Name Constraints Matching Rules .................................5
5. Security Considerations .........................................6
6. Normative References ............................................6
Appendix A. ASN.1 Syntax ...........................................7
Appendix A.1. 1988 ASN.1 Module .................................7
Appendix A.2. 1993 ASN.1 Module .................................8
This document specifies a name form for inclusion in X.509 certificates that may be used by a certificate relying party to verify that a particular host is authorized to provide a specific service within a domain.
このドキュメントは、特定のホストがドメイン内で特定のサービスを提供することが許可されていることを確認するために、証明書に依存する証明書が使用できるX.509証明書に含めるための名前フォームを指定します。
RFC 2782 [N3] defines a DNS RR (Resource Record) for specifying the location of services (SRV RR), which allows clients to ask for a specific service/protocol for a specific domain and get back the names of any available servers.
RFC 2782 [N3]は、サービスの場所（SRV RR）を指定するためのDNS RR（リソースレコード）を定義します。これにより、クライアントは特定のドメインの特定のサービス/プロトコルを要求し、利用可能なサーバーの名前を取り戻すことができます。
Existing name forms in X.509 certificates support authentication of a host name. This is useful when the name of the host is known by the client prior to authentication.
X.509の既存の名前フォームは、ホスト名の認証をサポートしています。これは、ホストの名前が認証前にクライアントによって知られている場合に役立ちます。
When a server host name is discovered through DNS RR lookup query based on service name, the client may need to authenticate the server's authorization to provide the requested service in addition to the server's host name.
サーバーのホスト名がサービス名に基づいてDNS RRルックアップクエリを使用して発見された場合、クライアントはサーバーのホスト名に加えて要求されたサービスを提供するためにサーバーの承認を認証する必要がある場合があります。
While DNS servers may have the capacity to provide trusted information, there may be many other situations where the binding between the name of the host and the provided service needs to be supported by additional credentials.
DNSサーバーには信頼できる情報を提供する能力があるかもしれませんが、ホストの名前と提供されたサービスの間の拘束力が追加の資格情報によってサポートされる必要がある他の多くの状況がある場合があります。
Current dNSName GeneralName Subject Alternative name form only provides for DNS host names to be expressed in "preferred name syntax", as specified by RFC 1034 [N4]. This definition is therefore not broad enough to allow expression of a service related to that domain.
現在のdnsname generalName件名代替名の形式は、RFC 1034 [N4]で指定されているように、「優先名の構文」で表現するDNSホスト名を提供します。したがって、この定義は、そのドメインに関連するサービスの表現を許可するほど広くありません。
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 [N1].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [N1]に記載されているように解釈される。
This section defines the SRVName name as a form of otherName from the GeneralName structure in SubjectAltName defined in RFC 3280 [N2].
このセクションでは、SRVNAME名を、RFC 3280 [N2]で定義されている主題の一般名構造の他の名前の形式として定義します。
id-on-dnsSRV OBJECT IDENTIFIER ::= { id-on 7 }
SRVName ::= IA5String (SIZE (1..MAX))
The SRVName, if present, MUST contain a service name and a domain name in the following form:
SRVNameは、存在する場合、次の形式のサービス名とドメイン名を含める必要があります。
_Service.Name
_サービス名
The content of the components of this name form MUST be consistent with the corresponding definition of these components in an SRV RR according to RFC 2782 [N3].
この名前フォームのコンポーネントのコンテンツは、RFC 2782 [N3]に従って、SRV RRのこれらのコンポーネントの対応する定義と一致する必要があります。
The content of these components are:
これらのコンポーネントのコンテンツは次のとおりです。
Service The symbolic name of the desired service, as defined in Assigned Numbers [N5] or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature. Some widely used services, notably POP, don't have a single universal name. If Assigned Numbers names the service indicated, that name is the only name that is allowed in the service component of this name form. The Service is case insensitive.
サービスが割り当てられた番号[n5]またはローカルで定義されているように、希望するサービスの象徴的な名前。アンダースコア（_）は、自然界で発生するDNSラベルとの衝突を回避するために、サービス識別子に準備されています。広く使用されているサービス、特にポップなサービスには、単一のユニバーサル名がありません。割り当てられた番号が示されているサービス名の場合、その名前は、この名前フォームのサービスコンポーネントで許可されている唯一の名前です。このサービスは、ケースの鈍感です。
Name The DNS domain name of the domain where the specified service is located.
指定されたサービスが配置されているドメインのDNSドメイン名に名前を付けます。
If the domain name is an Internationalized Domain Name (IDN), then encoding in ASCII form SHALL be done as defined in section 3.
ドメイン名が国際化されたドメイン名（IDN）である場合、ASCII形式でエンコードすることは、セクション3で定義されているとおりに行われます。
Even though this name form is based on the service resource record (SRV RR) definition in RFC 2782 [N3] and may be used to enhance subsequent authentication of DNS-based service discovery, this standard does not define any new conditions or requirements regarding use of SRV RR for service discovery or where and when such use is appropriate.
この名前フォームは、RFC 2782 [N3]のサービスリソースレコード（SRV RR）定義に基づいており、DNSベースのサービス発見のその後の認証を強化するために使用できますが、この標準は、使用に関する新しい条件または要件を定義していません。サービスの発見のためのSRV RRまたはそのような使用が適切である場所と時期。
The format of a DNS RR, according to RFC 2782, also includes a protocol component (_Service._Proto.Name). This protocol component is not included in the SRVName specified in this document. The purpose of the SRVName is limited to authorization of service provision within a domain. It is outside the scope of the SRVName to provide any means to verify that the host is using any intended protocol. By omitting the protocol component from the SRVName two important advantages have been achieved:
RFC 2782によると、DNS RRの形式には、プロトコルコンポーネント（_service._proto.name）も含まれています。このプロトコルコンポーネントは、このドキュメントで指定されたSRVNameには含まれていません。SRVNameの目的は、ドメイン内のサービス提供の承認に限定されます。ホストが意図したプロトコルを使用していることを確認する手段を提供することは、SRVNameの範囲外です。SRVNameからプロトコルコンポーネントを省略することにより、2つの重要な利点が達成されました。
* One certificate with a single SRVName can be issued to a host that offers multiple protocol alternatives.
* 単一のSRVNAMEを使用した1つの証明書は、複数のプロトコルの代替案を提供するホストに発行できます。
* Name constraints processing rules (specified in section 4)are significantly less complex to define without the protocol component.
* 名前の制約処理ルール（セクション4で指定）は、プロトコルコンポーネントなしで定義するのに大幅に複雑ではありません。
A present SRVName in a certificate MUST NOT be used to identify a host unless one of the following conditions applies:
証明書の現在のSRVNAMEを使用して、次の条件のいずれかが適用されない限り、ホストを識別するために使用してはなりません。
* Use of this name form is specified by the security protocol being used and the identified service has a defined service name according to RFC 2782, or;
* この名前フォームの使用は、使用されるセキュリティプロトコルによって指定され、識別されたサービスには、RFC 2782に従って定義されたサービス名があります。
* Use of this name form is configured by local policy.
* この名前フォームの使用は、ローカルポリシーによって構成されています。
IA5String is limited to the set of ASCII characters. To accommodate internationalized domain names in the current structure, conforming implementations MUST convert internationalized domain names to the ASCII Compatible Encoding (ACE) format as specified in section 4 of RFC 3490 [N6] before storage in the Name part of SRVName. Specifically, conforming implementations MUST perform the conversion operation specified in section 4 of RFC 3490 [N6], with the following clarifications:
IA5Stringは、ASCII文字のセットに限定されています。現在の構造の国際化されたドメイン名に対応するには、SRVNAMEの名前部分に保存する前に、RFC 3490 [n6]のセクション4で指定されているように、国際化されたドメイン名をASCII互換エンコード（ACE）形式に変換する必要があります。具体的には、適合実装は、次の説明を使用して、RFC 3490 [N6]のセクション4で指定された変換操作を実行する必要があります。
* in step 1, the domain name SHALL be considered a "stored string". That is, the AllowUnassigned flag SHALL NOT be set;
* ステップ1では、ドメイン名は「保存された文字列」と見なされます。つまり、Allowunassigned Flagは設定してはなりません。
* in step 3, set the flag called "UseSTD3ASCIIRules";
* ステップ3では、「uesestd3asciirules」と呼ばれるフラグを設定します。
* in step 4, process each label with the "ToASCII" operation; and
* ステップ4では、各ラベルを「toascii」操作で処理します。と
* in step 5, change all label separators to U+002E (full stop).
* ステップ5では、すべてのラベルセパレーターをU 002E（フルストップ）に変更します。
When comparing DNS names for equality, conforming implementations MUST perform a case-insensitive exact match on the entire domain name. When evaluating name constraints, conforming implementations MUST perform a case-insensitive exact match on a label-by-label basis.
平等のDNS名を比較する場合、順応の実装は、ドメイン名全体でケースに依存しない正確な一致を実行する必要があります。名前の制約を評価する場合、適合の実装は、ラベルごとにケースに依存しない正確な一致を実行する必要があります。
Implementations SHOULD convert IDNs to Unicode before display. Specifically, conforming implementations SHOULD perform the conversion operation specified in section 4 of RFC 3490 [N6], with the following clarifications:
実装は、表示される前にIDNをUnicodeに変換する必要があります。具体的には、適合実装は、次の説明を使用して、RFC 3490 [N6]のセクション4で指定された変換操作を実行する必要があります。
* in step 1, the domain name SHALL be considered a "stored string". That is, the AllowUnassigned flag SHALL NOT be set;
* ステップ1では、ドメイン名は「保存された文字列」と見なされます。つまり、Allowunassigned Flagは設定してはなりません。
* in step 3, set the flag called "UseSTD3ASCIIRules";
* ステップ3では、「uesestd3asciirules」と呼ばれるフラグを設定します。
* in step 4, process each label with the "ToUnicode" operation; and
* ステップ4では、各ラベルを「tounicode」操作で処理します。と
* skip step 5.
* ステップ5をスキップします。
Note: Implementations MUST allow for increased space requirements for IDNs. An IDN ACE label will begin with the four additional characters "xn--" and may require as many as five ASCII characters to specify a single international character.
注：実装では、IDNのスペース要件を増やす必要があります。IDN ACEラベルは、4つの追加文字「XN-」から始まり、1つの国際文字を指定するために5つのASCII文字を必要とする場合があります。
Name constraining, as specified in RFC 3280, MAY be applied to the SRVName by adding name restriction in the name constraints extension in the form of an SRVName.
RFC 3280で指定されているように、名前の制約は、srvnameの形で名前制約拡張に名前制限を追加することにより、srvnameに適用できます。
SRVName restrictions are expressed as a complete SRVName (_mail.example.com), just a service name (_mail), or just as a DNS name (example.com). The name restriction of the service name part and the DNS name part of SRVName are handled separately.
SRVNameの制限は、完全なsrvname（_mail.example.com）、単なるサービス名（_mail）、またはDNS名（Example.com）として表されます。SRVNAMEのサービス名部分とDNS名部分の名前の制限は、個別に処理されます。
If a service name is included in the restriction, then that restriction can only be satisfied by an SRVName that includes a corresponding service name. If the restriction has an absent service name, then that restriction is satisfied by any SRVName that matches the domain part of the restriction.
DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding subdomains to the left-hand side of the name satisfies the DNS name part of the name constraint. For example, www.host.example.com would satisfy the constraint (host.example.com) but 1host.example.com would not.
DNS名の制限は、host.example.comとして表されます。名前の左側にサブドメインを追加するだけで構築できるDNS名は、名前の制約のDNS名部分を満たします。たとえば、www.host.example.comは制約（host.example.com）を満たしますが、1host.example.comはそうしません。
Examples:
例：
Name Constraints
SRVName restriction Matching SRVName non-matching SRVName
=================== ================ ====================
example.com _mail.example.com _mail.1example.com
_ntp.example.com
_mail.1.example.com
_mail _mail.example.com _ntp.example.com _mail.1example.com
_mail _mail.example.com _ntp.example.com _mail.1example.com
_mail.example.com _mail.example.com _mail.1example.com _mail.1.example.com _ntp.example.com
_mail.example.com _mail.example.com _mail.1example.com _mail.1.example.com _ntp.example.com
Assignment of services to hosts may be subject to change. Implementers should be aware of the need to revoke old certificates that no longer reflect the current assignment of services and thus make sure that all issued certificates are up to date.
ホストへのサービスの割り当ては、変更される場合があります。実装者は、現在のサービスの割り当てを反映していない古い証明書を取り消す必要性を認識している必要があり、したがって、すべての発行された証明書が最新であることを確認する必要があります。
When X.509 certificates enhanced with the name form specified in this standard is used to enhance authentication of service discovery based on an SRV RR query to a DNS server, all security considerations of RFC 2782 applies.
この標準で指定された名前フォームで拡張されたX.509証明書を使用して、DNSサーバーへのSRV RRクエリに基づいてサービス発見の認証を強化すると、RFC 2782のすべてのセキュリティに関する考慮事項が適用されます。
[N1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[N2] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[N2] Housley、R.、Polk、W.、Ford、W.、およびD. Solo、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[N3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[N3] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[N4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", STD 13, RFC 1034, November 1987
[N4] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月
[N5] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[N5] Reynolds、J。、「割り当てられた番号：RFC 1700はオンラインデータベースに置き換えられます」、RFC 3232、2002年1月。
[N6] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[N6] Faltstrom、P.、Hoffman、P.、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
As in RFC 2459, ASN.1 modules are supplied in two different variants of the ASN.1 syntax.
RFC 2459と同様に、ASN.1モジュールは、ASN.1構文の2つの異なるバリアントで提供されます。
This section describes data objects used by conforming Public Key Infrastructure (PKI) components in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with the 1993 UNIVERSAL Type UTF8String.
このセクションでは、「ASN.1のような」構文で公開キーインフラストラクチャ（PKI）コンポーネントを適合させることで使用されるデータオブジェクトについて説明します。この構文は、1988年と1993年のASN.1構文のハイブリッドです。1988 ASN.1構文は、1993年のユニバーサルタイプのUTF8STRINGで補強されています。
The ASN.1 syntax does not permit the inclusion of type statements in the ASN.1 module, and the 1993 ASN.1 standard does not permit use of the new UNIVERSAL types in modules using the 1988 syntax. As a result, this module does not conform to either version of the ASN.1 standard.
ASN.1構文は、ASN.1モジュールにタイプステートメントを含めることを許可しておらず、1993 ASN.1標準では、1988構文を使用してモジュールで新しいユニバーサルタイプの使用を許可していません。その結果、このモジュールは、ASN.1標準のいずれのバージョンにも準拠していません。
Appendix A.1 may be parsed by an 1988 ASN.1-parser by replacing the definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
付録A.1は、1988年の普遍的なタイプの定義を1988年のキャッチオールの「Any」に置き換えることにより、1988年のASN.1-Parserによって解析される場合があります。
Appendix A.2 may be parsed "as is" by a 1997-compliant ASN.1 parser.
付録A.2は、1997年に準拠したASN.1パーサーによって「現状のまま」解析される場合があります。
In case of discrepancies between these modules, the 1988 module is the normative one.
これらのモジュール間で矛盾がある場合、1988年モジュールは規範的なモジュールです。
Appendix A.1. 1988 ASN.1 Module
付録A.1。1988 ASN.1モジュール
PKIXServiceNameSAN88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-dns-srv-name-88(39) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
始める
-- EXPORTS ALL --
- すべてエクスポート -
IMPORTS
輸入
-- UTF8String, / move hyphens before slash if UTF8String does not
-- resolve with your compiler
id-pkix
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
-- from RFC3280 [N2]
-- Service Name Object Identifier and Syntax
-- id-pkix OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7}
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-dnsSRV OBJECT IDENTIFIER ::= { id-on 7 }
SRVName ::= IA5String (SIZE (1..MAX))
END
終わり
Appendix A.2. 1993 ASN.1 Module
付録A.2。1993 ASN.1モジュール
PKIXServiceNameSAN93 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-dns-srv-name-93(40) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
始める
-- EXPORTS ALL --
- すべてエクスポート -
IMPORTS
輸入
id-pkix
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
-- from RFC 3280 [N2]
-- In the GeneralName definition using the 1993 ASN.1 syntax
-- includes:
OTHER-NAME ::= TYPE-IDENTIFIER
-- Service Name Object Identifier
- サービス名オブジェクト識別子
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-dnsSRV OBJECT IDENTIFIER ::= { id-on 7 }
-- Service Name
- サービス名
srvName OTHER-NAME ::= { SRVName IDENTIFIED BY { id-on-dnsSRV }}
SRVName ::= IA5String (SIZE (1..MAX))
END
終わり
Author's Address
著者の連絡先
Stefan Santesson Microsoft Tuborg Boulevard 12 2900 Hellerup Denmark
Stefan Santesson Microsoft Tuborg Boulevard 12 2900 Hellerup Denmark
EMail: stefans@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。