Internet DRAFT - draft-hallambaker-entity

draft-hallambaker-entity




          SMIME Working Group                                                  
          Internet Draft                                       P. Hallam-Baker 
          Document: draft-hallambaker-entity-00.txt              VeriSign Inc. 
          Expires: October 2004                                      July 2004 
           
           
                                Entity-to-Entity S/MIME 
           
           
       Status of this Memo 
           
          This document is an Internet-Draft and is NOT offered in accordance 
          with Section 10 of RFC2026, and the author does not provide the 
          IETF with any rights other than to publish as an Internet-Draft  
        
          Internet-Drafts are working documents of the Internet Engineering 
          Task Force (IETF), its areas, and its working groups.  Note that 
          other groups may also distribute working documents as Internet-
          Drafts. 
           
          Internet-Drafts are draft documents valid for a maximum of six 
          months and may be updated, replaced, or obsoleted by other 
          documents at any time.  It is inappropriate to use Internet-Drafts 
          as reference material or to cite them other than as "work in 
          progress." 
           
          The list of current Internet-Drafts can be accessed at 
               http://www.ietf.org/ietf/1id-abstracts.txt 
          The list of Internet-Draft Shadow Directories can be accessed at 
               http://www.ietf.org/shadow.html. 
           
       Abstract 
           
          This document describes a set of related protocol extensions to 
          S/MIME, SMTP and DNS that collectively simplify deployment of 
          S/MIME. Particular attention is given to ensuring that S/MIME 
          authenticated content is only received by end user clients capable 
          of presenting the content in an acceptable manner. The proposal 
          extends the æend-to-endÆ security model of traditional S/MIME to 
          support end-to-edge, edge-to-end and edge-to-edge use cases. 
        
       Conventions used in this document 
           
          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 [1]. 
          
          
         Hallam-Baker Expires - January !Undefined Bookmark, SAVEDATE[Page 1] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
           
       Table of Contents 
           
          1. Introduction...................................................2 
             1.1 Brick Wall Deployment Model................................2 
             1.2 Beyond "End-to-End"........................................4 
             1.3 Do no harm.................................................5 
             1.4 The S/MIME Sender Problem..................................5 
             1.5 Support for S/MIME Without Cryptography....................5 
             1.6 Locating Public Keys.......................................6 
             1.7 Validating Public Keys.....................................7 
          2. Architecture...................................................7 
             2.1 Authentication.............................................8 
       2.1.1 Originator  8 
       2.1.2 Outgoing Edge Server 8 
       2.1.3 Incoming Edge Server 8 
       2.1.4 Receiver 8 
          3. SMTP Extensions................................................9 
          4. DNS Extension..................................................9 
             4.1 Policy Element.............................................9 
             4.2 Key Element...............................................10 
             4.3 X509 Element..............................................10 
             4.4 Authentication Policy.....................................11 
             4.5 Encryption Policy.........................................12 
          5. S/MIME Extensions.............................................13 
             5.1 Signed Attribute OIDs.....................................14 
             5.2 MIME Header...............................................14 
          6. Client User Interface.........................................14 
          7. Key Management................................................15 
          References.......................................................15 
          Author's Addresses...............................................16 
           
       1. Introduction 
          
         Despite years of effort S/MIME use lags far behind deployment. This 
         document examines the reasons behind the failure of S/MIME to 
         become ubiquitous and proposes a small number of very minor changes 
         to protocols and user interfaces to remedy these problems. 
          
         The proposal is entirely backwards compatible with the legacy base 
         of email infrastructure, whether S/MIME aware or not. 
          
       1.1 Brick Wall Deployment Model 
          
          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 2] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
         Like many cryptographic security protocols, S/MIME has suffered 
         from a æbrick wallÆ deployment model that insists that the security 
         provided must be all or nothing. This approach refuses to accept 
         deployment strategies that are perceived as detrimental to 
         security, even when the security benefits are not actually relevant 
         to the party making the choice to deploy. 
          
         A particular problem in this respect has been security 
         architectures driven largely by ideological concerns rather than a 
         realistic approach to controlling and mitigating risk. 
          
         Deployment of network protocols and in particular security 
         protocols takes significant time and effort. This often leads to a 
         belief that a security protocol must be absolutely secure against 
         all imaginable forms of attack before deployment begins. In some 
         cases this belief has deployed release of an agreed specification 
         for over a decade.  
          
         Yet this concern for perfection should be compared to the clear 
         success of SSL and WiFi security protocols. Even though the initial 
         implementation of these protocols was deeply flawed these errors 
         were quickly corrected.  Today more email messages are secured 
         using the SSL protocol than by any of the security protocols 
         designed specifically for use with email. Even the deployment of 
         large numbers of WiFi hardware devices, which only provide support 
         for a weak security protocol, has not resulted in disaster. This 
         situation is certainly undesirable, but there is little doubt that 
         almost all WiFi users will be using devices that support genuinely 
         secure protocols long before deployment of IP-Sec achieves close to 
         the same level of ubiquity. 
          
         Far from precluding subsequent deployment of strong cryptographic 
         protocols, the earlier weak systems paved the way for the strong. 
         System administrators were used to the fact that these applications 
         required security configuration. When they discovered that the 
         security protocols were flawed they insisted that vendors provide 
         an expeditious correction. 
          
         The traditional argument that weak security is worse than no 
         security at all must be re-evaluated. Over the past ten years 
          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 3] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
         consumers have increasingly relied upon the Internet infrastructure 
         and made little distinction between those parts secured by 
         cryptography and those that are insecure. Nor is there any reason 
         to believe that consumer habits are likely to change through 
         education. Security is a means of controlling risk and in most 
         cases consumers have been effective in controlling their risk 
         exposure by transferring it to other parties. 
          
         Since security is risk control, not risk elimination, a protocol 
         enhancement that can be deployed immediately and mitigate a risk is 
         attractive even if another possible protocol enhancement might 
         become available that eliminates that risk. 
          
         A distinction must be made between the presence of protocol errors 
         that entirely eliminate the security of a protocol and understood 
         limitations of a protocol that mean that it does not provide 
         protection against every possible attack. 
          
       1.2 Beyond "End-to-End" 
          
         S/MIME, like PEM before it and also PGP is a product of the end-to-
         end security doctrine. The security of a message should be unbroken 
         from origin through to reception. 
          
         The origins of this doctrine are surprisingly difficult to find. 
         Almost none of the invocations of the end-to-end security principle 
         contain any form of citation. Those that do contain a citation 
         usually refer to one of David ClarkÆs paper describing the end-to-
         end argument in general. Unfortunately these papers deal with 
         complexity of protocol design and not security.  
          
         The end-to-end security principle appears to be the result of 
         subsequent efforts to adopt the end-to-end argument as a universal 
         truth. Unfortunately this claim is simply not substantiated, 
         particularly in respect of Internet security architecture. The fact 
         that no true æend-to-endÆ security architecture has been deployed 
         to date despite ten years of continuous effort requires that this 
         doctrine be re-examined. 
          

          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 4] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
         Re-examination of end-to-end is particularly critical when the 
         widespread success of edge security measures such as VPNs and 
         Firewalls is considered. Edge security measures have provided 
         security benefits that are both significant and measurable.  
          
         In the case of a personal email sent from one individual to another 
         the end-to-end principle offers a clear security advantage. In this 
         case the risk that network administrators at either end of the 
         communication might read or modify the contents or of an email 
         message is certainly significant. But this circumstance represents 
         only one of the many situations in which email is used. 
          
       1.3 Do no harm 
          
         Sending an S/MIME message today involves an element of risk. 
         Despite the fact that S/MIME has been an IETF draft standard for 
         many years, a significant number of email clients do not support 
         S/MIME and of those that do support S/MIME several provide a user 
         experience that can only be described as æuser-hostileÆ. Instead of 
         providing the email recipient with confidence that the message sent 
         is secure, several email clients æwarnÆ the user when a signed 
         message is received. 
          
         An Internet user should never be placed at a disadvantage when they 
         choose to enable security. 
          
       1.4 The S/MIME Sender Problem 
          
         The patchy nature of S/MIME support is a significant factor in 
         reducing the willingness of users to sign outgoing messages. Unless 
         the sender knows (and remembers) the capabilities of the 
         recipientÆs email client it is usually best to avoid use of S/MIME 
         in case this causes annoyance. 
          
       1.5 Support for S/MIME Without Cryptography 
          
         The S/MIME specification provides developers with instructions for 
         implementing cryptographic security. Unfortunately the 
         specification does not provide guidelines for applications that do 


          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 5] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
         not support cryptography but may nevertheless receive signed 
         messages. 
          
         While support for cryptographic processing inevitably requires the 
         application developer to spend considerable time and effort, 
         unpacking a multipart/signed container to display the contents 
         requires no more effort than the processing of any other MIME type 
         and developers should be encouraged to provide this minimal level 
         of support. 
          
       1.6 Locating Public Keys 
          
         Location of public keys has been a longstanding problem in PKI 
         deployments. First the client must discover the public key of the 
         party they wish to communicate with, secondly a trust path must be 
         constructed that establishes the key as trustworthy. 
          
         Location of a signing key is often simplified by including the 
         certificate of the signing key in the signed message itself. This 
         is also desirable for security reasons since it ensures that the 
         certificate subject and any attributes associated with the signing 
         certificate are strongly bound to the message certificate. If this 
         is not done there is the potential for a certificate substitution 
         attack. 
          
         Discovery of the trust path is a considerably harder problem, 
         particularly when cross certification is involved. The sender of a 
         signed message cannot know the trustworthiness criteria that will 
         be applied by the recipient. In a cross certification environment 
         the trust graph is a heterarchy with multiple roots, the sender 
         cannot know which roots the receiver trusts. It is therefore 
         necessary for the receiver to perform discovery of the trust path. 
          
         Directories based on the X.500 data model have been widely promoted 
         as a solution to the problem of discovering X.509 certificates. In 
         practice neither LDAP nor X.500 have provided much value outside 
         deployment in closed environments. Paradoxically it is the value of 
         the directory as the central hub of the enterprise information 
         infrastructure that constrains its use. Enterprises recognize the 
         value of perimeter security and resist proposals to expose internal 
          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 6] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
         directory services to external parties, whether through a border 
         directory or any form of data connector. The consensus amongst 
         network security administrators is that LDAP is not a protocol that 
         should be allowed to traverse firewalls. This consensus is unlikely 
         to change at any time. 
          
         As with any other routing problem, the trust path discovery problem 
         is tractable provided the necessary data is available. In the 
         Internet æend-to-endÆ architecture, routing functions are actually 
         performed in the network itself and not at the end points. The 
         trust path discovery problem is tractable when it can be delegated 
         to a service that maintains the complete  
          
       1.7 Validating Public Keys 
          
         Once a public key has been located the application should determine 
         whether it is trustworthy before treating the corresponding 
         communication as secure. 
          
         While X.509 path validation is considerably simpler than path 
         discovery, a device that cannot perform this service for itself 
         should have the capability of delegating validation. 
          
       2. Architecture 
          
         The entity-to-entity security model is entirely pragmatic and 
         opportunistic in the application of security enhancements.  
          
         Any entity in the communication path may apply a security 
         enhancement provided that the entity knows that a subsequent entity 
         in the communication path will ensure that the message is delivered 
         to the recipient in an acceptable form. 
         Any entity in the communication path may remove any security 
         enhancement for any reason provided that the enhancement is not 
         marked as being specifically intended for a subsequent entity in 
         the communication path. 
         Any entity in the communication path may remove any security 
         enhancement if it is known that this is necessary to ensure that 
         the message is delivered to the recipient in an acceptable form. 
          
          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 7] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
       2.1 Authentication 
          
         A signature may be opportunistic or explicit. An explicit signature 
         is added by means of explicit user intervention 

       2.1.1 Originator 
          
         An originator may add a signature opportunistically or by means of 
         explicit user intervention. An opportunistic signature may be added 
         automatically whenever the incoming edge server or the receiver is 
         known to provide acceptable support for an end user signature. 
          
         End to end security is achieved in the case that the end user is 
         known to provide acceptable signature support. 

       2.1.2 Outgoing Edge Server 
         An outgoing edge server may add a signature opportunistically or by 
         means of explicit user intervention. An opportunistic signature may 
         be added automatically whenever the incoming edge server or the 
         receiver is known to provide acceptable support for a domain 
         signature. 
          
         An outgoing edge server may remove a signature if it is not known 
         that the incoming edge server provides acceptable support for the 
         type of signature present. 

       2.1.3 Incoming Edge Server 
          
         An incoming edge server may remove a signature if it is not known 
         that the receiver provides acceptable support for the type of 
         signature present. 
          
         An incoming edge server may verify the signature and pass this 
         information on to the receiver using a discretionary header 
         encoding scheme. 

       2.1.4 Receiver 
          
         A receiver may verify a signature if present. 
          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 8] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
          
       3. SMTP Extensions 
          
          The SMTP option SMIME is used to advertise support for S/MIME 
          messages.  
           
          A server that returns the SMIME option in response to the SMTP EHLO 
          command undertakes to ensure that any message containing S/MIME 
          enhancements will be delivered to the user in an acceptable 
          fashion. In particular:  
           
            . The server undertakes to ensure that an S/MIME message is 
               delivered in an acceptable manner regardless of the 
               capabilities of the end users MUA. 
            . Messages that carry an S/MIME signature will be treated as if 
               they were unsigned if the recipient is unable to verify the 
               signature for any reason. 
           
          A server that returns the SMIME option in response to the SMTP EHLO 
          command does NOT undertake to verify the signature on any signed 
          message in any way. In particular: 
           
            . A compliant server MAY simply strip the S/MIME package and 
               deliver the message content. 
          
       4. DNS Extension 
          
         The MARID policy extension SMIME may be used to specify the email 
         authentication and encryption policy for all mail originating from 
         a domain. 
          
       4.1 Policy Element 
          
         The Policy element specifies the security policy for a DNS domain. 
          
         The Policy element may contain the following elements. 
          
             Key                     [Any number] 
                A signature key that may be used to sign messages from the 
                domain. 
             X509                    [Any number] 
                An X.509 cdertificate that may be used to sign messages from 
                the domain 
          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 9] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
             AuthenticationPolicy    [Any number] 
                An authentication policy corresponding to the domain 
             Encryption Policy       [Any number] 
                An encryption policy corresponding to the domain 
          
         The following schema defines the Policy element: 
          
         [TBS] 
          
       4.2 Key Element 
          
         The Key element specifies a signature key that may be used to sign 
         messages from the domain. 
          
         The Key element contains the following attributes: 
          
             Algorithm          [required] 
                The signature algorithm corresponding to the key 
             Value              [required] 
                The key value (base 64 encoded) 
          
         The following schema defines the Key element: 
          
         [TBS] 
          
       4.3 X509 Element 
          
         The X509 element is used to authenticate an X509 certificate that 
         is used to sign messages from the domain by means of a message 
         digest function. 
          
         The X509 element contains the following attributes: 
          
             X509IssuerAndSerial[Optional] 
                Specifies the X509 Issuer and Serial number of the 
                certificate in the same format used in XML Signature. 
             Type                    [required] 
                The type of certificate, valid values are: EndEntity, CA 
             DigestAlgorithm         [required] 
                The digest algorithm as specified by the S/MIME specification 
          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 10] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
             DigestValue             [required] 
                The result of applying the specified message digest function 
                to the certificate (base64 encoded) 
             Locator            [optional] 
                A URI that resolves to the certificate 
          
         The following schema defines the Key element: 
          
         [TBS] 
          
       4.4 Authentication Policy 
          
         The AuthenticationPolicy element specifies the authentication 
         policy of the domain.  
          
         If an email message is received that is in violation of the 
         specified authentication policy for the domain it SHOULD be 
         rejected. A security notice may be returned to the corresponding 
         domain. 
          
         The following authentication protocols are defined: 
          
             SMIME 
                SMIME security. 
             PGP 
                PGP security. 
             Other 
                Any other security protocol. 
          
          The following authentication policies are defined: 
          
             EHLO 
                The specified authentication protocol will always be applied 
                whenever the receiving server advertises support in response 
                to EHLO. 
             Always 
                The specified authentication protocol will always be applied.  
             Never 
                The specified authentication protocol will never be applied. 

          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 11] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
             Undefined 
                The specified authentication protocol may or may not be 
                applied. 
          
         The AuthenticationPolicy element contains the following attributes: 
          
             Protocol           [required] 
                The authentication protocol, valid values include SMIME and 
                PGP. 
             Policy             [required] 
                The authentication policy identifier, valid values include 
                EHLO, Always, Never and Undefined. If a different policy 
                identifier is specified it MUST be treated as if it was 
                Undefined. 
          
         The following schema defines the AuthenticationPolicy element: 
          
         [TBS] 
          
       4.5 Encryption Policy 
          
         The EncryptionPolicy element specifies the authentication policy of 
         the domain.  
          
         If an email message is received that is in violation of the 
         specified authentication policy for the domain it SHOULD be 
         accepted if the policy would require that the message be sent 
         encrypted but SHOULD be rejected if the policy would require that 
         the message be sent plaintext. A security notice SHOULD be returned 
         to the corresponding domain in either case. 
          
         The following encryption protocols are defined: 
          
             TLS 
                TLS security by means of the SMTP STARTTLS command. 
             SMIME 
                SMIME security. 
             PGP 
                PGP security. 

          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 12] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
             Other 
                Any other security protocol. 
          
          The following encryption policies are defined: 
          
             EHLO 
                The specified encryption protocol will always be applied 
                whenever the receiving server advertises support in response 
                to EHLO. 
             XKMS 
                The specified encryption protocol will always be applied 
                whenever the receiving domain advertises the existence of a 
                corresponding XKMS server by means of the SRV record 
                specified in the XKMS 2.0 specification. 
             Always 
                The specified encryption protocol will always be applied.  
             Never 
                The specified encryption protocol will never be applied. 
             Undefined 
                The specified encryption protocol may or may not be applied. 
          
         The EncryptionPolicy element contains the following attributes: 
          
             Protocol           [required] 
                The authentication protocol, valid values include STATLS, 
                SMIME and PGP. 
             Policy             [required] 
                The encryption policy identifier, valid values include EHLO, 
                XKMS, Always, Never and Undefined. If a different policy 
                identifier is specified it MUST be treated as if it was 
                Undefined. 
          
         The following schema defines the EncryptionPolicy element: 
          
         [TBS] 
          
       5. S/MIME Extensions 
          



          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 13] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
         Entity to entity signatures MAY be added automatically or through 
         the explicit intervention of the user. It is important that 
         applications are able to distinguish between these cases. 
          
       5.1 Signed Attribute OIDs 
          
         The use of the following OIDs as signed attributes allows the 
         status of the signature to be included within the scope of the 
         signature itself. 
          
         [TBS] 
          
       5.2 MIME Header 
          
         The following MIME header SHOULD be used to allow servers to 
         determine the status of the signature without decoding the S/MIME 
         signature package. 
          
         [TBS] 
          
       6. Client User Interface 
          
         All clients should tolerate multipart/signed messages of any form 
         without negatively impacting the user experience. 
          
         Should treat a message with an invalid signature as if it were 
         unsigned. 
          
         Should only warn users of invalid signature if it is known that the 
         message should have been signed. Rejecting the message is the 
         preferred course. 
          
         Should support the logotypes extension to present trust paths in a 
         graphical fashion. Important to display CA logos since these serve 
         as surrogate brands for companies that do not have a well known 
         logo. Logo display MUST be unspoofable. 
          
         Should support the automatic discovery of path discovery and key 
         registration services. In addition, why not discover the outgoing 
         MTA and the connection to the incoming MTA automatically? 
          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 14] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
          
         Should support the use of delegated path discovery. May support 
         delegated path delegation. 
          
         Should support simple registration process using the existing 
         client credentials used to access the email host to register a key 
         pair. 
          
       7. Key Management 
          
         For mechanisms for locating and validating keys see the XKMS 
         specification [XKMS]. 
          
         XKMS is a key centric public key infrastructure exposed as a Web 
         Service. We observe that as far as an application client is 
         concerned all public key operations involve a question of the form 
         æwhat is the public key that should be used for cryptographic 
         operation X when attempting to communicate using protocol Y to 
         entity Z. The XML Key Information Service Specification (X-KISS) 
         allows such a client to delegate this question to a Web Service. 
          
       References 
        
         [SMIME] B. Ramsdell, S/MIME Version 3 Message Specification RFC 
         2366, http://www.ietf.org/rfc/rfc2633.txt  
           
          [XKMS] Hallam-Baker, XML Key Management Specification Version 2.0 
                 (XKMS 2.0), W3C Candidate Recommendation 5 April 2004, 
                 http://www.w3.org/TR/2004/CR-xkms2-bindings-20040405/  
                            
          1  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
             Levels", BCP 14, RFC 2119, March 1997 
           
        
       Acknowledgments 
        
       The author acknowledges the contributions made to this proposal by 
       Nico Popp, Alex Deacon and Jeff Burstein. 
        



          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 15] 
          
          
          
                              Entity-to-Entity S/MIME              July 2004 
          
          
        
       Copyright Statement 
        
       Copyright (C) The Internet Society (year).  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." 
        
       "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 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." 
        
        
       Author's Addresses 
        
       Phillip Hallam-Baker 
       VeriSign Inc. 
       Email: pbaker@verisign.com 
               























          
          
         Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 16]