idnits 2.17.1 draft-otis-dkim-options-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 563. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 21, 2005) is 6698 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.crocker-csv-csa' == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-04 ** Downref: Normative reference to an Informational draft: draft-crocker-email-arch (ref. 'I-D.crocker-email-arch') ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 pre-workgroup D. Otis 3 Internet-Draft Trend Micro, NSSG 4 Expires: June 24, 2006 December 21, 2005 6 Extended Options for DomainKeys Identified Mail (DKIM) 7 draft-otis-dkim-options-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on June 24, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes options that extend protections offered by 41 DKIM. These options include Binding-Advice & Role-Assertion, Opaque- 42 Identifier, and an In-Channel check. The Binding-Advice & Role- 43 Assertion offers guidance in isolating the source of a message, in 44 addition to establishing message signature expectations. The Opaque- 45 Identifier (O-ID) offers protection from replay abuse and intra- 46 domain spoofing, even when email-addresses are not associated with 47 the signing-domain. The In-Channel check provides a means to 48 mitigate DNS lookups for avoiding possible message replay abuse. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Binding-Advice & Role-Assertion . . . . . . . . . . . . . . . 5 55 4. Opaque-Identifier . . . . . . . . . . . . . . . . . . . . . . 8 56 5. In-Channel Check . . . . . . . . . . . . . . . . . . . . . . . 10 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 61 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 63 Intellectual Property and Copyright Statements . . . . . . . . 13 65 1. Introduction 67 Message signing, as exemplified by DomainKeys Identified Mail (DKIM) 68 [I-D.allman-dkim-base], is a mechanism to allow an assertion of an 69 accountable domain for an email message in transit. The assertion is 70 made by means of a digital signature included within a header, which 71 also validates the integrity of selected headers and message body 72 content subsequent to the signing of the message. 74 Combining DKIM with an authorization mechanism, referenced from an 75 email-address contained within the message, may result in unintended 76 consequences. The email-address domain owner may be unfairly held 77 accountable for abuse found subsequent to their authorization. As 78 the email-address domain owner often has no administrative oversight 79 or ability to rectify abuse issues, such accountability may place 80 them in peril of having their email refused. 82 Even when authorization is restricted to a single provider, the 83 email-address domain owner would still be relying upon this 84 provider's diligence, and may be unable to ascertain the cause for 85 refusals or remedy their situation. Such restriction on allowable 86 sources for email also interferes with existing email practices, such 87 as the use of list-servers or sending email using the email-address 88 of one's alma mater. To ensure fair treatment for email-address 89 domain owners, and to minimize the impact upon email practices, the 90 ability to refute messages should not be contingent upon the use of 91 an authorization scheme. 93 Indicating the results of an authorization that compares an email- 94 address domain to a signing-domain would be unsafe. Domain matching 95 only indicates the email-address is within the same Administrative 96 Unit as the signing-domain. Ambiguity in the display of the email- 97 address and one's limited ability to detect variations from prior 98 messages means such indications may mislead the recipient into 99 erroneously trusting the source of the message. 101 In addition, the entity directly involved with sending email should 102 be held accountable for abuse. Such an assignment of accountability 103 permits effective and timely remedies, and ensures innocent parties 104 are not inadvertently harmed. For email, such an entity could be 105 discerned by the remote IP address, a verified host name, or the 106 domain used to verify the DKIM-Signature. The DKIM-Signature should 107 be considered an aspect of the message transport, and not necessarily 108 directly associated with message content or any contained email- 109 address. 111 Restoring trust and establishing the expectation of a signature being 112 present within email messages can be accomplished by way of a 113 recognition strategy, instead of using an email-address authorization 114 mechanism. Perhaps one of the greatest assets of DKIM would be the 115 enhanced ability to recognize previous email sources. Simple email- 116 address and signing-domain comparisons permit all too common social 117 engineering techniques that are often involved in the spoofing of 118 email-addresses. A recognition strategy can safely highlight those 119 messages emanating from a source specifically recognized by the 120 recipient through a prior message. 122 The ability to recognize a unique email source is enhanced with the 123 use of the Binding-Advice & Role-Assertion, and the O-ID. The O-ID 124 and In-Channel check can further enhance protections that curtail 125 abusive message replays. The In-Channel check allows a reduction in 126 the overhead associated with abusive message replay protections. 128 Binding identifiers from a prior correspondent at the behest of the 129 recipient allows indications of recognition without the use of 130 complex and problematic email-address domain authorizations, which 131 may create significant support issues. To support the recognition of 132 a prior correspondent, the MUA could simply highlight those messages 133 from prior correspondents. This approach would offer a higher level 134 of assurance and trust without using any DNS lookups. Following the 135 verification of the DKIM-Signature, the identification of the message 136 source would be contained completely within the message itself. 138 When assuming legacy MUAs, scant protections are possible by the MTA 139 even using many DNS lookups and registering thousands of look-alike 140 domains. Due to limitations of ensuring the visibility of checked 141 domains, the MTA approach provides an alarmingly low level of email- 142 address protections. There is also a potential for an undesired 143 exposure of email-addresses in the 'i=' parameter. 145 The O-ID approach could be used to detect when a previous 146 correspondent appears to be from a different source. Without the 147 O-ID, detecting intra-domain spoofing would depend upon the signing- 148 domain verifying the validity of the email-address. The signed 149 message may even advise what other information should be compared 150 against the email-address. While in most cases the collected 151 relationships (bindings) would be made at the behest of the recipient 152 and require their approval, some relationships could be established 153 automatically. 155 When the email-address domain is within the signing-domain, and when 156 the message advises that these messages should always be signed, then 157 it should be safe to capture this assertion automatically. When 158 signature assurances are captured (cached), the MTA or MUA would be 159 able to detect when a message violated these expected relationships. 160 Before rejecting a message for not having the proper signature, a 161 check may be made to verify that the signature assurance remains 162 valid. 164 To recognize the source of a message when there are no assurances 165 being made regarding the email-address, an O-ID that tracks accounts 166 could be added by the signing-domain. This O-ID would become a part 167 of the captured relationship once approved by the recipient. A 168 provision has been added to indicate when the signing role has been 169 delegated. The message from a delegated signer is not allowed to 170 make "broad" recommendations with respect to the scope of a binding. 171 This delegated role will also require the O-ID to equal the left-most 172 label of the DKIM-Signature selector. 174 2. Definitions 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 Terminology: Terminology conforms to [I-D.crocker-email-arch]. 182 3. Binding-Advice & Role-Assertion 184 The displayed character-repertoire may be defined by the sender as 185 result of [RFC2047] or [RFC3492]. Even displaying raw puny-code 186 would represent a difficult basis for recognition, especially for 187 recipients who's native language is not based upon ASCII characters. 188 In addition, a large percentage of recipients only see the "display- 189 name" as defined by [RFC2822] (also called the "pretty-name") where 190 the email-address is not normally seen by the recipient. 192 A safe indication shown to the recipient would be that a message 193 source has been recognized as belonging to a prior correspondent. To 194 help achieve this goal, the signer of the message assists by 195 indicating which aspects of the message's information may be used to 196 isolate the message's source. 198 Three roles are defined in the following tables. For example, 199 although an MSA is indicated as providing the signature, this role 200 could be delegated to an MUA or another less trusted MSA. Detecting 201 the delegation of a role involves examining the DKIM-Key optional 202 parameters. Whenever the 'g=' has an email-address 203 assigned, or the 'w=' first letter is 'D' then the 204 role should be considered delegated. In the case of a delegated 205 role, the O-ID is derived from the DKIM-Signature 's=' 206 parameter. When the role is delegated and the 'u=' parameter is present, it MUST match that of the left- 208 most selector label. A "broad" assertion by a Delegated signer is 209 not valid. 211 +------+------------------------------------------------------------+ 212 | Code | Scope of Binding, and Role | 213 +------+------------------------------------------------------------+ 214 | w=b | Always signed by MSA, broad ass. across email-domain | 215 | w=n | Always signed by MSA, narrow ass. with email-address | 216 | w=d | Signed by MSA, broad association across email-domain | 217 | w=a | Signed by MSA, narrow association with email-address | 218 | w=o | Signed by MSA, association with Opaque-Identifier | 219 | none | Signed by MSA, no association assured | 220 | w=B | Always signed by Mediator, broad ass. across email-domain | 221 | w=N | Always signed by Mediator, narrow ass. with email-address | 222 | w=D | Signed by Mediator, broad association across email-domain | 223 | w=A | Signed by Mediator, narrow association with email-address | 224 | w=O | Signed by Mediator, association with Opaque-Identifier | 225 | w=M | Signed by Mediator, no association assured | 226 | w=X | Signed by MDA, no association assured | 227 +------+------------------------------------------------------------+ 229 When the DKIM-Signature header field has the option 'w=' with a value 230 of 'b','B','d', or 'D', then the email-address domain associated with 231 the signing-role together with the signing-domain can be used to 232 recognize the source of a message. With a value of 'n','N','a', or 233 'A', then the entire email-address associated with the signing-role 234 together with the signing-domain should be used to recognize the 235 source of a message. With a value of 'o', or 'O', the O-ID together 236 with the signing-domain can be used to recognize the source of a 237 message. With a value of 'M', 'X' or no 'w=' option (default), just 238 the signing-domain can be used to recognize the source of a message. 240 When the DKIM-Signature header field has the option 'w=' with a value 241 of 'X', this is used to verify that the message has been accepted by 242 the MDA of the signing-domain and the 'u=' parameter, if present, 243 represents an assessment made by the MDA. To ensure signatures are 244 not misused to perpetrate abusive message replays, the MDA may 245 overlay the 'b=' of other roles with "!MDA-verified" or 246 "!MDA-invalid". DKIM-Signature header fields containing the 'w=X' 247 option will include other DKIM-Signature header fields containing an 248 "!MDA-verified" signature overlay, in sequential order from the 249 beginning of the message. These additional DKIM-Signature header 250 fields are processed immediately following the processing of the 251 DKIM-Signature header field with the 'w=X' option, and before the 252 remainder of the message. A message with a DKIM-Signature header 253 field signed by a domain of a different Administrative Unit with the 254 'w=X' option is invalid and SHOULD be rejected. 256 When the DKIM-Signature header field has the option 'w=' with a value 257 of 'B','N','D', or 'A', then the email-address associated with the 258 DKIM-Signature should be found within a "Resent-*" header field. 259 Each DKIM-Signature should be uniquely associated with a MSA, 260 Mediator, or MDA role. The DKIM-Signature header field added by the 261 MDA or Mediator MUST be removed by the MSA prior to processing the 262 message. When a signature added by an MSA is known by the Mediator 263 to be currently invalid, the DKIM-Signature header field SHOULD be 264 removed or the Mediator may otherwise overlay the 'b=' 265 with "!Mediator-verified" or "!Mediator-invalid". 267 +------+-------------------+---------------+------------+----------+ 268 | Code | Binding | Assurances | Validation | Role | 269 +------+-------------------+---------------+------------+----------+ 270 | w=b | email-domain | always signed | DKIM key | MSA | 271 | w=n | email-address | always signed | DKIM key | MSA | 272 | w=d | email-domain | none | none | MSA | 273 | w=a | email-address | none | none | MSA | 274 | w=o | Opaque-Identifier | none | none | MSA | 275 | none | none | none | none | MSA | 276 | w=B | email-domain | always signed | DKIM key | Mediator | 277 | w=N | email-address | always signed | DKIM key | Mediator | 278 | w=D | email-domain | none | none | Mediator | 279 | w=A | email-address | none | none | Mediator | 280 | w=O | Opaque-Identifier | none | none | Mediator | 281 | w=M | none | none | none | Mediator | 282 | w=X | none | none | none | MDA | 283 +------+-------------------+---------------+------------+----------+ 285 When the DKIM-Signature header field has the option 'w=' with a value 286 of 'n', or 'b', and the email-address domain is within the signing- 287 domain as denoted by the 'd=' parameter, then the assurance 288 of a signature for this domain can be automatically cached. The 289 cached information should include both the domain where an assurance 290 has been made, and the label for a record used to confirm the 291 continued status of the assurance. A parameter within the DKIM-Key 292 can be used to consolidate where assurances are confirmed when 293 multiple DKIM-Keys are being used. When there are no parameters 294 added to the DKIM-Key, the default signature-assurance validation 295 location would be determined by the 'd=' and parameters 296 's='. The left-most label within the selector would be 297 used as follows: 299 "._dkim-sa.". 301 When the 'w=' option is present within the DKIM-Key, the value of 302 this parameter modifies the signature-assurance validation location 303 to be: 305 "._dkim-sa.". 307 The 'w=' option would be composed of 1 to 63 308 characters within the DKIM-Key and used to consolidate signature 309 assurances. The operation of this signature-assurance validation 310 record mechanism would take the form of a single A record lookup 311 where the existence of the record would validate a cached assurance. 313 ::= [ [ ] ] 314 ::= | 315 ::= | "-" 316 ::= | 317 ::= %x41-5A / %x61-7A 318 ::= "T" | "D" 319 ; Trusted or Delegated role 320 ::= %x30-39 321 ._dkim-sa. IN A 127.0.0.2 323 4. Opaque-Identifier 325 The Opaque-Identifier (O-ID) is an option that supports two different 326 mechanisms. One mechanism isolates the source of a message to a 327 specific account as denoted by the Binding-Advice & Role-Assertion. 328 The other mechanism provides a means to revoke messages being 329 abusively replayed. An O-ID added to the signature header MUST also 330 be a valid domain name label. The term 'opaque' means only the 331 domain creating the identifier understands the associations indicated 332 in Binding-Advice & Role-Assertion. There are two modes for creating 333 the O-ID. One mode would make the O-ID persistent with the account 334 used to access the signing-domain, and the other could be sequential 335 for cases where an account is not involved. A prefix added to a 336 sequential O-ID prevents collisions with identifiers used for 337 accounts. 339 If an identifier were added to an unsigned message, this would invite 340 forgery and therefore offer little value. A standardized O-ID, 341 included within the validated content of a signed message, would 342 offer significant value. A persistent O-ID would be most useful and 343 could be derived from the access server that authenticates the 344 account being used. 346 A sequential O-ID may be appropriate when distributing bulk mailings. 347 To identify abusers that may attempt to stage replay attacks, having 348 a unique identifier for each recipient could prove helpful. These 349 replay attacks could be done using the unchanged content of the 350 message, but sent to recipients that would consider the information 351 to be unsolicited. The reason for such a replay attack may be to 352 damage the reputation of the signing-domain. 354 The persistent O-ID would greatly aid the correlation of abuse and 355 the locating of compromised systems. This identifier could be 356 effective against systems compromised by Trojan programs, stolen 357 passwords, and cracked wireless access points, among many other 358 nefarious methods. Abuse reports that catalog signed messages and 359 that are correlated with a persistent O-ID would provide 360 incontrovertible evidence of where the source of a problem exists. 361 The publishing of the revocation record for the O-ID would also 362 provide feedback that actions were taken to rectify a policy breach. 364 In odd cases where an In-Channel check fails, a single lookup of a 365 revocation record for the O-ID returning no record would be an 366 indication that this particular O-ID is still authorized by the 367 signing-domain. This mechanism would be most valuable in those cases 368 where the message may have been forwarded, such as at the typical 369 alma mater, or where a mailing list opts to also forward signed 370 messages unaltered. 372 If there is a problem, the signature would offer the name of the most 373 capable domain able to remedy abuse. People can still safely use 374 their forwarding email accounts given to them by their school or 375 society. Mailing lists would be given a strong identifier upon which 376 to grant the replication of messages. Complaints would also likely 377 be directed to those most able to curtail future episodes of bad 378 behavior, i.e. the provider of the abusive account! 380 Within the signature header, a 'u=' parameter or 381 within the DKIM-Key, a 'w=' parameter where the first 382 letter is 'D' a would indicate the use of an O-ID. The operation of 383 this revocation record mechanism takes the form of a single A record 384 lookup where the return of a record indicates the O-ID has been 385 revoked. The O-ID would be composed of 1 to 63 characters and select 386 a record in this fashion: 388 ::= [ [ ] ] 389 ::= | 390 ::= | "-" 391 ::= | 392 ::= %x41-5A / %x61-7A 393 ::= "P" | "S" 394 ; Persistent and Sequential O-ID assignment 395 ::= %x30-39 396 ._dkim-or. IN A 127.0.0.2 398 When the first letter in the O-ID is 'P,' this represents an 399 identifier where the portion of the identifier to the right of the 400 leftmost '-' character is persistent with the account used to obtain 401 access. When the first letter is 'S,' then no portion of the 402 identifier can be used to isolate which account was used to obtain 403 access. 405 When the signing-domain has not revoked authorization for the O-ID, 406 no record would be returned and the remote DNS cache would retain the 407 absence of this record for a brief period of time, see [RFC2308]. 408 For the majority of cases, where messages are obtained directly from 409 the signing-domain, confirmation of an In-Channel check allows the 410 O-ID revocation check to be skipped. 412 The O-ID revocation check would be performing nearly an identical 413 lookup now ubiquitously done to investigate the status of the SMTP 414 client's IP address against a DNS black-hole list. Those addresses 415 or identifiers that warrant refusal are granted a long lived address 416 record to ensure their immediate refusal and limit DNS traffic 417 resulting from abusive sources. Otherwise, not offering a record 418 allows for the prompt cessation of an O-ID's authorization when the 419 situation regarding a particular identifier changes. The Time-To- 420 Live for negative DNS caching may be determined by the recipient, or 421 represent the lesser of the SOA TTL or the SOA MINIMUM field, 422 depending upon the recipient's implementation. 424 5. In-Channel Check 426 There are two methods that can be used to ascertain whether a message 427 is In-Channel. In-Channel would be when the RCPT TO list has been 428 specified by or sourced by the originating Administrative Unit. One 429 method uses a hash of the initial [RFC2821] RCPT TO: email-address 430 list. The other method verifies the EHLO using a DNS lookup for an 431 address record or CSV-CSA record as defined in [I-D.crocker-csv-csa]. 432 When the signing-domain as noted in the DKIM-Signature 'd=' 433 parameter are within the verified EHLO domain name, the message could 434 be said to be In-Channel. Another method may use a [RFC2821] RCPT 435 TO: email-address hash parameter stored within the DKIM-Signature to 436 confirm that the RCPT TO list has not been altered. 438 When the message is determined to be In-Channel, and an O-ID option 439 is being used, checking for O-ID revocation may be skipped. When 440 O-ID revocation should be checked, the receiving SMTP server may 441 issue an SMTP 450 temporary error and delay acceptance for a few 442 minutes. Once the receiving SMTP server decides enough time has 443 elapsed from the initial delivery attempt for the specific message, a 444 O-ID revocation check would be made instead. If the O-ID 445 authorization has not been revoked, the message may be accepted. 447 When the 'm=' parameter is included, an SHA-1 hash algorithm defined 448 in [RFC3174] is used to hash all [RFC2821] RCPT TO: email-addresses 449 in sequence from left to right and first to last. The hash will 450 include only the [RFC2821] RCPT TO: email-addresses, and to obfuscate 451 the use of a BCC header, the hash may be initialized by a special 452 SMTP extension MF-SALT. The result of the hash is stored in Base 64 453 within the DKIM-Signature 'm=' parameter. When the 454 MF-SALT extension has been allowed, a RCPT TO parameter may return an 455 SMTP extension MF-SALT-?????????????? where the fourteen '?' are 456 replaced by "URL and Filename safe" Base 64 Alphabet characters as 457 defined in [RFC3548] representing an 84 bit random number. When the 458 MF-SALT parameter is found within the initial RCPT TO parameter, 459 without a binary conversion, the fourteen Base 64 Alphabet characters 460 are hashed first, followed by the RCPT TO: email-addresses. When the 461 MF-SALT parameter is not present, just the RCPT TO: list may have 462 been hashed. 464 6. IANA Considerations 466 The SMTP extension MF-SALT will require registration by IANA. 468 Use of the _dkim-sa and _dkim-or prefix in DNS records will require 469 registration by IANA. 471 To avoid conflicts, tag names for the DKIM-Signature header and key 472 records the following should be added to those registered with IANA. 474 Tag values for the "w=", "u=", and "m=" tags in the DKIM-Signature 475 header, and the "w=", tags in key records should be registered with 476 IANA for the same reason. 478 7. Security Considerations 480 This document describes options that can be used with DomainKeys 481 Identified Mail (DKIM) to improve upon the secure use of this 482 mechanism. 484 8. References 486 8.1 Normative References 488 [I-D.crocker-csv-csa] 489 Crocker, D., "Client SMTP Authorization (CSA)", 490 draft-crocker-csv-csa-00 (work in progress), October 2005. 492 [I-D.crocker-email-arch] 493 Crocker, D., "Internet Mail Architecture", 494 draft-crocker-email-arch-04 (work in progress), 495 March 2005. 497 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 498 Part Three: Message Header Extensions for Non-ASCII Text", 499 RFC 2047, November 1996. 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, March 1997. 504 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 505 NCACHE)", RFC 2308, March 1998. 507 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 508 April 2001. 510 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 511 April 2001. 513 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 514 (SHA1)", RFC 3174, September 2001. 516 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 517 for Internationalized Domain Names in Applications 518 (IDNA)", RFC 3492, March 2003. 520 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 521 Encodings", RFC 3548, July 2003. 523 8.2 Informative References 525 [I-D.allman-dkim-base] 526 Allman, E., "DomainKeys Identified Mail (DKIM)", 527 draft-allman-dkim-base-01 (work in progress), 528 October 2005. 530 Author's Address 532 Douglas Otis 533 Trend Micro, NSSG 534 1737 North First Street, Suite 680 535 San Jose, CA 95112 536 USA 538 Phone: +1.408.453.6277 539 Email: doug_otis@trendmicro.com 541 Intellectual Property Statement 543 The IETF takes no position regarding the validity or scope of any 544 Intellectual Property Rights or other rights that might be claimed to 545 pertain to the implementation or use of the technology described in 546 this document or the extent to which any license under such rights 547 might or might not be available; nor does it represent that it has 548 made any independent effort to identify any such rights. Information 549 on the procedures with respect to rights in RFC documents can be 550 found in BCP 78 and BCP 79. 552 Copies of IPR disclosures made to the IETF Secretariat and any 553 assurances of licenses to be made available, or the result of an 554 attempt made to obtain a general license or permission for the use of 555 such proprietary rights by implementers or users of this 556 specification can be obtained from the IETF on-line IPR repository at 557 http://www.ietf.org/ipr. 559 The IETF invites any interested party to bring to its attention any 560 copyrights, patents or patent applications, or other proprietary 561 rights that may cover technology that may be required to implement 562 this standard. Please address the information to the IETF at 563 ietf-ipr@ietf.org. 565 Disclaimer of Validity 567 This document and the information contained herein are provided on an 568 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 569 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 570 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 571 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 572 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 573 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 575 Copyright Statement 577 Copyright (C) The Internet Society (2005). This document is subject 578 to the rights, licenses and restrictions contained in BCP 78, and 579 except as set forth therein, the authors retain all their rights. 581 Acknowledgment 583 Funding for the RFC Editor function is currently provided by the 584 Internet Society.