>> We are not establishing an IETF working group, which is an option that
>> was explored prior to the Paris meeting and has been sidelined at
>> present for depth-of-bureaucracy by the backing commercial entities.
>> Rather, we are establishing a top-level IANA registry group. This is
>> not antic
>
> We are not establishing an IETF working group, which is an option that
> was explored prior to the Paris meeting and has been sidelined at
> present for depth-of-bureaucracy by the backing commercial entities.
> Rather, we are establishing a top-level IANA registry group. This is
> not anticipa
>> We are currently working with IETF staff, with open offers of support
>> from multiple well funded commercial bodies, to transition these
>> proposals through to IANA management.
>
> I hate to inform you that you have been mislead. The IETF and the IANA
> do not operate as you outlined above. Ha
On Mon, Nov 26, 2012 at 7:16 PM, Walter Stanish wrote:
>>> X-ISO4217-A3
>>
>> I see that draft-stanish-x-iso4217-a3 is not standards track, is there
>> a reason for this?
>
> Of the three currently published proposals, all are essentially IANA
> registry proposals.
>
> We are currently working wit
>> X-ISO4217-A3
>
> I see that draft-stanish-x-iso4217-a3 is not standards track, is there
> a reason for this?
Of the three currently published proposals, all are essentially IANA
registry proposals.
We are currently working with IETF staff, with open offers of support
from multiple well funded
On Mon, Nov 26, 2012 at 9:16 PM, Walter Stanish wrote:
> X-ISO4217-A3
I see that draft-stanish-x-iso4217-a3 is not standards track, is there
a reason for this?
It also doesn't appear to address ~any of the the targeted items here.
Is there another draft I should be looking for which has more ove
> This is the next big "lets all agree to do things the same way" thing
> I think we should tackle. I'm particularly looking for feedback from
> other bitcoin client developers, even if it is just a quick "looks
> reasonable, if everybody else is going to do it then I will
> (eventually) too..."
I
Supporting DNSSEC/DANE in the future when they are widely deployed is a great
idea.
Note that the x509chain field is 'repeated', and any repeated field may have
zero entries. So I would suggest supporting other PKI systems in the future by
adding optional new fields (for maximum compatibility o
On Mon, Nov 26, 2012 at 4:26 PM, Mike Hearn wrote:
>> Perhaps we should agree to talk about everything _except_ that first?
>
> Yeah, alternatives to X.509 chains don't interest me right now except
> in the sense that they should be cleanly implementable with future
> extensions.
>
> So if you car
On Tuesday, November 27, 2012 12:16:07 AM Gregory Maxwell wrote:
> On Mon, Nov 26, 2012 at 6:44 PM, Luke-Jr wrote:
> > On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
> >> Would you find it acceptable if something supported a static whitelist
> >> plus a OS provided list minus a us
On Mon, Nov 26, 2012 at 4:31 PM, Luke-Jr wrote:
> On Tuesday, November 27, 2012 12:02:42 AM Rick Wesson wrote:
>> Another nifty thing is that it can associate a cert to a domain and a
>> payment address, if one were to put said address in the DNS :)
>>
>> Now I am sure the majority of the bitcoin
On Tuesday, November 27, 2012 12:02:42 AM Rick Wesson wrote:
> Another nifty thing is that it can associate a cert to a domain and a
> payment address, if one were to put said address in the DNS :)
>
> Now I am sure the majority of the bitcoin user-base desires anonymity,
> but as a merchant I wou
> Perhaps we should agree to talk about everything _except_ that first?
Yeah, alternatives to X.509 chains don't interest me right now except
in the sense that they should be cleanly implementable with future
extensions.
So if you care about DANE or DNSSEC or custom PKI infrastructures or
whateve
On Mon, Nov 26, 2012 at 6:44 PM, Luke-Jr wrote:
> On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
>> Obviously the state of the world with browsers is not that good... but
>> in our own UAs we can do better and get closer to that.
>
> This effectively centralizes Bitcoin (at least
I hope you all take a moment to see what DANE leverages with DNSSEC
and SelfSigned x.509 certs. DANE provides the capability for any
entity to associate a self signed certificate with a domain name. This
capability removes the critical path of whitelists and/or Root CA
certs.
Another nifty thing i
X.509 has some problems we have recent experience with. I'd prefer to
leverage something like DANE which looks to help with assertions
around certificates and creates an option around the CAs and x.509
roots.
-rick
On Mon, Nov 26, 2012 at 2:37 PM, Gavin Andresen wrote:
> This is the next big "l
On Mon, Nov 26, 2012 at 5:37 PM, Gavin Andresen wrote:
> This is the next big "lets all agree to do things the same way" thing
> I think we should tackle. I'm particularly looking for feedback from
> other bitcoin client developers, even if it is just a quick "looks
> reasonable, if everybody else
On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
> Obviously the state of the world with browsers is not that good... but
> in our own UAs we can do better and get closer to that.
This effectively centralizes Bitcoin (at least in the eyes of many) and even
if each competing client
On Mon, Nov 26, 2012 at 6:19 PM, Luke-Jr wrote:
> On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote:
>> They could be included as well of course, but from a seller
>> perspective the most important thing is consistency. You have to be
>> able to predict what CAs the user has, otherwise you
> That's expected behaviour - except it's mainly be manipulated by *users*, not
> viruses (which can just as easily manipulate whatever custom cert store we
> use).
The point of using signed invoices as virus protection isn't to change
what the user sees on the infected host. The point is the invo
On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote:
> They could be included as well of course, but from a seller
> perspective the most important thing is consistency. You have to be
> able to predict what CAs the user has, otherwise your invoice would
> appear in the UI as unverified and i
They could be included as well of course, but from a seller
perspective the most important thing is consistency. You have to be
able to predict what CAs the user has, otherwise your invoice would
appear in the UI as unverified and is subject to manipulation by
viruses, etc.
So using the OS cert st
On Monday, November 26, 2012 11:02:14 PM Mike Hearn wrote:
> Minor caveat, IMHO we should support all CAs used by the popular
> browsers.
I would prefer using the user-accepted certs at the operating system level...
--
Mo
Obviously this LGTM :)
Minor caveat, IMHO we should support all CAs used by the popular
browsers. This ensures no merchant ever finds that their SSL cert they
already own is OK for the web but not for Bitcoin. I don't see a need
to be stricter here, given all it achieves is signing some data in a
This is the next big "lets all agree to do things the same way" thing
I think we should tackle. I'm particularly looking for feedback from
other bitcoin client developers, even if it is just a quick "looks
reasonable, if everybody else is going to do it then I will
(eventually) too..."
Thanks to P
It appears that something about Boost doesn't play nicely with the default
build instructions (possibly the switch to clang++?).
I will dig in eventually but for now, if anyone has a recipe that fixes
things, let me know.
26 matches
Mail list logo
