idnits 2.17.1 draft-wiley-paymentassoc-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 -- The document date (February 27, 2015) is 3346 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3986' is mentioned on line 302, but not defined == Missing Reference: 'RFC5280' is mentioned on line 331, but not defined == Missing Reference: 'RFC1035' is mentioned on line 364, but not defined == Missing Reference: 'BIP16' is mentioned on line 521, but not defined == Unused Reference: 'RFC4648' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'RFC2181' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'RFC3597' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'RFC6672' is defined on line 719, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Wiley, Ed. 3 Internet-Draft E. Osterweil, Ed. 4 Intended status: Standards Track D. Smith, Ed. 5 Expires: August 31, 2015 Verisign 6 A. Reiner, Ed. 7 D. Roark, Ed. 8 Armory Technologies 9 February 27, 2015 11 Using DANE to associate payment information with email addresses 12 draft-wiley-paymentassoc-00 14 Abstract 16 There is no standard, interoperable method for associating Internet 17 service identifiers with payment information. This document 18 specifies a means for retrieving information sufficient for a party 19 to render payment using various payment networks given the 20 recipient's email address by leveraging the DNS to securely publish 21 payment information in a payment association record. A payment 22 association record associates an Internet service identifier such as 23 an email address with payment information such as an account number 24 or Bitcoin address. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 31, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Sending Money . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. The Payment Association Resource Record . . . . . . . . . . . 5 64 2.1. The PMTA RDATA wire format . . . . . . . . . . . . . . . 5 65 2.1.1. Payment Network Selector Field . . . . . . . . . . . 6 66 2.1.2. Preference Field . . . . . . . . . . . . . . . . . . 6 67 2.1.3. URI Length Field . . . . . . . . . . . . . . . . . . 7 68 2.1.4. Uniform Resource Identifier Field . . . . . . . . . . 7 69 2.1.5. Payment Association Data Type Field . . . . . . . . . 7 70 2.1.6. Payment Association Data Field . . . . . . . . . . . 8 71 2.2. The PMTA RDATA presentation format . . . . . . . . . . . 8 72 3. Locating the PMTA record . . . . . . . . . . . . . . . . . . 9 73 3.1. Using Email addresses to Locate PMTA records . . . . . . 9 74 4. Payment Association Data for ACH . . . . . . . . . . . . . . 10 75 4.1. ACH Bank Routing Number . . . . . . . . . . . . . . . . . 10 76 4.2. ACH Account Number . . . . . . . . . . . . . . . . . . . 10 77 4.3. ACH Receiving Name . . . . . . . . . . . . . . . . . . . 11 78 4.4. Wire Format Payment Association Data Field for ACH . . . 11 79 5. Payment Association Data for Bitcoin . . . . . . . . . . . . 11 80 5.1. Bitcoin Addresses . . . . . . . . . . . . . . . . . . . . 11 81 5.2. Bitcoin Components . . . . . . . . . . . . . . . . . . . 12 82 5.3. Wire Format Payment Association Data field for BTC/TBTC . 13 83 5.4. Constructed Script Components . . . . . . . . . . . . . . 13 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 6.1. Email address information leak . . . . . . . . . . . . . 14 86 6.2. Inherent Risk . . . . . . . . . . . . . . . . . . . . . . 14 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 7.1. PMTA RRtype . . . . . . . . . . . . . . . . . . . . . . . 14 89 7.2. Payment Network Selector Registry . . . . . . . . . . . . 15 90 7.3. Payment Association Data Type Registry . . . . . . . . . 15 91 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 94 9.2. Informative References . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 In order to receive payment for goods or services a seller must 100 provide account information or a payment address. Finance systems 101 currently leverage a number of different approaches for providing 102 information required to affect a transfer of money between parties to 103 a transaction. The risk of cut and paste errors and vulnerability to 104 MITM attacks is significant. How can a buyer be certain that they 105 are sending money to the right person? 107 In the case of cryptocurrency, such as Bitcoin, transactions are not 108 reversible; if Bitcoin is sent to the wrong address the funds are 109 permanently lost. In the case of interbank transfers there may be 110 some recourse if funds are sent to the wrong recipient, however 111 recovering the funds can be difficult. It is important that a payer 112 be confident in the association between the recipient and the payment 113 information. 115 This association is most useful in cases where payments are made out 116 of band from a transaction negotiation. For example when buying a 117 product or service you could simply look up the payment information 118 by leveraging an email address. Another example would be when 119 negotiating a transaction over the phone - the seller could provide a 120 mnemonic (such as an email address) that could be reliably retrieved 121 via the DNS. 123 The payment association record ("PMTA") addresses these issues by 124 providing a secure and reliable association between service 125 identifiers and payment information via a new RR type: PMTA. 127 If multiple PMTA records are present in an RRSet then any one of them 128 is valid (provided the preference field is not set to REJECT); which 129 facilitates the use of multiple payment networks and allows the payer 130 to select which network they would like to use. 132 This draft leverages two use cases as practical implementations of 133 the payment association record to demonstrate the use of a payment 134 association. A simple use case provides Automated Clearing House 135 (ACH) information. A more complex use case demonstrates the use of a 136 cryptocurrency (Bitcoin). Other payment networks can also use the 137 PMTA record, which uses should be captured in separate drafts 138 including changes to the IANA registries referenced in this draft. 140 1.1. Sending Money 142 In a retail setting there is infrastructure in place to provide a 143 payer the means for sending money to a payee. In the simplest case 144 the payer hands the payee cash. In a slightly more complicated case 145 the payer uses a credit card terminal to transfer money from a credit 146 card to the payee. Transactions become less secure and reliable once 147 we consider the use cases outside the retail setting, particularly in 148 cases where there is a deferred payment. In the current financial 149 model payers prefer to use either cash or to rely on familiar 150 infrastructure to transfer money to a payee. In the absence of cash 151 or familiar infrastructure (which varies from locale to locale) a 152 payer will defer payment until they can send money via a wire 153 transfer, mail a bank check or purchase a money order. This imposes 154 significant friction on the transactions that occur outside retail or 155 online settings. 157 The security of different payment mechanisms varies widely with 158 respect to vulnerability to unauthorized transfers. In the case of a 159 cryptocurrency like Bitcoin that vulnerability is very low (provided 160 the payer uses their wallet properly). In many parts of the world 161 the bank account and routing numbers are the most common means for 162 affecting transfers. 164 This draft addresses use cases that satisfy two conditions: 1) they 165 occur outside the typical retail setting that provides familiar 166 payment infrastructure and 2) they rely on a source of payment that 167 can be provided to a payer without exposing the payee to the risk of 168 unauthorized transfers. 170 Although Bitcoin provides an almost ideal use case for payment 171 associations some more traditional payment mechanisms are also good 172 candidates for PMTA. Consider account numbers in cases where 173 authentication mechanisms prevent unauthorized transfers from the 174 account (such as shared secrets). It would be very useful for payees 175 to make the account information available to payers in order to 176 reduce the friction in transactions outside a typical retail setting. 178 Companies in the finance industry have spawned an impressive number 179 of "safe" mechanisms for transferring money. Most of which share the 180 same problem we have identified earlier: How do I know that I have 181 the right account number to which to send money? The sheer volume of 182 solutions is a strong indication of the need for making associations 183 between payment information and service identifiers. The model used 184 by Paypal offers probably one of the strongest cases that 185 demonstrates the utility of being able to provide something like an 186 email address as a key to payment information for payers. 188 1.2. Terminology 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC 2119 [RFC2119]. 194 This document also makes use of standard DNSSEC and DANE terminology. 195 See DNSSEC [RFC4033], [RFC4034], [RFC4035], and DANE [RFC6698] for 196 these terms. 198 2. The Payment Association Resource Record 200 The Payment Association (PMTA) DNS resource record (RR) is used to 201 associate payment information with an email address or other internet 202 service identifier, thus forming a "payment association". The goal 203 is to provide sufficient detail to allow for unambiguous and secure 204 delivery of a payment to the requester who has published the PMTA 205 record. 207 A value for the PMTA RR type will be assigned (temporarily use type 208 code 65337 from the block of experimental RR type codes). 210 The PMTA RR is class independent. 212 2.1. The PMTA RDATA wire format 214 The RDATA for a PMTA RR consists of a series of header fields 215 followed by the payment association data: 217 o Payment Network Selector field that indicates which payment 218 network the payment information is relevant to. The value is 219 defined in a new IANA registry in order to make it easier to add 220 new payment networks. 222 o Preference field which indicates the relative preference for this 223 PMTA record compared to other PMTA records in the RR set. 225 o URI Length field that indicates the length of the URI String 226 field. 228 o URI String field that indicates an alternate service that will 229 provide the payment information. 231 o Payment Association Data Type field which indicates the type of 232 the data in payment association data field 234 o The Payment Association Data field is interpreted based on the 235 Payment Network Selector and Payment Association Data Type fields 236 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Payment Network Selector | Preference | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | URI String Length | URI String / 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 243 / / 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Association Data Type | Payment Association Data / 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 247 / / 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 2.1.1. Payment Network Selector Field 252 The Payment Network Selector field indicates which payment network 253 will be used for the transfer of funds. The value of the payment 254 network selector affects the way the Payment Association Data field 255 is interpreted. The value is specific to the payment network and is 256 defined in a new IANA registry in order to make it easier to add new 257 payment network types and usages. This document populates the 258 registry with the following initial values: 260 0 or ACH, Automated Clearing House 262 1 or TBTC, Bitcoin blockchain test network 264 2 or BTC, Bitcoin blockchain network 266 2.1.2. Preference Field 268 The Preference field is a two-octet value interpreted as a 16-bit 269 unsigned integer that indicates the relative preference for this PMTA 270 record compared to other PMTA records in the RR set. A lower value 271 in this field indicates a higher preference. The record with the 272 lowest preference value that the payer can support should be used by 273 the payer. 275 A value of 65535 (2^16-1) in the Preference field indicates that this 276 PMTA RR MUST be considered invalid. This is a way of asserting that 277 the payment information in a previously valid record is no longer 278 valid. 280 2.1.3. URI Length Field 282 The URI Length field indicates the number of characters that follow 283 that should be interpreted as a URI. If the URI Length is greater 284 than 0 then the URI String field specifies an alternate means for 285 retrieving the Payment Information. 287 If the URI Length field is 0 then the URI String field is not 288 populated or used for this record and the Payment Association Data 289 contains the payment information. 291 2.1.4. Uniform Resource Identifier Field 293 The Uniform Resource Identifier (URI) String field is a string 294 encoded as hex digits that specifies an alternate means for 295 retrieving payment information. It describes an alternative location 296 for the payment information. Some domain owners may not want to 297 publish payment information via the DNS but may want to use the DNS 298 to advertise the means to access it. 300 The URI includes a scheme (such as "http", "https", "ftp", etc.) 301 followed by a colon character and then a scheme-specific part as 302 defined in [RFC3986]. 304 The data returned by the service addressed by the URI is interpreted 305 based on specifications provided by the service that responds to the 306 URI. If the URI String field length is greater than 0 then the 307 Payment Association Data field contains cryptographic material that 308 is used to sign the data that is returned by the service addressed by 309 the URI. 311 It is important to note that a URI may specify protocols or service 312 locations that are not universally reachable to relying parties, and 313 administrators should be conscious of this when deciding to store 314 payment information off-axis. 316 2.1.5. Payment Association Data Type Field 318 The Payment Association Data Type field is a two-octet value 319 interpreted as an unsigned integer that specifies how to use the 320 Payment Association Data field. These values will be defined in a 321 new IANA registry. This document populates the new registry with the 322 following initial selector values: 324 0 or ADDR, Payment Association is a static payment address 325 1 or SPKI, if the URI Length field is non-zero then the Payment 326 Association Data contains subject public key info in a DER-encoded 327 binary structure as defined in [RFC5280] 329 2 or CERT, if the URI Length field is non-zero then the Payment 330 Association Data contains a full certificate as defined in 331 [RFC5280] 333 2.1.6. Payment Association Data Field 335 The previously described fields indicate what the payment association 336 field is used for. Although ACH and Bitcoin payment networks are 337 used to demonstrate the PMTA record, other payment networks will 338 require interpretation of the data in this field according to 339 specifications written to describe the indicated payment network. 341 2.2. The PMTA RDATA presentation format 343 The RDATA Presentation Format, as visible in textual zone files is 344 defined as follows: 346 o The Payment Network Selector must be represented as a payment 347 network selector mnemonic or a 16-bit unsigned integer. 349 o Preference must be represented as a 16-bit unsigned integer. 351 o The URI Length field must be represented as a 16-bit unsigned 352 integer. 354 o The URI String field representation will be determined by future 355 work, the description in draft-faltrsom-uri appears to be a 356 reasonable approach. 358 o The Payment Association Data Type field MUST be represented either 359 as a Payment Association Data Type field mnemonic or an 16-bit 360 unsigned integer. 362 o Payment association data MUST be represented as a string of 363 hexadecimal characters. White space is allowed within the string 364 of hexadecimal characters as described in [RFC1035]. 366 Where practical the mnemonic form SHOULD be used in order to provide 367 clarity. 369 3. Locating the PMTA record 371 One of the valuable use cases for payment association records in the 372 DNS is the ability for a user to communicate a predictable and simple 373 anchor to a payer without weakening security. Email addresses are a 374 ubiquitous means for identifying users and make a logical choice as a 375 way of providing payment associations. 377 While email addresses provide a very simple and predictable means for 378 locating a payment association, there is also a need for more 379 flexible mechanisms. Operators may choose to provision a PMTA record 380 with any label in a zone. In these cases the operator simply offers 381 a valid DNS name to payers from which they can retrieve the PMTA 382 records. 384 3.1. Using Email addresses to Locate PMTA records 386 Email addresses are mapped into DNS using the following method: 388 1. The user name (the "left-hand side" of the email address, called 389 the "local-part" in the mail message format definition [RFC2822] 390 and the "local part" in the specification for internationalized 391 email [RFC6530]), is hashed using the SHA2-224 [RFC5754] 392 algorithm represented as hex to become the left-most label in the 393 prepared domain name. This does not include the at symbol ("@") 394 that separates the left and right sides of the email address. 396 2. The DNS does not allow the use of all characters that are 397 supported in "local-part" of email addresses as defined in 398 [RFC2822] and [RFC6530] . The SHA2-224 hashing of the user name 399 ensures that none of these characters would need to be placed 400 directly in the DNS. 402 3. The string "_pmta" becomes the second left-most label in the 403 prepared domain name. 405 4. The domain name (the "right-hand side" of the email address, 406 called the "domain" in RFC 2822) is appended to the result of 407 step 2 to complete the prepared domain name. 409 For example, to request a PMTA resource record for a user whose email 410 address is "bob@example.com", a PMTA query would be placed for the 411 following QNAME: "550c233eeabd0f03bb42b99956efa56cdadaef7d346a04e351a 412 c1b7a._pmta.example.com" The corresponding RR in the example.com zone 413 might look like (hash shortened for formatting): 415 55[..]7a._pmta.example.com. IN PMTA 417 4. Payment Association Data for ACH 419 Automated Clearing House (ACH) is ubiquitous as a means for 420 transferring money between parties. In the United States bank checks 421 are routinely used to make payments when a physical exchange is made 422 between parties. The payer writes a check drawn on their bank, this 423 check includes the ABA routing number (in some cases this is the same 424 as the ACH routing number), account number and authorization to 425 withdraw funds using a hand written signature to authenticate the 426 payer. 428 In many other parts of the world the bank routing number and account 429 number are used to affect electronic transfers between parties 430 without the use of hand signed checks. In these cases the payer 431 initiates the transfer once the recipient of the funds provides their 432 bank routing number and account number. 434 A payer needs very little information to affect a transfer of funds 435 to the recipient, namely: 437 o ACH Bank Routing Number 439 o ACH Account Number 441 o ACH Recipient Name 443 Although there are some additional requirements for an ACH transfer, 444 these can be populated by the payer and do not need to be identified 445 in the payment information. 447 4.1. ACH Bank Routing Number 449 A nine digit number (the ACH Bank Routing Number) encoded as a string 450 of nine octets containing ASCII digits that uniquely identifies the 451 recipient's bank. 453 4.2. ACH Account Number 455 The recipient's account number can be up to thirty five octets long 456 and uniquely identifies the recipient's account at the bank indicated 457 by the routing number. The account number is encoded as a left 458 justified string of ASCII digits, the unused positions are filled 459 with the null character. 461 4.3. ACH Receiving Name 463 The receiving company or individual name must be provided in an ACH 464 transaction as it will appear in the ACH transfer is up to thirty 465 five characters long. The receiving name is left justified and 466 encoded as hexadecimal characters in 70 octets with the unused 467 positions set to 0. 469 4.4. Wire Format Payment Association Data Field for ACH 471 If the Payment Network Selector is ACH then the Payment Association 472 Data Type Field is ADDR and the Payment Association Data field 473 contains the static payment information sufficient to send money to 474 the recipient. 476 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 477 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Routing | Account / 480 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ 481 / | Name / 482 +-+-+-+-+-+-+-+-+-+-+-+-+ / 483 / / 484 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-/ 485 / | unused / 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 5. Payment Association Data for Bitcoin 490 The Payment Association Data Type field shall have the value ADDR for 491 the BTC and TBTC payment networks. Some of the implementation 492 details are left to future work. 494 5.1. Bitcoin Addresses 496 The technical side of Bitcoin causes addresses to have ambiguous 497 meanings. Therefore, the word "address" is not used in this 498 specification without giving a specific definition for the address; 499 an address indicates particular use types that are strictly defined. 501 A Bitcoin address provided to receive payment is simply a chunk of 502 data to be used in a particular script template type. Such templates 503 are known as TxOut script templates. A TxOut script specifies who 504 exactly will receive payment. As of Jan. 2015, there are five 505 standard TxOut types on the Bitcoin network. The TxOut types are not 506 of specific interest except to help explain what this specification 507 is attempting to accomplish. 509 For example, as of Jan. 2015, the most common TxOut type on the 510 Bitcoin network is known as the pay-to-public-key-hash (P2PKH) 511 template. P2PKH uses addresses starting with 1. In P2PKH, the payer 512 must insert a 20 byte payload, based on a secure hash of a public 513 key, into the accompanying P2PKH script template. The P2PKH template 514 is defined as follows: 516 OP_DUP OP_HASH160 <20 byte payload> OP_EQUALVERIFY OP_CHECKSIG 518 Another address example is an address starting with 3. For such 519 addresses, the payer must insert the inner 20 byte payload into what 520 is known as a pay-to-script-hash (P2SH) template, as defined in BIP 521 16 [BIP16]. The P2SH template is defined as follows: 523 OP_HASH160 <20 byte payload> OP_EQUAL 525 This specification focuses on that fact that the Bitcoin wallet 526 software, at the time of payment, is ultimately constructing a 527 destination, or destinations, for the coins. This specification 528 defines a way for Bitcoin wallet software to communicate both the 529 TxOut script to be paid, as well as a secure authentication chain for 530 verifying that a TxOut script is associated with a given recipient. 532 5.2. Bitcoin Components 534 Public Key Source (PKS): Communicates the simplest of ID information, 535 typically about a single BIP32 key tree that would be used as a 536 single signature wallet to manage funds. A PKS can also be used as a 537 placeholder in a more complex, constructed script. A public key 538 source can also be a reference to another resource for getting the 539 public key source. 541 Constructed Script (CS): This is a data structure which includes a 542 script template and a list of public key sources. 544 Raw Payment Script (RPS): This is the final, complete script expected 545 to receive payment as part of a given payment association. The payer 546 may ignore any attached proofs and simply use this script to pay. 547 This will usually be provided with a PKRP and/or SRP (see below). 548 However, if a PKS is a stealth address, requires a user-supplied key, 549 or uses an external source, an RPS cannot be included. There may be 550 other conditions when an RPS cannot be provided. Encoding and 551 Implementation details are left to future work. 553 Public Key Relationship Proof (PKRP): This is a list of multipliers 554 to apply to a given PKS. If the PKS specifies a root-level public 555 key, but the payment script uses a 3rd-level public key, then the 556 proof will actually be three 32-byte multipliers. Encoding and 557 Implementation details are left to future work. 559 Script Relationship Proof (SRP): This is a list of PKRPs to be 560 applied to a Constructed Script, one per public key placeholder in 561 the script template. Encoding and Implementation details are left to 562 future work. 564 5.3. Wire Format Payment Association Data field for BTC/TBTC 566 In the example cases using the simplest bitcoin addresses the wire 567 format for the Payment Association Data field includes a few fields. 569 The Script Length field is encoded as a 16-bit unsigned integer (two- 570 octets) and specifies the length in octets of the Script/Address 571 field. 573 The Script/Address field is encoded as a 575 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 576 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Script Length | Script/Address / 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 580 / / 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 5.4. Constructed Script Components 585 Some use cases will leverage payment information more complex than a 586 static payment address. If the selector field specifies a 587 constructed script then the payment association data is further 588 described as: 590 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 591 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Tx Method | Script Template | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 / PKS entries / 596 / / 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 Tx Method is a one-octet value that specified the transaction 600 method. Values include 0 or 1 to indicate whether a P2SH is to be 601 used. 603 A Script template that contains specifically designed opcodes that 604 use public key data to construct the final TxOut script. 606 PKS entries is a list of PKS entries used with the script template 607 to construct the final script. 609 6. Security Considerations 611 PMTA usage considerations are published in a separate usage document. 613 6.1. Email address information leak 615 Using email addresses as a key to fetch payment information by 616 including them in the DNS provides an undesirable opportunity for 617 harvesting email addresses for attackers willing to "walk" the zone. 618 While using NSEC3 increases the difficulty of harvesting email 619 addresses by "walking" a zone it does not prevent this approach. 621 NSEC5 might be a more viable option than NSEC3 for preventing 622 unintended leaks via the DNS however at the time of this draft it is 623 still being discussed as a proposal. Note that this problem is 624 shared by other proposed record types that create associations 625 similar to those used by PMTA (SMIMEA, OPENPGPKEY). 627 6.2. Inherent Risk 629 The use of the PMTA RR type should be restricted to zones that are 630 properly signed (DNSSEC). The use of the DNS for delivering payment 631 information underscores the importance of keeping the keys used for 632 signing the zone secure. 634 7. IANA Considerations 636 7.1. PMTA RRtype 638 This document defines a new DNS RR type, PMTA, whose value will be 639 allocated by IANA from the Resource Record (RR) TYPEs subregistry of 640 the Domain Name System (DNS) Parameters registry. 642 IANA is requested to create two other registries: 644 o Payment Network Selector 646 o Payment Association Data Type 648 7.2. Payment Network Selector Registry 650 This document creates a new registry, the "Payment Network Selector". 651 The registry policy is "RFC required" and the initial entries in the 652 registry are: 654 Value Short Description Mnemonic Reference 655 ----- ------------------------------- -------- --------- 656 0 Automated Clearing House ACH 657 1 Bitcoin blockchain test network TBTC 658 2 Bitcoin blockchain BTC 660 7.3. Payment Association Data Type Registry 662 This document creates a new registry, the "Payment Association Data 663 Type". The registry policy is "RFC required" and the initial entries 664 in the registry are: 666 Value Short Description Mnemonic Reference 667 ----- -------------------------- -------- --------- 668 0 Simple Address ADDR 669 1 Subject Public Key for URI SPKI 670 2 Full certificate for URI CERT 672 8. Acknowledgments 674 Burt Kaliski provided significant direction and useful feedback to 675 this document. Additional input from Scott Hollenbeck, Swapneel 676 Sheth and Lynch Davis contributed to this document. Some text was 677 taken from an early draft of the DANE SMIME proposal by Scott Rose 678 and the DANE openpgp draft by Paul Wouters as well. 680 9. References 682 9.1. Normative References 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, March 1997. 687 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 688 Rose, "DNS Security Introduction and Requirements", RFC 689 4033, March 2005. 691 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 692 Rose, "Resource Records for the DNS Security Extensions", 693 RFC 4034, March 2005. 695 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 696 Rose, "Protocol Modifications for the DNS Security 697 Extensions", RFC 4035, March 2005. 699 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 700 Encodings", RFC 4648, October 2006. 702 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 703 Message Syntax", RFC 5754, January 2010. 705 9.2. Informative References 707 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 708 Specification", RFC 2181, July 1997. 710 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 711 2001. 713 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 714 (RR) Types", RFC 3597, September 2003. 716 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 717 Internationalized Email", RFC 6530, February 2012. 719 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 720 DNS", RFC 6672, June 2012. 722 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 723 of Named Entities (DANE) Transport Layer Security (TLS) 724 Protocol: TLSA", RFC 6698, August 2012. 726 Authors' Addresses 728 Glen Wiley (editor) 729 Verisign 731 Email: gwiley@verisign.com 733 Eric Osterweil (editor) 734 Verisign 736 Email: eosterweil@verisign.com 737 David Smith (editor) 738 Verisign 740 Email: dsmith@verisign.com 742 Alan Reiner (editor) 743 Armory Technologies 745 Email: alan@bitcoinarmory.com 747 Douglas Roark (editor) 748 Armory Technologies 750 Email: doug@bitcoinarmory.com