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=40entrust....@dmarc.ietf.org> > Sent: Thursday, March 20, 2025 5:28 PM > To: acme@ietf.org > 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 -- acme@ietf.org > To unsubscribe send an email to acme-le...@ietf.org _______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
