Thought folks here might be interested in this news. Tidbits I found notable:
I hope that will mean that all those "internal CF certs" will now be trusted everywhere!
Reading this blog I started worrying about the financial foundation, as Cloudflare may move away from Let'sEncrypt. Does Cloudflare sponsor Let'sEncrypt today?
Not according to this: Sponsors and Donors - Internet Security Research Group
Maybe by not issuing unless you have previously polled their endpoint? And perhaps by not allowing earlier renewals than allowed by ARI? Requiring the ARI "replaces" seems problematic so hopefully only a "should" rather than "must" 
From that blog post about ARI:
Subscribers must maintain automation that polls our renewal endpoint, acts on the renewal windows we publish, and identifies the certificate it is replacing.
Hope so.
also even shorter than 6 days, perhaps 48 hours certs! or even shorter, ¨
Not sure what you are replying to but Google Trust Services CA offers certs for the duration you request. Your ACME Client must support the notAfter option. GTS recommend not less than 3 days although technically they allow as short as 1 day.
That said, I am getting a bit off-topic for this thread
sorry some got cut off, i am all for more acme, today there is a few. but only lets encrypt is total free and offerd wildcard would bue nice with more options,
zerossl is meh and charge way to much
Google Trust Services is free and offers wildcards. In addition it supports "notAfter" (and "notBefore") to allow you to set cert durations.
ZeroSSL is free if using ACME.
Actually, quite a few CA support ACME but a number of those charge fees.
I think what you want are more "free" cert providers. I agree it would be nice to have another one that has a history of handling large scale really well. Perhaps express your desires for features on the Cloudflare forum?
Also see: ACME CA Comparison - Posh-ACME
We're now both fairly off-topic. The Client Dev section is intended for developers of ACME clients and related products to discuss issues. I look forward to discussing those once Cloudflare announces more details. Exciting news that.
The biggest problem is when a subscriber loses his certificate. So requiring ARI could become problematic that way since you must have the certificate's serial number.
One thing to allow more lenient ratelimits if you issue with ARI, but requiring it can be problematic.
Sure, but there are options. CF could have a panel showing all unexpired certs and you'd have to mark it as "lost" (or even revoke) to exclude from ARI enforcement. Or, they could require using a new account with its related, but surmountable, issues. Or, they could tolerate a small percentage of certs issued for an account to be out-of-compliance (needing a new account should someone lose all their certs due to poor setup). These are just top-of-my-head and may not stand up to scrutiny. A new CA doesn't have the technical debt of others so has some flexibility.
Will be interesting to see what they come up with. They know the space well. In general I like their idea of guiding client setups towards best practices.
My first thought for how a CA might be able to "force" use of ARI is for the initial certificate to be of very short duration (a day, maybe even less). (Maybe even not from a publicly trusted root, though I haven't thought through that yet.) And have the ARI for that initial certificate be for immediate renewal, and only when getting that renewal have it be for a "normal" duration. That would allow for "bootstrapping" new (or lost) certs from clients while helping making sure they support ARI in general.
My second thought is that they could filter by user agent for clients known to support or not support ARI. Kind of makes me wince, but if getting a request from a known-obsolete user agent, one could return a reasonable error message telling the user that they need to use a more modern client. That doesn't ensure that ARI is actually enabled and used even with a client that's known to support it, but might be something that could help anyway.
This is a security strategy, Cloudflare can provide you with a 'click to download certificate', but it is not secure.
And CA can't give you a 15 years certificate due to CA/B forum rule
The person who wrote the article is likely not the actual engineer, and he may not have considered how to distinguish ARI clients.
Probably not. Those certificates break a lot of the requirements for publicly-trusted certificates.
Given the level to which ARI can potentially cause clients to create self-imposed denial of service if you follow it to the letter I think their implementation probably needs time to shake out after it's release. For instance if they rejected renewals before (or after!) the ARI suggested renewal window that would an interesting choice.
I'd also be very surprised if it doesn't require a cloudflare account and EAB so at the very least for them it's a new customer onboarding stream. Their other services are great and my stuff has served many billions of requests via them over the years.
The blog post says their plan is for "anyone already pointed at any existing free CA can move to us by changing a directory URL, with no new tooling and nothing to re-architect." So I had read that as meaning they were going to offer accounts without EAB. Though until there's actually an ACME server to connect to for testing nothing is really certain, I suppose. (And even then it could certainly change further at any time.)
I didn't interpret that as literally as you. It was in the context of saying issuance would be using ACME and ended by mentioning the directory URL. I think they were just making it abundantly clear ACME and not a proprietary protocol will be used. After all, the blog also said ARI will be required so may require more than just a URL change for some.
I believe all other free CA require EAB apart from LE. So, not unusual to require that and is common part of ACME.
There are likely to be rate limits and perhaps other restrictions that may require re-architecting for certain situations. Unlikely to be zero re-tooling for every existing ACME user
Will be fun to watch this develop for sure.
The MTC part is definitely the most interesting to me. The root acquisition and ARI requirement also make sense if they’re trying to speed up compatibility and improve certificate lifecycle management. Curious to see how widely clients actually adopt it.