Re: [Acme] Indicating scope in DNS validation label

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>
>