Not sure this is the technology at play here, but ATL Server, a C++ based Microsoft web technology discontinued in 2008 basically supported two files extensions - .srf and .dll. See e.g. https://github.com/redpower1998/ATLServer/blob/bf3fd601bf281... .
How would it hurt you? The American Heritage Dictionary gives three definitions of hurt:
> 1. To cause physical damage or pain to (an individual or a body part); injure.
> 2. To experience injury or pain to or in (an individual or a body part).
> 3. To cause mental or emotional suffering to; distress.
Does looking at them cause you mental or emotional suffering?
What if I said that it caused me the same mental or emotional suffering anytime anybody wore a tshirt? Would you also say people should only wear tshirts inside?
7 Billion people wearing t-shirts vs 2 statues, not the same, sorry. There are laws for offensive shirts though so yes, specific t-shirts can cause emotional suffering and could land the person wearing it in a lot of trouble based on hate speech and obscenity laws.
They do. The problem is drug addiction. If you give drug addicts free houses, eventually the word gets out, and then even more drug addicts move to your state. Eventually you find yourself like California - spending an immense amount of money of an immense number of drug addicts mixed in with a few people who are down on their luck.
People addicted to heroin don't achieve their potential or their aspirations. The compassionate thing to do for drug addicts is to help them stop being addicted to drugs, not give them an apartment where they can do drugs without bothering anybody. Parent commenter is saying the state is doing mostly the latter and little of the former.
It's a bit more complex than that. At the surface, it's true - only 15% of homeless people in Seattle lived out of county before becoming homeless. But a deeper look shows as many as 30% more never really could afford housing - they had marginal housing situations, living with a friend, relative, or romantic partner without paying a proportionate share for their prior living situation.
This is part of the discrepancy - one side shoves the 15% number at everybody while the other side shoves at 45% number at everybody - we can't agree on what we're measuring.
It's not quite so understandable to me that somebody would believe that position to be an inherent truth ("truly owe") rather than just a position.
Capital gains taxes have historically been lower to encourage the investment of capital. This might be good or bad policy. Many economists say it's good policy.
>Capital gains taxes have historically been lower to encourage the investment of capital.
That's nonsense. They have historically been lower because rich people make (or at the very least, heavily influence) the rules and so they tipped the tax scales in their favor. The 'encouraging investment' bit is just the nice sounding excuse they use.
Seems specious. Democratically elected representatives said it was to encourage the investment of capital as they wrote the laws, and then got reelected by the voters. You can say the representatives were lying and the voters didn't care / are dumb - but where's the evidence?
I think the simplest explanation for why representatives vote the way they do is the public statements they themselves make before and after their votes. If you want to make a more convoluted argument and assert a conspiracy, you should bring some evidence.
"economic elites and organized interest groups play a substantial part in affecting public policy, but the general public has little or no independent influence."
interesting then in Washington State that employed people are not paying their fair share and the capital class should use their influence to do something about that, by your logic
Whether it's good and whether it's fair are different criteria. It would be incorrect to say low capital gains taxes are bad, but that's not what the previous commenter said. They said they're not fair and I cannot think of a legitimate defense to low capital gains taxes being fair. For example, it may or may not be good to steal all the money from the richest man in the world and give it to the poorest, but it's absolutely not fair.
I didn't quite speak clearly and so let me try to clarify. It's the opinion presented as opinion containing opinion presented as fact :).
In examples:
- "summer is the best season" is an opinion
- "summer has the highest temperatures" is a fact
- "summer is the best time to have romantic encounters" is an opinion
- "summer is the best season because romantic encounters truly only happen in the summer" is a weird amalgamation. It clearly presents an opinion, and says that opinion is based on a true fact, but in fact, the true fact the opinion relies on is not a fact at all, but merely another opinion.
> Meanwhile if DNSSEC's vision is ever fully realized, you will lose that control entirely. There is no CT there, and even if it was build somehow it will be useless as it has no "teeth"
This is a false dichotomy. DNSSEC secures DNS records, it doesn't prevent logging certificate issuance.
I think you misunderstood the claim: say the U.S. government leaned on the .com DNS server operators to issue a different response for, say, Gmail.com to certain requesting IPs. The absence of a mechanism like CT makes that very hard to detect since everyone else in the world is going to see the same correct response, and there’s no reason for the target’s DNS resolver to question a response with a valid DNSSEC signature, and since DNSSEC has no UI there’s not even a way for the user to notice.
That matters because, as the person you were replying to explained, there’s no plausible way to build such a thing. We have CT because the browser developers insisted on it and they control the clients but DNSSEC doesn’t have an equivalent party with that kind of leverage.
It seems like some folks are missing the motivation for DNSSec and suggesting TLS instead. If your threat model includes global adversaries, you have can't rely on TLS because governments can trivially compromise TLS providers and TLS exposes users to the lowest common denominator TLS. The lowest common denominator TLS (ACME DNS-1) and the mitigation to the TLS provider problem (CAA records) are both based on DNS.
So you either accept that TLS is the global maxima for security and world governments can basically permanently compromise the internet, or you build private PKI systems, or you want something like DNSSec. And DNSSec is something like DNSSec.
With DNSSEC zones are controlled and signed by a single authority, and for CCTLDs that authority is controlled by ... the government. If they wanted to produce a malicious signature and serve it narrowly to a targeted victim ... that's quite doable with little in the DNSSEC system to prevent it.
While it's true that there many TLS root cert operators and some probably could be compromised by a government (though I wouldn't say "trivially"), there is also a gigantic mutual destruction pact in the form of certificate transparency that means all certs issued are visible in transparency logs and there are quite sophisticated technical and social controls in place to detect malicious certs. The cert operator would be imperiling their business and future trust in a way that isn't as true for DNSSEC.
The fundamental difference is that with TLS you have to trust ALL certificate issuers, but with DNSSec you only have to trust your TLD and your certificate issuer. Most companies trust their home country as a matter of practicality.
Certificate transparency is cool, but it's not clear it really works for many classes of devices (particularly devices that only use one network like gaming systems or TVs). The global adversary just compromises the channels used to obtain the transparency logs and to report violations. It seems to work for mobile consumer devices like cel phones, because these devices naturally connect to many different networks, of which only some are compromised.
Somebody has got to check the logs and report violations. Chrome does, so CT works mostly for the world wide web, because all websites want to work in Chrome.
For a device like a router, if the router doesn't check the logs itself, and a global adversary compromises the TLS update channel for the router, and starts distributing malicious firmware... If the router itself doesn't report the violation, for how long might such a compromise go undetected? Is there any reason to think it'd ever be detected?
CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients. For homogenous configurations (like the implementations of AWS, Azure, or GCM, or the deployment of routers, IOT devices, or gaming systems), it seems like a competent global adversary would simply figure out how to go unreported for that configuration, and nobody would particularly check.
> CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients.
Unless I'm misunderstanding you, this isn't really how CT works: the expectation for clients under a PKI with CT is that the presented certificate is already present in one or more logs, meaning that it's never (or more accurately, never has to be) the client actually doing the reporting. Reporting is left to separate monitoring parties.
In other words: a global adversary cannot surreptitiously use a novel CA against a particular configuration; they must first make themselves visible to one or more CT logs. Failing to do so means that their CA will be rejected outright by the client (or accepted by the client if the client doesn't do CT, but still with a loss of stealth).
The client has to get the CT log from somewhere, like an update channel (typically TLS). An attacker would compromise both the target and the process by which the client gets CT log updates.
Such an attack would be detected if some clients reported which certs they actually saw the next time they connected to an uncompromised network (as Chrome does) but if no clients report, such an attack could go undetected.
Clients get pre certificates (which are portions of the log) as claims in certificates. It's correct that they never download the whole log - I'm simplifying for clarity, not out of lack of understanding.
The fact remains - an adversary with a CA private key that can mitm all of the internet connections for a device can forge a fake CT log and go undetected, if that clients never uses a non-mitm network again.
No, because the presented certificate won't have any SCT entries (which are embedded in the certificate), and you can't fake the SCT entries without having access to the CT private keys.
This is why multiple SCT entries are required. Could you subvert all of this with enough effort? Yes, and the same is true of dnssec. Any form of cryptographic validation is only as secure as the control of its private keys, but modern TLS is designed to require you to compromise at least 3 independent parties in the TLS ecosystem to provide a plausible fake. And at that point why not just get the browser vendor to push a fake update to the user that disables TLS validation entirely? You're either doing all validation yourself, or you're trusting someone. Modern TLS avoids you needing to place trust in any one organisation from the TLS perspective, which makes attacks on other infrastructure components much more appealing.
This is not an accurate description of how CT provides security.
To begin with, CAs are allowed to operate logs themselves, so the minimum number of independent parties is 2, not 3.
Second, CT log private keys are not particularly well-protected. They are not stored in HSMs. One log's private key has been presumed compromised since 2020 because the server running the log was pwned via a vulnerability in the Salt configuration management system. SCTs from this log are still accepted by Apple (and by Chrome, until earlier this year) for satisfying the minimum SCT requirement.
Rather, CT provides security by using a Merkle Tree so that SCTs can be audited. In theory, clients can demand proof that an SCT is really included in a log, and gossip tree heads with monitors to ensure that monitors have the same view of the log as them. If an SCT fails auditing, or a log is found to have presented inconsistent views of its Merkle Tree, this can be detected and the log can be distrusted. In practice, this is quite challenging. Apple currently doesn't audit SCTs at all; Chrome probabilistically audits a subset of SCTs.
The crucial difference is who decides which cryptographic entities to trust. With TLS and CT, the browser defines the list of entities and if 3 or more of those entities live in a hostile country, you can be compromised. With DNSSec and CAA, the site operator gets to define the list of entities.
Ok. That's an argument you can make. Now go back and make that in the first place rather than diverting everyone down an incredibly tedious demonstration of you making assertive statements that are just factually wrong. There's space to talk about what tradeoffs are reasonable here (eg, if this is something you're concerned about, you can pick a CA that's not in a hostile country, and you can enable certificate stapling at the cost of increased fragility and depending on some level of TOFU), but when you start the conversation by just being clearly wrong and then double down on that when multiple people suggest that you're wrong and point at resources indicating that you're wrong, you're not doing a great job of making that space available.
> The fundamental difference is that with TLS you have to trust ALL certificate issuers, but with DNSSec you only have to trust your TLD and your certificate issuer.
It's probably fair to say I've been a bit over assertive about CT, but it's all in the margin to me. No amount of technical complexity can turn community trust into direct trust. TLS is a community trust model and DNSSec is a direct trust model. The fact that CT is a pretty good community trust model and that browsers have (so far) done a pretty good job at keeping the CT community small is interesting, but it doesn't turn community trust into direct trust. So while I'd agree it's an incredibly tedious tangent, I'd say it's tedious moreso because the pro-CT folks are missing the forest for the trees than for any technical details about CT.
Edit: because community trust fundamentally relies on the notion of the community taking action against bad actors. Whether it's a CA or a CT log provider, and whether it's malicious action or a bug or just ceasing to do business, community trust has a time axis where membership in the community changes and notions of keeping devices up to date and political struggles ("too big to fail") and the like that simply aren't needed in direct trust.
Of course it does. CT trust relies on root programs removing bad CAs and root programs and security researchers sharing information about bad CAs with root programs. The root programs, CA, and security researchers are colloquially "the CA community".
This kind of handwaving summary would be more credible if it hadn't been preceded by a long thread where it was made clear you didn't understand how CT functioned, at, like, a very basic level. You entered this conversation stridently equating CT monitoring with things like revocation checking.
I'm not looking for a debate; I'm just calling out things you say that are misleading and moving on. You're welcome to dispute my callouts! I'm satisfied that the thread establishes which arguments are credible and which aren't.
You are looking for a debate, I think. It's the whole thread. You're nerd sniping. It's classic.
You're not a fan of DNSSEC and prefer CT. When faced with examples where CT doesn't cut it, you refuse to discuss the big picture, pounce on incorrect details, and then resort to claiming your opponents are uninformed or arguing in bad faith.
The bottom line is my original big picture claim, the part that's on-topic for the article - that CT works for browsers on personal computers but not other classes of internet connected devices - it's true! And you know it! But you'd rather debate the details than inform readers about what they actually want to know (the big picture - i.e. that DNSSEC is useful).
I've observed your behavior before on hacker news, but experiencing it directly is eye opening.
It is difficult to make any sense out of your claim that internet connected devices can't benefit from CT. The initial claim you made was based on the unreliable connectivity and update channels of those devices, neither of which are especially implicated in enforcing CT --- your belief was that devices went and checked CT logs over the Internet on the fly to validate certificates, which, of course, no.
Ironically, this actually is a problem for DNSSEC validation! It's the literal reason why Chrome pulled its original DNSSEC/DANE implementation from the browser.
It's not a completely nonsensical concern - Chrome relies on a reliable connection to Google in order to get log list updates and do SCT auditing. If an attacker can block log list updates for long enough, CT enforcement is disabled entirely (i.e. certificates with no SCTs will be accepted), and if they can block SCT auditing for long enough, bogus SCTs will not be detected. This fail-open behavior was an intentional design choice so that CT would never break the Internet, as DNSSEC so often has. I think CT made very sensible tradeoffs here, but I understand matthew9219's complaints even if the details aren't entirely correct.
You are almost correct. The claims are called SCTs (precertificates are something else). The SCT is a promise by the log that they have (or will soon) publish the certificate. The promise could be lie. To detect that, the client is supposed to audit the SCT. If the audit fails, the client reports it so the log can be distrusted.
So yes, it's true that if an adversary can permanently silo off a client, it can prevent log misbehavior from being detected, either by blocking the reporting of audit failures, or by presenting a completely different view of the log to to the client. However, in many cases it would be impractical for an adversary to keep up such an attack forever, so CT still has value and I'm a huge fan of it. But it's true it can't stop literally all attacks.
Source: I run the CT monitor which has detected misbehavior in multiple CT logs.
If you wanted to use your words to explain why you think that, that might be more constructive. I could well respond "yes, it does work" but that wouldn't be useful. I know you're an expert in the space and might appreciate learning from you, but this is not that.
I'm sorry, but I'm declining to do that, because I recognize the message board conversational pattern where all the information you have about the subject is coming from comments rebutting you (this is apparent from things you've said already that fundamentally misapprehend how CT works), and, rather than acknowledging any of that information, you just use it as vocabulary for new misapprehensions.
Clients do not get pre-certs. Those are generated by the CA, and submitted to the log in return for an SCT.
Forging a ‘fake CT log’ isn’t possible, either. Nor do clients talk to CT logs, at all.
Aside from what mjg59 said, it's clear you don't quite understand how CT works.
Logs are stood up and then go through a fairly rigorous acceptance process by Google (and Apple) before finally being used. 'Used' in that a CA can then submit pre-certs to it and include the resulting SCTs in signed certificates, making them functional on Chrome/Apple platforms. Even the CA using the log generally takes some communication with the log operator to ensure the right set of roots are trusted for submitted pre-certs.
CT logs are used by CAs, not clients. A 'fake' log isn't a thing.
If you are able to compromise a CA and generate a bogus certificate, why couldn't you also compromise a certificate transparency log provider and generate a bogus signed merkle hash?
(Not that I'm a DNSSEC user myself, my feet aren't bulletproof)
Not sure what you really mean here - CAs are required to get SCTs from multiple, independently-operated logs. Even then, I think what you're implying here is mathematically impossible, and easily and immediately detectable. Bear in mind on at least 2 occasions these logs have detected and been decommissioned based on cosmic-ray induced bit-flips, not discovered by the actual log operators.
CT is a pretty robust system.
Fwiw (tangent), I don't necessarily believe either of those instances were cosmic-ray induced bit-flips. I'd have to dig up the study, but I read a study once that more or less concluded "cosmic-rays are more common in memory unsafe languages and on overclocked PCs". Or more accurately, engineers frequently misattribute memory corrupt and operating outside specification to cosmic rays.
Particularly when the software in question is running on somebody else computer, proprietary software and OS (or OS modules), unknown patch versions, etc.
I'm not sure why you're so fixated on this idea of client systems monitoring CT logs.
Operators who host infrastructure can and should be monitoring issuance in CT logs for domains they operate, which will allow them to identify and react to any unexpected issuance for those domains.
Most browsers will reject such a certificate. See https://googlechrome.github.io/CertificateTransparency/ct_po... for the policy Chrome imposes - my understanding is that Safari is broadly similar. Right now I don't think Firefox performs this validation, so this is possible if you know in advance that your target runs Firefox.
That page explains that Chrome (which is best in class here - most IOT devices don't do any of this stuff) fails open:
> If the installed version of Chrome has not applied security updates and has been unable to obtain an updated CT log list from the Component Updater for 70 days or more, then CT enforcement will be disabled.
That means a global adversary need merely block the update channel to targeted devices and wait. How will a Smart TV behave?
You're moving the goalposts to a ridiculous degree. Chrome will be incredibly angry at you if you haven't updated in 70 days. How will a smart TV behave? I've no idea. It's probably not paying any attention to dnssec (otherwise pihole and co wouldn't work), so I don't think you're presenting a credible alternative.
That's just not what's happening. Reread the conversation. I started from here:
> Certificate transparency is cool, but it's not clear it really works for many classes of devices
Smart TVs aren't some gotcha I'm throwing in at the end. It's literally the first thing I said about CT. CT works ok for mobile phones, laptops, and other devices where you can make certain assumptions about multiple networks and frequent updates. If you want a technology that doesn't require these assumptions, you want DNSSec.
Once you've got a 70 day old browser you're just waiting for it to hit one domain you can MITM or serve content from and then you've got arbitrary code execution and who cares whether dnssec is involved or not. Attacking CT is just not the threat model to be concerned about.
The example I gave was a router or gaming system updating itself (e.g. using CUrl) not a full browser. Don't strawman please - if my argument is as weak as you say, you shouldn't need to.
I want a version of Web PKI strong enough that I can turn off my tablet for a year, turn it back on in a coffee shop, apply automatic updates, and not have my web traffic monitored, even if I'm gay and the coffee shop is in Saudi Arabia.
From what I can see, DNSSec+CAA+.com+US CA+US hosting for the Android update server does the trick. No version of CT does.
Web PKI so strong that we recommend not using it for critical scenarios.. /s
It's late and I maybe haven't been super constructive here, but I think when you try to write out the actual assumptions behind CT as the whole solution, you realize you've got something that mostly works assuming assuming assuming - and worse, we'll never do any better, because those assumptions are fundamental technical limits. DNSSec may be ugly but at least its problems (like validators failing open) are just deployment issues, not fundamental technical issues.
I'm sick and tired of using technologies that provide security or correctness subject to a long list of preconditions and ways for folks to tell me I'm using it wrong. To build secure systems, we need technology that provides correct security without so much asterisks and fine print.
Do you believe CT protects set-top boxes against surveillance from nation state actors who compromise your router? Yes or no, if you don't answer, you're not engaging in good faith.
Nobody's ever going to continue discussing things with you when you end your comments with barbs like "if you don't answer, you're not engaging in good faith."
I don't think firmware updates for routers is a good example. That seems more like the kind of situation where you should actually be using your own PKI.
Even if you trust the current CAs (all of them) to not intentionally issue bad certificates, you must also trust all of them not to have their systems broken into. If even one CA gets compromised, the hackers can issue certificates for any name.
You can't, but a certificate that isn't logged won't work for the overwhelming majority of practical use-cases (ie any Google or Apple owned product).
If you need a certificate that doesn't care about those, you perhaps don't need a publicly-trusted certificate in the first place.
In addition to what nickf said in the parallel comment, CAs have committed to CT logging as part of being included in browser trust stores. If anyone were to find and report any certificates issued by those CAs via their trusted certificates that were not in CT logs, that would be strong evidence for browsers to remove them from the trust stores, which would essentially destroy their company.
That is not true. CAs are not required to log their certificates. Instead, Chrome and Safari by default do not accept certificates unless they are accompanied by a signed receipt from a recognized log. If you don't need your certificate to work in a default-configured Chrome or Safari there is no need for your certificate to be logged.
Here what you really mean is "if your certificates will never touch Chrome", because it's not just that Chrome won't accept them, but that Chrome's SCT auditing is part of a surveillance system for certificate misissuance.
I'm not sure what you mean by "surveillance system for certificate misissuance". Chrome's SCT auditing has nothing to do with detecting certificate misissuance; just misbehaving logs.
I'm literally just waking up right now and typing this from bed (ignore what that says about me as a person) so cut me some slack if this makes no sense and I reserve the right to come back and "clarify" what I was saying but: if Chromes see a Sectigo certificate for (say) Facebook.com with no SCTs, Google is going to notice.
Nope. If Chrome sees a certificate with no SCTs, it rejects the certificate but doesn't report it to Google. (Except possibly for telemetry.) Google doesn't care if CAs issue certificates without SCTs; in fact, some CAs routinely do so for customers which want to keep internal hostnames private. (e.g. https://docs.aws.amazon.com/acm/latest/userguide/acm-bestpra...)
SCT auditing only takes place if a certificate has SCTs. SCT auditing checks to make sure that the log really published the certificate. If it didn't, then the bad SCT is reported to Google so the log can be kicked out of Chrome.
The US seizes the cryptographic material for a US based root, issues keys and certificates for the domains it wants to compromise and intercepts and modifies the traffic for targeted users. There's some additional asterisks around not getting caught and certificate transparency logs and browser reporting structure, but for many classes of devices, it will suffice to simply also hijack the domains used for requesting the transparency log or the domains used for reporting certificates that don't appear in the log.
Users who are concerned about a government like the United States can use DNSSec to prevent a threat like this by using a non-US based TLD that employs DNSSec, and by running their client in a mode that requires valid DNSSec records for their domains. Of course, such services would practically need to be located outside of the country of concern as well.
If the US is going to seize cryptographic material from CAs, they've probably got no problem ordering US based domain registries to do their bidding either. If it's Verisign registry, they can use the Verisign CA too, and it's only one company to compel.
If all else fails, ICANN runs the root servers more or less, and is based in the US, and subject to being compelled to make bad signatues of tld glue records.
First off, ICANN doesn't run the root servers. ICANN operates 1 root server identity,l-root.root-servers.net. The others are run by different organizations.
Secondly, the root server operators have no control over the cryptography. They get a zone file and they serve it.
ICANN only runs the key generation ceremony which is scripted to prevent any single entity from tampering with the keys. ZSKs are generated a few months in advance and used by Verisign (the root zone maintainer) to sign the root zone. No one gets to see the private part of the KSK. So there is no way to compel ICANN to produce bad signatures.
> ICANN only runs the key generation ceremony which is scripted to prevent any single entity from tampering with the keys. ZSKs are generated a few months in advance and used by Verisign (the root zone maintainer) to sign the root zone. No one gets to see the private part of the KSK. So there is no way to compel ICANN to produce bad signatures.
Ok, well back to compelling Verisign. Certainly they are able to sign zones, although that authority flows from ICANN.
> Finally, glue records aren't signed!
If glue records aren't signed, then why wouldn't an adversary simply modify the glue records to omit the DNSSEC content? Maybe you're making a technical argument that the whole root zone is signed, not its individual components?
For a state like the US, with it's laws and history on surveillance. I assume PKI has been compromised.
I don't check or audit my CA's and don't think most people do either. Wouldn't be surprised if more than one of these has been compromised in some fashion already. It only takes one and there's plenty to target.
The next thing you'd need is a mitm attack and again that's entirely possible for a nation state to pull off at scale.
> I don't check or audit my CA's and don't think most people do either.
The people responsible for running the root stores do. And when CAs screw up, they are nuked from orbit--this has happened a few times. And they can be proactive: when Kazakhstan announced they would require all TLS connections to be MITM'd, the browsers promptly added the MITM certificate to the root store with the explicit distrust bit set, meaning that the resulting certificate error can't be clicked through, effectively breaking the internet if you tried to use that for MITM (which put the kibosh on that plan immediately).
And for another thing, I wouldn't trust the people who run the nameservers any more intrinsically than CAs. After all, the TLD that runs most of the commercial internet (.com) is run by a company that had problems when it ran a CA. There's no way to route around an untrustworthy TLD operator, and it needs to be recalled that many TLDs are literally run by state governments. And several of those governments believe the privacy of their citizens to be a bug, not a feature; giving them a more prominent role in securing privacy is not a good thing.
Everybody has to do business somewhere. Nobody can prevent the government in whose territory they do business from compromising them. The question is whether you can be compromised by all governments (TLS) or just your government (TLS+DNSSec).
> The people responsible for running the root stores do. And when CAs screw up, they are nuked from orbit--this has happened a few times
The CAs that got the boot were detected because they issued certificates that were obviously invalid, for example for domains like example.com (Symantec), test.com (Certinomis), or domains that didn't even exist (Camerfirma).
A CA that issues an unauthorized certificate for some random domain won't be detected unless that domain's owner is monitoring CT because no one else knows if the certificate is authorized or not.
So please do monitor CT for your domains and don't just rely on root stores and security researchers to do so.
Every single certificate issued by a WebPKI CA (ie: a CA whose certificates are accepted by Google or Mozilla's root programs) is logged in a globally auditable tamper-proof log. You can stand up an instance of that log, or monitor any of the existing logs yourself. You're not relying on laws to surveil the WebPKI CAs, but rather mathematics.
A log to secure TLS which clients typically obtain over a TLS connection and whose violations they report over a TLS connection. It's a circular dependency.
CT provides a guarantee like: "hopefully one of those devices will eventually connect to a non-compromised network and report the prior compromise". By observing the lack of such reports, we can be reasonably confident compromises of size N>millions are not happening, but it's difficult to reason about what compromises may be happening at small N.
That’s not all what CA means in standard usage. Terms like WebPKI exist specifically to make that distinction since, for example, the U.S. government runs its own certificate authorities which are trusted by millions of clients and even some mainstream software (Adobe) but not browsers. This is far from unique as far as governments go, and in some cases may even be required within a country.
Those non-web CAs are not the topic of discussion, though. When we are discussing the DNSSEC PKI, we are not discussing any altroots¹. When people are discussing the CA system for TLS, they overwhelmingly mean the normal web CAs.
"The normal web CAs" means "the Mozilla and Chrome root programs". There are other CAs, and some of them are even in the root stores of other browsers, but they're not "trusted" in the sense you meant upthread.
If your threat model includes nation-states then DNSSEC won't help you either. WebPKI at least has a method for keeping track of and detecting misissuance, DNSSEC doesn't.
I'm not the person you replied to, but in my native tongue (English), excessive repetition is also poor usage. Repeating the question too literally is indicative of unsophisticated (pre-college) writing, and repeating the same phrases word for word a signal that you don't believe your listener is paying attention to your words (as opposed to rephrasing, which signals that your prior explanation might have been unclear).
I've been a bit shocked how poor ChatGPT's usage is - it writes more like a very articulate 15 year old than like an adult - and how nobody else seems to notice. I can't help but think part of the reason nobody is noticing is that most of the attention is coming from engineers (for whom language is not a top skill).
Everybody noticed. It's what people mean when they refer to a comment sounding like it was written by ChatGPT.
I suspect it's a deliberate choice, much as The Sun newspaper aims at an 8 year old reading level, while newspapers like The Times or Guardian aim at 14 year old. Try asking ChatGPT to shift to a more advanced level.
Also, the whole "say what you're going to say, say it, say what you said" technique is very common because it works. Even "smart" people don't remember things quite as well as they think they do.
> I've been a bit shocked how poor ChatGPT's usage is - it writes more like a very articulate 15 year old than like an adult - and how nobody else seems to notice.
No, we're just mesmerized that a freaking machine, a bunch of PCBs and wires, can fairly convincingly impersonate a 15 year old, including making stuff up with great confidence.
