From 19845126ec697f043a23f382a2653c0bdd10a6a3 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Thu, 17 Mar 2016 05:21:40 +0000 Subject: Put BIP 75 in the right place in README, and clean up formatting a bit --- README.mediawiki | 12 ++++++------ bip-0070/extensions.mediawiki | 2 +- bip-0075.mediawiki | 21 ++++++++++----------- 3 files changed, 17 insertions(+), 18 deletions(-) diff --git a/README.mediawiki b/README.mediawiki index 970cf93..be60e8f 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -314,6 +314,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0075.mediawiki|75]] +| Out of Band Address Exchange using Payment Protocol Encryption +| Justin Newton, Matt David, Aaron Voisine, James MacWhyte +| Standard +| Draft +|- | [[bip-0080.mediawiki|80]] | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets | Justus Ranvier, Jimmy Song @@ -332,12 +338,6 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- -| [[bip-0075.mediawiki|75]] -| Out of Band Address Exchange using Payment Protocol Encryption -| Justin Newton, Matt David, Aaron Voisine and James MacWhyte -| Standard -| Draft -|- | [[bip-0099.mediawiki|99]] | Motivation and deployment of consensus rule changes ([soft/hard]forks) | Jorge Timón diff --git a/bip-0070/extensions.mediawiki b/bip-0070/extensions.mediawiki index b572b1d..51400d8 100644 --- a/bip-0070/extensions.mediawiki +++ b/bip-0070/extensions.mediawiki @@ -6,4 +6,4 @@ Add your extension below using tags starting at 1000 and submit a pull-req. | Field Number || Extension Name || Field Name || Description |- | 1000 || [[https://example.com|(unassigned)]] || (unassigned) || (unassigned) -|} \ No newline at end of file +|} diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki index 753c6e5..6d1587e 100644 --- a/bip-0075.mediawiki +++ b/bip-0075.mediawiki @@ -14,7 +14,7 @@ This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol. -# It allows the requester (Sender) of a Payment Request to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with. +# It allows the requester (Sender) of a Payment Request to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with. # It encrypts the Payment Request that is returned, before handing it off to the SSL/TLS layer to prevent man in the middle viewing of the Payment Request details. @@ -34,15 +34,15 @@ The motivation for defining this extension to the BIP70 Payment Protocol is to a The motivation for this extension to BIP70 is threefold: -# Ensure that the payment details can only be seen by the participants in the transaction, and not by any third party. +# Ensure that the payment details can only be seen by the participants in the transaction, and not by any third party. # Enhance the Payment Protocol to allow for store and forward servers in order to allow, for example, mobile wallets to sign and serve Payment Requests. # Allow a sender of funds the option of sharing their identity with the receiver. This information could then be used to: -#* Make Bitcoin logs more human readable -#* Give the user the ability to decide who to release payment details to -#* Allow an entity such as a political campaign to ensure donors match regulatory and legal requirements +#* Make Bitcoin logs more human readable +#* Give the user the ability to decide who to release payment details to +#* Allow an entity such as a political campaign to ensure donors match regulatory and legal requirements #* Allow for an open standards based way for regulated financial entities to meet regulatory requirements #* Automate the active exchange of payment addresses, so static addresses and BIP32 X-Pubs can be avoided to maintain privacy and convenience @@ -118,7 +118,6 @@ message EncryptedInvoiceRequest { required uint64 nonce = 5; optional bytes signature = 6; optional bytes identifier = 7; - } @@ -277,7 +276,7 @@ The process overview for using InvoiceRequests and receiving encrypted PaymentRe # The PaymentRequest is processed according to BIP70, including optional EncryptedPayment and EncryptedPaymentACK messages '''NOTE:''' See section [[#Initial_Public_Key_Retrieval_for_InvoiceRequest_Encryption|Initial Public Key Retrieval for InvoiceRequest Encryption]] below for possible options to retrieve Receiver InvoiceRequest public keys. - + Flow diagram of Encrypted InvoiceRequest ==Message Interaction Details== @@ -334,7 +333,7 @@ Where used, '''nonce''' MUST be set to a non-repeating number AND MUST be chosen ===InvoiceRequest Validation=== * Validate sender_public_key is a valid EC public key -* The nonce MUST not be repeated. The service receiving the InvoiceRequest MAY use whatever method to make sure that the nonce is never repeated. +* The nonce MUST not be repeated. The service receiving the InvoiceRequest MAY use whatever method to make sure that the nonce is never repeated. * Validate notification_url if set, contains characters deemed valid for a URL (avoiding XSS related characters, etc). * If pki_type is None, InvoiceRequest is VALID * If pki_type is x509+sha256 and signature is valid for the serialized InvoiceRequest where signature is set to "", InvoiceRequest is VALID @@ -360,7 +359,7 @@ Where used, '''nonce''' MUST be set to a non-repeating number AND MUST be chosen ===ECDH Point Generation and AES-256 (CBC Mode) Setup=== * Generate the '''secret point''' using [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH] using the local entity's private key and the remote entity's public key as inputs. -* Initialize [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG] +* Initialize [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG] ** Use '''secret point's''' X value for Entropy ** Use the given message's nonce field for Nonce * Initialize AES-256 in CBC Mode @@ -414,11 +413,11 @@ Store & Forward servers MAY accept and/or overwrite EncryptedPayment messages un * Each ECC signature included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded. ==Implementation== -A reference implementation for a Store & Forward server supporting this proposal can be found here: +A reference implementation for a Store & Forward server supporting this proposal can be found here: [https://github.com/netkicorp/addressimo Addressimo] -A reference client implementation can be found in the InvoiceRequest functional testing for Addressimo here: +A reference client implementation can be found in the InvoiceRequest functional testing for Addressimo here: [https://github.com/netkicorp/addressimo/blob/master/functest/functest_ir.py InvoiceRequest Client Reference Implementation] -- cgit v1.2.3