This thread
was complaining that Let's Encrypt is willing to issue certificates for sites that have been seized (typically by law enforcement).
I pointed out that CAs are expected (by their own issuance policies, by the CA/B Forum, by browsers, and arguably to some extent by end users) to issue certificates based on the ground truth established by ICANN or other Internet community consensus processes. Even though we had some internal discussions during the founding process of Let's Encrypt about not always being thrilled about those things, I'd maintain that nobody seriously questioned whether Let's Encrypt certificates would follow the ICANN root ground truth¹—nor do I think browsers would allow Let's Encrypt or another CA to intentionally diverge from it.
In part, this is because Domain Validation has been defined to mean validating the current ownership of DNS domains according to the ICANN root and according to the entities that operate under contract with ICANN. (I've also heard the term Domain Control Validation, which is even more explicit about that.) For other kinds of validation, obviously (to me, at least) an OV or EV CA should not issue a certificate to law enforcement that identifies the law enforcement agency as someone else, like if a law enforcement agency seizes Megaupload's domain name, it should not be able to get an OV or EV certificate saying that it is the Hong Kong company Megaupload Ltd., but it seems difficult to argue that it shouldn't be able to get a DV certificate saying that it is the new owner of that domain name, even if one is unhappy that it was able to carry out the seizure.
However, end users famously almost never look at any identity data in certificates (a fact which different people have been lamenting for decades), so it's easy to imagine people being "fooled" in some sense by a domain seizure (or even a case where a domain lapses and is then re-registered by a squatter). I could then imagine having some kind of technical mechanism that advises users somehow about ownership continuity, like "this site is no longer run by the same entity that it was run by the previous time that you visited it".
I'm not sure what that would look like, though, or how CAs might be able to participate in it. For DV CAs, the most obvious problem is: how can we get reliable machine-readable data about domain ownership changes that avoids both false positives and false negatives? In general, the bigger problems probably apply to browsers more than to CAs: how would browsers implement this? Would they refuse to connect at all? Invalidate existing cookies and offline session data? Connect but show a pop-up or other UI indication? For any subresource, or just for the main site origin? In this case, how could people deliberately migrate from one registrar to another without triggering a false positive warning? Would browser developers think of this as something that could be meaningfully and usefully communicated to users?
I'm not personally going to advocate for any Terms of Service-based policy here because I think ideally any solution would cover a wide range of reasons why control of a domain name can change, and also not get CAs involved in saying which ones they thought were more or less legitimate or appropriate compared to others.
¹ I think @pde thought at one time that Let's Encrypt should find ways to cooperate with mechanisms that would help sites migrate their user bases away from ICANN domain names if they wanted to, but no mechanisms like that emerged (at least not that CAs were a part of), and it was never considered a high priority compared to automating traditional DV.