I'm confused. Are you arguing against the usage of X.509 certs or not?
So far, neither. As you said, the paper as well as the bakery example do not discuss how you get the provable identity from. I come back to that at the end. Some comments first.
If a company owns an SSL cert, then why would they not use it to secure their website too?
I suppose you mean an
X.509 cert with all the bitcoin specific extensions that are currently being discussed, not a standard SSL cert? I ask this because I think of a "bitcoin cert" as something more universal than an "SSL cert". Yes, a bitcoin cert could be used by a company also to secure their website, and also to secure their vending/teller/etc machines which operate non-SSL. I do not want to discourage SSL connections when they are possible. My only point is to
not sign payment addresses at order time with the SSL cert. The bitcoin cert can sign a weaker SSL cert, which then secures the connection. And the PaymentRequest can be partially signed, even at order time, with some weaker certs (to certify something like "yes, we have this item in stock"). Just the payment address should not be signed (consequently, can be removed alltogether from the PaymentRequest, because the customer derives the payment address).
BTW, deriving the payment address from the raw PaymentRequest (raw=not containing a payment address yet) can interoperate with the previous protocol where the merchant generates the payment address. So yes, as you say, this can be backwards compatible and customer generated payment addresses would just be an extension.
Just pointing out that, for now, for most merchants/websites, it wouldn't make a practical difference because they don't have a separate identity that can be used only for Bitcoin payments and not web connections.
Most merchants are not accepting bitcoin. Aren't we early enough in the adoption to bootstrap an infrastructure for authenticated "bitcoin identities"? Better now than later.
Bear in mind some of the most widely used wallets don't support hierarchical deterministic wallets at all yet, so writing specs that assume them will just delay implementation significantly.
We don't need
hierarchical deterministic wallets. The type 2 deterministic wallets that are already implemented suffice. Just agree how to encode strings to 256bit numbers, thats all.
People throw around "web of trust" as if that approach hasn't been an even greater failure than PKI.
What exactly is "web of trust". Are the PGP distribution keys in my packet manager "web of trust"?
Show me another mechanism to get a certificate asserting my identity in a way that's intuitive to all end users.
For an all-bitcoin integrated solution we can distribute the links of a string to a pubkey via the blockchain. Strings can be colored coins and the address who currently owns that colored coin defines the pubkey linked to that string. The original owner of ""Mikes Widget Shop, Ltd" is the pubkey
G["Mikes Widget Shop, Ltd"] := Hash256("Mikes Widget Shop, Ltd")*G
where G is some arbitrary base point that we all agree on and whose privkey is public. Since the address of G["Mikes Widget Shop, Ltd"] doesn't appear on the blockchain there is no owner. If you make a transaction from G["Mikes Widget Shop, Ltd"] to your own address then you have transferred that string/colored coin to your possession. If you want to update your key or sell your string, pass on the colored coin.