Short lived certificates alternative: Delegated credentials

Mozilla, Cloudflare and Facebook announced “Delegated Credentials for TLS”:

Which require a X.509 certificate extension: id-ce-delegationUsage (

Thoughts about that mechanism?

It’s probably too early to ask that question, but, is Let’s Encrypt considering supporting that certificate extension?


I feel like someone just discovered new land!
I think this could be a very big step towards complete global encryption.
Needless to say, I second the question and add:

And, if so, is that discussion open (will it be open for discussion)?

1 Like

IIRC LE has different idea for short life certificate, which called ACME-STAR and acme-star-delegation

but this delegated credentials has working implantation for it.

Comparing for this and acme star most significant differences is ACME-STAR creates real certificate with few days of lifetime each, but for De-Cr leaf certificate signs another short lived token(about few hours?)

pro for acme-star

  1. it’s a real x509 certificate, so all current web client and servers work without touching anything after you get cert.

con for acme-star

  1. increased load to CT servers
  2. unless we change CA/B BR, each challenge will only valid for 30 day to sign new shout life certs.

pro for Delegated credentials

  1. have a working implantation inside cloudflare and facebook
  2. major companies fund behind this.


  1. Does CA/B BR really allow this?
    a. Is it allowed to add arbitrary extension for public cert?
    b. let leaf certificate to sign any sub-tokens? cloudflare want to sign EDDSA token and many other new type of crypt using this, witch would be violate BR and clearly try to bypass that rule with this.
  2. it need client and webserver implantations, with has no public available code for server implantation.
1 Like

And as Let’s Encrypt already support another TLS extension (OCSP Must Staple -, adding another one should be easy (in terms of development and maintenance).

So both way could be explored.

1 Like

Digicert has already issued some public certificates with that extension:

At a high level, I don’t understand the point. If you’re pointing your domain to a CDN, they already have full MITM on you. Is the underlying suggestion here that your CDN is a threat actor or incompetent? The upside is protection against one narrow form of CDN edge compromise? :confused:


In that light, it would seem that their point is to ensure that one can't be overly exploited by those they are forced to trust. I guess it will make them sleep better at night...

But this actually puts the control back in the hands of the domain holder (more so).
In that the next logical step is to remove the MiTM from being able to issue any certs at all - even though the A record points to their IP (work in progress). Thus requiring the domain holder to renew delegated control via the "limited use lease" for their continued use.

But I see a bigger picture... one where these types of certs can be used like "a one-day pass at Disney World!"
A "user" obtains one of these certs, and it allows them access to:

  • Games
  • VPN
  • Anonymous Proxy
  • Music/TV/Radio/News
  • SFTP/Cloud Storage
  • eMail encryption (not repudiation)
  • etc.

For a limited time only, see store for details...


We are not actively considering this or tracking the work closely.

Quick note: ACME STAR is completely separate from Let’s Encrypt. Nobody associated with ISRG has participated in its development and we have no plan to implement support.


Related thread on forum:

1 Like

This is my understanding yes. And while the use case seems narrow (CDNs and other large Internet companies), it's not totally unrealistic. CDNs have PoPs all over the world, usually not under their physical control. And someone with physical access to a server in a PoP can almost certainly get keys off of it.

But yes, as @cpu said, this isn't something we plan to work on.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.