(for background: I did a lot of the design work with Gavin on the payment
protocol and suggested/prototyped using x.509 in the way we do).
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
> 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
> 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.
On Thu, Apr 25, 2013 at 12:05:06PM +0200, Mike Hearn wrote:
> 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,
>
> > That's a pointless goal to try and solve right now, because the SSL
> > PKI cannot handle compromised web servers and so neither can we (with
> > v1 of the payments spec).
>
> I don't think the OP intended to solve it "right now", i.e. in v1.
>
> He differentiated between "most trusted" and "
>
> So I don't see how you can have a payment request signing key that's safer
> than an SSL key. As Jeremy notes, CAs will not issue you intermediate
> certificates. Perhaps if one existed that would do the necessary things for
> a reasonable price you could indeed give yourself an offline interme
On Thu, Apr 25, 2013 at 12:45:33PM +0200, Mike Hearn wrote:
> > That's a pointless goal to try and solve right now, because the SSL
> > PKI cannot handle compromised web servers and so neither can we (with
> > v1 of the payments spec).
>
> I don't think the OP intended to solve it
unfortunately my winter has proven a complicated series of significant life
events - new work, etc - which sees me with little free time to help out.
sorry.
Arklan
--
As long as there is light, the darkness holds no fear. And yet, even in the
deepest black, there is life. - Arklan Uth Os
On Thu, Apr 25, 2013 at 4:13 PM, Mike Caldwell wrote:
> I am not sure if my replies hit the list. If not, can anyone who sees this
> help?
>
> In the past, I have pre signed (with PGP) large batches of Bitcoin
> addresses for distribution on my server. This way, even in the event of
> compromise,
There are definitely ways to keep the pay-to address secure even if the web
server is compromised, just perhaps not perfectly clean standard X.509 ways
under the current ecosystem which would be easier for everyone to agree on.
- If a more trusted cert is an EV end cert, and a less trusted is a D
On Thu, Apr 25, 2013 at 3:12 PM, Jeremy Spilman wrote:
> Right now I'm leaning towards writing a prototype using a single cert with
> a fingerprint of PubKey in the Subject Alternate Name, and getting PubKey
> and InvoiceID in the Payment Request. Gavin, would the best way to work on
> this be to
11 matches
Mail list logo
