Added additional pki_type values

1 files changed, 18 insertions, 2 deletions

diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki
index 77616ba..89ed5bf 100644
--- a/bip-0075.mediawiki
+++ b/bip-0075.mediawiki
@@ -67,6 +67,21 @@ A Bitcoin wallet developer would like to use a public Store & Forward service fo
 
 With this BIP, returned payment information is encrypted with an ECDH-computed shared key before sending to a Store & Forward service. In this case, a successful attack against a Store & Forward service would not be able to read or modify wallet address or payment information, only delete encrypted messages.
 
+==Modifying BIP70 pki_type==
+This BIP adds additional possible values for the pki_type variable in the PaymentRequest message. The complete list is now as follows:
+
+{| class="wikitable"
+! pki_type !! Description
+|-
+| x509+sha256           || A x.509 certificate, as described in BIP70
+|-
+| pgp+sha256            || An [[https://en.wikipedia.org/wiki/Pretty_Good_Privacy#OpenPGP|OpenPGP]] certificate
+|-
+| ecdsa+sha256          || A [[https://en.bitcoin.it/wiki/Secp256k1|secp256k1]] [[https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm|ECDSA]] public key
+|}
+
+'''NOTE''': Although SHA1 was supported in BIP70, it has been deprecated and BIP75 only supports SHA256. The hashing algorithm is still specified in the values listed above for forward and backwards compatibility.
+
 ==New Messages==
 Updated [/bip-0075/paymentrequest.proto paymentrequest.proto] contains the existing PaymentRequest Protocol Buffer messages as well as the messages newly defined in this BIP.
 
@@ -94,7 +109,7 @@ message InvoiceRequest {
 |-
 | amount                || amount is integer-number-of-satoshis (default: 0)
 |-
-| pki_type              || none / x509+sha256 (default: "none")
+| pki_type              || none / x509+sha256 / pgp+sha256 / ecdsa+sha256 (default: "none")
 |-
 | pki_data              || Depends on pki_type
 |-
@@ -343,8 +358,9 @@ If a Store & Forward server wishes to protect themselves from spam or abuse, the
 Clients SHOULD keep in mind Receivers can broadcast a transaction without returning an ACK. If a Payment message needs to be updated, it SHOULD include at least one input referenced in the original transaction to prevent the Receiver from broadcasting both transactions and getting paid twice.
 
 ==Public Key & Signature Encoding==
-* All EC public keys ('''sender_public_key''', '''receiver_public_key''') included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded.
+* All EC public keys ('''sender_public_key''', '''receiver_public_key''') or x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded.
 * All ECC signatures included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded.
+* All OpenPGP certificates must follow [[https://tools.ietf.org/html/rfc4880|RFC4880]], sections 5.5 and 12.1.
 
 ==Implementation==
 A reference implementation for a Store & Forward server supporting this proposal can be found here: