devrand

This has come up in discussions before. The argument that small CAs shouldn't be in root stores since they have huge risk for little upside is compelling, except that it would also make it impossible for businesses to enter the market. You'd need to prove you have market share, but you cannot reasonably get market share if you're not in a root store.

So you'd just end up with the big players (ex. Sectigo, who cross-signed these certs btw), who would then claim too big to fail should anything actually go wrong with them (see: Comodo).

All two letter TLDs are reserved for ccTLDs.

If you're using ACME to handle certificate rotation, can't you just configure multiple providers?

Is DOGE still there? The latest reporting [1] I've seen is that it's leaderless and has more or less just been absorbed into other organizations. This aligns with DOGE not posting anything for several months now.

[1]: https://www.reuters.com/world/us/doge-doesnt-exist-with-eigh...

It seems like you can also finance it interest free through Apple themselves without being locked to a carrier.

What's the concern here? Can the phone not just be bought outright?

This article links to a Forbes article that states it was a leak of a Saleforce instance that contained contact information about small and medium businesses.

This PCWorld article seems to be taking that to mean that every single gmail account (2.5B) is at risk with nothing to support that claim.

You could also use the `_acme-challenge` CNAME record to delegate cert acquisition, assuming you're using separate subdomains for each.

ah-ha! Didn't consider that GoDaddy operates the TLD (in my mind I assumed it was just Verisign). Thank you for pointing that out.

Yeah I don't understand this. MarkMonitor themselves are a registry, so is the potentially a mistake in migrating from GoDaddy to MarkMonitor?

Puget Systems has similar publications covering their experience building client systems, though not always in the same level of detail. They also have PugetBench to benchmark systems in real-world applications/workflows.

It was dead long before Google was involved. Pebble filed for insolvency back in 2016 with Fitbit acquiring much of the assets. It was dead at this point. 5 years later Google bought Fitbit.

I presume it's in a company's interest as L-1 visas cannot be transferred so you're tethered to them.

Looks like WSJ finally implemented bot protection as archive.today just has a CAPTCHA archived.

And the recent antitrust ruling against Google might see Mozilla lose like 80% of their revenue...

I suggest you read the indictment for Megaupload (Wikipedia summarizes it, but they cite the actual document you can view): https://en.wikipedia.org/wiki/Megaupload_legal_case#Basis_of...

The indictment explicitly answers your questions about why Megaupload was different from other file sharing services.

Viacom International Inc. v. YouTube, Inc.: https://en.wikipedia.org/wiki/Viacom_International_Inc._v._Y....

At least in the short term they probably would. Why not take the basically free money?

Longer term, yeah they'll probably just make their own search engine.

I highly doubt Google would give Mozilla anything. The only reason I think they would would be to appease Chrome monopoly concerns, but I don't think Chrome is even at risk of that. It's not the default browser on any platform other than ChromeOS and some Android devices.

Presumably these deals with Google will be nullified, but can the various browsers just make new deals with someone else? Can Microsoft just just swoop in and make a deal with Apple/Mozilla/Samsung? Mozilla is going to be desperate to find a new partner...

It sounds like they intended to use it as the primary e-mail domain for himself and family. They claimed that they had already switched to using it.

However, the total window of time here is small. They registered the domain in late November 2023 and this UDRP was filed in late February 2024. It also sounds like initial contact to try to acquire the domain occurred in early December 2023... so only a couple days after it was registered.

I think they generally give a lot of weight to someone who registered the domain well ahead of the said company registering their mark. Though you might run into trouble if you started using the domain in bad-faith against that company (ex. impersonating them).

In your example, you had that domain well in advance, it's your self-identified pseudonym that predates said mark, and it's actively being used to host your personal website. That seems like a pretty strong defense.

That's one option. Alternatively, they could just delegate the _acme-challenge with a CNAME.

If clientportal.somebank.com is actually run by somesaas.com, they can define CNAME _acme-challenge.clientportal.somebank.com --> [some_key].domainvalidations.somesaas.com

When the SaaS vendor needs to request a new cert, they set the appropriate TXT record on [some_key].domainvalidations.somesaas.com.

Heck, subscribers could go to 10 day certs today (soon 7) and be immune from revocation entirely.

I think they're suggesting that 1 year certificates are still at the point where people can just manually rotate them as they expire. If you keep reducing the lifespan, to say 90 days, that starts to tip the scale. You'll be spending too much human time manually rotating certificates that it will make financial sense to just automate the process.

If the process is automated then revocation can be automatically handled as well (so long as ARI gains traction).

"Never had to deal with 3rd party SaaS vendors certificate pinning requiring service tickets to change"

I think this tends to fall into "probably shouldn't have been using Web PKI". I can't immediately think of a reason why you'd need a publicly trusted certificate if you're pinning a specific public key.. at that point who cares who signed it?

I do agree that there are real costs with rotating certificates that ultimately may make it impossible for an organization to complete that work in the revocation window. That is very much an area that needs further automation developed and more importantly, for it to actually be adopted. I believe that's what ACME Renewal Information is attempting to address.

"but in those cases the business users are ok with an outage to remediate a real security issue"

Ideally yes, but that might be the same point you find out the certificate was used in some critical system (let's say Air Traffic Control like a previous CA tried to claim). They still may very well not be okay with the revocation despite the security issue. _Those_ are the people that need to stop using these certificates and there's really no way to weed them out until a revocation actually needs to occur.

"Digicert screwed up their system implementation and made their customers suffer."

And those customers are right to be mad at DigiCert. They probably don't have a legal basis to challenge as the subscriber agreement explicitly permits immediate revocation without prior notice, but they can certainly take their business elsewhere.

"It's also disheartening to see browsers in the CA consortium ignore the CA resolutions as well. Like how everyone voted for 2 year certs and Apple did their own thing anyways. Any punishment for Apple come? So why pick on the others?"

Admittedly I'm not very familiar with the various root programs and the obligations they have with CAs, but it doesn't seem unreasonable that root programs would be free to impose stricter requirements then the BRs.

Though I do find it two-faced for Apple to vote for Ballot 193 only to then impose a stricter requirement. At the very least they should have abstained.

Spoke too soon... seems like subscriber(s?) issued DigiCert a Temporary Restraining Order to not revoke: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c8

Bold.

Respect to them for actually abiding by the BRs. Most CAs just shrug [1] and [2] say [3] it's [4] too [5] complicated [6], or just lie and claim planes will start crashing [7]. It's really disheartening that publicly trusted CAs just ignore their contractual obligations however they see fit.

Ideally these companies should have response plans in place to prioritize certificate rotation. They can use this as a fire drill for what would happen if there were a key compromise.

Alternatively, if companies cannot handle the rotation, then they likely should re-evaluate if WebPKI is even appropriate for their use-case.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1885568 [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1898848 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1910237 [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1896053 [5]: https://bugzilla.mozilla.org/show_bug.cgi?id=1896553 [6]: https://bugzilla.mozilla.org/show_bug.cgi?id=1877388 [7]: https://bugzilla.mozilla.org/show_bug.cgi?id=1903066#c48

They’re saying that once you’ve sold certs to governments, distrusting that root will deny people access to government resources. They’re merely using “.gov” as a proxy for “some government”.

Also roots can be TLD constrained, typically to ccTLD(s).

It does seem like Netflix has been doing a decent cat-and-mouse game with Widevine for anything over 540p the last few months. There's been several shows that took several days to get properly copied (i.e. not just screen recorded).

This is get first that I’m hearing that VAC is kernel level. Do you have a source for that?