Of course. You’re absolutely right. That was inexact of me and I do know better. Thanks for pointing it out, Nit.
That is exactly my point.
I asked myself; What’s the use of a certificate? What is it good for?
And especially; What is it not good for?
I believe a certificate shouldn’t even try to guarantee the quality of the contents of the site. Also not guarantee that it’s contents or intentions are legally or morally ‘sane’. (Who’s to say?) Nor that it looks or doesn’t look like any other site. (Problems that could and should be dealt with in completely different ways.)
I believe it should do it’s best to guarantee that it actually is the site it technically claims to be and that you may communicate with the site resting assured that no one may eavesdrop the information exchanged with the site.
Microsoft’s acceptance or non-acceptance to trust the ISRG root certificate for its buyers should not put them in a position to apply indirect censorship on the sites having proved to be who they claim to be to Let’s Encrypt. That would create a very delicate situation for Microsoft and a very uncomfortable situation for Let’s Encrypt and its users. And one could only speculate how such censorship potentially could be (mis-) used in such a future.
Imagine having to go through an MACF (*) test once every six months or risking to loose the rights to the Let’s Encrypt certificate for your site.
And then, there’s Apple. And Google (Android). And so on and so forth…
(*) Microsoft Approved Contents and Functionality test.
Seriously? Then stop complaining and use a self signed certificate.
You just said:
but now you’re claiming the cert has nothing to do with the validity of what the site claims to be. You can’t have it both ways - either a Certificate Authority is backing up the validity of the site, or the CA has no bearing on the sites validity and you may as well use a self signed cert.
Make up your mind.
I agree with @Biker. The purpose of a CA is to issue certificates to the entity controlling a domain name, as determined by ICANN. It is troublesome to allow or encourage private entities to make arbitrary decisions secondguessing this. Of course the ICANN regime is private in itself, which creates its own problems, but adding further layers of arbitrary, unaccountable decisionmaking is not a gain for the openness, transparency and fairness of Internet infrastructure.
Let’s suppose, hypothetically, that Microsoft followed the proper procedure to challenge the registration by issuing a UDRP trademark complaint via ICANN. Let’s also suppose they lost. But under this contractual arrangement, this condition of their root programme, they’re still perfectly free, it seems, to try and obstruct the use of such a domain name, even if ICANN deems it legitimate. Moreover, the biggest issue with this is that such revocation orders affect all CA users, not only Microsoft users. There are various other avenues which Microsoft could pursue which are less troublesome; anti-phising lists, revocation lists pushed to IE (I gather all browser vendors are doing this now).
Since any CA is going to want inclusion in the Microsoft root programme, this is essentially a way for Microsoft to decide what websites get to use TLS, and eventually (as use of TLS becomes essentially mandatory, especially for newer web platform features as is intended), whether websites are allowed to substantially exist. This is not necessarily a power that will be abused, but it’s also one I’d argue it’s not Microsoft’s place to possess. This also circumvents the whole CA/B Forum process of determining certificate issuance criteria.
Then go to a different signing entity. You know why virtually none will supply a cert for windowsnotificationcentre.com? Because the domain is deceptive in nature and nobody wants to back such an obvious malware site.
This is hardly an arbitrary decision - notificationsforwindows.com would be fine, because it’s not directly using a trademarked part of the world’s most widely used desktop/laptop OS. But windowsnotificationcentre.com is obviously trying to sound like an official part of the Windows ecosystem, being named exactly like a component on Windows.
Let’s not, since that’s a complete non-sequitur. MS isn’t challenging the domain, nobody have ever said MS is challenging the domain. Biker himself complained that the cert should be available since the domain was validly obtained.
All MS (and Let’s Encrypt and StartSSL and any other legit CA) are doing is refusing to validate that domain.
And so they shouldn’t. Biker can generate a self signed cert for whatever domain he gets, but he can’t get international recognition if the domain is likely to appear to be from a separate recognised organisation.
There’s a very interesting blog post on this topic from a couple of months ago, along with a lengthy discussion of the policy. The short version is that Let’s Encrypt agrees that CAs should not be a judge of quality or legitimacy when it comes to DV certificates. DV merely verifies that a public key belongs to a domain.
At the same time, that’s exactly how existing CAs have conducted business and marketed their products for decades (think: site seals and what not), so it’s not something that a new player can just completely ignore. That’s why Let’s Encrypt is currently checking Google’s Safe Browsing API before certificates are issued.
In the end, I think this is a user education and browser UI problem. Users have been told to look out for “the lock” as a sign of authenticity for decades, but that’s not really what it is. Once we get to a point where regular HTTP can be marked as insecure, the UI for DV could be changed to look like HTTP does today, and the “secure” look can be reserved for certificates of a higher validation level, where the authenticity of the certificate owner has been verified to a certain degree.
Finally, just a gentle reminder: Try to be agreeable, even when you disagree. This is an important conversation to have, and it would be in everyone’s interest to keep the discussion to the facts.
(I pointed out a typo, which pfg has now fixed, nothing to see here)
Will any explanation be given by Let’s Encrypt staff that did that? Since the matter is very interesting…
If I hold a TLD it should be possible for me to hold a cert for the same
TLD. If I can’t get a cert, then the root case should be addressed,
i.e. someone trying to refuse me the cert should try to refuse me the
TLD, not the certificate.
Let’s Encrypt (and all other CA’s) should NOT dance to the music of any
external company trying to protect their economical interests (Don’t
even try to convince me about the “for the user’s interest” thing. I’ve
been in this business and on this planet too long to believe in that
I don’t think anyone is trying to reduce your property rights.
What happens when that certificate is used to phish you, your family or your friends? (I often use my mother and father as worse case, so its not meant as an insult. It drives home the imperativeness).
We need the DBOUND Working Group (http://datatracker.ietf.org/wg/dbound/charter/) to provide a solution for domain administration boundaries.
Microsoft asked us to revoke because of “unwanted” software on one of the domains (the .online one, don’t recommend visiting it). They were also concerned about one of the domain names (windowsnotificationcenter.com). We do not know details about the unwanted software, for the most part we just know that the Microsoft root program required us to revoke and we need to comply with root programs.
when you guys have to obey MS’s root program, is the ISRG already trusted by MS?
- Even if you want to get added you have to follow the rules.
- The domain currently only serve 404 .
- It should added to the rules that sides containing malware can cause an revocation.
is there anywhere a tldr of the root program rules?
legal native language is hard enough, but legal foreign language is not funny.
We are required to follow the MS root program rules even though we aren’t in it because IdenTrust is in the program, and we inherit the obligations through the sub-CAs from IdenTrust.
well that makes sense as well.
Can you answer also to this thread (https://community.letsencrypt.org/t/inclusion-of-isrg-root/) about the progress that has been made regarding the Root Inclusion? Or hasn’t there been any progress?
That i already anticipated that you have to follow the root programm independent if you want to get added or because you have to inherit because of sub-CA. But it would be great if you could ad links to the rules of the different root programs you need to follow. From the current i think we can say:
- High Risk domains are forbidden because there is no manually verification.
- Domains containing malware are forbidden -> inherited from MS root rules.
- Domains to similar to high risk names.
But if would be great to have an overview of all rules.
For Mozilla the root programme’s rules are published here:
I’m not aware of Microsoft, Apple or Oracle publishing full rules for their programmes, although I agree in principle that it seems as though participants in the web PKI should do so.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.