Re: [Acme] [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Tim Hollebeek <[e-mail]>]

I'll accept that the terms of service stuff is already in one ACME spec, so it might as well be in all of them.  So I'll retract my suggestion to remove it.

On the issue of 'issuewild', I don't think just stating that the records are retrieved according to RFC 8659 is sufficient, because then neither that draft nor this one provides any guidance about whether the new parameters can be used with issuewild or not.  I think the draft needs to be clear about the suitability of the new parameters for each of the issue types, not just 'issue' itself.

As you note that's probably a pretty fast fix, just make it explicitly clear it's ok, and provide an example.

-Tim

I don't think 8.4.1/2 is in scope or makes the document better.  There are a
wide variety of contractual solutions here, and how a user agrees to a
particular CA's terms of service is not a relevant topic for IETF.
This consideration is included because RFC 8659 section 7.3.3.<https://www.rfc-editor.org/rfc/rfc8555#section-7.3.3> describes the acceptance of the terms of service, while section 10.5 is also clear that CAs need to keep in mind that ACME clients can automate this agreement, possibly not involving a human user.

I'm ok to remove or replace this with a more generic comment, any thoughts from anyone on this?
Oops, I forgot the most important one.  The draft ignores the existence of the
"issuewild" tag.  This won't work, because both issue and issuewild work together
in RFC 8659.  See, for example, section 4.3, third paragraph.  There's a requirement
to ignore "issue" records in certain circumstances, and it's not clear how that would
interact with the "issue" tags specified in this draft.  I think explicit consideration of
issuewild and how it would work together with this draft and RFC 8659 is needed.

This is especially important because ACME can be used in conjunction with the
 issuance of wildcard certificates, and this draft probably needs to specify how
things work for that, too.
I don't think that the draft doesn't ignores this, section 5 item 1 starts with:

1. The ACME client initiates a DNS lookup to retrieve the CAA record(s) according to [RFC8659]

where RFC8659 specifies the details on how CAA records must be checked. But I agree that this could be made more explicit, I added an example to describe this scenario in more detail.

Do you think that is sufficient or should we add in introduction to section 5 or update item 2 with a normative requirement that the ACME MUST follow RFC8659 when selecting the valid CAA records for the domain.

