[TrueDuality]

I think this is solving a real operational pain point, definitely one that I've experienced. My biggest hesitation here is the direct exposure of the managing account identity not that I need to protect the accounts key material, I already need to do that.

While "usernames" are not generally protected to the same degree as credentials, they do matter and act as an important gate to even know about before a real attack can commence. This also provides the ability to associate random found credentials back to the sites you can now issue certificates for if they're using the same account. This is free scope expansion for any breach that occurs.

I guarantee sites like Shodan will start indexing these IDs on all domains they look at to provide those reverse lookup services.

[liambigelow]

CAA records including an accounturi already expose the account identity in the same manner, so I feel like that ship has already sailed somewhat (and I would prefer that the CAA and persist record formats match).

[TrueDuality]

The accounturi is an optional extension. Email, and phone are also optional. This is the first challenge that publicly requires you to specify your account ID publicly. There may be implementations that require it but neither Let's Encrypt or the protocols require them.

[Bender]

I think the difference is that using the existing DNS method listing the account is entirely optional. I have left it out on domains that I don't want correlated for that very reason.

[krunck]

Exactly. They should provide the user with a list of UUIDs(or any other randomish ID tied to the actual account) that can be used in the accounturi URL for these operations.

[gsich]

The account is the same as you create in any acme client. I don't see potential for a reverse lookup.

[Ayesh]

I think the previous post is talking about a search that will find the sibling domain names that have obtained certificates with the same account ID. That is a strong indication that those domains are in the same certificate renewal pipeline, most likely on the same physical/virtual server.

[TrueDuality]

This is publicly publishing the account ID. There is an optional extension in RFC8659 that extends it but it isn't required by any implementer. This puts that ID into a public well known location that is easy to scrape and will be (this is exactly the kind of opsec info project like Maltego love to go lookup and pull in).