📅 Original date posted:2015-07-20
📝 Original message:hi Mike,
I hope you had a good trip!
> To get more specific, DNSSEC uses RSA 1024 bit. This causes two problems:
>
> 1. A DNSSEC proof is large, bytes wise. Even a single RSA signature
> won't fit nicely in a QR code, I think.
>
> 2. 1024 bit is the absolute minimum strength you can get away with,
> really. DNSSEC assumes frequent key rotations to try and help, which
> complicates things.
>
> So I'm not sure using DNSSEC fixes the usability problem we want to fix.
>
In my previous post, I was suggesting to *not* include the proof in the
request, because the payer can download it independently. Only the final
signature is needed. What makes DNSSEC interesting is not the size of
the proof, but rather the fact that you can request it easily, and in a
canonical way.
A typical lightweight payment request, serialized with EC signature and
without the proof, would be about 150 bytes long.
> I will do a separate reply to break out some thoughts on replacing QR codes.
>
> Would it be possible to create the same kind of "lightweight payment
>> requests" using SSL certificates? Probably, if the final signing key is
>> a EC key, and if the payment request does not include the whole chain of
>> certificates.
>
>
> Given that the pre-existing value of the PKI is much lower for individuals
> than for companies/websites, where they all have certs already, building a
> Bitcoin-specific or entirely new/independent PKI for people is not so
> unthinkable, I agree.
>
> In theory such a cert could be as minimal as:
>
> <ECC signature>thomasv at electrum.org
>
> so literally just a signature + a UTF-8 string, and that's it! You don't
> need anything more if you're willing to sacrifice extensibility,
> revocability, etc.
Again, we don't have to sacrifice revocability, if the proof is
downloaded separately.
>
> The pubkey of the CA would be obtained by running the pubkey recovery
> algorithm on the signature, and then checked against a table of trusted
> pubkeys.
>
Thomas Voegtlin [ARCHIVE] /
npub10f…7ej47
2023-06-07 15:42:07
in reply to nevent1q…pnjn
Author Public Key
npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47Published at
2023-06-07 15:42:07Event JSON
{
"id": "b80c84ff1054716469c2d53037632ed222f4cd95f8eb0c91e828cf2a926ef363",
"pubkey": "7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05",
"created_at": 1686152527,
"kind": 1,
"tags": [
[
"e",
"2b792280c7c77e1a9146c50dbbc2a8f3336e57397d73b26f225d7fe35c48cd85",
"",
"root"
],
[
"e",
"029bf2656af7aed01efb6a5dcd8dbde765f848a55c67e840029092740114c5da",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2015-07-20\n📝 Original message:hi Mike,\n\nI hope you had a good trip!\n\n\n\u003e To get more specific, DNSSEC uses RSA 1024 bit. This causes two problems:\n\u003e \n\u003e 1. A DNSSEC proof is large, bytes wise. Even a single RSA signature\n\u003e won't fit nicely in a QR code, I think.\n\u003e \n\u003e 2. 1024 bit is the absolute minimum strength you can get away with,\n\u003e really. DNSSEC assumes frequent key rotations to try and help, which\n\u003e complicates things.\n\u003e \n\u003e So I'm not sure using DNSSEC fixes the usability problem we want to fix.\n\u003e \n\nIn my previous post, I was suggesting to *not* include the proof in the\nrequest, because the payer can download it independently. Only the final\nsignature is needed. What makes DNSSEC interesting is not the size of\nthe proof, but rather the fact that you can request it easily, and in a\ncanonical way.\n\nA typical lightweight payment request, serialized with EC signature and\nwithout the proof, would be about 150 bytes long.\n\n\n\u003e I will do a separate reply to break out some thoughts on replacing QR codes.\n\u003e \n\u003e Would it be possible to create the same kind of \"lightweight payment\n\u003e\u003e requests\" using SSL certificates? Probably, if the final signing key is\n\u003e\u003e a EC key, and if the payment request does not include the whole chain of\n\u003e\u003e certificates.\n\u003e \n\u003e \n\u003e Given that the pre-existing value of the PKI is much lower for individuals\n\u003e than for companies/websites, where they all have certs already, building a\n\u003e Bitcoin-specific or entirely new/independent PKI for people is not so\n\u003e unthinkable, I agree.\n\u003e \n\u003e In theory such a cert could be as minimal as:\n\u003e \n\u003e \u003cECC signature\u003ethomasv at electrum.org\n\u003e \n\u003e so literally just a signature + a UTF-8 string, and that's it! You don't\n\u003e need anything more if you're willing to sacrifice extensibility,\n\u003e revocability, etc.\n\nAgain, we don't have to sacrifice revocability, if the proof is\ndownloaded separately.\n\n\u003e \n\u003e The pubkey of the CA would be obtained by running the pubkey recovery\n\u003e algorithm on the signature, and then checked against a table of trusted\n\u003e pubkeys.\n\u003e",
"sig": "e1d6a40d29e2a186a061b83ca980f2707397ff9180e47128828d217e99703fce432eb14ba9d271945ee1eace800b17a9437126ab0cb6f1929c50301e4382a283"
}