Internet DRAFT - draft-wiley-paymentassoc

draft-wiley-paymentassoc







Network Working Group                                      G. Wiley, Ed.
Internet-Draft                                         E. Osterweil, Ed.
Intended status: Standards Track                           D. Smith, Ed.
Expires: August 31, 2015                                        Verisign
                                                          A. Reiner, Ed.
                                                           D. Roark, Ed.
                                                     Armory Technologies
                                                       February 27, 2015


    Using DANE to associate payment information with email addresses
                      draft-wiley-paymentassoc-00

Abstract

   There is no standard, interoperable method for associating Internet
   service identifiers with payment information.  This document
   specifies a means for retrieving information sufficient for a party
   to render payment using various payment networks given the
   recipient's email address by leveraging the DNS to securely publish
   payment information in a payment association record.  A payment
   association record associates an Internet service identifier such as
   an email address with payment information such as an account number
   or Bitcoin address.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 31, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Wiley, et al.            Expires August 31, 2015                [Page 1]

Internet-Draft        DANE for Payment Association         February 2015


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Sending Money . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  The Payment Association Resource Record . . . . . . . . . . .   5
     2.1.  The PMTA RDATA wire format  . . . . . . . . . . . . . . .   5
       2.1.1.  Payment Network Selector Field  . . . . . . . . . . .   6
       2.1.2.  Preference Field  . . . . . . . . . . . . . . . . . .   6
       2.1.3.  URI Length Field  . . . . . . . . . . . . . . . . . .   7
       2.1.4.  Uniform Resource Identifier Field . . . . . . . . . .   7
       2.1.5.  Payment Association Data Type Field . . . . . . . . .   7
       2.1.6.  Payment Association Data Field  . . . . . . . . . . .   8
     2.2.  The PMTA RDATA presentation format  . . . . . . . . . . .   8
   3.  Locating the PMTA record  . . . . . . . . . . . . . . . . . .   9
     3.1.  Using Email addresses to Locate PMTA records  . . . . . .   9
   4.  Payment Association Data for ACH  . . . . . . . . . . . . . .  10
     4.1.  ACH Bank Routing Number . . . . . . . . . . . . . . . . .  10
     4.2.  ACH Account Number  . . . . . . . . . . . . . . . . . . .  10
     4.3.  ACH Receiving Name  . . . . . . . . . . . . . . . . . . .  11
     4.4.  Wire Format Payment Association Data Field for ACH  . . .  11
   5.  Payment Association Data for Bitcoin  . . . . . . . . . . . .  11
     5.1.  Bitcoin Addresses . . . . . . . . . . . . . . . . . . . .  11
     5.2.  Bitcoin Components  . . . . . . . . . . . . . . . . . . .  12
     5.3.  Wire Format Payment Association Data field for BTC/TBTC .  13
     5.4.  Constructed Script Components . . . . . . . . . . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
     6.1.  Email address information leak  . . . . . . . . . . . . .  14
     6.2.  Inherent Risk . . . . . . . . . . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  PMTA RRtype . . . . . . . . . . . . . . . . . . . . . . .  14
     7.2.  Payment Network Selector Registry . . . . . . . . . . . .  15
     7.3.  Payment Association Data Type Registry  . . . . . . . . .  15
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  15
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16



Wiley, et al.            Expires August 31, 2015                [Page 2]

Internet-Draft        DANE for Payment Association         February 2015


1.  Introduction

   In order to receive payment for goods or services a seller must
   provide account information or a payment address.  Finance systems
   currently leverage a number of different approaches for providing
   information required to affect a transfer of money between parties to
   a transaction.  The risk of cut and paste errors and vulnerability to
   MITM attacks is significant.  How can a buyer be certain that they
   are sending money to the right person?

   In the case of cryptocurrency, such as Bitcoin, transactions are not
   reversible; if Bitcoin is sent to the wrong address the funds are
   permanently lost.  In the case of interbank transfers there may be
   some recourse if funds are sent to the wrong recipient, however
   recovering the funds can be difficult.  It is important that a payer
   be confident in the association between the recipient and the payment
   information.

   This association is most useful in cases where payments are made out
   of band from a transaction negotiation.  For example when buying a
   product or service you could simply look up the payment information
   by leveraging an email address.  Another example would be when
   negotiating a transaction over the phone - the seller could provide a
   mnemonic (such as an email address) that could be reliably retrieved
   via the DNS.

   The payment association record ("PMTA") addresses these issues by
   providing a secure and reliable association between service
   identifiers and payment information via a new RR type: PMTA.

   If multiple PMTA records are present in an RRSet then any one of them
   is valid (provided the preference field is not set to REJECT); which
   facilitates the use of multiple payment networks and allows the payer
   to select which network they would like to use.

   This draft leverages two use cases as practical implementations of
   the payment association record to demonstrate the use of a payment
   association.  A simple use case provides Automated Clearing House
   (ACH) information.  A more complex use case demonstrates the use of a
   cryptocurrency (Bitcoin).  Other payment networks can also use the
   PMTA record, which uses should be captured in separate drafts
   including changes to the IANA registries referenced in this draft.

