📅 Original date posted:2015-07-14
📝 Original message:Hi Thomas,
Re: NetKi, I think any proposal in this space has to be an open standard,
almost by the definition of what it is. At any rate, it may be worth
talking to them. They have signed up to implement their system at least.
I did understand that your proposal does not rely on email - for instance a
web forum could issue username at reddit.com type aliases, even if those are
not also email accounts. I am just continuing the comparison against email
address certs.
It's also the case that a domain can use the DKIM setup without actually
offering email accounts. They can just have a web form or API that triggers
sending of the signed email (or simply, providing the signed headers
themselves). Thus the same system can be used transparently by both email
providers and other sites that don't give their users email addresses, but
would still like to use the same system.
Hardly anyone uses email certificates today, so I don't think it would
> affect a lot of users.
No, but obviously we'd like to change that! The holdup is not the
certificate side of things, really, but rather the lack of a
store-and-forward network for signed payment requests. I keep asking
someone to build one but I fear the problem is almost too simple ......
everyone who looks at this decides to solve 12 other problems
simultaneously, it gets complicated, then they never launch :(
Once there's a simple and robust way to get PaymentRequest's from one end
user to another, even when that first user is offline, then getting an
email cert issued is no big deal.
That does not look so... not until (1) BIP70 wallets integrate with
> https://crt.sh, (2) you convince that service to index email certs (3)
> you convince all CAs to report all email certs they issue to crt.sh.
>
Any solution that separates identity providers from certificate issuers
would have these requirements, though. And as many identity providers today
do not wish to become CAs too, it seems fundamental.
I don't think it's such a problem, mind you. The crt.sh website is actually
a frontend to the CT protocol, which is a somewhat blockchain like audit
log that's eventually intended to contain all issued certificates. Right
now, of course, they focus on SSL certs because those are the most common
and important. If other kinds of certs became more widely used, support in
the infrastructure would follow.
Don't get me wrong - I would like to see a way for a domain to delegate
BIP70 signing power to a third party. For instance, this would mean payment
processors like BitPay could sign on the behalf of the merchant, and the
merchant identity would then show up in wallets. The "chain a cert off a
domain cert" trick would be a good way to do that, though rather than
hacking the X.509 stack to validate invalid stuff, at this point it may as
well be a custom (better) cert format. There's little reason to use X.509
beyond backwards compatibility.
But the most popular identity providers today either don't care about
Bitcoin at all, or worse, are developing competitors to it. So for real
adoption to occur, we must have solutions that do not require identity
provider cooperation. I realise this is a business reason rather than a
technical reason, but it's a very strong one - so bootstrapping off
existing infrastructure with a split CA/ID provider design still makes much
more sense to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150714/ebdd5af6/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:42:06
in reply to nevent1q…uaau
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:42:06Event JSON
{
"id": "14d68ccb6e8b009ec5d4eb1a7df3646416cf39a2ae633df8dd080c97741d1de0",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686152526,
"kind": 1,
"tags": [
[
"e",
"2b792280c7c77e1a9146c50dbbc2a8f3336e57397d73b26f225d7fe35c48cd85",
"",
"root"
],
[
"e",
"2be2cc2aa574dc649de935999b6705832180bfa4f153873f09c67006513d8a2b",
"",
"reply"
],
[
"p",
"7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05"
]
],
"content": "📅 Original date posted:2015-07-14\n📝 Original message:Hi Thomas,\n\nRe: NetKi, I think any proposal in this space has to be an open standard,\nalmost by the definition of what it is. At any rate, it may be worth\ntalking to them. They have signed up to implement their system at least.\n\nI did understand that your proposal does not rely on email - for instance a\nweb forum could issue username at reddit.com type aliases, even if those are\nnot also email accounts. I am just continuing the comparison against email\naddress certs.\n\nIt's also the case that a domain can use the DKIM setup without actually\noffering email accounts. They can just have a web form or API that triggers\nsending of the signed email (or simply, providing the signed headers\nthemselves). Thus the same system can be used transparently by both email\nproviders and other sites that don't give their users email addresses, but\nwould still like to use the same system.\n\nHardly anyone uses email certificates today, so I don't think it would\n\u003e affect a lot of users.\n\n\nNo, but obviously we'd like to change that! The holdup is not the\ncertificate side of things, really, but rather the lack of a\nstore-and-forward network for signed payment requests. I keep asking\nsomeone to build one but I fear the problem is almost too simple ......\neveryone who looks at this decides to solve 12 other problems\nsimultaneously, it gets complicated, then they never launch :(\n\nOnce there's a simple and robust way to get PaymentRequest's from one end\nuser to another, even when that first user is offline, then getting an\nemail cert issued is no big deal.\n\nThat does not look so... not until (1) BIP70 wallets integrate with\n\u003e https://crt.sh, (2) you convince that service to index email certs (3)\n\u003e you convince all CAs to report all email certs they issue to crt.sh.\n\u003e\n\nAny solution that separates identity providers from certificate issuers\nwould have these requirements, though. And as many identity providers today\ndo not wish to become CAs too, it seems fundamental.\n\nI don't think it's such a problem, mind you. The crt.sh website is actually\na frontend to the CT protocol, which is a somewhat blockchain like audit\nlog that's eventually intended to contain all issued certificates. Right\nnow, of course, they focus on SSL certs because those are the most common\nand important. If other kinds of certs became more widely used, support in\nthe infrastructure would follow.\n\n\n\nDon't get me wrong - I would like to see a way for a domain to delegate\nBIP70 signing power to a third party. For instance, this would mean payment\nprocessors like BitPay could sign on the behalf of the merchant, and the\nmerchant identity would then show up in wallets. The \"chain a cert off a\ndomain cert\" trick would be a good way to do that, though rather than\nhacking the X.509 stack to validate invalid stuff, at this point it may as\nwell be a custom (better) cert format. There's little reason to use X.509\nbeyond backwards compatibility.\n\nBut the most popular identity providers today either don't care about\nBitcoin at all, or worse, are developing competitors to it. So for real\nadoption to occur, we must have solutions that do not require identity\nprovider cooperation. I realise this is a business reason rather than a\ntechnical reason, but it's a very strong one - so bootstrapping off\nexisting infrastructure with a split CA/ID provider design still makes much\nmore sense to me.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150714/ebdd5af6/attachment.html\u003e",
"sig": "ced596020088f98bd38a23ec2a56b5d28fe8aba0e0f3ce5f87d8952121659187ca8b17019ced530d1a599f83537393eba34e44fa51ea5ececee4c5404fccd5c2"
}