š
Original date posted:2012-11-27
š Original message:On Monday 26 November 2012 22:37:31 Gavin Andresen wrote:
> x509chain: one or more DER-encoded X.509 certificates that identifies
> the merchant. See the "Certificates" section below for details.
Personally, I'd like to see fewer implicit ties to X509. With X509 as one
option. For example, I'd much prefer to see a doorway to the future left open
like this:
message Invoice {
repeated bytes issuerIdentityType;
repeated bytes issuerIdentityBytes;
or similar, instead of "x509chain".
In particular two additional identification types:
- GnuPG (obviously)
- Hash based
The hash-based system would be there as a method of leveraging an existing
trusted connection, without needing to get into the nitty-gritty of
certificates. For example, I am paying for something on a web site; I
presumably already have a secure connection that I trust to that site. That
site can issue me an invoice (which is to be sent to the bitcoin client) _and_
a hash of the certificate on the same page.
I trust that hash because I received it over a secure connection from a
trusted source. When my bitcoin client pops up with the received invoice, it
shows me the hash of the invoice, and I can be sure that it is from the web
site I thought it was from.
Imagine I'm a (very) small business, I have two or three customers. I want to
email one of my customers an invoice. I don't want to have to get an X509
certificate, and I don't necessarily know how. However, I can ring my
customer up and say "I've generated an invoice with my bitcoin client, it is
hashed A7DE-521X-9977. Write that down and confirm it when you get my
invoice". Alternatively, I might attach a file called
invoice-A7DE-521X-9977.bitinv to a signed GnuPG email. The receipient can
easily confirm I sent it because the filename must match the contents and
GnuPG protects against tampering.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
Andy Parkins [ARCHIVE] /
npub1nxā¦7wjrv
2023-06-07 10:41:20
in reply to nevent1qā¦3u6d
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvPublished at
2023-06-07 10:41:20Event JSON
{
"id": "263ca5ddadb2be93cb37d30503b785b658d500e2a8db22cd2c72a2da6319c3f6",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686134480,
"kind": 1,
"tags": [
[
"e",
"f5f2400f8aa8a7067be3d080f096fd7cbfeecdd6e589c178b85b63a9338150a5",
"",
"root"
],
[
"e",
"56d0145b08fe8d3f122ccfdc32683812121193daa7908bbb0542b4a3991c533d",
"",
"reply"
],
[
"p",
"77979142f3407f28a5a71956e33342e486ee981e614e0d2ea36ddaf27b8a5a67"
]
],
"content": "š
Original date posted:2012-11-27\nš Original message:On Monday 26 November 2012 22:37:31 Gavin Andresen wrote:\n\n\u003e x509chain: one or more DER-encoded X.509 certificates that identifies\n\u003e the merchant. See the \"Certificates\" section below for details.\n\nPersonally, I'd like to see fewer implicit ties to X509. With X509 as one \noption. For example, I'd much prefer to see a doorway to the future left open \nlike this:\n\n message Invoice {\n repeated bytes issuerIdentityType;\n repeated bytes issuerIdentityBytes;\n\nor similar, instead of \"x509chain\".\n\nIn particular two additional identification types:\n\n - GnuPG (obviously)\n - Hash based\n\nThe hash-based system would be there as a method of leveraging an existing \ntrusted connection, without needing to get into the nitty-gritty of \ncertificates. For example, I am paying for something on a web site; I \npresumably already have a secure connection that I trust to that site. That \nsite can issue me an invoice (which is to be sent to the bitcoin client) _and_ \na hash of the certificate on the same page.\n\nI trust that hash because I received it over a secure connection from a \ntrusted source. When my bitcoin client pops up with the received invoice, it \nshows me the hash of the invoice, and I can be sure that it is from the web \nsite I thought it was from.\n\nImagine I'm a (very) small business, I have two or three customers. I want to \nemail one of my customers an invoice. I don't want to have to get an X509 \ncertificate, and I don't necessarily know how. However, I can ring my \ncustomer up and say \"I've generated an invoice with my bitcoin client, it is \nhashed A7DE-521X-9977. Write that down and confirm it when you get my \ninvoice\". Alternatively, I might attach a file called\ninvoice-A7DE-521X-9977.bitinv to a signed GnuPG email. The receipient can \neasily confirm I sent it because the filename must match the contents and \nGnuPG protects against tampering.\n\n\n\n\nAndy\n\n-- \nDr Andy Parkins\nandyparkins at gmail.com",
"sig": "c4e1481609f97e1c37686f39428a0135043bb21efc414d98e02d40f6948579c36670bc1df7d2e0cbded6e7b231127929b80709438a86557768fd61316beb44c2"
}