<div dir="ltr">Hi Thomas,<div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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.</div><div><br></div><div>I did understand that your proposal does not rely on email - for instance a web forum could issue <a href="mailto:username@reddit.com">username@reddit.com</a> type aliases, even if those are not also email accounts. I am just continuing the comparison against email address certs.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hardly anyone uses email certificates today, so I don't think it would<br>
affect a lot of users.</blockquote><div><br></div><div>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 :(</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That does not look so... not until (1) BIP70 wallets integrate with<br>
<a href="https://crt.sh" rel="noreferrer" target="_blank">https://crt.sh</a>, (2) you convince that service to index email certs (3)<br>
you convince all CAs to report all email certs they issue to crt.sh.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div></div>