________________________________
From: Tim Hollebeek <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 12, 2023 22:45
To: Tim Hollebeek <tim.hollebeek=[e-mail]<mailto:tim.hollebeek=[e-mail]>>; Mike Ounsworth <Mike.Ounsworth=[e-mail]<mailto:Mike.Ounsworth=[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: Paul van Brouwershaven <[e-mail]<mailto:[e-mail]>>
Subject: RE: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

Oops, I forgot the most important one.  The draft ignores the existence of the
"issuewild" tag.  This won't work, because both issue and issuewild work together
in RFC 8659.  See, for example, section 4.3, third paragraph.  There's a requirement
to ignore "issue" records in certain circumstances, and it's not clear how that would
interact with the "issue" tags specified in this draft.  I think explicit consideration of
issuewild and how it would work together with this draft and RFC 8659 is needed.

This is especially important because ACME can be used in conjunction with the
 issuance of wildcard certificates, and this draft probably needs to specify how
things work for that, too.

-Tim

> -----Original Message-----
> From: Acme <[e-mail]<mailto:[e-mail]>> On Behalf Of Tim Hollebeek
> Sent: Wednesday, July 12, 2023 4:32 PM
> To: Mike Ounsworth <Mike.Ounsworth=[e-mail]<mailto:Mike.Ounsworth=[e-mail]>>;
> [e-mail]<mailto:[e-mail]>
> Cc: Paul van Brouwershaven <[e-mail]<mailto:[e-mail]>>
> Subject: Re: [Acme] [EXTERNAL] New Version Notification for draft-
> vanbrouwershaven-acme-auto-discovery-00.txt
>
> Some REALLY quick comments from a brief read:
>
> First, I think this is pretty clearly standards track, especially since I expect the
> authors are willing to work together with the IETF community and respond to
> feedback, and it includes normative requirements that are intended to be
> used with a major ecosystem, the WebPKI.
>
> 3.1.1. recommend clarifying the extent to which case matters.  How should
> "TRUE" or "True" be handled?
>
> 4-5. This is WAY in the weeds, and possibly should just be ignored, but there's
> actually no requirement that the CA is able to host content at the domain
> specified in the CAA tag.  At a minimum, they're only required to have
> permission from the domain owner (RFC 8659, first paragraph, item 2, second
> clause).  This might actually even happen due to acquisitions.  In such
> situations, a CA might actually be unable to host content on a .well-known
> URL for a tag it uses.
>
> I don't think 8.4.1/2 is in scope or makes the document better.  There are a
> wide variety of contractual solutions here, and how a user agrees to a
> particular CA's terms of service is not a relevant topic for IETF.
>
> -Tim
>
> > -----Original Message-----
> > From: Acme <[e-mail]<mailto:[e-mail]>> On Behalf Of Mike Ounsworth
> > Sent: Thursday, July 6, 2023 10:54 AM
> > To: [e-mail]<mailto:[e-mail]>
> > Cc: Paul van Brouwershaven <[e-mail]<mailto:[e-mail]>>
> > Subject: [Acme] FW: [EXTERNAL] New Version Notification for draft-
> > vanbrouwershaven-acme-auto-discovery-00.txt
> >
> > 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: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
> > Sent: Thursday, July 6, 2023 9:39 AM
> > To: Mike Ounsworth <[e-mail]<mailto:[e-mail]>>; Paul van
> > Brouwershaven <[e-mail]<mailto:[e-mail]>>
> > 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-__;!!FJ-Y8qCqXTj2!YiOqUhneydT1UxAan18BJQISEVf09TG69JKkNp5s_Vnr4Csm8QG788nMci3vob2EJesLVZb32pi-ePmpsgadKWsHNQbnYMpK1C_d$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-vanbrouwershaven-acme-__;!!FJ-Y8qCqXTj2!YiOqUhneydT1UxAan18BJQISEVf09TG69JKkNp5s_Vnr4Csm8QG788nMci3vob2EJesLVZb32pi-ePmpsgadKWsHNQbnYMpK1C_d$>
> > auto-discovery-00.txt
> > Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-__;!!FJ-Y8qCqXTj2!YiOqUhneydT1UxAan18BJQISEVf09TG69JKkNp5s_Vnr4Csm8QG788nMci3vob2EJesLVZb32pi-ePmpsgadKWsHNQbnYHCjiNIC$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-__;!!FJ-Y8qCqXTj2!YiOqUhneydT1UxAan18BJQISEVf09TG69JKkNp5s_Vnr4Csm8QG788nMci3vob2EJesLVZb32pi-ePmpsgadKWsHNQbnYHCjiNIC$>
> > auto-discovery/
> > Html:           https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-vanbrouwershaven-acme-__;!!FJ-Y8qCqXTj2!YiOqUhneydT1UxAan18BJQISEVf09TG69JKkNp5s_Vnr4Csm8QG788nMci3vob2EJesLVZb32pi-ePmpsgadKWsHNQbnYMpK1C_d$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-vanbrouwershaven-acme-__;!!FJ-Y8qCqXTj2!YiOqUhneydT1UxAan18BJQISEVf09TG69JKkNp5s_Vnr4Csm8QG788nMci3vob2EJesLVZb32pi-ePmpsgadKWsHNQbnYMpK1C_d$>
> > auto-discovery-00.html
> > Htmlized:    https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-vanbrouwershaven-__;!!FJ-Y8qCqXTj2!YiOqUhneydT1UxAan18BJQISEVf09TG69JKkNp5s_Vnr4Csm8QG788nMci3vob2EJesLVZb32pi-ePmpsgadKWsHNQbnYDiIankS$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-vanbrouwershaven-__;!!FJ-Y8qCqXTj2!YiOqUhneydT1UxAan18BJQISEVf09TG69JKkNp5s_Vnr4Csm8QG788nMci3vob2EJesLVZb32pi-ePmpsgadKWsHNQbnYDiIankS$>
> > acme-auto-discovery
> >
> >
> > 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
> > [e-mail]<mailto:[e-mail]>
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!YiOqUhneydT1UxAan18BJQISEVf09TG69JKkNp5s_Vnr4Csm8QG788nMci3vob2EJesLVZb32pi-ePmpsgadKWsHNQbnYC0DZKw9$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!YiOqUhneydT1UxAan18BJQISEVf09TG69JKkNp5s_Vnr4Csm8QG788nMci3vob2EJesLVZb32pi-ePmpsgadKWsHNQbnYC0DZKw9$>
>
> _______________________________________________
> Acme mailing list
> [e-mail]<mailto:[e-mail]>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!YiOqUhneydT1UxAan18BJQISEVf09TG69JKkNp5s_Vnr4Csm8QG788nMci3vob2EJesLVZb32pi-ePmpsgadKWsHNQbnYC0DZKw9$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!YiOqUhneydT1UxAan18BJQISEVf09TG69JKkNp5s_Vnr4Csm8QG788nMci3vob2EJesLVZb32pi-ePmpsgadKWsHNQbnYC0DZKw9$>
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.