Re: [Bitcoin-development] Cold Signing Payment Requests

[Timo Hanke <timo.hanke@web.de>]

> So, I'm not a fan of weird hacks involving non-existent domain names.
> There's a clean way to implement this and we decided to punt on it for
> v1 in order to get something shippable, but if you're volunteering ...
> :) then indeed having a custom cert type that chains onto the end is
> the way to go.

Chaining a custom cert onto the end doesn't work, at least not if your
"end" is the SSL cert. Chaining it to the SSL cert defeats the OP's
intention of "cold signing", as the SSL private key is usually kept
online, therefore can't be used to sign a pubkey that is supposed to
stay offline. Hence the idea of the "hack", to get two independent
things signed by the CA in just one cert: 1) your SSL pubkey, 2) your
custom cert (by including its cryptograhic hash). This hack seems the
easiest possible solution.

It also seems the only solution if you want to stick with domain-names
as identifiers for the payment protocol (and I think you do). A cleaner
way would be to get a cert signed by your CA that contains an extended
"bitcoin" attribute in compliance with X.509, but this seems a little
far off.

So I am in favor of the "hack" (properly thought out where to place the
hash).

ps. In the long run I would of course like to see payee identities based
on alt-chains rather than domain-names plus CAs. But that's rather a
concern for v3 than v2. Of course, you can also chain custom certs to
non-SSL identities like PGP-keys. You probably don't want to do that,
but it would solve Melvin Carvalho's problem of sending to RSA keys
(assuming the RSA key holder previously published his custom cert with a
cert server). 

-- 
Timo Hanke
PGP AB967DA8, Key fingerprint = 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 7DA8