1.1.  Sending Money

   In a retail setting there is infrastructure in place to provide a
   payer the means for sending money to a payee.  In the simplest case
   the payer hands the payee cash.  In a slightly more complicated case



Wiley, et al.            Expires August 31, 2015                [Page 3]

Internet-Draft        DANE for Payment Association         February 2015


   the payer uses a credit card terminal to transfer money from a credit
   card to the payee.  Transactions become less secure and reliable once
   we consider the use cases outside the retail setting, particularly in
   cases where there is a deferred payment.  In the current financial
   model payers prefer to use either cash or to rely on familiar
   infrastructure to transfer money to a payee.  In the absence of cash
   or familiar infrastructure (which varies from locale to locale) a
   payer will defer payment until they can send money via a wire
   transfer, mail a bank check or purchase a money order.  This imposes
   significant friction on the transactions that occur outside retail or
   online settings.

   The security of different payment mechanisms varies widely with
   respect to vulnerability to unauthorized transfers.  In the case of a
   cryptocurrency like Bitcoin that vulnerability is very low (provided
   the payer uses their wallet properly).  In many parts of the world
   the bank account and routing numbers are the most common means for
   affecting transfers.

   This draft addresses use cases that satisfy two conditions: 1) they
   occur outside the typical retail setting that provides familiar
   payment infrastructure and 2) they rely on a source of payment that
   can be provided to a payer without exposing the payee to the risk of
   unauthorized transfers.

   Although Bitcoin provides an almost ideal use case for payment
   associations some more traditional payment mechanisms are also good
   candidates for PMTA.  Consider account numbers in cases where
   authentication mechanisms prevent unauthorized transfers from the
   account (such as shared secrets).  It would be very useful for payees
   to make the account information available to payers in order to
   reduce the friction in transactions outside a typical retail setting.

   Companies in the finance industry have spawned an impressive number
   of "safe" mechanisms for transferring money.  Most of which share the
   same problem we have identified earlier: How do I know that I have
   the right account number to which to send money?  The sheer volume of
   solutions is a strong indication of the need for making associations
   between payment information and service identifiers.  The model used
   by Paypal offers probably one of the strongest cases that
   demonstrates the utility of being able to provide something like an
   email address as a key to payment information for payers.

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].



Wiley, et al.            Expires August 31, 2015                [Page 4]

Internet-Draft        DANE for Payment Association         February 2015


   This document also makes use of standard DNSSEC and DANE terminology.
   See DNSSEC [RFC4033], [RFC4034], [RFC4035], and DANE [RFC6698] for
   these terms.

2.  The Payment Association Resource Record

   The Payment Association (PMTA) DNS resource record (RR) is used to
   associate payment information with an email address or other internet
   service identifier, thus forming a "payment association".  The goal
   is to provide sufficient detail to allow for unambiguous and secure
   delivery of a payment to the requester who has published the PMTA
   record.

   A value for the PMTA RR type will be assigned (temporarily use type
   code 65337 from the block of experimental RR type codes).

   The PMTA RR is class independent.

2.1.  The PMTA RDATA wire format

   The RDATA for a PMTA RR consists of a series of header fields
   followed by the payment association data:

   o  Payment Network Selector field that indicates which payment
      network the payment information is relevant to.  The value is
      defined in a new IANA registry in order to make it easier to add
      new payment networks.

   o  Preference field which indicates the relative preference for this
      PMTA record compared to other PMTA records in the RR set.

   o  URI Length field that indicates the length of the URI String
      field.

   o  URI String field that indicates an alternate service that will
      provide the payment information.

   o  Payment Association Data Type field which indicates the type of
      the data in payment association data field

   o  The Payment Association Data field is interpreted based on the
      Payment Network Selector and Payment Association Data Type fields









