On Thu, Apr 7, 2022 at 10:36 AM Peter Thomassen <pe...@desec.io> wrote:
> Now, should it be possible for the DNS admin of eu.org to request a > certificate for example.de.eu.org (or subdomains thereof) through the > mechanism described in the draft, although there is a public suffix in > between? (I don't think so.) > > If this should be prevented, the corresponding public suffix check needs > to be mandatory. (However, I'm not sure if it needs to be in this draft, or > in the CA/B guidelines.) Given that public suffices are an unfortunate fiction invented by browsers, it'd be doubly unfortunate to codify it in an IETF doc. That said, it is already an existing requirement of the CA/Browser Forum Baseline Requirements (for TLS; no comments made re: S/MIME), such that the authorization domain name (aka the prefix) used to verify a domain requires termination of tree climbing upon encountering the first public suffix. So, in practice, a CA using this spec and conforming to the CA/Browser Forum BRs will refuse to issue such a certificate. However, this is a convenient fiction in separation: the DNS admin of eu.org can, at any time, remove de.eu.org from the public suffix list, as they are the parent authority. In that sense, they have the full technical capability to cause issuance. The requirement of public suffix separation is _primarily_ a holdover from when every validation method was treated equally by CAs (e.g. the use of HTTP to approve a wildcard domain, without demonstrating DNS-based control). With the new separations that restrict such broadening, it is conceivable to imagine that the requirement to "stop" at the public suffix is removed from the Baseline Requirements, in recognition that the parent domain fundamentally has more power than the child labels.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
