Hacker News Reader

Comment by Spivak | Hacker News Reader

I feel like this is a fairly narrow view of the situation. In theory the CA "System" ought to be much bigger than just web traffic since a globally distributed hierarchical database of certs is neat and could be used for all sorts of stuff.

The fact that browsers have so much say in how the CAs operate that database makes me think that the public CA system is actually a wildly successful failure. If the public CA system has no other use than to allow someone to securely connect to one of a handful of web browsers then why all the fanfare over just having letting the companies stewarding the browsers run the show entirely?

View on HN

People say this a lot. But where are the examples of all the "stuff" that would benefit by being linked into a single global PKI? Many of the most important public key crypto tools people actually use --- Signal, SSH and SSH CAs, U2F and WebAuthn, OAuth2 --- have little or no PKI at all.

I think the lack of standardization for a general purpose PKI is the biggest barrier, and the reason why Joe Schmo has no idea what a key pair is.

You're not really answering my question. Assume the standardization falls into place, and it's all JSON instead of X.509 so that Javascript developers will actually use it. What gets better? What thing out there was just begging to be encrypted by a giant tree shared by the whole Internet?

What gets better? What thing out there was just begging to be encrypted by a giant tree shared by the whole Internet?

The Nine Planes of the Internet would be connected. Níðhöggr, Dáinn, Dvalinn, Duneyrr and Duraþrór would be in their ordained places, no longer roaming lost in endless Violation of the Layers.

It would also be much easier to transfer your data to Fólkvangr / Valhöll after you die a hero's death on the battlefield.

First thing that comes to mind is official emails from organizations to individuals. Wouldn't such a system basically squash most fishing?

Please walk us through how a PKI would help against phishing emails?

Companies sign official correspondence, and email clients give blaring sirens/red flags for unsigned correspondence (or send it straight to the spam folder) similar to how browsers now handle http vs. https traffic?

It would also be very easy to detect any misrepresentation. Email contains a link to a domain that isn't on your cert? Alarms / no clickable links / etc.

Scammers are capable of setting up signing and getting certificates for their domains. It's an extra hurdle, but, like setting up https, it's not a big hurdle.