Wiley, et al.            Expires August 31, 2015                [Page 5]

Internet-Draft        DANE for Payment Association         February 2015


                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Payment Network Selector      | Preference                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | URI String Length             | URI String                    /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Association Data Type         |    Payment Association Data   /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.1.  Payment Network Selector Field

   The Payment Network Selector field indicates which payment network
   will be used for the transfer of funds.  The value of the payment
   network selector affects the way the Payment Association Data field
   is interpreted.  The value is specific to the payment network and is
   defined in a new IANA registry in order to make it easier to add new
   payment network types and usages.  This document populates the
   registry with the following initial values:

      0 or ACH, Automated Clearing House

      1 or TBTC, Bitcoin blockchain test network

      2 or BTC, Bitcoin blockchain network

2.1.2.  Preference Field

   The Preference field is a two-octet value interpreted as a 16-bit
   unsigned integer that indicates the relative preference for this PMTA
   record compared to other PMTA records in the RR set.  A lower value
   in this field indicates a higher preference.  The record with the
   lowest preference value that the payer can support should be used by
   the payer.

   A value of 65535 (2^16-1) in the Preference field indicates that this
   PMTA RR MUST be considered invalid.  This is a way of asserting that
   the payment information in a previously valid record is no longer
   valid.








Wiley, et al.            Expires August 31, 2015                [Page 6]

Internet-Draft        DANE for Payment Association         February 2015


2.1.3.  URI Length Field

   The URI Length field indicates the number of characters that follow
   that should be interpreted as a URI.  If the URI Length is greater
   than 0 then the URI String field specifies an alternate means for
   retrieving the Payment Information.

   If the URI Length field is 0 then the URI String field is not
   populated or used for this record and the Payment Association Data
   contains the payment information.

2.1.4.  Uniform Resource Identifier Field

   The Uniform Resource Identifier (URI) String field is a string
   encoded as hex digits that specifies an alternate means for
   retrieving payment information.  It describes an alternative location
   for the payment information.  Some domain owners may not want to
   publish payment information via the DNS but may want to use the DNS
   to advertise the means to access it.

   The URI includes a scheme (such as "http", "https", "ftp", etc.)
   followed by a colon character and then a scheme-specific part as
   defined in [RFC3986].

   The data returned by the service addressed by the URI is interpreted
   based on specifications provided by the service that responds to the
   URI.  If the URI String field length is greater than 0 then the
   Payment Association Data field contains cryptographic material that
   is used to sign the data that is returned by the service addressed by
   the URI.

   It is important to note that a URI may specify protocols or service
   locations that are not universally reachable to relying parties, and
   administrators should be conscious of this when deciding to store
   payment information off-axis.

2.1.5.  Payment Association Data Type Field

   The Payment Association Data Type field is a two-octet value
   interpreted as an unsigned integer that specifies how to use the
   Payment Association Data field.  These values will be defined in a
   new IANA registry.  This document populates the new registry with the
   following initial selector values:

      0 or ADDR, Payment Association is a static payment address






Wiley, et al.            Expires August 31, 2015                [Page 7]

Internet-Draft        DANE for Payment Association         February 2015


      1 or SPKI, if the URI Length field is non-zero then the Payment
      Association Data contains subject public key info in a DER-encoded
      binary structure as defined in [RFC5280]

      2 or CERT, if the URI Length field is non-zero then the Payment
      Association Data contains a full certificate as defined in
      [RFC5280]

2.1.6.  Payment Association Data Field

   The previously described fields indicate what the payment association
   field is used for.  Although ACH and Bitcoin payment networks are
   used to demonstrate the PMTA record, other payment networks will
   require interpretation of the data in this field according to
   specifications written to describe the indicated payment network.

2.2.  The PMTA RDATA presentation format

   The RDATA Presentation Format, as visible in textual zone files is
   defined as follows:

   o  The Payment Network Selector must be represented as a payment
      network selector mnemonic or a 16-bit unsigned integer.

   o  Preference must be represented as a 16-bit unsigned integer.

   o  The URI Length field must be represented as a 16-bit unsigned
      integer.

   o  The URI String field representation will be determined by future
      work, the description in draft-faltrsom-uri appears to be a
      reasonable approach.

   o  The Payment Association Data Type field MUST be represented either
      as a Payment Association Data Type field mnemonic or an 16-bit
      unsigned integer.

   o  Payment association data MUST be represented as a string of
      hexadecimal characters.  White space is allowed within the string
      of hexadecimal characters as described in [RFC1035].

   Where practical the mnemonic form SHOULD be used in order to provide
   clarity.








