RFC3008 日本語訳

Network Working Group                                      B. Wellington
Request for Comments: 3008                                       Nominum
Updates: 2535                                              November 2000
Category: Standards Track

コメントを求めるワーキンググループB.ウェリントン要求をネットワークでつないでください: 3008のNominumアップデート: 2535 2000年11月のカテゴリ: 標準化過程

         Domain Name System Security (DNSSEC) Signing Authority

ドメインネームシステムセキュリティ(DNSSEC)署名権威

Status of this Memo

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

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

Abstract

要約

   This document proposes a revised model of Domain Name System Security
   (DNSSEC) Signing Authority.  The revised model is designed to clarify
   earlier documents and add additional restrictions to simplify the
   secure resolution process.  Specifically, this affects the
   authorization of keys to sign sets of records.

このドキュメントは、Authorityに署名しながら、ドメインネームシステムSecurity(DNSSEC)の改訂されたモデルを提案します。 改訂されたモデルは、安全な解決プロセスを簡素化するために以前のドキュメントをはっきりさせて、追加制限を加えるように設計されています。 明確に、これは記録のセットに署名するキーの承認に影響します。

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?

1 - Introduction

1--序論

   This document defines additional restrictions on DNSSEC signatures
   (SIG) records relating to their authority to sign associated data.
   The intent is to establish a standard policy followed by a secure
   resolver; this policy can be augmented by local rules.  This builds
   upon [RFC2535], updating section 2.3.6 of that document.

このドキュメントは、関連データに署名する彼らの権威に関連しながら、DNSSEC署名(SIG)記録で追加制限を定義します。 意図は安全なレゾルバによって従われた標準約款を確立することです。 この方針はローカル・ルールで増大できます。 その.6通のセクション2.3ドキュメントをアップデートして、これは[RFC2535]を当てにします。

   The most significant change is that in a secure zone, zone data is
   required to be signed by the zone key.

最も重要な変化は安全なゾーンでは、ゾーンデータがゾーンキーで署名されるのに必要であるということです。

   Familiarity with the DNS system [RFC1034, RFC1035] and the DNS
   security extensions [RFC2535] is assumed.

DNSシステム[RFC1034、RFC1035]とDNSセキュリティ拡張子[RFC2535]への親しみは想定されます。

Wellington                  Standards Track                     [Page 1]

RFC 3008                DNSSEC Signing Authority           November 2000

権威11月が2000であると署名するウェリントン標準化過程[1ページ]RFC3008DNSSEC

2 - The SIG Record

2--SIG記録

   A SIG record is normally associated with an RRset, and "covers" (that
   is, demonstrates the authenticity and integrity of) the RRset.  This
   is referred to as a "data SIG".  Note that there can be multiple SIG
   records covering an RRset, and the same validation process should be
   repeated for each of them.  Some data SIGs are considered "material",
   that is, relevant to a DNSSEC capable resolver, and some are
   "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC
   validation.  Immaterial SIGs may have application defined roles.  SIG
   records may exist which are not bound to any RRset; these are also
   considered immaterial.  The validation process determines which SIGs
   are material; once a SIG is shown to be immaterial, no other
   validation is necessary.

通常、SIG記録はRRset、および「カバー」に関連しています。(それがそう、信憑性と保全を示す、)、RRset。 これは「データSIG」と呼ばれます。 RRsetをカバーする複数のSIG記録があることができることに注意してください。そうすれば、同じ合法化プロセスはそれぞれのそれらのために繰り返されるべきです。 何かが、いくつかのデータSIGがDNSSECの有能なレゾルバに「物質的で」、すなわち、関連していると考えられて、「重要でない」か「付加的なDNSSEC」です、それらがDNSSEC合法化に関連していないとき。 重要でないSIGには、アプリケーションの定義された役割があるかもしれません。 どんなRRsetにも縛られないSIG記録は存在するかもしれません。 また、これらは重要でないと考えられます。 合法化プロセスは、どのSIGが物質的であるかを決定します。 一度、他のどんな合法化も、重要でなくなるようにSIGが見せられている必要はありません。

   SIGs may also be used for transaction security.  In this case, a SIG
   record with a type covered field of 0 is attached to a message, and
   is used to protect message integrity.  This is referred to as a
   SIG(0) [RFC2535, RFC2931].

