Hi Amir, We described this challenge in the Security Considerations, Terms of Service and Acceptance:
https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-01.html#name-terms-of-service-and-accept A similar problem exists today, in case the subscriber uploads the certificate to a service provider. While it would have agreed to the terms of service, it basically delegates some of its responsibilities. In the security considerations we describe currently two mechanisms, implicit approval by setting the CAA record, or explicit approval by including a CAA parameter. I don't like an additional CAA parameter, but if a CA would like to get an explicit approval they could also send a request to the email of the ACME account to approve the terms of service before activating the ACME account. Where a CA is using an external account binding the terms of service have already been agreed to for the CA account. I will create an issue to update this section for further clarification. Paul ________________________________ From: Acme <acme-boun...@ietf.org> on behalf of Amir Omidi <amir=40aaomidi....@dmarc.ietf.org> Sent: Friday, July 7, 2023 04:32 To: Seo Suchan <tjtn...@gmail.com> Cc: acme@ietf.org <acme@ietf.org> Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt In this flow, the subscriber is the hosting company. This means that the end domain would be expecting an entity (the hosting company) to agree to the CA terms of service without ever actually reading them. Registering an account with a CA generally requires an affirmation to follow the terms of the agreement of the CA, and I think that could impose a problem with this draft. On Thu, Jul 6, 2023 at 22:29 Seo Suchan <tjtn...@gmail.com<mailto:tjtn...@gmail.com>> wrote: 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!Zi5QbjzclZVHaiNkeCqijL-X7C8hsEOQ7QXmvlVOdW6GuK51gyKJzMxszaA0GkDN36Ev8DA9h7jfN0HO737mnJHDtNMAIJgXQsQhgK0vSw$> 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://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.txt__;!!FJ-Y8qCqXTj2!Zi5QbjzclZVHaiNkeCqijL-X7C8hsEOQ7QXmvlVOdW6GuK51gyKJzMxszaA0GkDN36Ev8DA9h7jfN0HO737mnJHDtNMAIJgXQsRANgFd8w$> > Status: > https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/__;!!FJ-Y8qCqXTj2!Zi5QbjzclZVHaiNkeCqijL-X7C8hsEOQ7QXmvlVOdW6GuK51gyKJzMxszaA0GkDN36Ev8DA9h7jfN0HO737mnJHDtNMAIJgXQsSXPaaA5Q$> > Html: > https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-auto-discovery-00.html__;!!FJ-Y8qCqXTj2!Zi5QbjzclZVHaiNkeCqijL-X7C8hsEOQ7QXmvlVOdW6GuK51gyKJzMxszaA0GkDN36Ev8DA9h7jfN0HO737mnJHDtNMAIJgXQsSkdJiMDg$> > Htmlized: > https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-acme-auto-discovery__;!!FJ-Y8qCqXTj2!Zi5QbjzclZVHaiNkeCqijL-X7C8hsEOQ7QXmvlVOdW6GuK51gyKJzMxszaA0GkDN36Ev8DA9h7jfN0HO737mnJHDtNMAIJgXQsQqEaz0qw$> > > > 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://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!Zi5QbjzclZVHaiNkeCqijL-X7C8hsEOQ7QXmvlVOdW6GuK51gyKJzMxszaA0GkDN36Ev8DA9h7jfN0HO737mnJHDtNMAIJgXQsQrvXroOw$> _______________________________________________ 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!Zi5QbjzclZVHaiNkeCqijL-X7C8hsEOQ7QXmvlVOdW6GuK51gyKJzMxszaA0GkDN36Ev8DA9h7jfN0HO737mnJHDtNMAIJgXQsQrvXroOw$> -- Amir Omidi (he/them)
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
