Glossary / Developer reference
PP pki type
- Definition
- PP pki type was the one-word string in a BIP70 payment request that said how the merchant had signed it: none, x509 with SHA-256, or x509 with SHA-1.
Specified in BIP-70.
Every protocol that signs something has to name the algorithm, and naming it in a field the sender controls is how downgrade attacks begin. BIP70 offered three values, one of which had been considered weak for years before the specification was written. Browsers finished evicting SHA-1 certificates in January 2017, and the payment protocol never issued an update.
How it works
Status: historical. PP pki type was field 2 of PaymentRequest, defaulting to the string "none", and it has been absent from Bitcoin Core since version 0.20.0 on June 3, 2020.
Three values were defined and no fourth was ever registered, although the specification left room for one.
"none" meant an unsigned request. The certificate field stayed empty, the signature field stayed empty, and a wallet could show the amount and the destination but no identity whatsoever. Most requests in the wild were exactly this.
"x509+sha256" meant the merchant serialized the whole message with the signature field blanked, hashed the result with SHA-256, and signed that hash with the private key belonging to the first certificate in the attached chain.
"x509+sha1" meant the same procedure with SHA-1 substituted for SHA-256.
Offering the weak option is the interesting part. A verifier that honors whatever algorithm the sender names is only as strong as the worst algorithm it still accepts, which is why later designs fix the acceptable set on the verifying side instead of reading it off the message. SHA-1 was a poor candidate even in 2013. A collision attack faster than brute force was published in 2005, and NIST disallowed SHA-1 for generating new digital signatures after 2013. Certificate authorities stopped issuing SHA-1 certificates at the end of 2015, Chrome 56 stopped trusting them in January 2017, and a full public collision followed a month later.
Where you see it
Bitcoin itself supplies the counter-example to a sender-named signature algorithm, and it is worth holding on to.
A bitcoin transaction never negotiates its signature algorithm with whoever validates it. The output being spent settles the question: a pre-Taproot output is checked with ECDSA over secp256k1, and an output paying a Taproot key is checked with Schnorr under BIP340, a rule that activated at block 709,632 in November 2021. A spender cannot propose something cheaper to break, because the choice was fixed when the coins were received.
That difference explains why a certificate-based layer sat so badly on top of bitcoin. Consensus rules apply identically to everyone and change only by coordinated upgrade, while a field naming an algorithm is a negotiation, and negotiations get downgraded.
If you are choosing where to buy rather than writing software, the useful version is narrow but real. A platform that keeps an obsolete cryptographic option alive "for compatibility" is telling you how it weighs convenience against security, and that judgment applies to the parts of the system you cannot inspect too.
PP pki type vs SSL signature
PP pki type named a scheme; the SSL signature was the output of running it. Treating the two as one thing makes old BIP70 documentation confusing, because a request could name a type and carry no signature at all, which is precisely what "none" meant. Modern TLS keeps the same pairing, with an algorithm identifier recorded alongside the signature bytes, but a client no longer accepts every identifier that was once legal.