また、SIGはトランザクションセキュリティに使用されるかもしれません。 この場合、0のタイプのカバーされた分野があるSIG記録は、メッセージに添付されて、メッセージの保全を保護するのに使用されます。 これはSIG(0)[RFC2535、RFC2931]と呼ばれます。

   The following sections define requirements for all of the fields of a
   SIG record.  These requirements MUST be met in order for a DNSSEC
   capable resolver to process this signature.  If any of these
   requirements are not met, the SIG cannot be further processed.
   Additionally, once a KEY has been identified as having generated this
   SIG, there are requirements that it MUST meet.

以下のセクションはSIG記録の分野のすべてのための要件を定義します。 DNSSECの有能なレゾルバがこの署名を処理するように、これらの必要条件を満たさなければなりません。 これらの必要条件のいずれも満たされないなら、さらにSIGを処理できません。 さらに、KEYがこのSIGを生成したとしていったん特定されると、会わなければならないという要件があります。

2.1 - Type Covered

2.1--カバーされたタイプ

   For a data SIG, the type covered MUST be the same as the type of data
   in the associated RRset.  For a SIG(0), the type covered MUST be 0.

データSIGにおいて、カバーされたタイプは関連RRsetのデータのタイプと同じであるに違いありません。 SIG(0)において、カバーされたタイプは0歳であるに違いありません。

2.2 - Algorithm Number

2.2--アルゴリズム番号

   The algorithm specified in a SIG MUST be recognized by the client,
   and it MUST be an algorithm that has a defined SIG rdata format.

クライアントはSIGで指定されたアルゴリズムを認めなければなりません、そして、それは定義されたSIG rdata形式があるアルゴリズムであるに違いありません。

2.3 - Labels

2.3--ラベル

   The labels count MUST be less than or equal to the number of labels
   in the SIG owner name, as specified in [RFC2535, section 4.1.3].

ラベルカウントはSIG所有者名のラベルの、より数以下であるに違いありません、[RFC2535、セクション4.1.3]で指定されるように。

2.4 - Original TTL

2.4--オリジナルのTTL

   The original TTL MUST be greater than or equal to the TTL of the SIG
   record itself, since the TTL cannot be increased by intermediate
   servers.  This field can be ignored for SIG(0) records.

オリジナルのTTL MUSTはそう以上です。SIGのTTLはそれ自体を記録します、中間的サーバでTTLを増強できないので。 SIG(0)記録のためにこの分野を無視できます。

Wellington                  Standards Track                     [Page 2]

RFC 3008                DNSSEC Signing Authority           November 2000

権威11月が2000であると署名するウェリントン標準化過程[2ページ]RFC3008DNSSEC

2.5 - Signature Expiration and Inception

2.5--署名満了と始まり

   The current time at the time of validation MUST lie within the
   validity period bounded by the inception and expiration times.

合法化時点の時間が有効期間中に横たわらせなければならない電流は始まりと満了時間でバウンドしました。

2.6 - Key Tag

2.6--キー・タグ

   There are no restrictions on the Key Tag field, although it is
   possible that future algorithms will impose constraints.

将来のアルゴリズムが規制を課すのが、可能ですが、制限が全くKey Tagフィールドにありません。

2.7 - Signer's Name

2.7--署名者の名前

   The signer's name field of a data SIG MUST contain the name of the
   zone to which the data and signature belong.  The combination of
   signer's name, key tag, and algorithm MUST identify a zone key if the
   SIG is to be considered material.  The only exception that the
   signer's name field in a SIG KEY at a zone apex SHOULD contain the
   parent zone's name, unless the KEY set is self-signed.  This document
   defines a standard policy for DNSSEC validation; local policy may
   override the standard policy.

署名者のデータSIGの名前欄はデータと署名が属するゾーンの名前を含まなければなりません。 SIGが材料であると考えられるつもりであるなら、署名者の名前、キー・タグ、およびアルゴリズムの組み合わせはゾーンキーを特定しなければなりません。 唯一の例外、KEYがセットしなかったならゾーンの頂点SHOULDのSIG KEYの署名者の名前欄が親ゾーンの名前を含んでいるのは自己に署名されます。 このドキュメントはDNSSEC合法化のための標準約款を定義します。 ローカルの方針は標準約款をくつがえすかもしれません。

   There are no restrictions on the signer field of a SIG(0) record.
   The combination of signer's name, key tag, and algorithm MUST
   identify a key if this SIG(0) is to be processed.

制限が全くSIG(0)記録の署名者フィールドにありません。 このSIG(0)が処理されるつもりであるなら、署名者の名前、キー・タグ、およびアルゴリズムの組み合わせはキーを特定しなければなりません。

2.8 - Signature

2.8--署名

   There are no restrictions on the signature field.  The signature will
   be verified at some point, but does not need to be examined prior to
   verification unless a future algorithm imposes constraints.

制限が全く署名フィールドにありません。 将来のアルゴリズムが規制を課さないと、署名は何らかのポイントで確かめられますが、検証の前に調べられる必要はないでしょう。

3 - The Signing KEY Record

3--署名の主要な記録

   Once a signature has been examined and its fields validated (but
   before the signature has been verified), the resolver attempts to
   locate a KEY that matches the signer name, key tag, and algorithm
   fields in the SIG.  If one is not found, the SIG cannot be verified
   and is considered immaterial.  If KEYs are found, several fields of
   the KEY record MUST have specific values if the SIG is to be
   considered material and authorized.  If there are multiple KEYs, the
   following checks are performed on all of them, as there is no way to
   determine which one generated the signature until the verification is
   performed.

署名がいったん調べられて有効にされたその分野(署名が確かめられる前を除いて)になると、レゾルバは、SIGで署名者名、キー・タグ、およびアルゴリズム分野に合っているKEYの場所を見つけるのを試みます。 1つが見つけられないなら、SIGは、確かめることができないで、重要でないと考えられます。 KEYsが見つけられるなら、KEY記録のいくつかの分野には、SIGが材料であると考えられて、認可されるつもりであるなら、特定の値がなければなりません。 複数のKEYsがあれば、以下のチェックはそれらのすべてに実行されます、検証が実行されるまでどれが署名を生成したかを決定する方法が全くないとき。

Wellington                  Standards Track                     [Page 3]

RFC 3008                DNSSEC Signing Authority           November 2000

権威11月が2000であると署名するウェリントン標準化過程[3ページ]RFC3008DNSSEC

3.1 - Type Flags

3.1--タイプ旗

   The signing KEY record MUST have a flags value of 00 or 01
   (authentication allowed, confidentiality optional) [RFC2535, 3.1.2].
   A DNSSEC resolver MUST only trust signatures generated by keys that
   are permitted to authenticate data.

旗がKEY記録で評価しなければならない00か01(秘密性任意の状態で許された認証)の署名、[RFC2535、3.1、.2、] DNSSECレゾルバはデータを認証することが許可されているキーによって生成された署名を信じるだけでよいです。

3.2 - Name Flags

3.2--名前旗

   The interpretation of this field is considerably different for data
   SIGs and SIG(0) records.

データSIGとSIG(0)記録において、この分野の解釈はかなり異なっています。

3.2.1 - Data SIG

3.2.1 --データSIG

   If the SIG record covers an RRset, the name type of the associated
   KEY MUST be 01 (zone) [RFC2535, 3.1.2].  This updates RFC 2535,
   section 2.3.6.  The DNSSEC validation process performed by a resolver
   MUST ignore all keys that are not zone keys unless local policy
   dictates otherwise.

