idnits 2.17.1 draft-crocker-dkim-doseta-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Wildcard DNS records (for example, *.bar._domainkey.example.com) do not make sense in this context and SHOULD not be used. Note also that wildcards within domains (for example, s._domainkey.*.example.com) are not supported by the DNS. -- The document date (January 14, 2011) is 4850 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) == Unused Reference: 'ITU-X660-1997' is defined on line 2453, but no explicit reference was found in the text == Unused Reference: 'RFC3864' is defined on line 2506, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-2-2002' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-X660-1997' ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 4234 (ref. 'RFC5234') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4409 (Obsoleted by RFC 6409) -- Obsolete informational reference (is this intentional?): RFC 4871 (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5451 (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 5672 (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DKIM D. Crocker, Ed. 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Standards Track M. Kucherawy, Ed. 5 Expires: July 18, 2011 Cloudmark 6 January 14, 2011 8 DomainKeys Security Tagging (DOSETA) 9 draft-crocker-dkim-doseta-00 11 Abstract 13 DomainKeys Security Tagging (DOSETA) is a component mechanism that 14 enables development of a security-related service, such as 15 authentication or encryption, with keys based on domain names; the 16 name owner can be any actor involved in the handling of the data, 17 such as the author's organization, a server operator or one of their 18 agents. The DOSETA Library provides a collection of common 19 capabilities, including canonicalization, parameter tagging, and 20 retrieval of self-certified keys. The DOSETA Signing Template 21 affixes a signature to data that is in a "header/content" form. 22 Defining the meaning of the signature is the responsibility of the 23 service that incorporates DOSETA. The signature is validated through 24 a cryptographic signature and querying the signer's domain directly, 25 to retrieve the appropriate public key. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 18, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. DOSETA Features . . . . . . . . . . . . . . . . . . . . . 5 63 1.2. DOSETA Architecture . . . . . . . . . . . . . . . . . . . 6 64 2. Terminology and Definitions {rfc4871bis-02 2, subset} . . . . 6 65 2.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.2. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3. DOSETA Library . . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.1. Canonicalization {rfc4871bis-02 3.4} . . . . . . . . . . . 11 70 3.2. Tag=Value Parameters {rfc4871bis-02 3.2} . . . . . . . . . 15 71 3.3. Key Management {rfc4871bis-02 3.6} . . . . . . . . . . . . 16 72 3.4. Selectors for Keys {rfc4871bis-02 3.1} . . . . . . . . . . 17 73 3.5. DNS Binding for Key Retrieval {rfc4871bis-02 3.6.2} . . . 19 74 3.6. Stored Key Data {rfc4871bis-02 3.6.1, subset, with 75 preface} . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 4. DOSETA H/C Signing Template . . . . . . . . . . . . . . . . . 22 77 4.1. Cryptographic Algorithms {rfc4871bis-02 3.3, subset} . . . 22 78 4.2. Signature Data Structure {rfc4871bis-02 3.5, subset} . . . 24 79 4.3. Signature Calculation {rfc4871bis-02 3.7, reorganized 80 and clarified} . . . . . . . . . . . . . . . . . . . . . . 30 81 4.4. Signer Actions {rfc4871bis-02 5} . . . . . . . . . . . . . 33 82 4.5. Verifier Actions {rfc4871bis-02 6} . . . . . . . . . . . . 37 83 4.6. Requirements for Tailoring the Signing Service {added} . . 44 84 4.7. Signing by Parent Domains {rfc4871bis-02 3.8} . . . . . . 44 85 5. Semantics of Multiple Signatures {rfc4871bis-02 4} . . . . . . 45 86 5.1. Example Scenarios {rfc4871bis-02 4.1} . . . . . . . . . . 45 87 5.2. Interpretation {rfc4871bis-02 4.2} . . . . . . . . . . . . 46 88 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 47 89 6.1. IANA Considerations {rfc4871bis-02 7, subset} . . . . . . 47 90 6.2. Security Considerations {rfc4871bis-02 8, subset} . . . . 50 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 92 7.1. Normative References . . . . . . . . . . . . . . . . . . . 56 93 7.2. Informative References . . . . . . . . . . . . . . . . . . 57 94 Appendix A. Creating a Public Key {rfc4871bis-02 C} . . . . . . . 58 95 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 59 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 98 1. Introduction 100 DomainKeys Security Tagging (DOSETA) is a component mechanism that 101 enables development of a security-related service, such as 102 authentication or encryption, with keys based on domain names 103 [RFC1034]; the name owner can be any actor involved in the handling 104 of the data, such as the author's organization, a server operator or 105 one of their agents. The DOSETA Library provides a collection of 106 common capabilities, including canonicalization, parameter tagging, 107 and retrieval of self-certified keys. The DOSETA Signing Template 108 affixes a signature to data that is in a "header/content" form. 109 Defining the meaning of the signature is the responsibility of the 110 service that incorporates DOSETA. The signature is validated through 111 a cryptographic signature and querying the signer's domain directly, 112 to retrieve the appropriate public key. 114 The approach taken by DOSETA differs from previous approaches to data 115 signing (such as, Secure/Multipurpose Internet Mail Extensions 116 (S/MIME) [RFC1847], OpenPGP [RFC4880]) in that: 118 o the message signature can be packaged independently of the data it 119 is signing, so that neither human viewers of the data nor existing 120 data handling software is confused by signature-related content 121 appearing in the Content; 123 o there is no dependency on public and private key pairs being 124 issued by well-known, trusted certificate authorities; 126 o there is no dependency on the deployment of any new Internet 127 protocols or services for public key distribution or revocation; 129 o no attempt is made to include encryption as part of the mechanism; 131 DOSETA: 133 o enables compatibility with the existing data handling 134 infrastructure and transparent to the fullest extent possible; 136 o requires minimal new infrastructure; 138 o can be implemented independently of data clients in order to 139 reduce deployment time; 141 o can be deployed incrementally; 143 o allows delegation of signing to third parties. 145 DOSETA is taken directly from the original DKIM Signing specification 147 [RFC4871], [RFC5672]. It has merely extracted the core portions of 148 the specification, so that they can be applied to other security- 149 related services. For example, the core could support a DKIM-like 150 signing service for web pages, and it could support a data encryption 151 mechanism using the same DNS-based, self-certified key service as 152 DKIM. 154 NOTE: Much of the text for this draft is taken from the DKIM 155 working group draft-ietf-DKIM-rfc4871bis-02 revision. Sections in 156 this document cross reference their source with the notation: 157 {rfc4871bis-02 xx} 158 where "xx" indicates the section number. It might also indicate 159 that a subset is taken, such as when a portion is applied to the 160 DKIM-over-DOSETA draft and a portion to the DOSETA draft. In some 161 cases the base text also has been enhanced. 163 1.1. DOSETA Features 165 DOSETA features include: 167 Identity: DOSETA separates the question of the identity of the 168 DOSETA Creator from any other associated identifier, such as 169 the data's purported author. In particular, a DOSETA header 170 includes the identity of the signer. DOSETA Consumers can use 171 the DOSETA identity information to decide how they want to 172 process the data. That identity can be included in the 173 attributes of the data or recorded elsewhere. 175 NOTE: DOSETA does not, iiself, require that the identity it 176 uses be required to match any other associated identifier. 177 Those other identifiers already carry their own semantics 178 which might conflict with the use of the identifier needed 179 by DOSETA. However a particular service that incorporates 180 DNS might choose to add constraints on the choice of 181 identifier, such as having it match another identifier 182 associated with the data. 184 Scalability: DOSETA is designed to support the extreme 185 scalability requirements that characterize Internet data 186 identification. 188 Key Management: DOSETA differs from traditional hierarchical 189 public-key systems in that no Certificate Authority 190 infrastructure is required; the verifier requests the public 191 key from a repository in the domain of the claimed signer 192 directly rather than from a third party. Hence DOSETA provides 193 self-certifying keys. 195 The DNS is the initial mechanism for DOSETA public keys. Thus, 196 DOSETA currently depends on DNS administration and the security 197 of the DNS system. DOSETA is designed to be extensible to 198 other key fetching services as they become available. 200 Data Integrity: A DOSETA signature associates its identifier 201 with the computed hash of some or all of the data in order to 202 prevent the re-use of the signature with different data. 203 Verifying the signature asserts that the hashed data has not 204 changed since it was signed, and asserts nothing else about 205 "protecting" the end-to-end integrity of the data. 207 Assessment: For identity and authentication related processes, 208 this phase integrates the validation output for determing 209 further action. 211 1.2. DOSETA Architecture 213 As component technology, DOSETA is meant to be incorporated into a 214 service. This specification provides an underlying set of common 215 features and a template for using them to provide a signing service, 216 such as for authenticating an identifier. Hence, the pieces can be 217 depicted as follows, with DKIM being shown as a specific service that 218 incorporates DOSETA: 219 +--------+ +-----------------+ 220 | DKIM | | Message Privacy | 221 +---+----+ +--------+--------+ 222 | | 223 +-----V---------------------------+ | 224 | Header/Content Signing Template | | 225 +----------------+----------------+ | 226 | | 227 ...................V.................................V............. 228 . D O S E T A L I B R A R Y . 229 .+------------------+ +------------+ +-------------+ +-----------+. 230 .| | | Key | | Common | | Signature |. 231 .| Canonicalization | | Management | | Parameters | | Header |. 232 .| | | (DNS) | | (tab=value) | | |. 233 .+------------------+ +------------+ +-------------+ +-----------+. 234 ................................................................... 236 2. Terminology and Definitions {rfc4871bis-02 2, subset} 238 This section defines terms used in the rest of the document. 240 Within the specification, the label "TEMPLATE" is used to indicate 241 actions that are required to incorporate DOSETA into a service. 243 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in [RFC2119]. 249 2.1. Identity 251 Identity: A person, role, or organization. In the context of 252 DOSETA, examples include author, author's organization, an ISP 253 along the handling path, an independent trust assessment service, 254 and a data processing intermediary operator. 256 Identifier: A label that refers to an identity. 258 Signing Domain Identifier (SDID): A single domain name that refers 259 to the identity owning the key to be used for DOSETA processing. 260 The name has only basic domain name semantics; any possible owner- 261 specific semantics are outside the scope of DOSETA. It is 262 specified in Section 4.2. 264 2.2. Actors 266 Creator: An element in the data handling system that produces a 267 cryptographic encoding, on behalf of a domain, is referred to as a 268 Creator. 270 Consumer: An element in the data handling system that processes an 271 existing cryptographic encoding, on behalf of a domain, is 272 referred to as a Consumer. 274 Signer: An element in the data handling system that signs messages 275 on behalf of a domain is referred to as a signer. This element 276 specifies the organization acting as a type of DOSETA Creator. It 277 might be a client, server or other agent such as a reputation 278 service. The key issue is that the data MUST be signed before it 279 leaves the administrative domain of the signer. 281 Verifier: An element in the data handling system that verifies 282 signatures is referred to as a verifier. This element is a 283 Consumer of a signing service. It might be a client, server, or 284 other agent, such as a reputation service. In most cases it is 285 expected that a verifier will be close to an end user (Creator) of 286 the data or some consuming agent such as a data processing 287 intermediary. 289 2.3. Syntax 291 2.3.1. Whitespace 293 There are three forms of whitespace: 295 WSP: represents simple whitespace, that is, a space or a tab 296 character (formal definition in [RFC5234]). 298 LWSP: is linear whitespace, defined as WSP plus CRLF (formal 299 definition in [RFC5234]). 301 FWS: is folding whitespace. It allows multiple lines separated 302 by CRLF followed by at least one whitespace, to be joined. 304 The formal syntax for these are (WSP and LWSP are given for 305 information only): 307 ABNF: 308 WSP = SP / HTAB 309 LWSP = *(WSP / CRLF WSP) 310 FWS = [*WSP CRLF] 1*WSP 312 The definition of FWS is identical to that in [RFC5322] except for 313 the exclusion of obs-FWS. 315 2.3.2. Common ABNF Tokens 317 The following tokens are used in this document: 319 ABNF: 320 hyphenated-word = ALPHA 321 [ *(ALPHA / DIGIT / "-") 322 (ALPHA / DIGIT) ] 323 ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") 324 base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) 325 [ [FWS] "=" [ [FWS] "=" ] ] 326 hdr-name = field-name 327 qp-hdr-value = D-quoted-printable 328 ; with "|" encoded 330 2.3.3. Imported ABNF Tokens 332 The following tokens are imported from other RFCs as noted. Those 333 RFCs SHOULD be considered definitive. 335 From [RFC5321]: 337 (implementation warning: this permits quoted 338 strings) 340 342 From [RFC5322]: 344 (name of a header field) 346 From [RFC2045]: 348 a single line of quoted-printable-encoded text 350 a quoted-printable encoded octet) 352 NOTE: Be aware that the ABNF in [RFC2045] does not obey the rules 353 of [RFC5234] and MUST be interpreted accordingly, particularly as 354 regards case folding. 356 Other tokens not defined herein are imported from [RFC5234]. These 357 are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, 358 etc. 360 2.3.4. D-Quoted-Printable 362 The D-Quoted-Printable encoding syntax resembles that described in 363 Quoted-Printable [RFC2045], Section 6.7: 365 o Any character MAY be encoded as an "=" followed by two hexadecimal 366 digits from the alphabet "0123456789ABCDEF" (no lowercase 367 characters permitted) representing the hexadecimal-encoded integer 368 value of that character. 370 o All control characters (those with values < %x20), 8-bit 371 characters (values > %x7F), and the characters DEL (%x7F), SPACE 372 (%x20), and semicolon (";", %x3B) MUST be encoded. 374 o All whitespace, including SPACE, CR, and LF characters, MUST be 375 encoded. 377 o After encoding, FWS MAY be added at arbitrary locations in order 378 to avoid excessively long lines; such whitespace is NOT part of 379 the value, and MUST be removed before decoding. 381 The formal syntax for D-Quoted-Printable is: 383 ABNF: 384 D-quoted-printable = *(FWS / hex-octet / D-safe-char) 385 ; hex-octet is from RFC2045 386 D-safe-char = %x21-3A / %x3C / %x3E-7E 387 ; '!' - ':', '<', '>' - '~' 388 ; Characters not listed as "mail-safe" 389 ; in [RFC2049] are also not 390 ; recommended. 392 D-Quoted-Printable differs from Quoted-Printable as defined in 393 [RFC2045] in several important ways: 395 1. Whitespace in the input text, including CR and LF, MUST be 396 encoded. [RFC2045] does not require such encoding, and does not 397 permit encoding of CR or LF characters that are part of a CRLF 398 line break. 400 2. Whitespace in the encoded text is ignored. This is to allow tags 401 encoded using D-Quoted-Printable to be wrapped as needed. In 402 particular, [RFC2045] requires that line breaks in the input be 403 represented as physical line breaks; that is not the case here. 405 3. The "soft line break" syntax ("=" as the last non-whitespace 406 character on the line) does not apply. 408 4. D-Quoted-Printable does not require that encoded lines be no more 409 than 76 characters long (although there might be other 410 requirements depending on the context in which the encoded text 411 is being used). 413 3. DOSETA Library 415 DOSETA is distinguished by a DNS-based, self-certifying public key 416 mechanism, common canonicalization algorithms, and a common parameter 417 encoding mechanism. 419 3.1. Canonicalization {rfc4871bis-02 3.4} 421 Some data handling systems modify the original data, potentially 422 invalidating a cryptographic function, such as with a signature. For 423 most signers, mild modification of data is immaterial to validation 424 of the DOSETA domain name's use. For such signers, a 425 canonicalization algorithm that survives modest handling modification 426 is preferred. 428 Other signers demand that any modification of the data, however 429 minor, result in a signature verification failure. These signers 430 prefer a canonicalization algorithm that does not tolerate any in- 431 transit modification of the signed email. 433 To satisfy basic requirements, two canonicalization algorithms are 434 defined: a "simple" algorithm that tolerates almost no modification 435 and a "relaxed" algorithm that tolerates common modifications such as 436 whitespace replacement and data line rewrapping. 438 Data handling systems sometimes treat different portions of text 439 differentially and might be subject to more or less likelihood of 440 breaking a signature. DOSETA currently covers two types of data: 442 Header: Attribute:value sets, in the style of an Internet Mail 443 header fields 445 Content: Lines of ASCII text 447 Some DOSETA Creators might be willing to accept modifications to some 448 portions of the data, but not other portions. For DOSETA, a Creator 449 MAY specify either algorithm for one portion of the data and another 450 for a different portion when signing the data. 452 If no canonicalization algorithm is specified, the "simple" algorithm 453 defaults for all of the data. DOSETA Creators MUST implement both 454 canonicalization algorithms. Because further canonicalization 455 algorithms might be defined in the future, Creators MUST ignore any 456 signatures that use unrecognized canonicalization algorithms. 458 Canonicalization simply prepares the data for presentation to the 459 signing or verification algorithm. It MUST NOT change the 460 transmitted data in any way. Canonicalization of distinct data 461 portions is described below. 463 NOTE: This section assumes that data is already in "network normal" 464 format (text is ASCII encoded, lines are separated with CRLF 465 characters, etc.). See also Section 4.4.3 for information about 466 normalizing the message. 468 3.1.1. Header Canonicalization Algorithms 470 This section specifies initial entry for the IANA registry defined in 471 Table 2. 473 simple: The "simple" header canonicalization algorithm is for a set 474 of "attribute:value" textual data structures, such as email header 475 fields [RFC5322]. It does not change the original Header fields 476 in any way. Header fields MUST be presented to the signing or 477 verification algorithm exactly as they are in the message being 478 signed or verified. In particular, header field names MUST NOT be 479 case folded and whitespace MUST NOT be changed. 481 relaxed: The "relaxed" header canonicalization algorithm is for a 482 set of "attribute:value" textual data structures, such as email 483 header fields [RFC5322]. It does not change the original Header 484 fields in any way. It MUST apply the following steps in order: 486 * Convert all header field names (not the header field values) to 487 lowercase. For example, convert "SUBJect: AbC" to "subject: 488 AbC". 490 * Unfold all header field continuation lines as described in 491 [RFC5322]; in particular, lines with terminators embedded in 492 continued header field values (that is, CRLF sequences followed 493 by WSP) MUST be interpreted without the CRLF. Implementations 494 MUST NOT remove the CRLF at the end of the header field value. 496 * Convert all sequences of one or more WSP characters to a single 497 SP character. WSP characters here include those before and 498 after a line folding boundary. 500 * Delete all WSP characters at the end of each unfolded header 501 field value. 503 * Delete any WSP characters remaining before and after the colon 504 separating the header field name from the header field value. 505 The colon separator MUST be retained. 507 3.1.2. Content Canonicalization Algorithms 509 This section specifies initial entry for the IANA registry defined in 510 Table 3. 512 simple: The "simple" Content canonicalization algorithm is for 513 lines of ASCII text, such as occur in the body of email [RFC5322]. 514 It ignores all empty lines at the end of the Content. An empty 515 line is a line of zero length after removal of the line 516 terminator. If there is no Content or no trailing CRLF on the 517 Content, a CRLF is added. It makes no other changes to the 518 Content. In more formal terms, the "simple" Content 519 canonicalization algorithm converts "0*CRLF" at the end of the 520 Content to a single "CRLF". 522 Note that a completely empty or missing Content is canonicalized 523 as a single "CRLF"; that is, the canonicalized length will be 2 524 octets. 526 The sha1 value (in base64) for an empty Content (canonicalized to 527 a "CRLF") is: 528 uoq1oCgLlTqpdDX/iUbLy7J1Wic= 529 The sha256 value is: 530 frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY= 532 relaxed: The "relaxed" Content canonicalization algorithm is for 533 lines of ASCII text, such as occur in the body of email [RFC5322]. 534 It MUST apply the following steps (a) and (b) in order: 536 A. Reduce whitespace: 538 + Ignore all whitespace at the end of lines. Implementations 539 MUST NOT remove the CRLF at the end of the line. 541 + Reduce all sequences of WSP within a line to a single SP 542 character. 544 B. Ignore all empty lines at the end of the Content. "Empty 545 line" is defined in Section 3.4.3. If the Content is non- 546 empty, but does not end with a CRLF, a CRLF is added. (For 547 email, this is only possible when using extensions to SMTP or 548 non-SMTP transport mechanisms.) 550 The sha1 value (in base64) for an empty Content (canonicalized to 551 a null input) is: 552 2jmj7l5rSw0yVb/vlWAYkK/YBwk= 553 The sha256 value is: 554 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= 555 NOTE: It ought to be noted that the relaxed Content 556 canonicalization algorithm might enable certain types of 557 extremely crude "ASCII Art" attacks where a message might be 558 conveyed by adjusting the spacing between words. If this is a 559 concern, the "simple" Content canonicalization algorithm SHOULD 560 be used instead. 562 3.1.3. Canonicalization Examples (3.4.6} 564 In the following examples, actual whitespace is used only for 565 clarity. The actual input and output text is designated using 566 bracketed descriptors: "" for a space character, "" for a 567 tab character, and "" for a carriage-return/line-feed sequence. 568 For example, "X Y" and "XY" represent the same three 569 characters. 571 Example 1: An email message reading: 572 A: X 573 B : Y 574 Z 575 576 C 577 D E 578 579 581 when canonicalized using relaxed canonicalization for both header and 582 Content results in a header reading: 583 a:X 584 b:Y Z 586 and a Content reading: 587 C 588 D E 590 Example 2: The same message canonicalized using simple 591 canonicalization for both header and Content results in a header 592 reading: 593 A: X 594 B : Y 595 Z 597 and a Content reading: 598 C 599 D E 600 Example 3: When processed using relaxed header canonicalization and 601 simple Content canonicalization, the canonicalized version has a 602 header of: 603 a:X 604 b:Y Z 606 and a Content reading: 607 C 608 D E 610 3.2. Tag=Value Parameters {rfc4871bis-02 3.2} 612 DOSETA uses a simple "tag=value" syntax in several contexts, 613 including to represent associated cryptographic data and domain 614 cryptographic key records. 616 Values are a series of strings containing either plain text, "base64" 617 text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid, 618 Section 6.7), or "D-quoted-printable" (as defined in Section 2.6). 619 The name of the tag will determine the encoding of each value. 620 Unencoded semicolon (";") characters MUST NOT occur in the tag value, 621 since that separates tag-specs. 623 NOTE: Although the "plain text" defined below (as "tag-value") only 624 includes 7-bit characters, an implementation that wished to 625 anticipate future standards would be advised not to preclude the 626 use of UTF8-encoded text in tag=value lists. 628 Formally the syntax rules are as follows: 630 ABNF: 631 tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] 632 tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] 633 tag-name = ALPHA 0*ALNUMPUNC 634 tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] 635 ; WSP and FWS prohibited at beginning and end 636 tval = 1*VALCHAR 637 VALCHAR = %x21-3A / %x3C-7E 638 ; EXCLAMATION to TILDE except SEMICOLON 639 ALNUMPUNC = ALPHA / DIGIT / "_" 641 Note that WSP is allowed anywhere around tags. In particular, any 642 WSP after the "=" and any WSP before the terminating ";" is not part 643 of the value; however, WSP inside the value is significant. 645 Tags MUST be interpreted in a case-sensitive manner. Values MUST be 646 processed as case sensitive unless the specific tag description of 647 semantics specifies case insensitivity. 649 Tags with duplicate names MUST NOT occur within a single tag-list; if 650 a tag name does occur more than once, the entire tag-list is invalid. 652 Whitespace within a value MUST be retained unless explicitly excluded 653 by the specific tag description. 655 Tag=value pairs that represent the default value MAY be included to 656 aid legibility. 658 Unrecognized tags MUST be ignored. 660 Tags that have an empty value are not the same as omitted tags. An 661 omitted tag is treated as having the default value; a tag with an 662 empty value explicitly designates the empty string as the value. 664 3.3. Key Management {rfc4871bis-02 3.6} 666 Applications require some level of assurance that a cited public key 667 is associated with the Creator using it. Many applications achieve 668 this by using public key certificates issued by a trusted third 669 party. For applications with modest certification requirements, 670 DOSETA achieves a sufficient level of security, with significantly 671 enhanced scalability, by simply having the Consumer query the 672 purported Creator's DNS entry (or a supported equivalent) in order to 673 retrieve the public key. 675 DOSETA keys might be stored in multiple types of key servers and in 676 multiple formats. The storage and format of keys are irrelevant to 677 the remainder of the DOSETA algorithm. 679 The key lookup algorithm is: 680 public-key = D-find-key(q-val, d-val, s-val) 681 where: 683 q-val: The type of the lookup, as specified in the "q=" tag 684 (Section 4.2) 686 d-val: The domain of the signature, as specified in the "d=" tag 687 (Section 4.2) 689 s-val: The selector of the lookup as specified in the "s=" tag 690 (Section 4.2) 692 D-find-key: A function that uses q-val to determine the specific 693 details for accessing the desired stored Key record. 695 This document defines a single binding, using DNS TXT records to 696 distribute the keys, per Section 3.5. Other bindings might be 697 defined in the future. 699 3.4. Selectors for Keys {rfc4871bis-02 3.1} 701 To support multiple concurrent public keys per signing domain, the 702 key namespace is subdivided using "selectors". For example, 703 selectors might indicate the names of office locations (for example, 704 "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date 705 (for example, "january2005", "february2005", etc.), or even an 706 individual user. 708 Selectors are needed to support some important use cases. For 709 example: 711 o Domains that want to delegate signing capability for a specific 712 address for a given duration to a partner, such as an advertising 713 provider or other outsourced function. 715 o Domains that want to allow frequent travelers to generate signed 716 data locally without the need to connect to a particular server. 718 o "Affinity" domains (such as, college alumni associations) that 719 provide data forwarding, but that do not operate a data 720 origination agent for outgoing data. 722 Periods are allowed in selectors and are component separators. When 723 keys are retrieved from the DNS, periods in selectors define DNS 724 label boundaries in a manner similar to the conventional use in 725 domain names. Selector components might be used to combine dates 726 with locations, for example, "march2005.reykjavik". In a DNS 727 implementation, this can be used to allow delegation of a portion of 728 the selector namespace. 730 ABNF: 731 selector = sub-domain *( "." sub-domain ) 733 The number of public keys and corresponding selectors for each domain 734 is determined by the domain owner. Many domain owners will be 735 satisfied with just one selector, whereas administratively 736 distributed organizations might choose to manage disparate selectors 737 and key pairs in different regions or on different servers. 739 Beyond administrative convenience, selectors make it possible to 740 seamlessly replace public keys on a routine basis. If a domain 741 wishes to change from using a public key associated with selector 742 "january2005" to a public key associated with selector 743 "february2005", it merely makes sure that both public keys are 744 advertised in the public-key repository concurrently for the 745 transition period during which data might be in transit prior to 746 verification. At the start of the transition period, the outbound 747 servers are configured to sign with the "february2005" private key. 748 At the end of the transition period, the "january2005" public key is 749 removed from the public-key repository. 751 NOTE: A key can also be revoked as described below. The 752 distinction between revoking and removing a key selector record 753 is subtle. When phasing out keys as described above, a signing 754 domain would probably simply remove the key record after the 755 transition period. However, a signing domain could elect to 756 revoke the key (but maintain the key record) for a further 757 period. There is no defined semantic difference between a 758 revoked key and a removed key. 760 While some domains might wish to make selector values well known, 761 others will want to take care not to allocate selector names in a way 762 that allows harvesting of data by outside parties. For example, if 763 per-user keys are issued, the domain owner will need to make the 764 decision as to whether to associate this selector directly with the 765 name of a registered end-user, or make it some unassociated random 766 value, such as a fingerprint of the public key. 768 NOTE: The ability to reuse a selector with a new key (for 769 example, changing the key associated with a user's name) makes 770 it impossible to tell the difference between data that didn't 771 verify because the key is no longer valid versus a data that is 772 actually forged. For this reason, signers are ill-advised to 773 reuse selectors for new keys. A better strategy is to assign 774 new keys to new selectors. 776 3.5. DNS Binding for Key Retrieval {rfc4871bis-02 3.6.2} 778 This section defines a binding using DNS TXT records as a key 779 service. All implementations MUST support this binding. 781 3.5.1. Namespace 783 A DOSETA key is stored in a subdomain named: 785 ABNF: 786 dns-record = s "._domainkey." d 787 where: 789 s: is the selector of the lookup as specified in the "s=" tag 790 (Section 4.2) 792 d: is the domain of the signature, as specified in the "d=" tag 793 (Section 4.2) 795 NOTE: The string constant "_domainkey" is used to mark a sub-tree 796 that contains unified DOSETA key information. This string is a 797 constant, rather than being a different string for different key- 798 based services, in the view that keys are agnostic about the 799 service they are used for. That is, there is no semantic or 800 security benefit in having a different constant string for 801 different key services. 803 Given a DOSETA-Signature field with a "d=" tag of "example.com" and 804 an "s=" tag of "foo.bar", the DNS query will be for: 805 foo.bar._domainkey.example.com 807 Wildcard DNS records (for example, *.bar._domainkey.example.com) do 808 not make sense in this context and SHOULD not be used. Note also 809 that wildcards within domains (for example, 810 s._domainkey.*.example.com) are not supported by the DNS. 812 3.5.2. Resource Record Types for Key Storage 814 The DNS Resource Record type used is specified by an option to the 815 query-type ("q=") tag. The only option defined in this base 816 specification is "txt", indicating the use of a TXT Resource Record 817 (RR). A later extension of this standard might define another RR 818 type. 820 Strings in a TXT RR MUST be concatenated together before use with no 821 intervening whitespace. TXT RRs MUST be unique for a particular 822 selector name; that is, if there are multiple records in an RRset, 823 the results are undefined. 825 TXT RRs are encoded as described in Section 3.6. 827 3.6. Stored Key Data {rfc4871bis-02 3.6.1, subset, with preface} 829 This section defines a syntax for encoding stored key data within an 830 unstructured environment such as simple text. 832 TEMPLATE: (Key Retrieval) A service that incorporates DOSETA MAY 833 define the specific mechanism by which Consumers can obtain 834 associated public keys. This might be as easy as referencing 835 an existing key management system or it might require a new set 836 of conventions. 838 Absent an explicit specification for key retrieval, the default 839 mechanism is specified in Section 3.5. 841 The overall syntax is a tag-list as described in Section 3.2. The 842 current valid tags are described below. Other tags MAY be present 843 and MUST be ignored by any implementation that does not understand 844 them. 846 v= Version of the DOSETA key record (plain-text; RECOMMENDED, 847 default is "DKIM1"). If specified, this tag MUST be set to 848 "DKIM1" (without the quotes). This tag MUST be the first tag 849 in the record. Records beginning with a "v=" tag with any 850 other value MUST be discarded. Note that verifiers MUST do a 851 string comparison on this value; for example, "DKIM1" is not 852 the same as "DKIM1.0". 854 ABNF: 855 key-v-tag = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31 857 NOTE: The version string "DKIM1" is retained from the 858 original DKIM specification, in order to preserve the 859 installed base of records. In addition, there is no 860 functional benefit in defining a new string, since the key 861 record is not application-specific. 863 k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers 864 and verifiers MUST support the "rsa" key type. The "rsa" key 865 type indicates that an ASN.1 DER-encoded [ITU-X660-1997] 866 RSAPublicKey [RFC3447] (see Sections Section 3.4 and A.1.1) is 867 being used in the "p=" tag. (Note: the "p=" tag further 868 encodes the value using the base64 algorithm.) Unrecognized 869 key types MUST be ignored. 871 ABNF: 872 key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type 873 key-k-tag-type = "rsa" / x-key-k-tag-type 874 x-key-k-tag-type = hyphenated-word ; for future extension 876 n= Notes that might be of interest to a human (qp-section; 877 OPTIONAL, default is empty). No interpretation is made by any 878 program. This tag should be used sparingly in any key server 879 mechanism that has space limitations (notably DNS). This is 880 intended for use by administrators, not end users. 882 ABNF: 883 key-n-tag = %x6e [FWS] "=" [FWS] qp-section 885 p= Public-key data (base64; REQUIRED). An empty value means 886 that this public key has been revoked. The syntax and 887 semantics of this tag value before being encoded in base64 are 888 defined by the "k=" tag. 890 ABNF: 891 key-p-tag = %x70 [FWS] "=" [ [FWS] base64string] 893 NOTE: If a private key has been compromised or otherwise 894 disabled (for example, an outsourcing contract has been 895 terminated), a signer might want to explicitly state that it 896 knows about the selector, but also have all queries using 897 that selector result in a failed verification. Verifiers 898 SHOULD ignore any DOSETA-Signature header fields with a 899 selector referencing a revoked key. 901 NOTE: A base64string is permitted to include white space 902 (FWS) at arbitrary places; however, any CRLFs MUST be 903 followed by at least one WSP character. Implementors and 904 administrators are cautioned to ensure that selector TXT 905 records conform to this specification. 907 4. DOSETA H/C Signing Template 909 This section specifies the basic components of a signing mechanism, 910 which is similar to the one defined for DKIM. This template for a 911 signing service can be mapped to a two-part -- header/content -- data 912 model. As with DKIM it separates specification of the signer's 913 identity from any other identifiers that might be associated with 914 that data. 916 NOTE: The use of hashing and signing algorithms by DOSETA 917 inherently provides a degree of data integrity protection, 918 between the signing and verifying steps. However it does not 919 necessarily "authenticate" the data that is signed. For 920 example, it does not inherently validate the accuracy of the 921 data or declare that the signer is the author or owner of the 922 data. 924 TEMPLATE: (Header/Content Mapping) The service incorporating 925 this mechanism MUST define the precise mappings onto the 926 template provided in this section. (Note that data lacking a 927 header component might still be possible to cast in a header/ 928 content form, where the header comprises on the DOSETA 929 Signature information.) 931 The service also MUST define the precise meaning of a 932 signature. 934 4.1. Cryptographic Algorithms {rfc4871bis-02 3.3, subset} 936 DOSETA supports multiple digital signature algorithms: 938 rsa-sha1: The rsa-sha1 Signing Algorithm computes a message hash 939 as described in Section 4.3 below using SHA-1 [FIPS-180-2-2002] 940 as a hashing algorithm. That hash is then signed by the signer 941 using the RSA algorithm (defined in PKCS#1 version 1.5 942 [RFC3447]) as the crypt-alg and the signer's private key. The 943 hash MUST NOT be truncated or converted into any form other 944 than the native binary form before being signed. The signing 945 algorithm SHOULD use a public exponent of 65537. 947 rsa-sha256: The rsa-sha256 Signing Algorithm computes a message 948 hash as described in [RFC5451] below using SHA-256 949 [FIPS-180-2-2002] as the hash-alg. That hash is then signed by 950 the signer using the RSA algorithm (defined in PKCS#1 version 951 1.5 [RFC3447]) as the crypt-alg and the signer's private key. 952 The hash MUST NOT be truncated or converted into any form other 953 than the native binary form before being signed. 955 Other: Other algorithms MAY be defined in the future. Verifiers 956 MUST ignore any signatures using algorithms that they do not 957 implement. 959 Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers 960 MUST implement rsa-sha256. 962 NOTE: Although sha256 is strongly encouraged, some senders of low- 963 security messages (such as routine newsletters) might prefer to 964 use sha1 because of reduced CPU requirements to compute a sha1 965 hash. In general, sha256 is always preferred, whenever possible. 967 Selecting appropriate key sizes is a trade-off between cost, 968 performance, and risk. Since short RSA keys more easily succumb to 969 off-line attacks, signers MUST use RSA keys of at least 1024 bits for 970 long-lived keys. Verifiers MUST be able to validate signatures with 971 keys ranging from 512 bits to 2048 bits, and they MAY be able to 972 validate signatures with larger keys. Verifier policies might use 973 the length of the signing key as one metric for determining whether a 974 signature is acceptable. 976 Factors that ought to influence the key size choice include the 977 following: 979 o The practical constraint that large (for example, 4096 bit) keys 980 might not fit within a 512-byte DNS UDP response packet 982 o The security constraint that keys smaller than 1024 bits are 983 subject to off-line attacks 985 o Larger keys impose higher CPU costs to verify and sign data 987 o Keys can be replaced on a regular basis, thus their lifetime can 988 be relatively short 990 o The security goals of this specification are modest compared to 991 typical goals of other systems that employ digital signatures 993 See [RFC3766] for further discussion on selecting key sizes. 995 4.2. Signature Data Structure {rfc4871bis-02 3.5, subset} 997 A signature of data is stored into an data structure associated with 998 the signed data. This structure contains all of the signature and 999 key-fetching data. This DOSETA-Signature structure is a tag-list as 1000 defined in Section 3.2. 1002 TEMPLATE: (Signature Association) A service that incorporates 1003 DOSETA MUST define the exact means by which the Signature 1004 structure is associated with the data. 1006 When the DOSETA-Signature is part of a sequence of structures -- such 1007 as being added to an email header -- it SHOULD NOT be reordered and 1008 SHOULD be prepended to the message. (This is the same handling as is 1009 given to email trace Header fields, defined in Section 3.6 of 1010 [RFC5322].) 1012 The tags are specified below. Tags described as are 1013 encoded as described in Section 6.7 of MIME Part One [RFC2045], with 1014 the additional conversion of semicolon characters to "=3B"; 1015 intuitively, this is one line of quoted-printable encoded text. The 1016 D-quoted-printable syntax is defined in Section 2.3.4. 1018 Tags on the DOSETA-Signature structure along with their type and 1019 requirement status are shown below. Unrecognized tags MUST be 1020 ignored. 1022 v= Version (MUST be included). This tag defines the version of 1023 this specification that applies to the signature record. It 1024 MUST have the value "1". Note that verifiers MUST do a string 1025 comparison on this value; for example, "1" is not the same as 1026 "1.0". 1028 ABNF: 1029 sig-v-tag = %x76 [FWS] "=" [FWS] "1" 1030 NOTE: DOSETA-Signature version numbers are expected to 1031 increase arithmetically as new versions of this 1032 specification are released. 1034 a= The algorithm used to generate the signature (plain-text; 1035 REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; 1036 signers SHOULD sign using "rsa-sha256". See Section 4.1 for a 1037 description of algorithms. 1039 ABNF: 1041 sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg 1042 sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h 1043 sig-a-tag-k = "rsa" / x-sig-a-tag-k 1044 sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h 1045 x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) 1046 ; for later extension 1047 x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) 1048 ; for later extension 1050 b= The signature data (base64; REQUIRED). Whitespace is 1051 ignored in this value and MUST be ignored when reassembling the 1052 original signature. In particular, the signing process can 1053 safely insert FWS in this value in arbitrary places to conform 1054 to line-length limits. See Signer Actions (Section 4.4) for 1055 how the signature is computed. 1057 ABNF: 1058 sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data 1059 sig-b-tag-data = base64string 1061 bh= The hash of the canonicalized Content (body), as limited by 1062 the "l=" tag (base64; REQUIRED). Whitespace is ignored in this 1063 value and MUST be ignored when reassembling the original 1064 signature. In particular, the signing process can safely 1065 insert FWS in this value in arbitrary places to conform to 1066 line-length limits. See Section 4.3 for how the Content hash 1067 is computed. 1069 ABNF: 1070 sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data 1071 sig-bh-tag-data = base64string 1073 c= Message canonicalization (plain-text; OPTIONAL, default is 1074 "simple/simple"). This tag informs the verifier of the type of 1075 canonicalization used to prepare the message for signing. It 1076 consists of two names separated by a "slash" (%d47) character, 1077 corresponding to the header and Content canonicalization 1078 algorithms respectively: 1080 ABNF: 1081 sig-bh-tag = %x63 [FWS] "=" [FWS] sig-c-header "/" sig-c-content 1082 where: 1084 sig-c-header: A value from IANA registry defined in 1085 Table 2 1087 sig-c-content: A value from IANA registry defined in 1088 Table 3 1090 These algorithms are described in Section 3.1. If only one 1091 algorithm is named, that algorithm is used for the header and 1092 "simple" is used for the Content. For example, "c=relaxed" is 1093 treated the same as "c=relaxed/simple". 1095 ABNF: 1096 sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg 1097 ["/" sig-c-tag-alg] 1098 sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg 1099 x-sig-c-tag-alg = hyphenated-word ; for later extension 1101 d= The SDID doing the signing (plain-text; REQUIRED). Hence, 1102 the SDID value is used to form the query for the public key. 1103 The SDID MUST correspond to a valid DNS name under which the 1104 DOSETA key record is published. The conventions and semantics 1105 used by a signer to create and use a specific SDID are outside 1106 the scope of the DOSETA Signing specification, as is any use of 1107 those conventions and semantics. When presented with a 1108 signature that does not meet these requirements, verifiers MUST 1109 consider the signature invalid. 1111 Internationalized domain names MUST be encoded as described in 1112 [RFC5890]. 1114 TEMPLATE: (Semantics) The service incorporating DOSETA 1115 MUST define the semantics of a signature. 1117 ABNF: 1119 sig-d-tag = %x64 [FWS] "=" [FWS] domain-name 1120 domain-name = sub-domain 1*("." sub-domain) 1121 ; from RFC 5321 Domain, 1122 ; but excluding address-literal 1124 h= Signed Header fields (plain-text, but see description; 1125 REQUIRED). A colon-separated list of header field names that 1126 identify the Header fields presented to the signing algorithm. 1127 The field MUST contain the complete list of Header fields in 1128 the order presented to the signing algorithm. The field MAY 1129 contain names of Header fields that do not exist when signed; 1130 nonexistent Header fields do not contribute to the signature 1131 computation (that is, they are treated as the null input, 1132 including the header field name, the separating colon, the 1133 header field value, and any CRLF terminator). The field MUST 1134 NOT include the DOSETA Signature header field that is being 1135 created or verified, but might include others. Folding 1136 whitespace (FWS) MAY be included on either side of the colon 1137 separator. Header field names MUST be compared against actual 1138 header field names in a case-insensitive manner. This list 1139 MUST NOT be empty. See Section 4.4.4 for a discussion of 1140 choosing Header fields to sign. 1142 ABNF: 1143 sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name 1144 0*( [FWS] ":" [FWS] hdr-name ) 1146 By "signing" Header fields that do not actually exist, a signer 1147 can prevent insertion of those Header fields before 1148 verification. However, since a signer cannot possibly know all 1149 possible Header fields that might be created in the future, the 1150 security of this solution is not total. 1152 The exclusion of the header field name and colon as well as the 1153 header field value for non-existent Header fields prevents an 1154 attacker from inserting an actual header field with a null 1155 value. 1157 q= A colon-separated list of query methods used to retrieve the 1158 public key (plain-text; OPTIONAL, default is "dns/txt"). Each 1159 query method is of the form "type[/options]", where the syntax 1160 and semantics of the options depend on the type and specified 1161 options. If there are multiple query mechanisms listed, the 1162 choice of query mechanism MUST NOT change the interpretation of 1163 the signature. Implementations MUST use the recognized query 1164 mechanisms in the order presented. Unrecognized query 1165 mechanisms MUST be ignored. 1167 Currently, the only valid value is "dns/txt", which defines the 1168 DNS TXT record lookup algorithm described elsewhere in this 1169 document. The only option defined for the "dns" query type is 1170 "txt", which MUST be included. Verifiers and signers MUST 1171 support "dns/txt". 1173 ABNF: 1174 sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method 1175 *([FWS] ":" [FWS] sig-q-tag-method) 1176 sig-q-tag-method = "dns/txt" / x-sig-q-tag-type 1177 ["/" x-sig-q-tag-args] 1178 x-sig-q-tag-type = hyphenated-word ; for future extension 1179 x-sig-q-tag-args = qp-hdr-value 1181 s= The selector subdividing the namespace for the "d=" (domain) 1182 tag (plain-text; REQUIRED). 1184 ABNF: 1185 sig-s-tag = %x73 [FWS] "=" [FWS] selector 1187 t= Signature Timestamp (plain-text unsigned decimal integer; 1188 RECOMMENDED, default is an unknown creation time). The time 1189 that this signature was created. The format is the number of 1190 seconds since 00:00:00 on January 1, 1970 in the UTC time zone. 1191 The value is expressed as an unsigned integer in decimal ASCII. 1192 This value is not constrained to fit into a 31- or 32-bit 1193 integer. Implementations SHOULD be prepared to handle values 1194 up to at least 10^12 (until approximately AD 200,000; this fits 1195 into 40 bits). To avoid denial-of-service attacks, 1196 implementations MAY consider any value longer than 12 digits to 1197 be infinite. Leap seconds are not counted. Implementations 1198 MAY ignore signatures that have a timestamp in the future. 1200 ABNF: 1201 sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT 1203 x= Signature Expiration (plain-text unsigned decimal integer; 1204 RECOMMENDED, default is no expiration). The format is the same 1205 as in the "t=" tag, represented as an absolute date, not as a 1206 time delta from the signing timestamp. The value is expressed 1207 as an unsigned integer in decimal ASCII, with the same 1208 constraints on the value in the "t=" tag. Signatures MAY be 1209 considered invalid if the verification time at the verifier is 1210 past the expiration date. Ideally verification time is when a 1211 message is first received at the administrative domain of the 1212 verifier; otherwise the current time SHOULD be used. The value 1213 of the "x=" tag MUST be greater than the value of the "t=" tag 1214 if both are present. 1216 NOTE: The "x=" tag is not intended as an anti-replay defense. 1218 NOTE: Due to clock drift, the receiver's notion of when to 1219 consider the signature expired might not match exactly when 1220 the sender is expecting. Receivers MAY add a 'fudge factor' 1221 to allow for such possible drift. 1223 ABNF: 1224 sig-x-tag = %x78 [FWS] "=" [FWS] 1225 1*12DIGIT 1227 4.3. Signature Calculation {rfc4871bis-02 3.7, reorganized and 1228 clarified} 1230 Hashing and Cryptographic algorithms are combined into a procedure 1231 for computing a digital signature. 1233 Creators will choose appropriate parameters for the signing process; 1234 Creators will use the tags that are then passed as an associated 1235 DOSETA Header field. Section 4.2 defines the contents of the Header 1236 field. 1238 In the following discussion, the names of the tags in the Header 1239 field that either exist (when consuming) or will be created (when 1240 creating) are used. 1242 NOTE: Canonicalization (see Section 3.1) prepares a separate 1243 representation of the data for additional processing; it does 1244 not affect the transmitted data in any way. 1246 Creators MUST compute hashes in the order defined. Consumers MAY 1247 compute them in any order convenient to the Creator, provided that 1248 the result is semantically identical to the semantics that would be 1249 the case had they been computed in this order. 1251 The combined hashing algorithm is: 1253 Step 1: The Creator/Creator hashes the Content portion, 1254 canonicalized using the Content canonicalization algorithm 1255 specified in the "c=" tag and then truncated to the length 1256 specified in the "l=" tag. That hash value is then converted 1257 to base64 form. Signers then insert it into the "bh=" tag of 1258 the DOSETA-Signature field; verifiers compare their hash with 1259 the value in the "bh=" tag. 1261 Step 2: Pass the following to a second hash algorithm in the 1262 indicated order: 1264 + Complete attribute:value Header fields specified by the "h=" 1265 tag, in the order specified in that tag, and canonicalized 1266 using the Header canonicalization algorithm specified in the 1267 "c=" tag. Each field MUST be terminated with a single CRLF. 1269 + The DOSETA-Signature field that exists (verifying), or will 1270 be inserted (signing), in the Header, with the value of the 1271 "b=" signature data tag (including all surrounding 1272 whitespace) deleted (that is, treated as the empty string), 1273 canonicalized using the Header canonicalization algorithm 1274 specified in the "c=" tag, and without a trailing CRLF. 1276 + The hash produced in Step 1. 1278 When calculating or verifying a signature, the value of the "b=" tag 1279 (signature value) of that DOSETA-Signature structure MUST be treated 1280 as though it were an empty string. Unknown tags in the 1281 DOSETA-Signature header field MUST be included in the signature 1282 calculation but MUST be otherwise ignored by verifiers. Other 1283 DOSETA-Signature tags that are included in the signature SHOULD be 1284 treated as normal tags; in particular, the "b=" tag is not treated 1285 specially. 1287 All tags and their values in the DOSETA-Signature field are included 1288 in the cryptographic hash with the sole exception of the value 1289 portion of the "b=" (signature) tag, which MUST be treated as the 1290 null string. All tags MUST be included even if they might not be 1291 understood by the verifier. The DOSETA-Signature field MUST be 1292 presented to the hash algorithm after the Content. rather than with 1293 the rest of the Header fields and MUST be canonicalized as specified 1294 in the "c=" (canonicalization) tag. The DOSETA-Signature header 1295 structure MUST NOT be included in its own h= tag, although other 1296 DOSETA-Signature Header fields MAY be signed (see Section 5). 1298 When calculating the hash on data that will be transmitted using 1299 additional encoding, such as base64 or quoted-printable, signers MUST 1300 compute the hash after the encoding. Likewise, the verifier MUST 1301 incorporate the values into the hash before decoding the base64 or 1302 quoted-printable text. However, the hash MUST be computed before 1303 transport level encodings such as SMTP "dot-stuffing" (the 1304 modification of lines beginning with a "." to avoid confusion with 1305 the SMTP end-of-message marker, as specified in [RFC5321]). 1307 With the exception of the canonicalization procedure described in 1308 Section 3.1, the DOSETA signing process treats the Content as simply 1309 a string of octets. DOSETA Content MAY be either in plain-text or in 1310 MIME format; no special treatment is afforded to MIME content. 1312 More formally, the algorithm for the signature is as follows: 1314 ABNF: 1315 content-hash = bh-hash-alg (canon-content, l-param) 1316 data-hash = a-hash-alg (h-headers, D-SIG, content-hash) 1317 signature = sig-alg (d-domain, selector, data-hash) 1319 where: 1321 content-hash: is the output of a function to hash the data 1322 Content. 1324 bh-hash-alg: is the hashing algorithm specified in the "bh" 1325 parameter. 1327 canon-body: is a canonicalized representation of the body. 1329 l-param: is the value of the l= length parameter. 1331 data-hash: is the output from hashing the header, the 1332 DOSETA-Signature header, and the Content hash. 1334 a-hash-alg: is the hash algorithm specified by the "a=" tag, 1336 h-headers: is the list of headers to be signed, as specified in 1337 the h= parameter. 1339 D-SIG: is the canonicalized DOSETA-Signature field sans the 1340 signature value itself. 1342 canon-content: is the canonicalized data Content(respectively) 1343 as defined in Section 3.1 (excluding the DOSETA-Signature 1344 field). 1346 signature: is the signature value produced by the signing 1347 algorithm. 1349 sig-alg: is the signature algorithm specified by the "a=" tag, 1351 d-domain: is the domain name specified in the d= parameter. 1353 selector: is the value of the s= selector parameter 1355 NOTE: Many digital signature APIs provide both hashing and 1356 application of the RSA private key using last two steps in the 1357 algorithm would probably be combined into a single call that would 1358 perform both the "a-hash-alg" and the "sig-alg". 1360 4.4. Signer Actions {rfc4871bis-02 5} 1362 The following steps are performed in order by signers. 1364 4.4.1. Determine Whether the Data Should Be Signed and by Whom 1366 A signer can obviously only sign data using domains for which it has 1367 a private key and the necessary knowledge of the corresponding public 1368 key and selector information. However, there are a number of other 1369 reasons beyond the lack of a private key why a signer could choose 1370 not to sign the data. 1372 NOTE: Signing modules can be incorporated into any portion of a 1373 service, as deemed appropriate, including end-systems, servers and 1374 intermediaries. Wherever implemented, signers need to beware of 1375 the semantics of signing data. An example of how this can be 1376 problematic is that within a trusted enclave the signing address 1377 might be derived from the data according to local policy; the 1378 derivation is based on local trust rather than explicit 1379 validation. 1381 If the data cannot be signed for some reason, the disposition of that 1382 data is a local policy decision. 1384 4.4.2. Select a Private Key and Corresponding Selector Information 1386 This specification does not define the basis by which a signer ought 1387 to choose which private key and selector information to use. 1388 Currently, all selectors are equal, with respect to this 1389 specification. So the choices ought to largely be a matter of 1390 administrative convenience. Distribution and management of private 1391 keys is also outside the scope of this document. 1393 NOTE: A signer SHOULD use a private key with an associated selector 1394 record that is expected to still be valid by time the verifier is 1395 likely to have an opportunity to validate the signature. The 1396 signer SHOULD anticipate that verifiers can choose to defer 1397 validation, perhaps until the message is actually read by the 1398 final recipient. In particular, when rotating to a new key pair, 1399 signing SHOULD immediately commence with the new private key, but 1400 the old public key SHOULD be retained for a reasonable validation 1401 interval before being removed from the key server. 1403 4.4.3. Normalize the Message to Prevent Transport Conversions 1405 Some messages, particularly those using 8-bit characters, are subject 1406 to modification during transit, notably from conversion to 7-bit 1407 form. Such conversions will break DOSETA signatures. In order to 1408 minimize the chances of such breakage, signers SHOULD convert the 1409 data to a suitable encoding, such as quoted-printable or base64, as 1410 described in [RFC2045] before signing. Such conversion is outside 1411 the scope of DOSETA; the data SHOULD be converted to 7-bit prior to 1412 presentation to the DOSETA signing procedure. 1414 Similarly, data that is not compliant with its associated standard, 1415 might be subject to corrective efforts intermediaries. See Section 8 1416 of [RFC4409] for examples of changes that are commonly made to email. 1417 Such "corrections" might break DOSETA signatures or have other 1418 undesirable effects. 1420 If the data is submitted to the signer with any local encoding that 1421 will be modified before transmission, that modification to a 1422 canonical form MUST be done before signing. For Text data in 1423 particular, bare CR or LF characters (used by some systems as a local 1424 line separator convention) MUST be converted to the CRLF sequences 1425 before the data is signed. Any conversion of this sort SHOULD be 1426 applied to the data actually sent to the recipient(s), not just to 1427 the version presented to the signing algorithm. 1429 More generally, the signer MUST sign the data as it is expected to be 1430 received by the verifier rather than in some local or internal form. 1432 4.4.4. Determine the Header Fields to Sign 1434 Signers SHOULD NOT sign an existing header field that is likely to be 1435 legitimately modified or removed in transit. Signers MAY include any 1436 other Header fields present at the time of signing at the discretion 1437 of the signer. 1439 NOTE: The choice of which Header fields to sign is non-obvious. 1440 One strategy is to sign all existing, non-repeatable Header 1441 fields. An alternative strategy is to sign only Header fields 1442 that are likely to be displayed to or otherwise be likely to 1443 affect the processing of the Content at the receiver. A third 1444 strategy is to sign only "well known" headers. Note that 1445 verifiers might treat unsigned Header fields with extreme 1446 skepticism, including refusing to display them to the end user or 1447 even ignoring the signature if it does not cover certain Header 1448 fields. 1450 The DOSETA-Signature header field is always implicitly signed and 1451 MUST NOT be included in the "h=" tag except to indicate that other 1452 preexisting signatures are also signed. 1454 Signers MAY claim to have signed Header fields that do not exist 1455 (that is, signers MAY include the header field name in the "h=" tag 1456 even if that header field does not exist in the message). When 1457 computing the signature, the non-existing header field MUST be 1458 treated as the null string (including the header field name, header 1459 field value, all punctuation, and the trailing CRLF). 1461 NOTE: This allows signers to explicitly assert the absence of a 1462 header field; if that header field is added later the signature 1463 will fail. 1465 NOTE: A header field name need only be listed once more than the 1466 actual number of that header field in a message at the time of 1467 signing in order to prevent any further additions. For example, 1468 if there is a single Comments header field at the time of signing, 1469 listing Comments twice in the "h=" tag is sufficient to prevent 1470 any number of Comments Header fields from being appended; it is 1471 not necessary (but is legal) to list Comments three or more times 1472 in the "h=" tag. 1474 Signers choosing to sign an existing header field that occurs more 1475 than once in the message (such as Received) MUST sign the physically 1476 last instance of that header field in the header block. Signers 1477 wishing to sign multiple instances of such a header field MUST 1478 include the header field name multiple times in the h= tag of the 1479 DOSETA-Signature header field, and MUST sign such Header fields in 1480 order from the bottom of the header field block to the top. The 1481 signer MAY include more instances of a header field name in h= than 1482 there are actual corresponding Header fields to indicate that 1483 additional Header fields of that name SHOULD NOT be added. 1485 EXAMPLE: 1487 If the signer wishes to sign two existing Received Header fields, 1488 and the existing header contains: 1489 Received: 1490 Received: 1491 Received: 1493 then the resulting DOSETA-Signature header field ought to read: 1495 DKIM-Signature: ... h=Received : Received :... 1496 and Received Header fields and will be signed in that 1497 order. 1499 Signers need to be careful of signing Header fields that might have 1500 additional instances added later in the delivery process, since such 1501 Header fields might be inserted after the signed instance or 1502 otherwise reordered. Trace Header fields (such as Received) and 1503 Resent-* blocks are the only fields prohibited by [RFC5322] from 1504 being reordered. In particular, since DOSETA-Signature Header fields 1505 might be reordered by some intermediate MTAs, signing existing 1506 DOSETA-Signature Header fields is error-prone. 1508 NOTE: Despite the fact that [RFC5322] permits Header fields to be 1509 reordered (with the exception of Received Header fields), 1510 reordering of signed Header fields with multiple instances by 1511 intermediate MTAs will cause DOSETA signatures to be broken; such 1512 anti-social behavior ought to be avoided. 1514 NOTE: Although not required by this specification, all end-user 1515 visible Header fields SHOULD be signed to avoid possible "indirect 1516 spamming". For example, if the Subject header field is not 1517 signed, a spammer can resend a previously signed mail, replacing 1518 the legitimate subject with a one-line spam. 1520 4.4.5. Compute the Message Signature 1522 The signer MUST compute the message hash as described in Section 4.3 1523 and then sign it using the selected public-key algorithm. This will 1524 result in a DOSETA-Signature header field that will include the 1525 Content hash and a signature of the header hash, where that header 1526 includes the DOSETA-Signature header field itself. 1528 Entities such as mailing list managers that implement DOSETA and that 1529 modify the message or a header field (for example, inserting 1530 unsubscribe information) before retransmitting the message SHOULD 1531 check any existing signature on input and MUST make such 1532 modifications before re-signing the message. 1534 The signer MAY elect to limit the number of bytes of the Content that 1535 will be included in the hash and hence signed. The length actually 1536 hashed SHOULD be inserted in the "l=" tag of the DOSETA-Signature 1537 header field. 1539 4.4.6. Insert the DOSETA-Signature Header Field 1541 Finally, the signer MUST insert the DOSETA-Signature header field 1542 created in the previous step prior to transmitting the data. The 1543 DOSETA-Signature header field MUST be the same as used to compute the 1544 hash as described above, except that the value of the "b=" tag MUST 1545 be the appropriately signed hash computed in the previous step, 1546 signed using the algorithm specified in the "a=" tag of the 1547 DOSETA-Signature header field and using the private key corresponding 1548 to the selector given in the "s=" tag of the DOSETA-Signature header 1549 field, as chosen above in Section 4.4.2 1551 The DOSETA-Signature header field MUST be inserted before any other 1552 DOSETA-Signature fields in the header block. 1554 NOTE: The easiest way to achieve this is to insert the 1555 DOSETA-Signature header field at the beginning of the header 1556 block. In particular, it might be placed before any existing 1557 Received Header fields. This is consistent with treating 1558 DOSETA-Signature as a trace header field. 1560 4.5. Verifier Actions {rfc4871bis-02 6} 1562 Since a signer MAY remove or revoke a public key at any time, it is 1563 recommended that verification occur in a timely manner. In many 1564 configurations, the most timely place is during acceptance by the 1565 border MTA or shortly thereafter. In particular, deferring 1566 verification until the message is accessed by the end user is 1567 discouraged. 1569 A border or intermediate server MAY verify the data signature(s). An 1570 server that has performed verification MAY communicate the result of 1571 that verification by adding a verification header field to incoming 1572 data. 1574 A verifying server MAY implement a policy with respect to 1575 unverifiable data, regardless of whether or not it applies the 1576 verification header field to signed messages. 1578 Verifiers MUST produce a result that is semantically equivalent to 1579 applying the following steps in the order listed. In practice, 1580 several of these steps can be performed in parallel in order to 1581 improve performance. 1583 4.5.1. Extract Signatures from the Message 1585 The order in which verifiers try DOSETA-Signature Header fields is 1586 not defined; verifiers MAY try signatures in any order they like. 1587 For example, one implementation might try the signatures in textual 1588 order, whereas another might try signatures by identities that match 1589 the contents of the From header field before trying other signatures. 1590 Verifiers MUST NOT attribute ultimate meaning to the order of 1591 multiple DOSETA-Signature Header fields. In particular, there is 1592 reason to believe that some relays will reorder the Header fields in 1593 potentially arbitrary ways. 1595 NOTE: Verifiers might use the order as a clue to signing order in 1596 the absence of any other information. However, other clues as to 1597 the semantics of multiple signatures (such as correlating the 1598 signing host with Received Header fields) might also be 1599 considered. 1601 A verifier SHOULD NOT treat a message that has one or more bad 1602 signatures and no good signatures differently from a message with no 1603 signature at all; such treatment is a matter of local policy and is 1604 beyond the scope of this document. 1606 When a signature successfully verifies, a verifier will either stop 1607 processing or attempt to verify any other signatures, at the 1608 discretion of the implementation. A verifier MAY limit the number of 1609 signatures it tries to avoid denial-of-service attacks. 1611 NOTE: An attacker could send messages with large numbers of faulty 1612 signatures, each of which would require a DNS lookup and 1613 corresponding CPU time to verify the message. This could be an 1614 attack on the domain that receives the message, by slowing down 1615 the verifier by requiring it to do a large number of DNS lookups 1616 and/or signature verifications. It could also be an attack 1617 against the domains listed in the signatures, essentially by 1618 enlisting innocent verifiers in launching an attack against the 1619 DNS servers of the actual victim. 1621 In the following description, text reading "return status 1622 (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") 1623 means that the verifier MUST immediately cease processing that 1624 signature. The verifier SHOULD proceed to the next signature, if any 1625 is present, and completely ignore the bad signature. If the status 1626 is "PERMFAIL", the signature failed and SHOULD NOT be reconsidered. 1627 If the status is "TEMPFAIL", the signature could not be verified at 1628 this time but might be tried again later. A verifier MAY either 1629 defer the message for later processing, perhaps by queueing it 1630 locally or issuing a 451/4.7.5 SMTP reply, or try another signature; 1631 if no good signature is found and any of the signatures resulted in a 1632 TEMPFAIL status, the verifier MAY save the message for later 1633 processing. The "(explanation)" is not normative text; it is 1634 provided solely for clarification. 1636 Verifiers SHOULD ignore any DOSETA-Signature Header fields where the 1637 signature does not validate. Verifiers that are prepared to validate 1638 multiple signature Header fields SHOULD proceed to the next signature 1639 header field, if it exists. However, verifiers MAY make note of the 1640 fact that an invalid signature was present for consideration at a 1641 later step. 1643 NOTE: The rationale of this requirement is to permit messages that 1644 have invalid signatures but also a valid signature to work. For 1645 example, a mailing list exploder might opt to leave the original 1646 submitter signature in place even though the exploder knows that 1647 it is modifying the message in some way that will break that 1648 signature, and the exploder inserts its own signature. In this 1649 case, the message ought to succeed even in the presence of the 1650 known-broken signature. 1652 For each signature to be validated, the following steps need to be 1653 performed in such a manner as to produce a result that is 1654 semantically equivalent to performing them in the indicated order. 1656 4.5.2. Validate the Signature Header Field 1658 Implementers MUST meticulously validate the format and values in the 1659 DOSETA-Signature header field; any inconsistency or unexpected values 1660 MUST cause the header field to be completely ignored and the verifier 1661 to return PERMFAIL (signature syntax error). Being "liberal in what 1662 you accept" is definitely a bad strategy in this security context. 1663 Note however that this does not include the existence of unknown tags 1664 in a DOSETA-Signature header field, which are explicitly permitted. 1665 Verifiers MUST ignore DOSETA-Signature Header fields with a "v=" tag 1666 that is inconsistent with this specification and return PERMFAIL 1667 (incompatible version). 1669 NOTE: An implementation might, of course, choose to also verify 1670 signatures generated by older versions of this specification. 1672 If any tag listed as "required" in Section 4.2 is omitted from the 1673 DOSETA-Signature header field, the verifier MUST ignore the 1674 DOSETA-Signature header field and return PERMFAIL (signature missing 1675 required tag). 1677 NOTE: The tags listed as required in Section 4.2 are "v=", "a=", 1678 "b=", "bh=", "d=", "h=", and "s=". Should there be a conflict 1679 between this note and Section 4.2, is normative. 1681 If the DOSETA-Signature header field does not contain the "i=" tag, 1682 the verifier MUST behave as though the value of that tag were "@d", 1683 where "d" is the value from the "d=" tag. 1685 Verifiers MUST confirm that the domain specified in the "d=" tag is 1686 the same as or a parent domain of the domain part of the "i=" tag. 1687 If not, the DOSETA-Signature header field MUST be ignored and the 1688 verifier SHOULD return PERMFAIL (domain mismatch). 1690 If the "h=" tag does not include the From header field, the verifier 1691 MUST ignore the DOSETA-Signature header field and return PERMFAIL 1692 (From field not signed). 1694 Verifiers MAY ignore the DOSETA-Signature header field and return 1695 PERMFAIL (signature expired) if it contains an "x=" tag and the 1696 signature has expired. 1698 Verifiers MAY ignore the DOSETA-Signature header field if the domain 1699 used by the signer in the "d=" tag is not associated with a valid 1700 signing entity. For example, signatures with "d=" values such as 1701 "com" and "co.uk" might be ignored. The list of unacceptable domains 1702 SHOULD be configurable. 1704 Verifiers MAY ignore the DOSETA-Signature header field and return 1705 PERMFAIL (unacceptable signature header) for any other reason, for 1706 example, if the signature does not sign Header fields that the 1707 verifier views to be essential. As a case in point, if MIME Header 1708 fields are not signed, certain attacks might be possible that the 1709 verifier would prefer to avoid. 1711 4.5.3. Get the Public Key 1713 The public key for a signature is needed to complete the verification 1714 process. The process of retrieving the public key depends on the 1715 query type as defined by the "q=" tag in the DOSETA-Signature header 1716 field. Obviously, a public key need only be retrieved if the process 1717 of extracting the signature information is completely successful. 1718 Details of key management and representation are described in 1719 Section 3.3. The verifier MUST validate the key record and MUST 1720 ignore any public key records that are malformed. 1722 NOTE: The use of wildcard TXT records in the DNS will produce a 1723 response to a DOSETA query that is unlikely to be valid DOSETA key 1724 record. This problem applies to many other types of queries, and 1725 client software that processes DNS responses needs to take this 1726 problem into account. 1728 When validating a message, a verifier MUST perform the following 1729 steps in a manner that is semantically the same as performing them in 1730 the order indicated -- in some cases the implementation might 1731 parallelize or reorder these steps, as long as the semantics remain 1732 unchanged: 1734 1. Retrieve the public key as described in Section 3.3 using the 1735 algorithm in the "q=" tag, the domain from the "d=" tag, and the 1736 selector from the "s=" tag. 1738 2. If the query for the public key fails to respond, the verifier 1739 MAY defer acceptance of this data and return TEMPFAIL - key 1740 unavailable. (If verification is occurring during the incoming 1741 SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply 1742 code.) Alternatively, the verifier MAY store the message in the 1743 local queue for later trial or ignore the signature. Note that 1744 storing a message in the local queue is subject to denial-of- 1745 service attacks. 1747 3. If the query for the public key fails because the corresponding 1748 key record does not exist, the verifier MUST immediately return 1749 PERMFAIL (no key for signature). 1751 4. If the query for the public key returns multiple key records, the 1752 verifier might choose one of the key records or might cycle 1753 through the key records performing the remainder of these steps 1754 on each record at the discretion of the implementer. The order 1755 of the key records is unspecified. If the verifier chooses to 1756 cycle through the key records, then the "return ..." wording in 1757 the remainder of this section means "try the next key record, if 1758 any; if none, return to try another signature in the usual way". 1760 5. If the result returned from the query does not adhere to the 1761 format defined in this specification, the verifier MUST ignore 1762 the key record and return PERMFAIL (key syntax error). Verifiers 1763 are urged to validate the syntax of key records carefully to 1764 avoid attempted attacks. In particular, the verifier MUST ignore 1765 keys with a version code ("v=" tag) that they do not implement. 1767 6. If the "h=" tag exists in the public key record and the hash 1768 algorithm implied by the a= tag in the DOSETA-Signature header 1769 field is not included in the contents of the "h=" tag, the 1770 verifier MUST ignore the key record and return PERMFAIL 1771 (inappropriate hash algorithm). 1773 7. If the public key data (the "p=" tag) is empty, then this key has 1774 been revoked and the verifier MUST treat this as a failed 1775 signature check and return PERMFAIL (key revoked). There is no 1776 defined semantic difference between a key that has been revoked 1777 and a key record that has been removed. 1779 8. If the public key data is not suitable for use with the algorithm 1780 and key types defined by the "a=" and "k=" tags in the 1781 DOSETA-Signature header field, the verifier MUST immediately 1782 return PERMFAIL (inappropriate key algorithm). 1784 4.5.4. Compute the Verification 1786 Given a signer and a public key, verifying a signature consists of 1787 actions semantically equivalent to the following steps. 1789 1. Based on the algorithm defined in the "c=" tag, the Content 1790 length specified in the "l=" tag, and the header field names in 1791 the "h=" tag, prepare a canonicalized version of the Content as 1792 is described in Section 4.3 (note that this version does not 1793 actually need to be instantiated). When matching header field 1794 names in the "h=" tag against the actual message header field, 1795 comparisons MUST be case-insensitive. 1797 2. Based on the algorithm indicated in the "a=" tag, compute the 1798 message hashes from the canonical copy as described in 1799 Section 4.3 1801 3. Verify that the hash of the canonicalized Content computed in the 1802 previous step matches the hash value conveyed in the "bh=" tag. 1803 If the hash does not match, the verifier SHOULD ignore the 1804 signature and return PERMFAIL (Content hash did not verify). 1806 4. Using the signature conveyed in the "b=" tag, verify the 1807 signature against the header hash using the mechanism appropriate 1808 for the public key algorithm described in the "a=" tag. If the 1809 signature does not validate, the verifier SHOULD ignore the 1810 signature and return PERMFAIL (signature did not verify). 1812 5. Otherwise, the signature has correctly verified. 1814 NOTE: Implementations might wish to initiate the public-key query 1815 in parallel with calculating the hash as the public key is not 1816 needed until the final decryption is calculated. Implementations 1817 might also verify the signature on the message header before 1818 validating that the message hash listed in the "bh=" tag in the 1819 DOSETA-Signature header field matches that of the actual Content; 1820 however, if the Content hash does not match, the entire signature 1821 MUST be considered to have failed. 1823 4.5.5. Communicate Verification Results 1825 Verifiers wishing to communicate the results of verification to other 1826 parts of the data handling system can do so in whatever manner they 1827 see fit. For example, implementations might choose to add a Header 1828 field to the data before passing it on. Any such header field SHOULD 1829 be inserted before any existing DOSETA-Signature or preexisting 1830 verification status Header fields in the header field block. The 1831 Authentication-Results: header field ([RFC5451]) MAY be used for this 1832 purpose. 1834 Patterns intended to search for results Header fields to visibly 1835 mark authenticated data for end users SHOULD verify that the 1836 header field was added by the appropriate verifying domain. In 1837 particular, filters SHOULD NOT be influenced by bogus results 1838 header fields added by attackers. To circumvent this attack, 1839 verifiers SHOULD delete existing results Header fields after 1840 verification and before adding a new header field. 1842 4.5.6. Interpret Results/Apply Local Policy 1844 It is beyond the scope of this specification to describe what actions 1845 an Assessment phase will take, but data with a verified DOSETA 1846 signature presents an opportunity to an Assessor that unsigned data 1847 does not. Specifically, signed data creates a predictable identifier 1848 by which other decisions can reliably be managed, such as trust and 1849 reputation. Conversely, unsigned data typically lacks a reliable 1850 identifier that can be used to assign trust and reputation. It is 1851 usually reasonable to treat unsigned data as lacking any trust and 1852 having no positive reputation. 1854 In general, verifiers SHOULD NOT reject data solely on the basis of a 1855 lack of signature or an unverifiable signature; such rejection would 1856 cause severe interoperability problems. However, if the verifier 1857 does opt to reject such data. 1859 Temporary failures such as inability to access the key server or 1860 other external service are the only conditions that SHOULD use a 1861 temporary failure code. In particular, cryptographic signature 1862 verification failures MUST NOT return temporary failure replies. 1864 Once the signature has been verified, that information MUST be 1865 conveyed to the Assessor (such as an explicit allow/whitelist and 1866 reputation system) and/or to the end user. If the SDID is not the 1867 same as the address in the From: header field, the data system SHOULD 1868 take pains to ensure that the actual SDID is clear to the reader. 1870 The verifier MAY treat unsigned Header fields with extreme 1871 skepticism, including marking them as untrusted or even deleting 1872 them. 1874 While the symptoms of a failed verification are obvious -- the 1875 signature doesn't verify -- establishing the exact cause can be more 1876 difficult. If a selector cannot be found, is that because the 1877 selector has been removed, or was the value changed somehow in 1878 transit? If the signature line is missing, is that because it was 1879 never there, or was it removed by an overzealous filter? For 1880 diagnostic purposes, the exact nature of a verification failure 1881 SHOULD be made available to the policy module and possibly recorded 1882 in the system logs. If the data cannot be verified, then it SHOULD 1883 be rendered the same as all unverified data regardless of whether or 1884 not it looks like it was signed. 1886 4.6. Requirements for Tailoring the Signing Service {added} 1888 This generic template requires additional details, to define a 1889 specific service: 1891 D-Signature Association: Specify the means by which a 1892 DOSETA-Signature header field is associated with the data it 1893 signs. For example, DKIM uses the DKIM-Signature email header 1894 field. If the header field is encoded differently than defined 1895 for the DOSETA generic service, such as in XML, then that also 1896 needs to be specified including the algorithm for mapping 1897 between the common encoding provided here and the new encoding. 1899 Semantics Signaling: The means by which a Consumer is to know 1900 what semantics apply must be indicated. This is likely to be 1901 the same means by which the Consumer knows what specific 1902 service is being used. For example, different service-specific 1903 DOSETA-Signature header fields might be used. "DKIM-Signature" 1904 signals a name-affixing service, while "DKVM-Signature" might 1905 signal a message validation service. 1907 Semantics: Define the meaning of a signature. Note that exactly 1908 the same algorithms might be used for very different semantics. 1909 One might merely affix an identifier to some data, in a 1910 verifiable fashion, while the same set of mechanisms might 1911 separately be defined as authenticating the validity of that 1912 data. 1914 Header/Content Mapping: The mappings between the generic service 1915 and data of a particular service needs to be defined. For 1916 example, with DKIM Header maps to the email header and Content 1917 maps to the email body. 1919 4.7. Signing by Parent Domains {rfc4871bis-02 3.8} 1921 In some circumstances, it is desirable for a domain to apply a 1922 signature on behalf of any of its subdomains without the need to 1923 maintain separate selectors (key records) in each subdomain. By 1924 default, private keys corresponding to key records can be used to 1925 sign messages for any subdomain of the domain in which they reside; 1926 for example, a key record for the domain example.com can be used to 1927 verify messages where the AUID ("i=" tag of the signature) is 1928 sub.example.com, or even sub1.sub2.example.com. In order to limit 1929 the capability of such keys when this is not intended, the "s" flag 1930 MAY be set in the "t=" tag of the key record, to constrain the 1931 validity of the domain of the AUID. If the referenced key record 1932 contains the "s" flag as part of the "t=" tag, the domain of the AUID 1933 ("i=" flag) MUST be the same as that of the SDID (d=) domain. If 1934 this flag is absent, the domain of the AUID MUST be the same as, or a 1935 subdomain of, the SDID. 1937 5. Semantics of Multiple Signatures {rfc4871bis-02 4} 1939 5.1. Example Scenarios {rfc4871bis-02 4.1} 1941 There are many reasons why a message might have multiple signatures. 1942 For example, a given signer might sign multiple times, perhaps with 1943 different hashing or signing algorithms during a transition phase. 1945 EXAMPLE: Suppose SHA-256 is in the future found to be 1946 insufficiently strong, and DOSETA usage transitions to SHA-1024. 1947 A signer might immediately sign using the newer algorithm, but 1948 continue to sign using the older algorithm for interoperability 1949 with verifiers that had not yet upgraded. The signer would do 1950 this by adding two DOSETA-Signature Header fields, one using each 1951 algorithm. Older verifiers that did not recognize SHA-1024 as an 1952 acceptable algorithm would skip that signature and use the older 1953 algorithm; newer verifiers could use either signature at their 1954 option, and all other things being equal might not even attempt to 1955 verify the other signature. 1957 Similarly, a signer might sign a message including all headers and no 1958 "l=" tag (to satisfy strict verifiers) and a second time with a 1959 limited set of headers and an "l=" tag (in anticipation of possible 1960 message modifications in route to other verifiers). Verifiers could 1961 then choose which signature they preferred. 1963 EXAMPLE: A verifier might receive data with two signatures, one 1964 covering more of the data than the other. If the signature 1965 covering more of the data verified, then the verifier could make 1966 one set of policy decisions; if that signature failed but the 1967 signature covering less of the data verified, the verifier might 1968 make a different set of policy decisions. 1970 Of course, a message might also have multiple signatures because it 1971 passed through multiple signers. A common case is expected to be 1972 that of a signed message that passes through a mailing list that also 1973 signs all messages. Assuming both of those signatures verify, a 1974 recipient might choose to accept the message if either of those 1975 signatures were known to come from trusted sources. 1977 EXAMPLE: Recipients might choose to whitelist mailing lists to 1978 which they have subscribed and that have acceptable anti- abuse 1979 policies so as to accept messages sent to that list even from 1980 unknown authors. They might also subscribe to less trusted 1981 mailing lists (for example, those without anti-abuse protection) 1982 and be willing to accept all messages from specific authors, but 1983 insist on doing additional abuse scanning for other messages. 1985 Another related example of multiple signers might be forwarding 1986 services, such as those commonly associated with academic alumni 1987 sites. 1989 EXAMPLE: A recipient might have an address at members.example.org, 1990 a site that has anti-abuse protection that is somewhat less 1991 effective than the recipient would prefer. Such a recipient might 1992 have specific authors whose messages would be trusted absolutely, 1993 but messages from unknown authors that had passed the forwarder's 1994 scrutiny would have only medium trust. 1996 5.2. Interpretation {rfc4871bis-02 4.2} 1998 A signer that is adding a signature to a message merely creates a new 1999 DOSETA-Signature header, using the usual semantics of the h= option. 2000 A signer MAY sign previously existing DOSETA-Signature Header fields 2001 using the method described in Section 4.4.4 to sign trace Header 2002 fields. 2004 NOTE: Signers need to be cognizant that signing DOSETA-Signature 2005 Header fields might result in verification failures due to 2006 modifications by intermediaries, such as their reordering 2007 DOSETA-Signature header fields. For this reason, signing existing 2008 DOSETA-Signature Header fields is unadvised, albeit legal. 2010 NOTE: If a header field with multiple instances is signed, those 2011 Header fields are always signed from the "bottom" up (from last to 2012 first). Thus, it is not possible to sign only specific 2013 DOSETA-Signature Header fields. For example, if the message being 2014 signed already contains three DOSETA-Signature header fields A, B, 2015 and C, it is possible to sign all of them, B and C only, or C 2016 only, but not A only, B only, A and B only, or A and C only. 2018 A signer MAY add more than one DOSETA-Signature header field using 2019 different parameters. For example, during a transition period a 2020 signer might want to produce signatures using two different hash 2021 algorithms. 2023 Signers SHOULD NOT remove any DOSETA-Signature Header fields from 2024 messages they are signing, even if they know that the signatures 2025 cannot be verified. 2027 When evaluating a message with multiple signatures, a verifier SHOULD 2028 evaluate signatures independently and on their own merits. For 2029 example, a verifier that by policy chooses not to accept signatures 2030 with deprecated cryptographic algorithms would consider such 2031 signatures invalid. Verifiers MAY process signatures in any order of 2032 their choice; for example, some verifiers might choose to process 2033 signatures corresponding to the From field in the message header 2034 before other signatures. See Section 4.5.1 for more information 2035 about signature choices. 2037 NOTE: Verifier attempts to correlate valid signatures with invalid 2038 signatures in an attempt to guess why a signature failed are ill- 2039 advised. In particular, there is no general way that a verifier 2040 can determine that an invalid signature was ever valid. 2042 Verifiers SHOULD ignore failed signatures as though they were not 2043 present in the message. Verifiers SHOULD continue to check 2044 signatures until a signature successfully verifies to the 2045 satisfaction of the verifier. To limit potential denial-of-service 2046 attacks, verifiers MAY limit the total number of signatures they will 2047 attempt to verify. 2049 6. Considerations 2051 6.1. IANA Considerations {rfc4871bis-02 7, subset} 2053 This section carries forward the IANA registrations made by DKIM 2054 [RFC4871]. The original DKIM language has been retained, including 2055 the use of "DKIM" in the name of these registries, in order to 2056 provide continuity from the original specification. 2058 In all cases, new values are assigned only for values that have been 2059 documented in a published RFC that has IETF Consensus [RFC5226]. 2061 6.1.1. DKIM-Signature Tag Specifications 2063 NOTE: The content of a DOSETA-Signature structure match those in a 2064 DKIM-Signature header field. 2066 A DKIM-Signature provides for a list of tag specifications. IANA has 2067 established the DKIM-Signature Tag Specification Registry for tag 2068 specifications that can be used in DKIM-Signature fields. 2070 The initial entries in the registry comprise: 2072 +------+------------------------------+ 2073 | TYPE | REFERENCE | 2074 +------+------------------------------+ 2075 | v | (this document, Section 4.2) | 2076 | a | (this document, Section 4.2) | 2077 | b | (this document, Section 4.2) | 2078 | bh | (this document, Section 4.2) | 2079 | c | (this document, Section 4.2) | 2080 | d | (this document, Section 4.2) | 2081 | h | (this document, Section 4.2) | 2082 | q | (this document, Section 4.2) | 2083 | s | (this document, Section 4.2) | 2084 | t | (this document, Section 4.2) | 2085 | x | (this document, Section 4.2) | 2086 +------+------------------------------+ 2088 Table 1: DKIM-Signature Tag Specification Registry Initial Values 2090 6.1.2. DKIM-Signature Query Method Registry 2092 The "q=" tag-spec (specified in Section 4.2) provides for a list of 2093 query methods. 2095 IANA has established the DKIM-Signature Query Method Registry for 2096 mechanisms that can be used to retrieve the key that will permit 2097 validation processing of a message signed using DKIM. 2099 The initial entry in the registry comprises: 2101 +------+--------+------------------------------------+ 2102 | TYPE | OPTION | REFERENCE | 2103 +------+--------+------------------------------------+ 2104 | dns | txt | (this document, Section 4.2, "q=") | 2105 +------+--------+------------------------------------+ 2107 DKIM&nbhy;Signature Query Method Registry Initial Values 2109 6.1.3. DKIM-Signature Canonicalization Registry 2111 The "c=" tag-spec (specified in Section 4.2) provides for a specifier 2112 for canonicalization algorithms for the header and Content. 2114 IANA has established the DKIM-Signature Canonicalization Algorithm 2115 Registry for algorithms for converting a message into a canonical 2116 form before signing or verifying using DKIM. 2118 The initial entries in the Header registry comprise: 2120 +---------+--------------------------------+ 2121 | TYPE | REFERENCE | 2122 +---------+--------------------------------+ 2123 | simple | (this document, Section 3.1.1) | 2124 | relaxed | (this document, Section 3.1.1) | 2125 +---------+--------------------------------+ 2127 Table 2: DKIM-Signature Header Canonicalization Algorithm Registry 2128 Initial Values 2130 The initial entries in the Content (Body) registry comprise: 2132 +---------+--------------------------------+ 2133 | TYPE | REFERENCE | 2134 +---------+--------------------------------+ 2135 | simple | (this document, Section 3.1.2) | 2136 | relaxed | (this document, Section 3.1.2) | 2137 +---------+--------------------------------+ 2139 Table 3: DKIM-Signature Body Canonicalization Algorithm Registry 2140 Initial Values 2142 6.1.4. _domainkey DNS TXT Record Tag Specifications 2144 A _domainkey DNS TXT record provides for a list of tag 2145 specifications. IANA has established the DKIM _domainkey DNS TXT Tag 2146 Specification Registry for tag specifications that can be used in DNS 2147 TXT Records. 2149 The initial entries in the registry comprise: 2151 +------+------------------------------+ 2152 | TYPE | REFERENCE | 2153 +------+------------------------------+ 2154 | v | (this document, Section 3.6) | 2155 | k | (this document, Section 3.6) | 2156 | n | (this document, Section 3.6) | 2157 | p | (this document, Section 3.6) | 2158 +------+------------------------------+ 2160 DOSETA _domainkey DNS TXT Record Tag Specification Registry 2161 Initial Values 2163 6.1.5. DKIM Key Type Registry 2165 The "k=" (specified in Section 3.6) and the "a=" (specified in Section 4.2) tags provide for a list of 2167 mechanisms that can be used to decode a DKIM signature. 2169 IANA has established the DKIM Key Type Registry for such mechanisms. 2171 The initial entry in the registry comprises: 2173 +------+-----------+ 2174 | TYPE | REFERENCE | 2175 +------+-----------+ 2176 | rsa | [RFC3447] | 2177 +------+-----------+ 2179 DKIM Key Type Initial Values 2181 6.1.6. DKIM Hash Algorithms Registry 2183 The "h=" (specified in Section 3.6) and the "a=" (specified in Section 4.2) tags provide for a list of 2185 mechanisms that can be used to produce a digest of message data. 2187 IANA has established the DKIM Hash Algorithms Registry for such 2188 mechanisms. 2190 The initial entries in the registry comprise: 2192 +--------+-------------------+ 2193 | TYPE | REFERENCE | 2194 +--------+-------------------+ 2195 | sha1 | [FIPS-180-2-2002] | 2196 | sha256 | [FIPS-180-2-2002] | 2197 +--------+-------------------+ 2199 DKIM Hash Algorithms Initial Values 2201 6.2. Security Considerations {rfc4871bis-02 8, subset} 2203 It has been observed that any mechanism that is introduced that 2204 attempts to stem the flow of spam is subject to intensive attack. 2205 DOSETA needs to be carefully scrutinized to identify potential attack 2206 vectors and the vulnerability to each. See also [RFC4686]. 2208 6.2.1. Misappropriated Private Key 2210 If the private key for a user is resident on their computer and is 2211 not protected by an appropriately secure mechanism, it is possible 2212 for malware to send mail as that user and any other user sharing the 2213 same private key. The malware would not, however, be able to 2214 generate signed spoofs of other signers' addresses, which would aid 2215 in identification of the infected user and would limit the 2216 possibilities for certain types of attacks involving socially 2217 engineered messages. This threat applies mainly to MUA-based 2218 implementations; protection of private keys on servers can be easily 2219 achieved through the use of specialized cryptographic hardware. 2221 A larger problem occurs if malware on many users' computers obtains 2222 the private keys for those users and transmits them via a covert 2223 channel to a site where they can be shared. The compromised users 2224 would likely not know of the misappropriation until they receive 2225 "bounce" messages from messages they are purported to have sent. 2226 Many users might not understand the significance of these bounce 2227 messages and would not take action. 2229 One countermeasure is to use a user-entered passphrase to encrypt the 2230 private key, although users tend to choose weak passphrases and often 2231 reuse them for different purposes, possibly allowing an attack 2232 against DOSETA to be extended into other domains. Nevertheless, the 2233 decoded private key might be briefly available to compromise by 2234 malware when it is entered, or might be discovered via keystroke 2235 logging. The added complexity of entering a passphrase each time one 2236 sends a message would also tend to discourage the use of a secure 2237 passphrase. 2239 A somewhat more effective countermeasure is to send messages through 2240 an outgoing MTA that can authenticate the submitter using existing 2241 techniques (for example, SMTP Authentication), possibly validate the 2242 message itself (for example, verify that the header is legitimate and 2243 that the content passes a spam content check), and sign the message 2244 using a key appropriate for the submitter address. Such an MTA can 2245 also apply controls on the volume of outgoing mail each user is 2246 permitted to originate in order to further limit the ability of 2247 malware to generate bulk email. 2249 6.2.2. Key Server Denial-of-Service Attacks 2251 Since the key servers are distributed (potentially separate for each 2252 domain), the number of servers that would need to be attacked to 2253 defeat this mechanism on an Internet-wide basis is very large. 2254 Nevertheless, key servers for individual domains could be attacked, 2255 impeding the verification of messages from that domain. This is not 2256 significantly different from the ability of an attacker to deny 2257 service to the mail exchangers for a given domain, although it 2258 affects outgoing, not incoming, mail. 2260 A variation on this attack is that if a very large amount of mail 2261 were to be sent using spoofed addresses from a given domain, the key 2262 servers for that domain could be overwhelmed with requests. However, 2263 given the low overhead of verification compared with handling of the 2264 email message itself, such an attack would be difficult to mount. 2266 6.2.3. Attacks Against the DNS 2268 Since the DNS is a required binding for key services, specific 2269 attacks against the DNS need to be considered. 2271 While the DNS is currently insecure [RFC3833], these security 2272 problems are the motivation behind DNS Security (DNSSEC) [RFC4033], 2273 and all users of the DNS will reap the benefit of that work. 2275 DOSETA is only intended as a "sufficient" method of proving 2276 authenticity. It is not intended to provide strong cryptographic 2277 proof about authorship or contents. Other technologies such as 2278 OpenPGP [RFC4880] and S/MIME [RFC5751] address those requirements. 2280 A second security issue related to the DNS revolves around the 2281 increased DNS traffic as a consequence of fetching selector-based 2282 data as well as fetching signing domain policy. Widespread 2283 deployment of DOSETA will result in a significant increase in DNS 2284 queries to the claimed signing domain. In the case of forgeries on a 2285 large scale, DNS servers could see a substantial increase in queries. 2287 A specific DNS security issue that ought to be considered by DOSETA 2288 verifiers is the name chaining attack described in Section 2.3 of 2289 [RFC3833]. A DOSETA verifier, while verifying a DOSETA-Signature 2290 header field, could be prompted to retrieve a key record of an 2291 attacker's choosing. This threat can be minimized by ensuring that 2292 name servers, including recursive name servers, used by the verifier 2293 enforce strict checking of "glue" and other additional information in 2294 DNS responses and are therefore not vulnerable to this attack. 2296 6.2.4. Replay Attacks 2298 In this attack, a spammer sends a message to be spammed to an 2299 accomplice, which results in the message being signed by the 2300 originating MTA. The accomplice resends the message, including the 2301 original signature, to a large number of recipients, possibly by 2302 sending the message to many compromised machines that act as MTAs. 2303 The messages, not having been modified by the accomplice, have valid 2304 signatures. 2306 Partial solutions to this problem involve the use of reputation 2307 services to convey the fact that the specific email address is being 2308 used for spam and that messages from that signer are likely to be 2309 spam. This requires a real-time detection mechanism in order to 2310 react quickly enough. However, such measures might be prone to 2311 abuse, if for example an attacker resent a large number of messages 2312 received from a victim in order to make them appear to be a spammer. 2314 Large verifiers might be able to detect unusually large volumes of 2315 mails with the same signature in a short time period. Smaller 2316 verifiers can get substantially the same volume of information via 2317 existing collaborative systems. 2319 6.2.5. Limits on Revoking Keys 2321 When a large domain detects undesirable behavior on the part of one 2322 of its users, it might wish to revoke the key used to sign that 2323 user's messages in order to disavow responsibility for messages that 2324 have not yet been verified or that are the subject of a replay 2325 attack. However, the ability of the domain to do so can be limited 2326 if the same key, for scalability reasons, is used to sign messages 2327 for many other users. Mechanisms for explicitly revoking keys on a 2328 per-address basis have been proposed but require further study as to 2329 their utility and the DNS load they represent. 2331 6.2.6. Intentionally Malformed Key Records 2333 It is possible for an attacker to publish key records in DNS that are 2334 intentionally malformed, with the intent of causing a denial-of- 2335 service attack on a non-robust verifier implementation. The attacker 2336 could then cause a verifier to read the malformed key record by 2337 sending a message to one of its users referencing the malformed 2338 record in a (not necessarily valid) signature. Verifiers MUST 2339 thoroughly verify all key records retrieved from the DNS and be 2340 robust against intentionally as well as unintentionally malformed key 2341 records. 2343 6.2.7. Intentionally Malformed DOSETA-Signature Header Fields 2345 Verifiers MUST be prepared to receive messages with malformed 2346 DOSETA-Signature Header fields, and thoroughly verify the header 2347 field before depending on any of its contents. 2349 6.2.8. Information Leakage 2351 An attacker could determine when a particular signature was verified 2352 by using a per-message selector and then monitoring their DNS traffic 2353 for the key lookup. This would act as the equivalent of a "web bug" 2354 for verification time rather than when the message was read. 2356 6.2.9. Remote Timing Attacks 2358 In some cases it might be possible to extract private keys using a 2359 remote timing attack [BONEH03]. Implementations SHOULD obfuscate the 2360 timing to prevent such attacks. 2362 6.2.10. Reordered Header Fields 2364 Existing standards allow intermediate MTAs to reorder Header fields. 2365 If a signer signs two or more Header fields of the same name, this 2366 can cause spurious verification errors on otherwise legitimate 2367 messages. In particular, signers that sign any existing 2368 DOSETA-Signature fields run the risk of having messages incorrectly 2369 fail to verify. 2371 6.2.11. RSA Attacks 2373 An attacker could create a large RSA signing key with a small 2374 exponent, thus requiring that the verification key have a large 2375 exponent. This will force verifiers to use considerable computing 2376 resources to verify the signature. Verifiers might avoid this attack 2377 by refusing to verify signatures that reference selectors with public 2378 keys having unreasonable exponents. 2380 In general, an attacker might try to overwhelm a verifier by flooding 2381 it with data requiring verification. This is similar to other server 2382 denial-of-service attacks and needs to be dealt with in a similar 2383 fashion. 2385 6.2.12. Inappropriate Signing by Parent Domains 2387 The trust relationship described in Section 4.7 could conceivably be 2388 used by a parent domain to sign messages with identities in a 2389 subdomain not administratively related to the parent. For example, 2390 the ".com" registry could create messages with signatures using an 2391 "i=" value in the example.com domain. There is no general solution 2392 to this problem, since the administrative cut could occur anywhere in 2393 the domain name. For example, in the domain "example.podunk.ca.us" 2394 there are three administrative cuts (podunk.ca.us, ca.us, and us), 2395 any of which could create messages with an identity in the full 2396 domain. 2398 NOTE: This is considered an acceptable risk for the same reason 2399 that it is acceptable for domain delegation. For example, in the 2400 example above any of the domains could potentially simply delegate 2401 "example.podunk.ca.us" to a server of their choice and completely 2402 replace all DNS-served information. Note that a verifier MAY 2403 ignore signatures that come from an unlikely domain such as 2404 ".com", as discussed in Section 4.5.2. 2406 6.2.13. Attacks Involving Addition of Header Fields 2408 Many email implementations do not enforce [RFC5322] with strictness. 2409 As discussed in Section 4.4.3 DOSETA processing is predicated on a 2410 valid mail message as its input. However, DOSETA implementers need 2411 to be aware of the potential effect of having loose enforcement by 2412 email components interacting with DOSETA modules. 2414 For example, a message with multiple From: Header fields violates 2415 Section 3.6 of [RFC5322]. With the intent of providing a better user 2416 experience, many agents tolerate these violations and deliver the 2417 message anyway. An MUA then might elect to render to the user the 2418 value of the last, or "top", From: field. This might also be done 2419 simply out of the expectation that there is only one, where a "find 2420 first" algorithm would have the same result. Such code in an MUA can 2421 be exploited to fool the user if it is also known that the other 2422 From: field is the one checked by arriving message filters. Such is 2423 the case with DOSETA; although the From: field MUST be signed, a 2424 malformed message bearing more than one From: field might only have 2425 the first ("bottom") one signed, in an attempt to show the message 2426 with some "DOSETA passed" annotation while also rendering the From: 2427 field that was not authenticated. (This can also be taken as a 2428 demonstration that DOSETA is not designed to support author 2429 validation.) 2431 To resist this specific attack the signed header field list can 2432 include an additional reference for each field that was present at 2433 signing. For example, a proper message with one From: field could be 2434 signed using "h=From:From:..." Due to the way header fields are 2435 canonicalized for input to the hash function, the extra field 2436 references will prevent instances of the cited fields from being 2437 added after signing, as doing so would render the signature invalid. 2439 The From: field is used above to illustrate this issue, but it is 2440 only one of > several fields that Section 3.6 of [RFC5322] constrains 2441 in this way. In reality any agent that forgives malformations, or is 2442 careless about identifying which parts of a message were 2443 authenticated, is open to exploitation. 2445 7. References 2447 7.1. Normative References 2449 [FIPS-180-2-2002] 2450 U.S. Department of Commerce, "Secure Hash Standard", FIPS 2451 PUB 180-2, August 2002. 2453 [ITU-X660-1997] 2454 "Information Technology - ASN.1 encoding rules: 2455 Specification of Basic Encoding Rules (BER), Canonical 2456 Encoding Rules (CER) and Distinguished Encoding Rules 2457 (DER)", 1997. 2459 [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 2460 RFC 1034, November 1987. 2462 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2463 Extensions (MIME) Part One: Format of Internet Message 2464 Bodies", RFC 2045, November 1996. 2466 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2467 Extensions (MIME) Part Five: Conformance Criteria and 2468 Examples", RFC 2049, November 1996. 2470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2471 Requirement Levels", BCP 14, RFC 2119, March 1997. 2473 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2474 Standards (PKCS) #1: RSA Cryptography Specifications 2475 Version 2.1", RFC 3447, February 2003. 2477 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2478 Specifications: ABNF", RFC 4234, January 2008. 2480 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2481 October 2008. 2483 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 2484 October 2008. 2486 [RFC5890] Klensin, J., "Internationalizing Domain Names in 2487 Applications (IDNA): Definitions and Document Framework", 2488 RFC 5890, August 2010. 2490 7.2. Informative References 2492 [BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th 2493 USENIX Security Symposium, 2003. 2495 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 2496 "Security Multiparts for MIME: Multipart/Signed and 2497 Multipart/Encrypted", RFC 1847, October 1995. 2499 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 2500 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 2501 RFC 3766, April 2004. 2503 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 2504 Name System (DNS)", RFC 3833, August 2004. 2506 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2507 Procedures for Message Header Fields", BCP 90, RFC 3864, 2508 September 2004. 2510 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2511 Rose, "DNS Security Introduction and Requirements", 2512 RFC 4033, March 2005. 2514 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 2515 RFC 4409, April 2006. 2517 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 2518 Identified Mail (DKIM)", RFC 4686, September 2006. 2520 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 2521 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 2522 Signatures", RFC 4871, May 2007. 2524 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 2525 "OpenPGP Message Format", RFC 4880, November 2007. 2527 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2528 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2529 May 2008. 2531 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 2532 Message Authentication Status", RFC 5451, April 2009. 2534 [RFC5672] Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail 2535 (DKIM) Signatures: Update", RFC 5672, August 2009. 2537 [RFC5751] Ramsdell, B., "Secure/Multipurpose Internet Mail 2538 Extensions (S/MIME) Version 3.1 Message Specification", 2539 RFC 5751, January 2010. 2541 Appendix A. Creating a Public Key {rfc4871bis-02 C} 2543 The default signature is an RSA signed SHA256 digest of the complete 2544 email. For ease of explanation, the openssl command is used to 2545 describe the mechanism by which keys and signatures are managed. One 2546 way to generate a 1024-bit, unencrypted private key suitable for 2547 DOSETA is to use openssl like this: 2548 $ openssl genrsa -out rsa.private 1024 2549 For increased security, the "-passin" parameter can also be added to 2550 encrypt the private key. Use of this parameter will require entering 2551 a password for several of the following steps. Servers might prefer 2552 to use hardware cryptographic support. 2554 The "genrsa" step results in the file rsa.private containing the key 2555 information similar to this: 2556 -----BEGIN RSA PRIVATE KEY----- 2557 MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC 2558 jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb 2559 to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB 2560 AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX 2561 /1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ 2562 gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO 2563 n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m 2564 3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/ 2565 eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj 2566 7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA 2567 qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf 2568 eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX 2569 GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc= 2570 -----END RSA PRIVATE KEY----- 2572 To extract the public-key component from the private key, use openssl 2573 like this: 2574 $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM 2576 This results in the file rsa.public containing the key information 2577 similar to this: 2578 -----BEGIN PUBLIC KEY----- 2579 MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM 2580 oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R 2581 tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI 2582 MmPSPDdQPNUYckcQ2QIDAQAB 2583 -----END PUBLIC KEY----- 2584 This public-key data (without the BEGIN and END tags) is placed in 2585 the DNS: 2587 brisbane IN TXT 2588 ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" 2589 "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" 2590 "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" 2591 "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" 2592 "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") 2594 Appendix B. Acknowledgements 2596 DOSETA is derived from DKIM [RFC4871]. 2598 Authors' Addresses 2600 D. Crocker (editor) 2601 Brandenburg InternetWorking 2602 675 Spruce Dr. 2603 Sunnyvale 2604 USA 2606 Phone: +1.408.246.8253 2607 Email: dcrocker@bbiw.net 2608 URI: http://bbiw.net 2610 M. Kucherawy (editor) 2611 Cloudmark 2612 128 King St., 2nd Floor 2613 San Francisco, CA 94107 2614 USA 2616 Email: msk@cloudmark.com