No cross domain links would disrupt a lot of current emails, but most senders would likely setup in-domain redirectors to carry on their current mailing patterns. Unfortunately, some of those would probably be open redirectors (because it's easy to make an open redirector and it "solves" the immediate problem), leading to some amount of security issues.

> But where are the examples of all the "stuff" that would benefit by being linked into a single global PKI?

Estonia's national system and its e-services are a local example of a single central PKI. Provided services and systems seem to be far ahead of basically all other countries.

Identity theft, identification, authentication, signing etc. have been solved for nearly two decades now and I have to say the way the rest of the world does stuff looks stone-age to me.

For example I loathe how I've been asked to do identity verification by foreign companies "send us a picture of your ID", WTF. Sentences like "Use SMS 2FA to protect your account", "e-mail us the bill" and "come to our office to sign {x}" make me shudder, it's absolutely dogs*.

It's not an example of a global PKI and worse, Estonia had to invalidate/patch everyone's e-ids once already. A hassle somewhat mitigated by the fact that fewer people live in Estonia than in the Bronx.

What is one relatively trivial patch compared to the plethora of other worse issues you have, the time and money you waste?

Having to patch a country’s worth of deployed hardware tokens doesn’t sound like a trivial effort to me.

Not GP, but:

I think the point is more that even the (massive) concentrated effort it takes to patch the IDs will be less than the collective impact of not having those IDs at all (in terms of the convenience it would add to peoples’ lives) OR having the IDs without the patches at all.

It's not an example of global PKI either way. It's essentially a city-sized experiment in using cryptographic technology.

It's the closest to global we've had that involves actual people and agencies, not just computers. Dismissing it only gets you "send us a picture of your gas bill to prove your identity"-level hindrance and mess.

The anti-PKI crowd are getting waayyyyy ahead of themselves. Pretty much any large deployment of public-key cryptographic needs some sort of PKI. Any framework where there's a third-party authority that signs keys requires some sort of PKI, directly, indirectly, or both. And there's almost always such a third-party because otherwise public-key cryptography is barely just a step ahead of shared secrets. This is especially true when you have distinct vendors, but I can guarantee you that even Signal has an internal PKI framework, independent of the Android PKI framework that it also implicitly relies upon.

Someone else thread mentioned S/MIME. S/MIME might be a failure, but S/MIME is a thin wrapper around CMS (Content Messaging Syntax), which is widely deployed standard for signing, authenticating, and encrypting content. It's based on the same ASN.1 standards as PKIX. And like PKIX, the root authorities are whatever you want them to be; the standards just provide the syntax and semantics for building the PKI and providing interoperable messaging.

Correct me if I'm wrong, but AFAIU CMS is the basis for various European digital identity systems. See, e.g., https://en.wikipedia.org/wiki/CAdES_(computing)

You tried the same rhetorical sleight of hand in a different thread a week ago; what you're doing is claiming that any use of asymmetric cryptography is by definition a form of PKI, when what we're talking about --- top-down tree-structured global PKI --- is clearly different from what they're doing.

Your point about S/MIME and CMS kind of makes my overall point for me. Sure. A global PKI is super useful for making things like CMS happen.

You're talking about global PKI. But the "public" in PKI doesn't imply global any more than the public in public-key cryptography does.

What PKI does usually imply is some sort of top-down tree of trust and mechanisms and policy for managing and verifying that tree. But the roots of that tree of trust don't have to be global, and with the exception of Web PKI aren't.

You're creating the straw man. You keep saying that new protocols don't need PKI. Well, if we accept your criteria for what PKI means, and considering that the only example that meets your criteria, past, present, or future, is Web PKI, then what exactly is the point of your argument?

If you have a beef against PKIX, CMS, X.509, ASN.1 etc--i.e. the mechanisms--then just say so. There's a ton of reasonable criticism to be made there. But those things are not equivalent to "PKI". There are plenty of PKI systems out there that make use of alternative mechanisms, though mostly proprietary and hidden as interoperability usually demands making use of pre-existing standards. But, to reiterate, using those standards to build a PKI system absolutely does not require relying on the same global roots of trusts. Nothing in those standards even identifies such a root or the shape of the tree at all.

No. We're talking talking about global PKI. See: rest of thread. You're the one who's departed from the topic.

> S/MIME might be a failure

Primarily because very few e-mail clients support it and no web client seems to.

> Correct me if I'm wrong, but AFAIU CMS is the basis for various European digital identity systems

Yes, they're in theory trying to legislate the same thing across EU what Estonia has done.

OAuth2 relies on HTTPS and thus the Web PKI to prevent anyone from MitMing either the login page itself or API requests made using the OAuth token.

SSH's trust-on-first-use system is only secure under the assumption that you "usually" aren't being MitMed; this ought to be improved. For the typical server administration use case, I'd prefer a design that doesn't involve PKI – like encoding a hash of the key into the SSH command – but domain validation based on Web PKI could still be better than nothing. (Perhaps using some subdomain owned by the hosting provider, as opposed to the public-facing domain(s) for the server.) Domain validation would also be ideal for use cases where you're connecting not to your own server but to some known entity's, such as SSHing to GitHub. As for SSH CAs... I've never heard of them before. :) Looking it up, I see that some organizations use them, but I'm not sure their design is a good fit for the kind of non-organization-internal use cases I'm thinking of.

As it stands today, Signal's public key system is largely security theater since nobody bothers to check authentication codes. Even when people do check them, you always have an excuse for changing your code out of the blue (got a new phone, had to reset my phone, etc.), which an attacker can take advantage of. The latter could be fixed by having a better way to transfer trust between devices, but Signal could still have a better story for initial authentication than trusting the phone system. Now, I don't think a traditional PKI would help. But I do like what Keybase is doing here, bootstrapping trust off of a collection of signed attestations on social media accounts. I'd argue this amounts to a PKI in its own right, one where social media providers (unknowingly) play the role of CAs.

Sure a pki could help Signal. Carriers are the ultimate arbiters of who owns a phone number and have direct access to the hardware that checks that ownership. For many people they also do ID verification. Carriers could provision phones with certificates and that would decentralise the Signal key database enormously.

A few things are going on.

Firstly you often don't need a PKI, and when you do need a PKI (which as I said is less often than people think) you often don't need a public one.

Take EMV ("Chip cards"). There's public key crypto securing your payment card transaction. There are multiple organisations involved. So we've got a PKI, but does it need to be a public PKI? Why not just let EMVco run everything, probably badly, and have them and their members (the banks and other big financial firms) eat it when inevitably they do a bad job? So that's what happens. If a CA in the EMV ecosystem does a bad job your bank will end up eating the cost of that, or maybe your country, the headline won't be "Obscure CA misissues certificate" it'll be "Huge Bank loses $500Bn in IT catastrophe" or something.

Secondly, the thing a PKI does relies upon is a common naming scheme. The standard actually used in the Web PKI, X.509 was designed for a world with a global directory of everything, the X.500 global directory system. That directory does not exist. What common naming schemes are there that we'd want digital certificates for?

The IETF published RFCs from the PKIX working group, defining how X.509 can be used for the Internet's names. That is, mostly ipAddresses, dnsNames, and emailAddresses.

The Web PKI concerns itself de facto with the first two. You could and some people do use IP addresses or DNS names in a context outside the Web PKI, but mostly they don't. "Don't roll your own". Even the successor to TCP, QUIC, was re-designed to have it just envelop TLS and thus depend upon the Web PKI, rather than inventing a new shiny public key crypto technology and associated PKI.

So the only use case we actually care about that didn't end up happening was email, S/MIME is what was attempted and... I have no doubt Thomas Ptacek can explain at considerable length how unlikely it is that anybody can get that to do what you'd expect it to do and deliver you any meaningful security if you're interested.

It should definitely give you pause when you see a system which really seems like it could only be secured by a PKI and it isn't the Web PKI. Is it a private PKI? Who has oversight? Or are they just going through the motions and the security is illusory? The answer is the latter pretty often. Stakes are often thought to be very low until they aren't...

PKIs are a much more general system, but this is a very specific PKI that was built specifically for web browsers. You can use others, you can even build your own. The fact that the this PKI was first, means that some people depend on it who probably shouldn't. But its still by the browsers, for the browsers.

> In theory the CA "System" ought to be much bigger than just web traffic since a globally distributed hierarchical database of certs is neat and could be used for all sorts of stuff.

Honestly I would love it if my password manager would also act as a personal certificate authority.

Reply on news.ycombinator.com