SIG記録が01が(ゾーン)であったならRRset、関連KEY MUSTというタイプという名前をカバーしている、[RFC2535、3.1、.2、] これはRFC2535、セクション2.3.6をアップデートします。 レゾルバによって実行されたDNSSEC合法化プロセスはローカルの方針が別の方法で命令しない場合ゾーンキーでないすべてのキーを無視しなければなりません。

   The primary reason that RFC 2535 allows host and user keys to
   generate material DNSSEC signatures is to allow dynamic update
   without online zone keys; that is, avoid storing private keys in an
   online server.  The desire to avoid online signing keys cannot be
   achieved, though, because they are necessary to sign NXT and SOA sets
   [RFC3007].  These online zone keys can sign any incoming data.
   Removing the goal of having no online keys removes the reason to
   allow host and user keys to generate material signatures.

RFC2535がホストとユーザキーに物質的なDNSSEC署名を生成させるプライマリ理由はオンラインゾーンキーなしでダイナミックなアップデートを許すことです。 すなわち、オンラインサーバの秘密鍵を保存するのを避けてください。もっとも、それらがNXTとSOAがセット[RFC3007]であると署名するのに必要であるので、オンライン署名キーを避ける願望は達成できません。 これらのオンラインゾーンキーはどんな受信データにも署名することができます。 どんなオンラインキーも持っていないという目標を取り除くと、ホストとユーザキーが物質的な署名を生成するのを許容する理由は取り除かれます。

   Limiting material signatures to zone keys simplifies the validation
   process.  The length of the verification chain is bounded by the
   name's label depth.  The authority of a key is clearly defined; a
   resolver does not need to make a potentially complicated decision to
   determine whether a key has the proper authority to sign data.

物質的な署名をゾーンキーに制限すると、合法化プロセスは簡略化します。 名前のラベルの深さに従って、検証チェーンの長さは境界があります。 キーの権威は明確に定義されます。 レゾルバはキーにはデータに署名する適切な権威があるかどうか決定するという潜在的に複雑な決定をする必要はありません。

   Finally, there is no additional flexibility granted by allowing
   host/user key generated material signatures.  As long as users and
   hosts have the ability to authenticate update requests to the primary
   zone server, signatures by zone keys are sufficient to protect the
   integrity of the data to the world at large.

最終的に、物質的な署名であると生成されたホスト/ユーザキーを許容することによって与えられたどんな追加柔軟性もありません。 ユーザとホストにプライマリゾーンサーバに更新要求を認証する能力がある限り、ゾーンキーによる署名は、全体の世界にデータの保全を保護するために十分です。

3.2.2 - SIG(0)

3.2.2 --SIG(0)

   If the SIG record is a SIG(0) protecting a message, the name type of
   the associated KEY SHOULD be 00 (user) or 10 (host/entity).
   Transactions are initiated by a host or user, not a zone, so zone
   keys SHOULD not generate SIG(0) records.

00が(ユーザ)であったなら、SIG記録は関連KEY SHOULDでメッセージ、タイプという名前を保護するSIG(0)であるか、そして、10(ホスト/実体)。 トランザクションがゾーンではなく、ホストかユーザによって開始されるので、ゾーンキーSHOULDはSIG(0)記録を生成しません。

Wellington                  Standards Track                     [Page 4]

RFC 3008                DNSSEC Signing Authority           November 2000

権威11月が2000であると署名するウェリントン標準化過程[4ページ]RFC3008DNSSEC

   A client is either explicitly executed by a user or on behalf of a
   host, therefore the name type of a SIG(0) generated by a client
   SHOULD be either user or host.  A nameserver is associated with a
   host, and its use of SIG(0) is not associated with a particular zone,
   so the name type of a SIG(0) generated by a nameserver SHOULD be
   host.

したがって、ホスト、タイプというクライアントSHOULDによって生成されたSIG(0)の名前を代表したクライアントはユーザによって明らかに処刑されるか、ユーザかホストのどちらかになってください。 ネームサーバがホストに関連していて、SIG(0)の使用が特定のゾーンに関連づけられないので、名前はSIGをタイプします。ホストになってください(0) ネームサーバSHOULDによって生成されて。

3.3 - Signatory Flags

3.3--署名している旗

   This document does not assign any values to the signatory field, nor
   require any values to be present.

このドキュメントは、どんな値も署名している分野に割り当てて、どんな値も現在であるのを必要としません。

