Let's Encrypt continues to be available to almost every vulnerable population in the world, including those that need it most. I say almost as I'm hesitant to speak in absolutes regarding a topic as complex as this.
Most of our sanctions-related blocks apply only to the governments of certain sanctioned countries, not their general population.
This subscriber agreement update was intended to better reflect our legal requirements. It does not reflect a major change in the service we provide. Our compliance program does evolve over time, and part of that is communicating about it better in our terms of service. It's clear from some of the comments here that we have more work to do to make that text more understandable, we'll work on that.
> That said, pretty sure this is stems from the insane US legal requirement to not export SSL technology to enemy countries. I'm sure some of y'all are old enough to remember when web browsers came in "international friendly" versions that supported 40 bit encryption, or "fancy secure" versions with 128 bit encryption.
Star Joint Venture is the manager of the .kp TLD and one of DPRK's two email providers (the other is silibank.net.kp) [1], used as the official email for various government bodies ex. ipa817@star-co.net.kp (IP Office), kscost@star-co.net.kp (Sci/Tech Commission), ksf@star-co.net.kp (Ministry of Culture and Sports), mhs-ip@star-co.net.kp (Atomic Energy). It is also widely used by those universities and companies that engage with the outside world.
How did you determine that issuing a certificate to this domain or any .kp domain was compliant with the general ban on exporting goods and services to DPRK?
I only noticed the star net one (not sure if it’s even in use) when writing this. I noticed the Pyongyang Zoo (which shares an IP with the Architects Society—one on 443 and one on 80 lmao) first, just from flipping through their very small IP space on Shodan.
You can see them all on crt.sh, because LE has to upload them to a CT log for browsers to trust them. (That’s how most of those subdomain finder websites work too.) The email servers seem to have gotten certs from a for profit CA back in 2015, but I’m not sure if they ever used them. Most of their webspace seems to be HTTP only. (And it’s a good thing, because some of their Apache versions are potentially old enough to have Heartbleed.)
The architects website has some pretty cool PDF magazines btw. They also have several websites for their insurance company’s (perhaps some intl org needs them to have a website for listing)—that’s a core hard currency stream for them and they previously have been accused of submitting false losses.
> Most of our sanctions-related blocks apply only to the governments of certain sanctioned countries, not their general population.
The agreement very plainly says otherwise:
> You are not a person or entity that is: (a) located in, organized under the
laws of, or ordinarily resident in any country or territory that is the target
of comprehensive U.S. sanctions
The general population of those countries are absolutely "persons" "located in" a "country or territory that is the target of comprehensive U.S. sanctions."
> communicating about it better in our terms of service. It's clear from some of the comments here that we have more work to do to make that text more understandable, we'll work on that.
This tries to frame it as a comprehension issue. It's not.
The wording in your agreement is actually quite clear. I think it's reckless, if not disingenuous to frame this as "we really only mean government entities".
Apropos of anything else, it's also not how US sanctions work - they are absolutely aimed at both the populace as well as the government itself.
They have "clarified" elsewhere on here that the normal citizenry get a legal exemption [waves hands mystically] somehow, and that they're only blocking people when they legally have to.
Obviously (to the rest of us) if the agreement says otherwise, then they're saying that it's LE that is forbidding the citizens of these countries, and it's not (entirely) the government's fault, which completely contradicts what they're trying to say.
We should probably be clear that this document is most likely a backside-covering exercise; it exists so that people can't sue LE for denial of service without a just cause, and so that the US can't prosecute them for intentionally shipping cryptographic services, or some such rubbish.
If you live entirely outside the US legal system, or its multifaceted tendrils, and if you don't make too much noise, you may be fine. Obviously that's a far cry from a "right to free speech" level of protection, but then LE have no obligation to provide that to people outside the US, and arguably non-rich citizens within the US lost that a long time ago.
OFAC sanctions are far more nuanced than what you make them out to be. Very often "general licenses" are carved out for providing IT services or technology to individuals for personal use. The purpose of this is for censorship circumvention, which often supports American interests abroad.
This is not something that you apply for; a general license already applies to everyone. The legalese or restrictions companies use exist because they cannot (or will not) validate everyone is who they say they are. This obviously doesn't apply to companies who deal with controlled exports, where they are responsible for whoever ultimately receives the controlled export.
I get this, but you say "very often", but it's not, and generally, looking at OFAC lists, there's only a few countries with personal carveouts (less than 5 of the countries on the list), usually for remittances, and in a few of those countries only to US persons residing there.
Generally the software carveouts are very limited - it's not just "providing IT services or technology to individuals for personal use", i.e. Sudan:
> software updates for medical devices to Sudan
Indeed, of the software carveouts listed on that page, only two are not related to the operation or update of medical devices:
- provision of Internet services to the people of the Ukraine (read: "Starlink")
- provision of messaging services to members of the Government of Venezuela.
It may be the case that "most of" their sanctions-related blocks apply only to governments (let's say there are 100 such blocks), while they still disallow usage by persons located in a country or territory that is the target of comprehensive US sanctions (let's say there are 50).
Sounds like "comprehensive" does the heavy-lifting here (in "country or territory that is the target of comprehensive U.S. sanctions"): what countries are under comprehensive sanctions, and which are under non-comprehensive sanctions?
Thanks for responding, and to clarify, I am confident that Let's Encrypt is shared as widely as they are able. Could you explain what that requirement does stem from?
According to the current administration, almost half of the US is considered a political enemy of the current administration.
Soon they might be pushing for Operating Systems to gather political party preference information, so they can know who should be restricted from the use of strong encryption. The options being:
It'll be interesting when/if they sanction Antifa. Since it doesn't exist, you can't prove that you're not a member of it. So they get to sanction anyone.
> move somewhere more willing to respect international law?
Some of these sanctions are required by international law (i.e. sanctions imposed by UNSC). For the other ones, international law generally lets countries have whatever trade policy they see fit including sanctions, unless they violate some other rule of international law or treaty obligation.
Sanctioning the ICC obviously has nothing to do with trade policy.
The USA signed the Rome Statute but never ratified it, and then withdrew its signatory status. There's an argument to be made that there was a treaty obligation there, but it's pretty weak.
I personally think sanctioning the ICC judges is a disgusting act. However ultimately all sanctions are decisions to refrain from trading with someone, so it is in a sense a trade policy. I think what you're getting at is that usa is implementing that policy to obtain a political/diplomatic goal, which is true, but you could say the same about most trade policies.
I think article 18(a) of the vienna convention of the law of treaties means that once you withdraw your signature, you no longer have any obligations in regards to the treaty.
Maybe you could make some sort of argument that the sanctions violate the purpose of the geneva convention as they are designed to prevent bringing to justice people accused of grave breaches of the geneva convention. Like its an attempt to frustrate the application of article 49 of the first geneva convention [Ianal]
I can't answer why or why not but just in terms of track record the US is fairly egregious. The executive attempts to coerce individual UN officials via sanctions. While it may not be strictly illegal it is clearly flagrantly unethical.
> Let's Encrypt continues to be available to almost every vulnerable population in the world, including those that need it most. I say almost as I'm hesitant to speak in absolutes regarding a topic as complex as this.
> Most of our sanctions-related blocks apply only to the governments of certain sanctioned countries, not their general population.
It doesn't work that way.
Blocking governments from getting certs doesn't hurt them in the slightest. The government can just create their own pki.
But it hurts the general population instead. People do not live in vacuum, they still need to access government sites. And thus people are forced to install root certificates of questionable trust.
When Let's Encrypt blocks government entities, it instead puts respective vulnerable population in even less secure environment.
Although, given the current events, I am not sure Let's Encrypt continues to deserve the trust it had.
Sanctions compliance is unfortunately fairly complex.
Let's Encrypt can issue certificates for non-government entities in Iran and Russia due to statutory exemptions protecting personal communications, alongside specific Office of Foreign Assets Control (OFAC) authorizations designed to promote Internet freedom and human rights.
We will look into whether we can make things more easily understandable in the subscriber agreement.
> You are not a person or entity that is: (a) located in, organized under the
laws of, or ordinarily resident in any country or territory that is the target
of comprehensive U.S. sanctions
Seems to be pretty clear that it would include non-government entities in sanctioned countries.
I'm not sure if you're talking generally about sanctions or specifically about Let's Encrypt, but to avoid any doubt: citizens of Crimea are free to use Let's Encrypt. We do not, however, serve government entities in occupied Crimea.
you should update the documents to reflect this stance.
"You are not a person or entity that is: (a) located in, organized under the
laws of, or ordinarily resident in any country or territory that is the target
of comprehensive U.S. sanctions; "
this says nothing (edit: specific) about government (edit: only), and is applicable to normal people in those areas.
Stopping all issuance is an pretty standard response if a CA thinks what they are issuing might be non-compliant in any way. It's an action we're required to take. It's not necessarily a sign of a more dramatic failure mode or key compromise. That said, the impact is the same for as long as the downtime lasts so it is unfortunate and we're sorry for the disruption.
I don't think the premise behind short lived (six day) certificates being viable is that CA issuance never goes down. Sure, the runway is shorter, but not that short. Most down time is a few hours or less, which is not a problem for six day certificates that should be renewed every three days.
Short lived certificates are optional though, so if it's not worth it to you there are longer lifetime options.
"compliance incident" is the catchall for everything from a spelling error on a CPS (certification practice statement) or being one second late on revocation, all the way up to to key compromise.
it is almost always closer to the spelling mistake side than it is the key compromise side of the spectrum.
Indeed. "Compliance" can mean some internal audit/monitoring system has tripped and requires in depth investigation and preservation of logging, or it can mean "federal law enforcement with badges are right now standing in our datacenter and/or NOC serving a court order".
I heard the CEO of Lets Encrypt, Warren Buffet, accidentally started a fire while charging his e-unicycle in the data centre and that knocked out the server that issues the certificates. They've got a backup, but it's in a safe only two people have keys to; one keyholder, Anne Hathaway, is at a parrot show in Singapore this week and her flight back is delayed due to fuel shortages. The other keyholder, Henry Kissinger, it turns out has been dead for 3 years.
I sincerely hope it's the most mundane and least spectacular explanation possible, just saying from my point above that compliance has a very wide range of possible meanings and interpretations (also depending on the background/career POV of the reader), until the incident is further explained..
Federal law enforcement in your DC isn't something you'd call a "compliance" issue, that's not what that term means. Yes it's various derivatives of the English word "comply", but this is a field of well-defined verbiage, and that ain't it. Compliance means they failed (or are being questioned) about following particular practices that they have agreed to, nothing else really.
NB: "legal compliance" is another term. So is "{legal,lawful} enforcement"
Compliance here means compliance with the CA/B Forum Baseline Requirements (and similar other policies), which cover a lot of operational obligations, from character encoding to physical security.
I don't use voice so I couldn't be sure, but in the video, the instructor pushes a button to activate Voice. So that may vary depending on the specific year and model.
Their networking is awful in my experience. The WiFi chip is cheap crap, extremely sensitive, cuts out a lot, and doesn’t support WPA3.
I had to set up a dedicated Nanit-only AP in my house in order to stabilize the connection. It would not work any other way, tried many different configurations, even other APs.
Rust is generally a much better tool for building software than C. When your software is built with better tools, you will most likely get better software (at least eventually / long term, sometimes a transition period can be temporarily worse or at least not better).
I'm not sure exactly what you mean but of course people are facing implementation deficiencies in Git. Last I checked submodules were still "experimental" and extremely buggy, and don't work at all with worktrees. (And yeah submodules suck but sometimes I don't have a choice.)
Your reply seems to imply that using rust would make submodules better. Since that's not the case, maybe you can provide an alternative where rust would address an actual issue git users have.
If we're talking about feelings, I find it "not likely" unless, perhaps as a side-effect of rethinking the whole feature all together. Or do you have some actual indicators that the issues with how modules are likely to break your work directory are related to problems that rust avoids?
Yes I do. Rust's strong type system makes logic bugs less likely, because you can encode more invariants into the type system.
This also makes it easier to refactor and add features without risk of breaking things.
The borrow checker also encourages ownership structures that are less error-prone.
Finally the more modern tooling makes it easier to write tests.
If you're thinking "where is the peer reviewed study that proves this?" then there isn't one, because it's virtually impossible to prove even simple things like that comments are useful. I doubt there's even a study showing that e.g. it's easier to write Python than assembly (although that one probably isn't too hard to prove).
That doesn't mean you get to dismiss everything you disagree with simply because it hasn't been scientifically proven.
The things I'm talking about have been noted many times by many people.
OK, but I'm not convinced for this specific case. And it wouldn't take a peer reviewed study to convince me. Issues in the git submodules handling that you could link to C's lack of safety would suffice.
However what you're doing is to reply with the same platitudes and generalities that all rust aficionados seem to have ready on demand. Sure, rust is better at those things, but I don't see how that would make a rewrite of an existing feature better by default. I don't doubt that new features of git that would be written in rust will be safer and more ergonomic, but for existing code to be rewritten, which is what I understand to be your stance, I remain skeptical.
You missed "IMO". We get it, you love Rust and/or hate C, and if so, I wonder why. Try Ada + SPARK though if you really want REAL safety. Its track record speaks for itself.
Most of our sanctions-related blocks apply only to the governments of certain sanctioned countries, not their general population.
This subscriber agreement update was intended to better reflect our legal requirements. It does not reflect a major change in the service we provide. Our compliance program does evolve over time, and part of that is communicating about it better in our terms of service. It's clear from some of the comments here that we have more work to do to make that text more understandable, we'll work on that.
> That said, pretty sure this is stems from the insane US legal requirement to not export SSL technology to enemy countries. I'm sure some of y'all are old enough to remember when web browsers came in "international friendly" versions that supported 40 bit encryption, or "fancy secure" versions with 128 bit encryption.
It doesn't.
reply