Substantive comments:
Reading through the history of this document, I see that it started out as
simply specifying server behavior to allow particular kinds of
authorization re-use, and has now grown to an API extension that adds new
fields to various request and response objects. My comments here may seem
like circling back to square one, and for that I apologize. Fresh eyes, and
all that.
Overall, this document reads to me as "RFC 8555 didn't handle wildcards
well; this is essentially how wildcard should have been specified in the
first place". I certainly agree with that stance -- in hindsight, it should
have been possible to do wildcard preauthorization (e.g. by setting a
"wildcard" boolean flag in the preauthorization request). It is unfortunate
that the wording of RFC 8555 seems to preclude simply extending the
existing wildcard mechanism.
That said, it is not clear to me that this draft enables truly novel
behavior. I believe that the desired result -- authorization for a single
parent domain, but issuance only for specific subdomains -- is possible
using current mechanisms:
1) Create a NewOrder for *.example.com
2) Complete the necessary challenge to prove control over example.com
3) Don't bother finalizing the order
4) Create a NewOrder for foo.example.com
5) The ACME Server notices the wildcard authorization for example.com,
attaches that to the new order, and sets the order's state to "valid"
6) Finalize the order, receive a certificate for foo.example.com
Yes, this is messy. It's absolutely just using the newOrder flow as an
end-run around the fact that you can't use newAuthz to generate wildcard
authorizations. But I believe it is fully possible today, with no
extensions or modifications to the ACME protocol. The only changes
necessary to enable this flow would be in internal server policy, creating
a willingness to re-use pre-existing wildcard authorizations with orders
for specific subdomains.
I freely admit that I am less familiar with the RFC process than many here,
so the following proposal may be completely infeasible. But would it be
possible for this draft to effectively become "let's extend newAuthz
requests with a wildcard field"? Then the pre-authorization flow outlined
in the current draft could be used rather than the hack "create but don't
finalize an order" flow I outlined above. Or would the act of contradicting
8555's restrictions on the wildcard field be too big of an issue?
Minor comments:
* In Section 2 Terminology, it would be good to make clear that the CA/BF
BRs are constantly changing, and that the definitions copied into this
document are from a particular version (in the current draft, v1.7.1).
* In the same section, several of these definitions have been updated since
v1.7.1, including ADN now being defined in terms of FQDN rather than in
terms of Domain Names.
* Section 3, Step 4 references "the specified challenge", while none of the
preceding steps identify where that challenge comes from (the authorization
object). Obviously this is not a major comment, as this section is not
normative, but it may cause some confusion for readers less familiar with
ACME.
* In Section 3, the references to various sections of RFC 8555 have
inconsistent capitalization, and one ("Sections 8.3") is pluralized.
* In the HTMLized version of the draft, those section references attempt to
link to sections of this document, rather than linking to RFC 8555.
* The reference to Section 7.1.4 spells out un-capitalized "fully qualified
domain name", while the capitalized version of that term is defined in
Section 2.
* It's not clear to me that Section 4.1 is necessary at all: as the draft
states in Section 7.1, different ACME servers (especially those operating
outside of the CA/BF BRs) may have different server policies. The current
restriction that DNS-01 MUST be used for wildcard validation comes from the
BRs, not from 8555, so it seems inconsistent to mandate DNS-01 in this
document.
* If it is retained, then it seems better to define Section 4.1 in terms of
negatives: challenges HTTP-01 and TLS-ALPN-01 MUST NOT be used. This leaves
the door open for future challenge types which have equivalent security
properties to DNS-01 to be used for this case.
* Finally, in Appendix A, the CA/BF BRs no longer allow Agreed-Upon Change
to Website validations for Wildcard Domain Names.
Thanks,
Aaron
On Tue, Aug 31, 2021 at 8:37 AM Cooley, Dorothy E <decoole=
40nsa....@dmarc.ietf.org> wrote:
> This is a working group call for adoption of:
> draft-friel-acme-subdomains-05. We have had presentations of this work at
> the past couple of IETF meetings (back to when we still met in person -
> sigh).
>
> Please review the draft and post your comments to the list by Wednesday, 15
> September 2021.
>
> Thanks,
> Deb and Yoav
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