Wiley, et al.            Expires August 31, 2015                [Page 8]

Internet-Draft        DANE for Payment Association         February 2015


3.  Locating the PMTA record

   One of the valuable use cases for payment association records in the
   DNS is the ability for a user to communicate a predictable and simple
   anchor to a payer without weakening security.  Email addresses are a
   ubiquitous means for identifying users and make a logical choice as a
   way of providing payment associations.

   While email addresses provide a very simple and predictable means for
   locating a payment association, there is also a need for more
   flexible mechanisms.  Operators may choose to provision a PMTA record
   with any label in a zone.  In these cases the operator simply offers
   a valid DNS name to payers from which they can retrieve the PMTA
   records.

3.1.  Using Email addresses to Locate PMTA records

   Email addresses are mapped into DNS using the following method:

   1.  The user name (the "left-hand side" of the email address, called
       the "local-part" in the mail message format definition [RFC2822]
       and the "local part" in the specification for internationalized
       email [RFC6530]), is hashed using the SHA2-224 [RFC5754]
       algorithm represented as hex to become the left-most label in the
       prepared domain name.  This does not include the at symbol ("@")
       that separates the left and right sides of the email address.

   2.  The DNS does not allow the use of all characters that are
       supported in "local-part" of email addresses as defined in
       [RFC2822] and [RFC6530] . The SHA2-224 hashing of the user name
       ensures that none of these characters would need to be placed
       directly in the DNS.

   3.  The string "_pmta" becomes the second left-most label in the
       prepared domain name.

   4.  The domain name (the "right-hand side" of the email address,
       called the "domain" in RFC 2822) is appended to the result of
       step 2 to complete the prepared domain name.

   For example, to request a PMTA resource record for a user whose email
   address is "bob@example.com", a PMTA query would be placed for the
   following QNAME: "550c233eeabd0f03bb42b99956efa56cdadaef7d346a04e351a
   c1b7a._pmta.example.com" The corresponding RR in the example.com zone
   might look like (hash shortened for formatting):

   55[..]7a._pmta.example.com.  IN PMTA <payment association>




Wiley, et al.            Expires August 31, 2015                [Page 9]

Internet-Draft        DANE for Payment Association         February 2015


4.  Payment Association Data for ACH

   Automated Clearing House (ACH) is ubiquitous as a means for
   transferring money between parties.  In the United States bank checks
   are routinely used to make payments when a physical exchange is made
   between parties.  The payer writes a check drawn on their bank, this
   check includes the ABA routing number (in some cases this is the same
   as the ACH routing number), account number and authorization to
   withdraw funds using a hand written signature to authenticate the
   payer.

   In many other parts of the world the bank routing number and account
   number are used to affect electronic transfers between parties
   without the use of hand signed checks.  In these cases the payer
   initiates the transfer once the recipient of the funds provides their
   bank routing number and account number.

   A payer needs very little information to affect a transfer of funds
   to the recipient, namely:

   o  ACH Bank Routing Number

   o  ACH Account Number

   o  ACH Recipient Name

   Although there are some additional requirements for an ACH transfer,
   these can be populated by the payer and do not need to be identified
   in the payment information.

4.1.  ACH Bank Routing Number

   A nine digit number (the ACH Bank Routing Number) encoded as a string
   of nine octets containing ASCII digits that uniquely identifies the
   recipient's bank.

4.2.  ACH Account Number

   The recipient's account number can be up to thirty five octets long
   and uniquely identifies the recipient's account at the bank indicated
   by the routing number.  The account number is encoded as a left
   justified string of ASCII digits, the unused positions are filled
   with the null character.








Wiley, et al.            Expires August 31, 2015               [Page 10]

Internet-Draft        DANE for Payment Association         February 2015


4.3.  ACH Receiving Name

   The receiving company or individual name must be provided in an ACH
   transaction as it will appear in the ACH transfer is up to thirty
   five characters long.  The receiving name is left justified and
   encoded as hexadecimal characters in 70 octets with the unused
   positions set to 0.