3.4 - Protocol

3.4--プロトコル

   The signing KEY record MUST have a protocol value of 3 (DNSSEC) or
   255 (ALL).  If a key is not specified for use with DNSSEC, a DNSSEC
   resolver MUST NOT trust any signature that it generates.

署名KEY記録には、3の1(すべて)か255のプロトコル値(DNSSEC)がなければなりません。 キーがDNSSECとの使用に指定されないなら、DNSSECレゾルバはそれが生成するどんな署名も信じてはいけません。

3.5 - Algorithm Number

3.5--アルゴリズム番号

   The algorithm field MUST be identical to that of the generated SIG
   record, and MUST meet all requirements for an algorithm value in a
   SIG record.

アルゴリズム分野は、発生しているSIG記録のものと同じでなければならなく、SIG記録のアルゴリズム値のためにすべての必要条件を満たさなければなりません。

4 - Security Considerations

4--セキュリティ問題

   This document defines a standard baseline for a DNSSEC capable
   resolver.  This is necessary for a thorough security analysis of
   DNSSEC, if one is to be done.

このドキュメントはDNSSECの有能なレゾルバのために標準の基線を定義します。これがDNSSECの徹底的な証券分析に必要です、1つが完了しているつもりであるなら。

   Specifically, this document places additional restrictions on SIG
   records that a resolver must validate before the signature can be
   considered worthy of DNSSEC trust.  This simplifies the protocol,
   making it more robust and able to withstand scrutiny by the security
   community.

明確に、DNSSEC信頼にふさわしいと署名を考えることができる前にこのドキュメントはレゾルバが有効にしなければならないSIG記録に関して追加制限を課します。 安全保障共同体による精査に耐えるのをより強健でできるようにして、これはプロトコルを簡素化します。

5 - Acknowledgements

5--承認

   The author would like to thank the following people for review and
   informative comments (in alphabetical order):

作者はレビューと有益なコメント(アルファベット順に)について以下の人々に感謝したがっています:

   Olafur Gudmundsson
   Ed Lewis

Olafurグドムンソン・Ed Lewis

Wellington                  Standards Track                     [Page 5]

RFC 3008                DNSSEC Signing Authority           November 2000

権威11月が2000であると署名するウェリントン標準化過程[5ページ]RFC3008DNSSEC

6 - References

6--参照

   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, November 1987.

[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
              Specification", STD 13, RFC 1035, November 1987.

[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
              "Dynamic Updates in the Domain Name System", RFC 2136,
              April 1997.

Vixie編、P.、トムソン、S.、Rekhter、Y.、およびJ.が縛った[RFC2136]、「ドメインネームシステムにおけるダイナミックなアップデート」、RFC2136(1997年4月)。

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

[RFC2535] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。

   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
              (SIG(0)s )", RFC 2931, September 2000.

D.、「DNS要求とトランザクション署名(SIG(0)s)」、RFC2931 2000年9月の[RFC2931]イーストレーク。

   [RFC3007]      Wellington, B., "Simple Secure Domain Name System
              (DNS) Dynamic Update", RFC 3007, November 2000.

[RFC3007] ウェリントン、B.、「簡単な安全なドメインネームシステム(DNS)ダイナミック・アップデート」、RFC3007、2000年11月。

7 - Author's Address

7--作者のアドレス

   Brian Wellington
   Nominum, Inc.
   950 Charter Street
   Redwood City, CA 94063

通りレッドウッドシティー、ブライアンウェリントンNominum Inc.950Charterカリフォルニア 94063

   Phone: +1 650 381 6022
   EMail: Brian.Wellington@nominum.com

以下に電話をしてください。 +1 6022年の650 381メール: Brian.Wellington@nominum.com

Wellington                  Standards Track                     [Page 6]

RFC 3008                DNSSEC Signing Authority           November 2000

権威11月が2000であると署名するウェリントン標準化過程[6ページ]RFC3008DNSSEC

8  Full Copyright Statement

8 完全な著作権宣言文

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Wellington                  Standards Track                     [Page 7]

ウェリントン標準化過程[7ページ]