logoalt Hacker News

Scott_Helme_ • today at 3:37 PM • 2 replies • view on HN

1. They could do this now, the implementation exists publicly, but I think it would be better at the OS level like upki for revocation: https://discourse.ubuntu.com/t/addressing-linuxs-missing-pki...

2. I don't think such constraints would really work. My company might have 4 domains on different TLDs and then end up needing to use 4 different CAs. Geography doesn't really apply on the Internet.


Replies

amluto • today at 7:53 PM

> I don't think such constraints would really work. My company might have 4 domains on different TLDs and then end up needing to use 4 different CAs. Geography doesn't really apply on the Internet.

I'm not sure it needs to map out this way. In the last few years people have gotten used to the idea that ACME means that the client interacts directly with the actual CA, but there's another model that at least used to be widespread: certificate brokers. Right now, I tell my ACME cliejnt to get me a Let's Encrypt certificate, and Let's Encrypt validates my request and makes it happen.

But what if I instead tell my ACME client to talk to a broker? The broker would arrange with various CAs for whatever portions of the overall namespace it supports, and it would give me TOS that those CAs find acceptable. And it would then forward my requests to appropriate backend CAs, and those backend CAs would (and would be required to by CA/B rules) validate my request. And I'd get a cert without particularly caring who the backend CA is.

The root stores would treat the backends as fully responsible for validation.

I don't know whether the current ACME model actually supports this very well. The tricky bits I can imagine mostly involve ACME account identification, CAA record details and dns-persist-01. If I authorize my ACME account (held with the broker) for my domain, the backend needs to be able to validate, in a manner that the broker cannot forge except to the extent that it's unavoidable. So if I have account 12345 (just an identifier), then I think the backend should be able to trust the broker's assertion that the client really did convince it (with replay protection) that it's the client for account 12345. But if I have an account where the account itself indicates a public key, then the broker should not be able to forge it.

In any case, I think it's vaguely ridiculous that, right now, the UK government has essentially no say in whether Let's Encrypt may issue certificates for .gov.uk domains. (This is just an example.)

Parodper • today at 6:34 PM

> My company might have 4 domains on different TLDs

Your CA would have a root cert per TLD. Alternatively, we get rid of non-cc TLD (and leave ccTLD only for truly geography-bound organizations, like governments).

➕ show 1 reply