4.4.  Wire Format Payment Association Data Field for ACH

   If the Payment Network Selector is ACH then the Payment Association
   Data Type Field is ADDR and the Payment Association Data field
   contains the static payment information sufficient to send money to
   the recipient.

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Routing        |  Account                                    /
   +-+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
   /                       |  Name                                 /
   +-+-+-+-+-+-+-+-+-+-+-+-+                                       /
   /                                                               /
   /                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-/
   /                                   | unused                    /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.  Payment Association Data for Bitcoin

   The Payment Association Data Type field shall have the value ADDR for
   the BTC and TBTC payment networks.  Some of the implementation
   details are left to future work.

5.1.  Bitcoin Addresses

   The technical side of Bitcoin causes addresses to have ambiguous
   meanings.  Therefore, the word "address" is not used in this
   specification without giving a specific definition for the address;
   an address indicates particular use types that are strictly defined.

   A Bitcoin address provided to receive payment is simply a chunk of
   data to be used in a particular script template type.  Such templates
   are known as TxOut script templates.  A TxOut script specifies who
   exactly will receive payment.  As of Jan. 2015, there are five
   standard TxOut types on the Bitcoin network.  The TxOut types are not
   of specific interest except to help explain what this specification
   is attempting to accomplish.




Wiley, et al.            Expires August 31, 2015               [Page 11]

Internet-Draft        DANE for Payment Association         February 2015


   For example, as of Jan. 2015, the most common TxOut type on the
   Bitcoin network is known as the pay-to-public-key-hash (P2PKH)
   template.  P2PKH uses addresses starting with 1.  In P2PKH, the payer
   must insert a 20 byte payload, based on a secure hash of a public
   key, into the accompanying P2PKH script template.  The P2PKH template
   is defined as follows:

       OP_DUP OP_HASH160 <20 byte payload> OP_EQUALVERIFY OP_CHECKSIG

   Another address example is an address starting with 3.  For such
   addresses, the payer must insert the inner 20 byte payload into what
   is known as a pay-to-script-hash (P2SH) template, as defined in BIP
   16 [BIP16].  The P2SH template is defined as follows:

       OP_HASH160 <20 byte payload> OP_EQUAL

   This specification focuses on that fact that the Bitcoin wallet
   software, at the time of payment, is ultimately constructing a
   destination, or destinations, for the coins.  This specification
   defines a way for Bitcoin wallet software to communicate both the
   TxOut script to be paid, as well as a secure authentication chain for
   verifying that a TxOut script is associated with a given recipient.

5.2.  Bitcoin Components

   Public Key Source (PKS): Communicates the simplest of ID information,
   typically about a single BIP32 key tree that would be used as a
   single signature wallet to manage funds.  A PKS can also be used as a
   placeholder in a more complex, constructed script.  A public key
   source can also be a reference to another resource for getting the
   public key source.

   Constructed Script (CS): This is a data structure which includes a
   script template and a list of public key sources.

   Raw Payment Script (RPS): This is the final, complete script expected
   to receive payment as part of a given payment association.  The payer
   may ignore any attached proofs and simply use this script to pay.
   This will usually be provided with a PKRP and/or SRP (see below).
   However, if a PKS is a stealth address, requires a user-supplied key,
   or uses an external source, an RPS cannot be included.  There may be
   other conditions when an RPS cannot be provided.  Encoding and
   Implementation details are left to future work.

   Public Key Relationship Proof (PKRP): This is a list of multipliers
   to apply to a given PKS.  If the PKS specifies a root-level public
   key, but the payment script uses a 3rd-level public key, then the




Wiley, et al.            Expires August 31, 2015               [Page 12]

Internet-Draft        DANE for Payment Association         February 2015


   proof will actually be three 32-byte multipliers.  Encoding and
   Implementation details are left to future work.

   Script Relationship Proof (SRP): This is a list of PKRPs to be
   applied to a Constructed Script, one per public key placeholder in
   the script template.  Encoding and Implementation details are left to
   future work.

