>>You are correct, to facilitate account binding it's important that each >>customer is using its own ACME key.
> I will create an issue to spell this out more clearly in the document. I have added the need for unique ACME key to the security considerations: https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html#name-acme-keys ________________________________ From: Paul van Brouwershaven <paul.vanbrouwersha...@entrust.com> Sent: Friday, July 7, 2023 10:56 To: Q Misell <q=40as207960....@dmarc.ietf.org> Cc: acme@ietf.org <acme@ietf.org> Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt Hi Q, You are correct, to facilitate account binding it's important that each customer is using its own ACME key. I will create an issue to spell this out more clearly in the document. Paul ________________________________ From: Q Misell <q=40as207960....@dmarc.ietf.org> Sent: Friday, July 7, 2023 10:50:04 AM To: Paul van Brouwershaven <paul.vanbrouwersha...@entrust.com> Cc: acme@ietf.org <acme@ietf.org> Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt Hi, Reading the draft I think it is the author's intention (correct me if wrong) that each customer of a hosting provider would have a new ACME account created for them, and for the contact details on the ACME account to be that of the customer, not the hosting provider. I know it is common with hosting providers at the present time to have one ACME account for all customers, and for the contact details to be that of the hosting provider. Might it be worth spelling out in the I-D the author's intentions about who is the holder of the account. This would also help clarify who is actually agreeing to the CA ToS. Thanks, Q ________________________________ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574<https://urldefense.com/v3/__https://find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!c7XYcqfuEqSdOdkjQ0F2h1p8h_jBL5-aD8KCIDGefelG2Ug4epJsYVUuNkPdJ81OO-sYR_6f8adUvZCApdYEAbi1LdzfL9owygcfPGBKLQ$>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876<https://urldefense.com/v3/__https://ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!c7XYcqfuEqSdOdkjQ0F2h1p8h_jBL5-aD8KCIDGefelG2Ug4epJsYVUuNkPdJ81OO-sYR_6f8adUvZCApdYEAbi1LdzfL9owygfUo261AA$>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Fri, 7 Jul 2023 at 09:23, Paul van Brouwershaven <Paul.vanBrouwershaven=40entrust....@dmarc.ietf.org<mailto:40entrust....@dmarc.ietf.org>> wrote: Adding, that I agree that it would be great if service providers would all provide an option to configure ACME clients with a custom server and account binding, but I do not see how this would solve the problem of rate limiting. ________________________________ From: Paul van Brouwershaven <paul.vanbrouwersha...@entrust.com<mailto:paul.vanbrouwersha...@entrust.com>> Sent: Friday, July 7, 2023 10:16:55 AM To: Seo Suchan <tjtn...@gmail.com<mailto:tjtn...@gmail.com>>; acme@ietf.org<mailto:acme@ietf.org> <acme@ietf.org<mailto:acme@ietf.org>> Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt I expect that rate limiting is main the problem for a CA that is configured as default. If there would be thousands of users setting the same CAA records this CA would need to identify that the rate limit is hit and adjust accordingly if these requests seem to be legit. This would be less of a problem for a commercial CA who would be bound by service level agreements and can identify the customers through the account binding so apply a rate limit per customer instead of per IP address/block. Paul ________________________________ From: Seo Suchan <tjtn...@gmail.com<mailto:tjtn...@gmail.com>> Sent: Friday, July 7, 2023 10:07:27 AM To: Paul van Brouwershaven <paul.vanbrouwersha...@entrust.com<mailto:paul.vanbrouwersha...@entrust.com>>; acme@ietf.org<mailto:acme@ietf.org> <acme@ietf.org<mailto:acme@ietf.org>> Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt how about ratelimit? for large hosting they will hit CA's default API ratelimit fast, so they contract with a specific CA for ratelimit increase. feels like entire automatic CA loadbearing doesn't work without hosting provider having eab/acme account from domain holder: if it already have menu for upload such that menu could have a box for acme directory Uri too. 2023-07-07 오후 4:54에 Paul van Brouwershaven 이(가) 쓴 글: Hi Seo, a. ) CAs may want to put list of acme endpoints at well-known, for example one each for DV/OV/EV like sectigo did with https://acme.sectigo.com/v2/EV<https://urldefense.com/v3/__https://acme.sectigo.com/v2/EV__;!!FJ-Y8qCqXTj2!fOwwhASnPzBhTF0h_VK_hIwZsD3TU3aktKzTejf2fcZQY8dC5SasEv0izXw6vrG49jAHmrONh9Hn2QpK64AdFctM2w$> This could be solved by setting a CAA record to for example "ev.sectigo.com<https://urldefense.com/v3/__http://ev.sectigo.com__;!!FJ-Y8qCqXTj2!c7XYcqfuEqSdOdkjQ0F2h1p8h_jBL5-aD8KCIDGefelG2Ug4epJsYVUuNkPdJ81OO-sYR_6f8adUvZCApdYEAbi1LdzfL9owygdTqdC2zg$>" who could have its own ACME server. b. ) I think hosting provider wouldn't want to visit a random CA without human intervention, not only due to potential Malicious one but an open acme endpoint may not allowed to use, for example CA having noncommercial use only limit on that endpoint, and likely stick to CA they know even if it's low priority from CAA. If the terms of service limit usage to non-commercial use, the domain owner should not set the CAA record if they run a commercial service, the domain owner is the entity giving the instruction to the ACME client and thus requests the certificate from the CA and be bound to the terms of service. Paul ________________________________ From: Acme <acme-boun...@ietf.org><mailto:acme-boun...@ietf.org> on behalf of Seo Suchan <tjtn...@gmail.com><mailto:tjtn...@gmail.com> Sent: Friday, July 7, 2023 04:29 To: acme@ietf.org<mailto:acme@ietf.org> <acme@ietf.org><mailto:acme@ietf.org> Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt a. ) CAs may want to put list of acme endpoints at well-known, for example one each for DV/OV/EV like sectigo did with https://urldefense.com/v3/__https://acme.sectigo.com/v2/EV__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTvjUpZ_0A$ b. ) I think hosting provider wouldn't want to visit a random CA without human intervention, not only due to potential Malicious one but an open acme endpoint may not allowed to use, for example CA having noncommercial use only limit on that endpoint, and likely stick to CA they know even if it's low priority from CAA. 2023-07-06 오후 11:54에 Mike Ounsworth 이(가) 쓴 글: > Hi ACME! > > This is new business that we would like to add to the agenda for 117. > > Thanks, > --- > Mike Ounsworth & Paul van Brouwershaven > > -----Original Message----- > From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> > <internet-dra...@ietf.org><mailto:internet-dra...@ietf.org> > Sent: Thursday, July 6, 2023 9:39 AM > To: Mike Ounsworth > <mike.ounswo...@entrust.com><mailto:mike.ounswo...@entrust.com>; Paul van > Brouwershaven > <paul.vanbrouwersha...@entrust.com><mailto:paul.vanbrouwersha...@entrust.com> > Subject: [EXTERNAL] New Version Notification for > draft-vanbrouwershaven-acme-auto-discovery-00.txt > > WARNING: This email originated outside of Entrust. > DO NOT CLICK links or attachments unless you trust the sender and know the > content is safe. > > ______________________________________________________________________ > > A new version of I-D, draft-vanbrouwershaven-acme-auto-discovery-00.txt > has been successfully submitted by Paul van Brouwershaven and posted to the > IETF repository. > > Name: draft-vanbrouwershaven-acme-auto-discovery > Revision: 00 > Title: Auto-discovery mechanism for ACME client configuration > Document date: 2023-07-06 > Group: Individual Submission > Pages: 16 > URL: > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTtFe7gh7Q$ > Status: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTuBIoUWfg$ > Html: > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTvXjxu71A$ > Htmlized: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTt9chylcg$ > > > Abstract: > A significant impediment to the widespread adoption of the Automated > Certificate Management Environment (ACME) [RFC8555] is that ACME > clients need to be pre-configured with the URL of the ACME server to > be used. This often leaves domain owners at the mercy of their > hosting provider as to which Certification Authorities (CAs) can be > used. This specification provides a mechanism to bootstrap ACME > client configuration from a domain's DNS CAA Resource Record > [RFC8659], thus giving control of which CA(s) to use back to the > domain owner. > > Specifically, this document specifies two new extensions to the DNS > CAA Resource Record: the "discovery" and "priority" parameters. > Additionally, it registers the URI "/.well-known/acme" at which all > compliant ACME servers will host their ACME directory object. By > retrieving instructions for the ACME client from the authorized > CA(s), this mechanism allows for the domain owner to configure > multiple CAs in either load-balanced or fallback prioritizations > which improves user preferences and increases diversity in > certificate issuers. > > > > > The IETF Secretariat > > > 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<mailto:Acme@ietf.org> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTsRXrENiw$ _______________________________________________ Acme mailing list Acme@ietf.org<mailto:Acme@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!brMU-rWmiKuQ6G5EN8Ns5JEESSjbP9myZLjFfF9ISFYfPkLxgoTVs-Vuaaw80lPbmpqojB3H7KCIz7G4NTsRXrENiw$ _______________________________________________ Acme mailing list Acme@ietf.org<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!c7XYcqfuEqSdOdkjQ0F2h1p8h_jBL5-aD8KCIDGefelG2Ug4epJsYVUuNkPdJ81OO-sYR_6f8adUvZCApdYEAbi1LdzfL9owygdRgZjgiw$>
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
