📅 Original date posted:2012-11-27
📝 Original message:Luke-Jr - common subset of what operating systems ship is fine for me
as long as people do due diligence around mobile OS' here. It seems
easier to me to just grab a list from a popular browser, on the
grounds that SSL is mostly used by them so nobody is going to buy an
SSL cert rejected by IE/Firefox/Chrome/etc. But intersecting OS lists
is effectively the same.
For my own clients I'd just ship my own copy of the canonical CA certs
regardless, because integrating with each operating systems
proprietary crypto APIs is a lot of work vs just loading a pem file
into OpenSSL. If there are a lot of people who want to use the OS cert
management UIs then I guess that can be a point wallet clients compete
on.
> Removing that and adding a opaque string called domain name, or
> identityName would be sufficient to move the conversation forward
> without the x.509 baggage.
But it would result in implementations that do not meet the requirements.
Yes, X.509 has problems. It's in the proposal because we can get the
effect we want (verifiable domain names in the UI) in about 50 lines
of code, today, with the id-verified keys people actually have already
bought.
As Gavin says, we can add optional fields later to extend the protocol
in a backwards compatible way.
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 10:40:03
in reply to nevent1q…7cpd
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 10:40:03Event JSON
{
"id": "9ba7ca01ad9d4de2288a49c3ac403ee9cafb253731503a18155f1a0e8472f9a3",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686134403,
"kind": 1,
"tags": [
[
"e",
"f5f2400f8aa8a7067be3d080f096fd7cbfeecdd6e589c178b85b63a9338150a5",
"",
"root"
],
[
"e",
"7d7e2a6b61b3938de5e9b6a5afab6688dbcabc47a21989e2b62ef572d56841ee",
"",
"reply"
],
[
"p",
"4b1a5906489c6232556bd6a398a430750448185cee39bc8d0b764178775dc150"
]
],
"content": "📅 Original date posted:2012-11-27\n📝 Original message:Luke-Jr - common subset of what operating systems ship is fine for me\nas long as people do due diligence around mobile OS' here. It seems\neasier to me to just grab a list from a popular browser, on the\ngrounds that SSL is mostly used by them so nobody is going to buy an\nSSL cert rejected by IE/Firefox/Chrome/etc. But intersecting OS lists\nis effectively the same.\n\nFor my own clients I'd just ship my own copy of the canonical CA certs\nregardless, because integrating with each operating systems\nproprietary crypto APIs is a lot of work vs just loading a pem file\ninto OpenSSL. If there are a lot of people who want to use the OS cert\nmanagement UIs then I guess that can be a point wallet clients compete\non.\n\n\u003e Removing that and adding a opaque string called domain name, or\n\u003e identityName would be sufficient to move the conversation forward\n\u003e without the x.509 baggage.\n\nBut it would result in implementations that do not meet the requirements.\n\nYes, X.509 has problems. It's in the proposal because we can get the\neffect we want (verifiable domain names in the UI) in about 50 lines\nof code, today, with the id-verified keys people actually have already\nbought.\n\nAs Gavin says, we can add optional fields later to extend the protocol\nin a backwards compatible way.",
"sig": "2054a4b79f0bdd9e3e821edbae6e109cde986ea9f4e0fb934863b00306b599cf1fb69a09a6b243dac384c8d6f02864dc2b1aebc27c7fa9193299a90a2cafff86"
}