5.3.  Wire Format Payment Association Data field for BTC/TBTC

   In the example cases using the simplest bitcoin addresses the wire
   format for the Payment Association Data field includes a few fields.

   The Script Length field is encoded as a 16-bit unsigned integer (two-
   octets) and specifies the length in octets of the Script/Address
   field.

   The Script/Address field is encoded as a

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Script Length                | Script/Address                /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.4.  Constructed Script Components

   Some use cases will leverage payment information more complex than a
   static payment address.  If the selector field specifies a
   constructed script then the payment association data is further
   described as:

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Tx Method    |  Script Template                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                 PKS entries                                   /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Tx Method is a one-octet value that specified the transaction
      method.  Values include 0 or 1 to indicate whether a P2SH is to be
      used.





Wiley, et al.            Expires August 31, 2015               [Page 13]

Internet-Draft        DANE for Payment Association         February 2015


      A Script template that contains specifically designed opcodes that
      use public key data to construct the final TxOut script.

      PKS entries is a list of PKS entries used with the script template
      to construct the final script.

6.  Security Considerations

   PMTA usage considerations are published in a separate usage document.

6.1.  Email address information leak

   Using email addresses as a key to fetch payment information by
   including them in the DNS provides an undesirable opportunity for
   harvesting email addresses for attackers willing to "walk" the zone.
   While using NSEC3 increases the difficulty of harvesting email
   addresses by "walking" a zone it does not prevent this approach.

   NSEC5 might be a more viable option than NSEC3 for preventing
   unintended leaks via the DNS however at the time of this draft it is
   still being discussed as a proposal.  Note that this problem is
   shared by other proposed record types that create associations
   similar to those used by PMTA (SMIMEA, OPENPGPKEY).

6.2.  Inherent Risk

   The use of the PMTA RR type should be restricted to zones that are
   properly signed (DNSSEC).  The use of the DNS for delivering payment
   information underscores the importance of keeping the keys used for
   signing the zone secure.

7.  IANA Considerations

7.1.  PMTA RRtype

   This document defines a new DNS RR type, PMTA, whose value will be
   allocated by IANA from the Resource Record (RR) TYPEs subregistry of
   the Domain Name System (DNS) Parameters registry.

   IANA is requested to create two other registries:

   o  Payment Network Selector

   o  Payment Association Data Type







Wiley, et al.            Expires August 31, 2015               [Page 14]

Internet-Draft        DANE for Payment Association         February 2015


7.2.  Payment Network Selector Registry

   This document creates a new registry, the "Payment Network Selector".
   The registry policy is "RFC required" and the initial entries in the
   registry are:

         Value Short Description               Mnemonic Reference
         ----- ------------------------------- -------- ---------
         0     Automated Clearing House        ACH
         1     Bitcoin blockchain test network TBTC
         2     Bitcoin blockchain              BTC

7.3.  Payment Association Data Type Registry

   This document creates a new registry, the "Payment Association Data
   Type".  The registry policy is "RFC required" and the initial entries
   in the registry are:

            Value Short Description          Mnemonic Reference
            ----- -------------------------- -------- ---------
            0     Simple Address             ADDR
            1     Subject Public Key for URI SPKI
            2     Full certificate for URI   CERT

8.  Acknowledgments

   Burt Kaliski provided significant direction and useful feedback to
   this document.  Additional input from Scott Hollenbeck, Swapneel
   Sheth and Lynch Davis contributed to this document.  Some text was
   taken from an early draft of the DANE SMIME proposal by Scott Rose
   and the DANE openpgp draft by Paul Wouters as well.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.





Wiley, et al.            Expires August 31, 2015               [Page 15]

Internet-Draft        DANE for Payment Association         February 2015


   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
              Message Syntax", RFC 5754, January 2010.

9.2.  Informative References

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
              2001.

   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
              (RR) Types", RFC 3597, September 2003.

   [RFC6530]  Klensin, J. and Y. Ko, "Overview and Framework for
              Internationalized Email", RFC 6530, February 2012.

   [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the
              DNS", RFC 6672, June 2012.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

Authors' Addresses

   Glen Wiley (editor)
   Verisign

   Email: gwiley@verisign.com


   Eric Osterweil (editor)
   Verisign

   Email: eosterweil@verisign.com








Wiley, et al.            Expires August 31, 2015               [Page 16]

Internet-Draft        DANE for Payment Association         February 2015


   David Smith (editor)
   Verisign

   Email: dsmith@verisign.com


   Alan Reiner (editor)
   Armory Technologies

   Email: alan@bitcoinarmory.com


   Douglas Roark (editor)
   Armory Technologies

   Email: doug@bitcoinarmory.com



































Wiley, et al.            Expires August 31, 2015               [Page 17]