idnits 2.17.1 draft-ietf-dnsext-delegation-signer-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 157: '...in a secure zone MUST contain a DS RR ...' RFC 2119 keyword, line 160: '...ld zone is unsecure. DS sets MUST NOT...' RFC 2119 keyword, line 163: '... In a zone that uses DS, insecure delegations MUST have the NODS[TBD]...' RFC 2119 keyword, line 169: '...Delegating zones MUST NOT store KEY re...' RFC 2119 keyword, line 173: '... Zone MUST self sign its apex KEY set...' (8 more instances...) -- The abstract seems to indicate that this document updates RFC1035, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC2535, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC3008, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC2119. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2001) is 8228 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1035' on line 420 looks like a reference -- Missing reference section? 'RFC2535' on line 423 looks like a reference -- Missing reference section? 'RFC3090' on line 429 looks like a reference -- Missing reference section? 'RFC3008' on line 426 looks like a reference -- Missing reference section? 'Parent' on line 435 looks like a reference -- Missing reference section? 'TBD' on line 163 looks like a reference -- Missing reference section? 'OKbit' on line 432 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group Olafur Gudmundsson 3 INTERNET-DRAFT October 2001 4 6 Updates: RFC 1035, RFC 2535, RFC 3008. 8 Delegation Signer record in parent. 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Comments should be sent to the authors or the DNSEXT WG mailing list 31 namedroppers@ops.ietf.org 33 This draft expires on March 26, 2002. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). All rights reserved. 39 Abstract 41 The Delegation Signer (DS) RR set is stored in a delegating (parent) 42 zone at each delegation point, and indicates the keys used in the 43 delegated (child) zone. The main design goal of the DS RR simplify the 44 operation of secure delegations by eliminating the need to store the 45 same RR in parent and child, as is done with the NS RR set and the KEY 46 set in RFC2535. 47 Secure resolvers need to take an additional step with DS to verify a 48 child's KEY RR set. Operationally this schema is much simpler as 49 operation of the two zones at delegation is now decoupled to great 50 extent. 51 This document updates RFC1035, RFC2535 and RFC3008. 53 1 - Introduction 55 Familiarity with the DNS system [RFC1035], DNS security extensions 56 [RFC2535] and DNSSEC terminology [RFC3090] is important. 58 When the same data can reside in two administratively different DNS 59 zones, the data frequently gets out of sync. NS record in a zone 60 indicates that this name is a delegation and the NS record lists the 61 authorative servers for the real zone. Based on actual measurements 62 10-30% of all delegations in the Internet have differing NS sets at 63 parent and child. There are number of reasons for this, including lack 64 of communication between parent and child and bogus name-servers being 65 listed to meet registrar requirements. 67 DNSSEC [RFC2535,RFC3008,RFC3090] specifies that child must have its 68 KEY set signed by the parent to create a verifiable chain of KEYs. 69 There is some debate, where the signed KEY set should reside, 70 parent[Parent] or child[RFC2535]. If the KEY set resides at the child, 71 frequent two way communication is needed between the two parties. 72 First the child needs to transmit the key set to parent and then the 73 parent sends the signed set or signatures to child. If the KEY set 74 resides at the parent the communication is reduced as the child only 75 sends changed key sets to parent. 77 DNSSEC[RFC2535] requires that the parent store NULL key set for 78 unsecure children, this complicates resolution process in many cases 79 as servers for both parent and child need to be queried for KEY set if 80 the child server does not return a KEY set. Storing the KEY record 81 only in the parent zone simplifies this and allows the elimination of 82 the NULL key set. 84 Another complication of the DNSSEC KEY model is that KEY record is 85 used to store DNS zone keys and public keys for other protocols. 86 There are number of potential problems with this including: 87 1. KEY set can become quite large if many applications/protocols 88 store their keys at the zone apex. Possible protocols are IPSEC, 89 HTTP, SMTP, SSH and others that use public key cryptography. 90 2. Key set may require frequent updates. 91 3. Probability of compromised/lost keys increases and triggers 92 emergency key rollover procedures. 94 4. Parent may refuse sign key sets with NON DNS zone keys. 95 5. Parent may not meet the child's expectations in turnaround time 96 in resigning the key set. 98 Given these and other reasons there is good reason to explore 99 alternatives to using only KEY records to create chain of trust. 101 Some of these problems can be reduced or eliminated by operational 102 rules or protocol changes. To reduce the number of keys at apex, a 103 rule to require applications to store their KEY records at the SRV 104 name for that application is one possibility. Another is to restrict 105 KEY record to DNS keys only and create a new type for all non DNS 106 keys. Third possible solution is to ban the storage of non DNS related 107 keys at zone apex. There are other possible solutions but they are 108 outside the scope of this document. 110 1.2 - Reserved words 112 The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", 113 "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be 114 interpreted as described in RFC2119. 116 2 - DS (Delegation KEY Signer) 118 2.1 - Delegation Signer Record model 120 This document proposes an alternative to the KEY record chain of 121 trust, that uses a special record that can only reside at the parent. 122 This record will identify the key(s) that child are allowed to self 123 sign its own KEY set. 125 The chain of trust is now established by verifying the parent KEY set, 126 the DS set from the parent and the KEY set at the child. This is 127 cryptographically equivalent to just using KEY records. 129 Communication between the parent and child is greatly reduced, since 130 the child only needs to notify parent about changes in keys that sign 131 its apex KEY RRset. Parent is ignorant of all other keys in the 132 child's apex KEY RRset, and the child maintains full control over the 133 apex KEY set and its content. Child can maintain any policies over 134 its DNS and other KEY usage with minimal impact on parent. Thus if 135 child wants to have frequent key rollover for its DNS keys parent does 136 not need to be aware of it as the child can use one key to only sign 137 its apex KEY set and other keys to sign the other record sets in the 138 zone. 140 This model fits well with slow roll out of DNSSEC and islands of 141 security model. In the islands of security model someone that trusts 142 "good.example." can preconfigure a key from "good.example." as a 143 trusted keys and from then on trusts any data that is signed by that 144 key or has a chain of trust to that key. If "example." starts 145 advertising DS records, "good.example." does not have to change 146 operations, by suspending self-signing. DS records can also be used to 147 identify trusted keys instead of KEY records. One further advantage 148 is the information stored in the parent is minimized, as only records 149 for secure delegations are needed. 151 The main disadvantage of this approach that verifying delegations KEY 152 set requires twice as many signature verification operations. There 153 is no impact on the number of signatures verified for other RR sets. 155 2.2 Protocol change 157 Each secure delegation in a secure zone MUST contain a DS RR set. If 158 a DS RR set accompanies the NS RR set, the intent is to state that the 159 child zone is secured. If an NS RR set exists without a DS RR set the 160 intent is to state that the child zone is unsecure. DS sets MUST NOT 161 appear at non delegations or at zone APEX. 163 In a zone that uses DS, insecure delegations MUST have the NODS[TBD] 164 bit set in the NXT record. This is required to differenciate this 165 delegation from Secure RFC2535 delegation. 167 Updates RFC2535 sections 2.3.4 and 3.4, as well as RFC3008 section 168 2.7: 169 Delegating zones MUST NOT store KEY records for delegations. The only 170 records that can appear at delegation in parent are NS, SIG, NXT and 171 DS. 173 Zone MUST self sign its apex KEY set, it SHOULD sign it with a key 174 that corresponds to a DS record in the parent. The KEY used to sign 175 the apex KEY RRset MAY sign other RRsets in the zone. 177 If child apex KEY RRset is not signed with one of the keys specified 178 in the DS record the child is locally secure[RFC3090] and SHOULD only 179 be considered secure if the resolver has been configured to trust the 180 key used. 182 Authorative server answering a query with the OK bit[OKbit] set, MUST 183 include the DS records and NXT record along with signatures in answers 184 for a delegation and space is available. DS and NXT records SHOULD 185 have lower priority than address records but higher priority than KEY. 186 Caching servers SHOULD return the DS and parent NXT record(s) in the 187 additional section under the same condition. 189 2.2.1 - Comments on protocol change 191 Over the years there has been various discussions on that the 192 delegation model in DNS is broken as there is no real good way to 193 assert if delegation exists. In RFC2535 version of DNSSEC the 194 authentication of a delegation is the NS bit in the NXT bitmap at the 195 delegation point. Something more explicit is needed and the DS record 196 addresses this for secure delegations. 198 DS record is the first DNS record that can only appear on the upper 199 side of a delegation. NS records appear at both sides as do SIG and 200 NXT. All other records can only appear at the lower side. This will 201 cause some problems as servers authorative for parent, reject DS 202 record even if the server understands unknown types, or will not hand 203 them out unless explicitly asked. Similarly a nameserver acting as a 204 authorative for child and as a caching recursive server may never 205 return the DS record. 207 A caching server that supports unkown types, does not care from which 208 side DS record comes from and thus does not have to be changed. 209 Different TTL values on the child's NS set and parents DS set can 210 cause the DS set to expire before the NS set. 212 Secure resolvers need to know about the DS record and how to interpret 213 it. In the worst case, introducing the DS record, doubles the 214 signatures that need to be checked to validate a KEY set. 216 2.3 Wire format of DS record 218 The DS (type=TDB) record consists of algorithm, key tag and SHA-1 219 digest of the public key KEY record allowed to sign the child's 220 delegation. 222 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | key tag | algorithm | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | SHA-1 digest | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | (20 bytes) | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 The key tag is calculated as specified in RFC2535, Algorithm MUST be 239 an algorithm number assigned in the range 1..251. The SHA-1 digest is 240 calculated over the canonical name of the delegation followed by the 241 RDATA of the KEY record. 242 The size of the DS RDATA is 23 bytes, regardless of key size. 244 2.3.1 Justifications for fields 246 The algorithm and key tag fields are here to allow resolvers to 247 quickly identify the candidate KEY records to examine. The key tag 248 adds some greater assurance than SHA-1 digest on its own. SHA-1 is a 249 strong cryptographic checksum, it is real hard for attacker to 250 generate a KEY record that has the same SHA-1 digest. Combining the 251 name of the key and the key data as input to the digest provides 252 stronger assurance of the binding. 254 This format allows concise representation of the keys that child will 255 use, thus keeping down the size of the answer for the delegation, 256 reducing the probability of packet overflow. The SHA-1 hash is strong 257 enough to uniquely identify the key. This is similar to the PGP 258 footprint. 260 DS record is also well suited to lists trusted keys for islands of 261 security in configuration files. 263 2.4 Presentation format of DS record 265 The presentation format of DS record consists of 2 numbers followed by 266 digest presented in hex. 267 foo.example DS 12345 3 123456789abcdef67890 269 2.5 Transition issues for installed base 271 RFC2535 compliant resolver will assume that all DS secured delegations 272 are locally secure. This is a bad thing, thus it might be necessary 273 for a transition period to support both DS and SIG@Child. The cost is 274 one or more signatures in the answer for KEY records and that early 275 adopters have to use cumbersome communications that DS solves. 277 2.6 Backwards compatibilty with RFC2535 SIG@child and RFC1035 279 This section documents how a resolver determines the type of 280 delegation. 281 RFC1035 delegation has: 283 RFC1035 NS 285 RFC2535 adds the following two cases: 287 Secure RFC2535: NS + NXT + SIG(NXT) 288 NXT bit map contains: NS SIG NXT 289 Insecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT) 290 NXT bit map contains: NS SIG KEY NXT 291 KEY must be null-key. 293 DS adds the following two states: 295 Secure DS: NS + DS + SIG(DS) + NXT + SIG(NXT) 296 NXT bit map contains: NS SIG NXT DS 297 Insecure DS: NS + NXT + SIG(NXT) 298 NXT bit map contains: NS SIG KEY NXT NODS 300 If the NODS bit is not used, a resover can not determine if this is a 301 DS delegation zone. Thus is not able to determine if this delegtion is 302 a secure RFC2535 or a insecure DS. 304 2.6.1 NODS support in servers 306 NODS is a virtual type, servers MUST refuse to store any record of 307 this type. No special processing is required on answers. 309 3 Resolver Example 311 To create a chain of trust resolver goes from trusted KEY to DS to 312 KEY. 314 Assume the key for domain "example." is trusted. In zone "example." 315 we have 316 example. KEY 317 secure.example. DS tag=10243 alg=3 318 secure.example. NS ns1.secure.example. 319 NS ns2.secure.example. 320 secure.example. NXT NS SIG NXT DS unsecure.example. 321 secure.example. SIG(NXT) 322 secure.example. SIG(DS) 323 unsecure.example NS ns1.unsecure.example. 324 unsecure.example NS ns2.unsecure.example. 326 unsecure.example. NXT NS SIG NXT NODS .example. 327 unsecure.example. SIG(NXT) 329 In zone "secure.example." we have 330 secure.example. SOA 331 secure.example. NS ns1.secure.example. 332 NS ns1.secure.example. 333 secure.example. KEY 334 KEY 335 KEY 336 secure.example. SIG(KEY) 337 secure.example. SIG(SOA) 338 secure.example. SIG(NS) 340 In this example the trusted key for "example." signs the DS record for 341 "secure.example.", making that a trusted record. The DS record states 342 what key is expected to sign the KEY RRset at "secure.example". Here 343 "secure.example." has three different KEY records and the KEY 344 identified in the DS record signs the KEY set, thus the KEY set is 345 validated and trusted. Note that one of the other keys in the keyset 346 actually signs the zone data, and resolvers will trust the signatures 347 as the key appears in the KEY set. 349 This example has only one DS record for the child but there no reason 350 to outlaw multiple DS records. More than one DS record is needed 351 during signing key rollover. It is strongly recommended that the DS 352 set be kept small. 354 Resolver determines the security status of "unsecure.example." by 355 examining the parent size NXT for this name. 357 3.1 Resolver cost estimates for DS records 359 From a RFC2535 resolver point of view for each delegation followed to 360 chase down an answer one KEY record has to be verified and possibly 361 some other records based on policy, for example the contents of the NS 362 set. Once the resolver gets to the appropriate delegation validating 363 the answer may require verifying one or more signatures. A simple A 364 record lookup requires at least N delegations to be verified and 1 365 RRset. For a DS enabled resolver the cost is 2N+1. For MX record the 366 cost where the target of the MX record is in the same zone as the MX 367 record the costs are N+2 and 2N+2. In the case of negative answer the 368 same ratios hold true. 370 Resolver may require an extra query to get the DS record and this may 371 add to the overall cost of the query, but this is never worse than 372 chasing down NULL KEY records from the parent in RFC2535 DNSSEC. 374 DS adds processing overhead on resolvers, increases the size of 375 delegation answers but much less than SIG@Parent. 377 4 Acknowledgments 379 Number of people have over the last few years contributed number of 380 ideas that are captured in this document. The core idea of using one 381 key to only sign key set, comes from discussions with Bill Manning and 382 Perry Metzger on how to put in a single root key in all resolvers. 383 Alexis Yushin, Brian Wellington, Jakob Schlyter, Scott Rosen, Edward 384 Lewis, Dan Massey, Lars-Johan Liman, Mark Kosters, Olaf Kolman, Miek 385 Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, 386 Rob Austein, Derek Atkins, Roy Arends, and others have provided useful 387 comments. 389 4 - Security Considerations: 391 This document proposes a change to the validation chain of KEY records 392 in DNS. The change in is not believed to reduce security in the 393 overall system, in RFC2535 DNSSEC child must communicate keys to 394 parent and prudent parents will require some authentication on that 395 handshake. The modified protocol will require same authentication but 396 allows the child to exert more local control over its own KEY set. 398 There is a possibility that an attacker can generate an valid KEY that 399 matches all the DS fields thus starting to forge data from the child. 400 This is considered impractical as on average more than 2^80 keys must 401 be generated before one is found that will match. 403 DS record is a change to DNSSEC protocol and there is some installed 404 base of implementations, as well as text books on how to set up 405 secured delegations. Implementations that do not understand DS record 406 will not be able to follow the KEY to DS to KEY chain and consider all 407 zone secured that way insecure. 409 5 - IANA Considerations: 411 IANA needs to allocate RR type code for DS from the standard RR type 412 space. 414 IANA needs to allocate RR type code for the virtual NODS record from 415 the standard RR type space. Note: SINK (40) was never implemented and 416 that type code can be reused for NODS. 418 References: 420 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 421 Specification'', STD 13, RFC 1035, November 1987. 423 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC 424 2535, March 1999. 426 [RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing 427 Authority'', RFC 3008, November 2000. 429 [RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone 430 Status'', RFC 3090, March 2001. 432 [OKbit] D. Conrad, ``Indicating Resolver Support of DNSSEC'', work in 433 progress , April 2001. 435 [Parent] R. Gieben, T. Lindgreen, ``Parent stores the child's zone 436 KEYs'', work in progress , May 2001. 439 Author Address 441 Olafur Gudmundsson 442 3826 Legation Street, NW 443 Washington, DC, 20015 444 USA 445 447 Appendix A: Changes from Prior versions 449 Changes from version 02 450 Added text outlawing DS at non delegations. 451 Added table showing the contents of DS, SIG@child, and RFC1034 452 delegations. 453 Added the NODS type/bit definition to distiguish insecure DS 454 delegation from secure SIG@child one. 455 Added the requirement that NXT be returned with referal answers. 456 Minor text edits. 458 Changes from version 01 459 Deleted KEY size field as it did not contribute anything but 460 complexity. 461 Number of wordsmith changes to make document more readable. 462 The word CAN was used when SHOULD was intended. 463 Deleted section 2.4 "Justifications for compact format" moved relevant 464 text to section 2.2. 465 Reverse alphabetized the acknowledgments section. 466 Reorganized sections 1 and 2 for readability. 468 Changes from version 00 469 Changed name from DK to DS based on working group comments. 470 Dropped verbose format based on WG comments. 471 Added text about TTL issue/problem in caching servers. 472 Added text about islands of security and clarified the cost impact. 473 Major editing of arguments and some reordering of text for clarity. 474 Added section on transition issues. 476 Full Copyright Statement 478 Copyright (C) The Internet Society (2001). All Rights Reserved. 480 This document and translations of it may be copied and furnished to 481 others, and derivative works that comment on or otherwise explain it 482 or assist in its implementation may be prepared, copied, published and 483 distributed, in whole or in part, without restriction of any kind, 484 provided that the above copyright notice and this paragraph are 485 included on all such copies and derivative works. However, this 486 document itself may not be modified in any way, such as by removing 487 the copyright notice or references to the Internet Society or other 488 Internet organizations, except as needed for the purpose of developing 489 Internet standards in which case the procedures for copyrights defined 490 in the Internet Standards process must be followed, or as required to 491 translate it into languages other than English. 493 The limited permissions granted above are perpetual and will not be 494 revoked by the Internet Society or its successors or assigns. 496 This document and the information contained herein is provided on an 497 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 498 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 499 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 500 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 501 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."