Hey Peter, Sorry, this email got lost in my post-Bangkok email pile.
I’m not sure that I fully understand your question. It has also been a long time since I put thought into these drafts, so my memory is getting fuzzy. Can you please expand what you are referring to with this: “My question is about this "certificate" that needs distribution” “And what are the required works for it to proceed?” I believe that the technical content is fairly mature, although there are a few small open issues that should be described in my slides from past ACME meetings. But more importantly, and more time-consuming, is the political consensus-building work: some effort is required to make sure that the big public CAs and ACME client maintainers feel that this document is serving their interests, and need a few cloud providers to give at least neutral statements that they would allow this mechanism to be turned on within their environments. --- Mike Ounsworth From: Liuchunchi(Peter) <[email protected]> Sent: Tuesday, April 1, 2025 2:22 AM To: Mike Ounsworth <[email protected]>; [email protected] Subject: [EXTERNAL] RE: ACME discovery drafts looking for an author 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 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 > <[email protected]<mailto:[email protected]>> > Sent: Thursday, March 20, 2025 5:28 PM > To: [email protected]<mailto:[email protected]> > 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 -- [email protected]<mailto:[email protected]> > To unsubscribe send an email to > [email protected]<mailto:[email protected]>
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
