[Acme] Re: ACME discovery drafts looking for an author

["Liuchunchi(Peter)" <[e-mail]>]

If I get it right, you are maintaining a whitelist of authorized clients (via pks) that can request issued certificates from SP/CA. This part is quite clear. 

My question is about this "certificate" that needs distribution restraining -- is it the server certificate (of a web)? If it is, I thought it is free to distribute in order to visit the service?

If it does need distribution restraining, the reason I can think of is "private key is also maintained by the SP/CA so they can be used together for third party adversary to spoof my domain". But this becomes more of a private key protection problem...  I think it is interesting work but I am just trying to understand the exact value use case.

And what are the required works for it to proceed?

Peter

> -----Original Message-----
> From: Mike Ounsworth <Mike.Ounsworth=[e-mail]>
> Sent: Thursday, March 20, 2025 5:28 PM
> To: [e-mail]
> Subject: [Acme] ACME discovery drafts looking for an author
> 
> Hi ACME,
> 
> As I said during ACME today, I have a pair of (expired) drafts that I can no
> longer continue to put time and effort into. They are looking for a new lead
> author. FREE TO A GOOD HOME!
> 
> They are:
> 
> draft-vanbrouwershaven-acme-auto-discovery
> draft-vanbrouwershaven-acme-client-discovery
> 
> The idea of the drafts is:
> 
> acme-auto-discovery:
> What if your website is hosted by a cloud hosting provider and their UI only
> gives you two options for where to get a certificate for your website: A) use
> the CA of the cloud provider's choice over ACME, B) upload a PEM file. The
> first means that you have no ability to manage that certificate, control which
> clients can request that certificates, manage how many copies of that
> certificate get issued, or revoke that certificate. It also becomes very difficult
> to monitor CT logs for abuse of your website since you have no visibility into
> which cert requests were made on your behalf. This also leads to lack of CA
> diversity since many cloud hosters use the same small number of CAs. Option
> B) "upload PEM file" is going to become an extinct species with the push to
> 45-day certificates and beyond. This draft provides a mechanism where you
> can put in your website's CAA DNS record (although maybe SRV would be
> better?) the URL and CA Account info for where you would like the ACME
> client to go to retrieve a cert for your domain.
> 
> 
> acme-client-discovery:
> If, using the above mechanism, you wish to configure at your CA an allow-list
> of ACME clients that may request certs for your domain, how would you do it?
> The obvious way is to configure an allow-list of ACME Client public keys,
> however a naïve approach here would lock-in keys such that hosting providers
> cannot rotate ACME client keys or add new ACME clients. This draft registers
> a .well-known URI at which a hosting provider can publish the set of public
> keys that belong to its ACME clients. Essentially, a level of abstraction for
> allow-listing ACME clients that may request certificates against your CA
> account.
> 
> 
> These drafts have had some design team iterations and are fairly mature, but
> will require some effort to get them through adoption and WGLC. If you think
> these problems are worth solving, these drafts can be yours free-of-charge! I
> would be happy to stay on either as a secondary author or document
> shepherd, but I can no longer dedicate time to advancing them.
> 
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
> 
> Any email and files/attachments transmitted with it are intended solely for
> the use of the individual or entity to whom they are addressed. If this message
> has been sent to you in error, you must not copy, distribute or disclose of the
> information it contains. Please notify Entrust immediately and delete the
> message from your system.
> 
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]