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 <[email protected]> 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 [email protected]https://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
