Re: [Acme] Indicating scope in DNS validation label

CAA can help, but agreed that it's a blunt tool and only part of the
ecosystem.

it would be preferable to differentiate within the DV record being added to
the zone,
especially as there could be cases where both an exact cert and a wildcard
cert may
be desirable for a zone.  The DNS operator of the zone (or any automation
framework that authorizes access) which is adding the record should
preferably
be able to distinguish what name(s) is/are being validated.  Including this
in the ACME label name would give zone operators better control.

This would enable CA operators to give better controls to their customers
so would not be in conflict with the MAY in the BR.  (Although if we had a
better
ecosystem here it might make sense to tighten the BR at some point.)
In the interim, CAA along with such a differentiation could be used
by zone operators to limit allowed CAs to only those who support this
differentiation feature, which is the scope/intent of CAA.

     Erik

On Wed, Oct 4, 2023 at 4:46 AM Seo Suchan <tjtncks@gmail.com> wrote:

> while it's blunt tool current CAA issuewild record with whiltelist
> accounturi would able to do that, as issuewild overides issue.
> 2023-10-04 오후 4:59에 Q Misell 이(가) 쓴 글:
>
> Regardless of the inclusion of that paragraph in the BR I still think it
> would be worthwhile to be able to limit a DNS based validation to not
> issuing wildcards, should an admin so desire.
> ------------------------------
>
> 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://e.as207960.net/w4bdyj/Tuxjr0hL>, LEI 875500FXNCJPAPF3PD10. ICO
> register №: ZA782876 <https://e.as207960.net/w4bdyj/w06IBwih>. 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 Tue, 3 Oct 2023 at 20:04, Seo Suchan <tjtncks@gmail.com> wrote:
>
>> Because CA/B baseline DNS Change auth have this paragraph, I think DNS
>> admin should consider any DNS record there to be valid for wildcard.
>>
>> Note: Once the FQDN has been validated using this method, the CA MAY also
>> issue Certificates for
>> other FQDNs that end with all the Domain Labels of the validated FQDN.
>> This method is suitable
>> for validating Wildcard Domain Names.
>>
>>
>> 2023-10-03 오후 10:31에 Erik Nygren 이(가) 쓴 글:
>>
>> Within draft-ietf-dnsop-domain-verification-techniques
>> <https://e.as207960.net/w4bdyj/KvYIoLDG> there is considerable
>> discussion about the risks associated with DNS DCV records (such as ACME
>> DNS-01) not being clear in the record about whether the scope applies to
>> just a single hostname (example.com
>> <https://e.as207960.net/w4bdyj/qLxR85iE>) or to a wildcard (*.example.com
>> <https://e.as207960.net/w4bdyj/tcl3DZPh>).  While DNS-01 has this within
>> the token, the DNS TXT record itself only includes a hash of the token
>> making this hard for a DNS admin to validate.
>>
>> We have a proposed change to use distinct labels for different scopes.
>> For example:
>>
>> * "`_acme-host-challenge.example.com
>> <https://e.as207960.net/w4bdyj/JpqJjdxE>`" applies only to the specific
>> host name of "example.com <https://e.as207960.net/w4bdyj/oHE7qkwz>" and
>> not to anything underneath it.
>> * "`_acme-wildcard-challenge.example.com
>> <https://e.as207960.net/w4bdyj/xVMcJdIL>`" applies to all host names at
>> the level immediately underneath "example.com
>> <https://e.as207960.net/w4bdyj/K9ajyGUJ>". For example, it would apply
>> to "foo.example.com <https://e.as207960.net/w4bdyj/t7IJuCyq>" but not "
>> example.com <https://e.as207960.net/w4bdyj/zyBITmRO>" nor "
>> quux.bar.example.com <https://e.as207960.net/w4bdyj/wvu0juZp>".  In the
>> ACME context this would be for *.example.com
>> <https://e.as207960.net/w4bdyj/oirLEOAx>.
>>
>> Pull request for this is here:
>>
>> <http://goog_1991325217>
>>
>> https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/90/files
>> <https://e.as207960.net/w4bdyj/awm4ssbi>
>>
>> What is the sense of the ACME WG on if this would make sense?  Roll-out
>> would presumably take quite some time so both would need to keep working.
>>
>> I'd suggest that it may make sense to incorporate as part of
>> draft-ietf-acme-dns-account-challenge since the roll-out for both would
>> likely follow a similar pattern.  In that case I'd proposed that we'd
>> replace the "-account" in that draft with a specification to use either
>> "-host" or "-wildcard" depending on scope.  (That might also mean expanding
>> the title of that draft.)
>>
>> There's also a scope of the domain and its subdomains, covering
>> example.com <https://e.as207960.net/w4bdyj/LVqv0vTq>, *.example.com
>> <https://e.as207960.net/w4bdyj/cV3n3pfP>, *.*.example.com
>> <https://e.as207960.net/w4bdyj/xHJHAQvD>, *.{...}.example.com
>> <https://e.as207960.net/w4bdyj/gnFjNtwj>, etc, but this isn't something
>> specified by ACME due to the semantics of wilcards X509 certs.
>>
>>     Erik
>>
>>
>> _______________________________________________
>>
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme <https://e.as207960.net/w4bdyj/eLTGHv1V>
>>
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>> <https://e.as207960.net/w4bdyj/cbz6pd9N>
>>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>