Re: [Acme] Indicating scope in DNS validation label

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://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. 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://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques>
> 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) or to a
> wildcard (*.example.com).  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`" applies only to the specific host
> name of "example.com" and not to anything underneath it.
> * "`_acme-wildcard-challenge.example.com`" applies to all host names at
> the level immediately underneath "example.com". For example, it would
> apply to "foo.example.com" but not "example.com" nor "quux.bar.example.com".
> In the ACME context this would be for *.example.com.
>
> Pull request for this is here:
>
> <http://goog_1991325217>
>
> https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/90/files
>
> 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, *.example.com, *.*.example.com, *.{...}.example.com, etc,
> but this isn't something specified by ACME due to the semantics of wilcards
> X509 certs.
>
>     Erik
>
>
> _______________________________________________
> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>