I think the spirit of this idea is a good one, but I haven't investigated enough to comment on your proposed implementation.
Is it possible for a secure hardware wallet or a bitcoin signing tag to provide the "green address" signature? The idea would be that the secure hardware contains a signing key that the user does not know and uses this to sign authorized transactions. The secure hardware would track which outputs it has signed in the past to prevent the possibility of double spending.
Now let's say the manufacturer of the secure hardware learns that one of its signing keys loaded into a device (or devices) in the field is compromised. The manufacturer can't stop his in-field hardware from producing signatures with the now-compromised green-address key. Would it be possible for the manufacturer to revoke certification for just this particular key (or keychain)? If so, can you explain in more detail how this would be done?
Is it possible for a secure hardware wallet or a bitcoin signing tag to provide the "green address" signature? The idea would be that the secure hardware contains a signing key that the user does not know and uses this to sign authorized transactions. The secure hardware would track which outputs it has signed in the past to prevent the possibility of double spending.
Now let's say the manufacturer of the secure hardware learns that one of its signing keys loaded into a device (or devices) in the field is compromised. The manufacturer can't stop his in-field hardware from producing signatures with the now-compromised green-address key. Would it be possible for the manufacturer to revoke certification for just this particular key (or keychain)? If so, can you explain in more detail how this would be done?
AFAIK the BIP proposal extension doesn't cover HOW to provide a "green address" signature. It covers how a payee can communicate which entities it trust to avoid problems in accepting transactions prior the confirmation and how a listed trusted entity can communicate its identity in response.
Yes, I recognize that. But I think a discussion of the "how" is important as it might imply changes to the BIP in order to make the "how" possible for a wider range of signers. For instance, I see Mike Hearn made similar comments to the first draft (which I assume Tryexcept took into account when he modified it to use X.509 certificates). My understanding of X.509 is weak, so perhaps if I understood it better it would be obvious how Tryexcept's recent changes solves this issue identified by Mike here:
Quote
Now someone observes that not all wallets are websites. Perhaps a hardware wallet like the TREZOR is upgraded to start tracking which outputs it signed for and refusing to do so again. It wants to take part in this protocol too, using a device-specific key that's embedded into the chips at the factory. But now it doesn't fit with your design because there's no way to do an HTTPS GET from a TREZOR. So you say maybe the manufacturer key could sign device keys in a chain, and then the signature contains the signed device key .... now you have a cert chain.
If this new hardware wallet gets put under a scanning electron microscope and the per-device key is extracted then used for fraud, it'd be nice if there was a way to revoke it without revoking all the devices at once. Now you have OCSP.
If this new hardware wallet gets put under a scanning electron microscope and the per-device key is extracted then used for fraud, it'd be nice if there was a way to revoke it without revoking all the devices at once. Now you have OCSP.
