Adriano, An earlier draft of this did call out the specific characters, but the feedback from Kirk was that adding the technical detail caused it to have “no meaning”.
(https://cabforum.org/pipermail/public/2017-June/011361.html <https://cabforum.org/pipermail/public/2017-June/011361.html>) Merging all the recent suggestions, we get something like: A string starting with "*." (U+002A ASTERISK, U+002E FULL STOP) immediately followed by a Fully-Qualified Domain Name. This clarifies that "⁎．” is not acceptable. What do people think? Thanks, Peter > On Jul 19, 2017, at 8:09 AM, Adriano Santoni via Public <[email protected]> > wrote: > > How about further specifying that the string '*' (that a Wildcard Domain Name > starts with) is made up of one (1) ASCII character with code 0x2A ? > > (that is, the Unicode "low asterisk" and "asterisk above" characters are not > acceptable there :) ) > > If we are going to clarify things, better be super-clear! > > Adriano > > > Il 19/07/2017 04:15, Wayne Thayer via Public ha scritto: >> Peter – I agree. Adding “starting with” to the new definition is enough to >> resolve this concern. >> >> Thanks, >> >> Wayne >> From: Peter Bowen <[email protected]> <mailto:[email protected]> >> Date: Tuesday, July 18, 2017 at 7:01 PM >> To: Wayne Thayer <[email protected]> <mailto:[email protected]>, >> CA/Browser Forum Public Discussion List <[email protected]> >> <mailto:[email protected]> >> Subject: Re: [cabfpub] [EXTERNAL]Re: Problems with Ballot 202 >> >> Wayne, >> >> Based on Geoff’s recommendation, Ben, Ryan, and I were going to update the >> definitions as follows: >> >> Domain Label: A label of a domain name, as defined in RFC 5890 section 2.2; >> for example, the domain name "www.example.com <http://www.example.com/>" is >> composed of three labels: "www", "example", and "com". >> Domain Name: A string which is a ‘domain name’, as defined in RFC 5890 >> section 2.2, with labels separated by dots, or a Wildcard Domain Name. For >> example “www.example.com <http://www.example.com/>” and “*.example.net >> <http://example.net/>” are domain names. >> Wildcard Domain Name: The string ‘*.’ followed by a ‘domain name’ with >> labels separated by dots, as defined in RFC 5890 section 2.2 >> >> I think you make a good point. How does this work for Wildcard Domain Name? >> >> Wildcard Domain Name: A string starting with ‘*.’ followed by a ‘domain >> name’ with labels separated by dots, as defined in RFC 5890 section 2.2 >> >> I’m not quite sure how to fit “left” into the definition proposed by Geoff, >> but I think “starting with” should make it clear that “www.*.example.com >> <http://example.com/>” is not acceptable, as it does not start with “*.”. >> >> Do either of these definitions of Wildcard Domain Name work for you? >> >> Thanks, >> Peter >> >> >> On Jul 18, 2017, at 6:49 PM, Wayne Thayer via Public <[email protected] >> <mailto:[email protected]>> wrote: >> >> Peter, >> >> Would you consider adding ‘in the left most Domain Label’ to the definition >> of Wildcard Domain Name? While the definition of Authorization Domain Name >> contradicts this, it was pointed out to me that someone unfamiliar with the >> history might misinterpret the new definition to allow something like >> ‘www.*.example.com <http://example.com/>’. >> >> Wildcard Domain Name: A Domain Name consisting of a single asterisk >> character ("*") [in the left most Domain Label] followed by a single full >> stop character (".") followed by a Fully-Qualified Domain Name. >> >> Thanks, >> >> Wayne >> From: Public <[email protected] >> <mailto:[email protected]>> on behalf of Peter Bowen via Public >> <[email protected] <mailto:[email protected]>> >> Reply-To: Peter Bowen <[email protected] <mailto:[email protected]>>, CA/Browser >> Forum Public Discussion List <[email protected] >> <mailto:[email protected]>> >> Date: Monday, July 17, 2017 at 6:48 PM >> To: Kirk Hall <[email protected] >> <mailto:[email protected]>> >> Cc: CA/Browser Forum Public Discussion List <[email protected] >> <mailto:[email protected]>> >> Subject: Re: [cabfpub] [EXTERNAL]Re: Problems with Ballot 202 >> >> Kirk, >> >> The only new definitions in ballot 202 are “Domain Label” and “Wildcard >> Domain Name”. >> >> “Domain Label” was defined so we could define the characters we wanted to >> allow underscores in a label. >> >> “Wildcard Domain Name” was defined to help make it very clear that these are >> allowed. One of the concerns that has been heard multiple times is that it >> is not clear if “Fully-Qualified Domain Name” includes names with wildcards. >> This ballot resolves this ambiguity by clearly stating that “Domain Name” >> means both wildcard and fully-qualified domain names. >> >> Geoff and my responses crossed. Geoff suggested: >> Domain Label: A label of a domain name, as defined in RFC 1034. >> Domain Name: A string which is a ‘domain name’ as defined in RFC 1034 with >> labels separated by dots, or a Wildcard Domain Name. >> Domain Namespace (of a domain): All domains which are subdomains of the >> referenced domain, as described in RFC 1034. >> Fully Qualified Domain Name: A domain name interpreted relative to the root. >> The Fully Qualified Domain Names used in this document do not end with a >> period. >> Wildcard Domain Name: The string ‘*.’ followed by a ‘domain name’ with >> labels separated by dots as defined in RFC 1034. >> >> I would suggest the following as slight updates, in order to support >> Internationalized Domain Names: >> >> Domain Label: A label of a domain name, as defined in RFC 5890 section 2.2; >> for example, the domain name "www.example.com <http://www.example.com/>" is >> composed of three labels: "www", "example", and "com". >> Domain Name: A string which is a ‘domain name’, as defined in RFC 5890 >> section 2.2, with labels separated by dots, or a Wildcard Domain Name. For >> example “www.example.com <http://www.example.com/>” and “*.example.net >> <http://example.net/>” are domain names. >> Wildcard Domain Name: The string ‘*.’ followed by a ‘domain name’ with >> labels separated by dots, as defined in RFC 5890 section 2.2 >> >> I suggest we hold any updates for Fully Qualified Domain Name and Domain >> Namespace for ballot 190 and limit the changes to Authorization Domain Name >> and Base Domain Name in this ballot to only remove “Fully Qualified”. >> >> Do you feel you could support this ballot if it had these definitions >> instead? >> >> Thanks, >> Peter >> >> >> >> On Jul 17, 2017, at 5:01 PM, Kirk Hall <[email protected] >> <mailto:[email protected]>> wrote: >> >> I did know that some of the definitions were unchanged from the past – but >> when you look at the body of definitions in 202 taken together (including >> the new ones that rely on the old, unchanged, confusing ones) they seem open >> to multiple interpretations and frankly get so complex that it’s hard to >> describe the rules to another person – not good from a standpoint of uniform >> applications and compliance. >> >> I want to think a bit more about the simplified definitions just posted by >> Geoff, but I much prefer that kind of approach – short, simple sentences >> that mostly stand on their own, and make reference to RFCs where appropriate >> – to a series of “nesting”, ever widening definitions where each depends on >> the other. >> >> From: Peter Bowen [mailto:[email protected] <mailto:[email protected]>] >> Sent: Monday, July 17, 2017 4:56 PM >> To: Kirk Hall <[email protected] >> <mailto:[email protected]>>; CA/Browser Forum Public Discussion >> List <[email protected] <mailto:[email protected]>> >> Subject: [EXTERNAL]Re: [cabfpub] Problems with Ballot 202 >> >> >> On Jul 17, 2017, at 3:28 PM, Kirk Hall via Public <[email protected] >> <mailto:[email protected]>> wrote: >> >> Here are the difficulties I’m having understanding the new (very complex) >> Ballot 202 definitions shown below. I can’t imagine explaining this to our >> engineering and vetting teams, and I think people will make mistakes. >> Assuming these definitions parse out, at a bare minimum we should give easy >> examples for each definition. These are arranged in a logical order, not >> alphabetically. >> >> Kirk, >> >> Thank you for the feedback. I’ve added comments inline, but I one >> overarching note is that many of the definitions you list are unchanged in >> this ballot. In several of the other cases the portion of the definition >> that seems to be causing concern is from the current BRs. I tried hard to >> avoid changing definitions and minimize changes to existing ones. >> >> Also – we won’t really know if these definitions are good and useful unless >> we compare them to the new text of BR 3.2.2.4, which defines how we are to >> do validation. Last week when we pulled back Ballot 190 it was to allow >> Peter time to tune up the definition of Authorized Domain Name in Ballot 190 >> the context of BR 3.2.2.4 (so we could remove the Notes that had been added >> to Ballot 190), but to my surprise, the new definitions have shown up in >> Ballot 202 instead – I think that’s a mistake. >> >> This ballot has been in discussion for months. As noted below, terms like >> “Authorization Domain Name” are not included in this ballot; the text quoted >> is from the current BRs and is unmodified. >> >> >> >> >> As recently as July 4, Ben said this Ballot 202 would cover the following >> four subjects: (1) adds dnQualifier as an allowed attribute for all >> certificate types (including DV), (2) adds ASN.1 info on the EV jurisdiction >> attribute types, (3) adds language to the EV guidelines to clarify that CAs >> may limit their aggregate liabilities, (4) allows underscores in domain >> names and clarifies what can go in common names. Why did the authors decide >> to include changes to crucial definitions applicable to domain validation at >> the same time, but not allow discussion in a pre-ballot? >> >> At this point, Entrust is inclined to vote no – not because we necessarily >> oppose the ballot’s aims, but because there are some questions and no time >> to resolve them before voting starts. >> >> This ballot only covers (4). I would ask that you please double check the >> current BRs to confirm that many of the definitions are already present and >> are not introduced in the ballot. >> >> >> >> >> Here are our concerns about the new definitions. Again, it would be nice to >> have more time to discuss, and not start voting on Wednesday. >> >> >> >> Domain Label: An individual component of a Domain Name. >> >> [What does this mean – “component”? Is a period a Domain Label? A couple >> of letters? This seems circular with the Domain Name definition below. Did >> you mean “node” and not “component”? At a minimum, give examples – “In >> mail.example.com <http://mail.example.com/>, the components are “mail”, >> “example”, and “com”. The period “.” is not a component, nor are characters >> that are less than a full node such as “exa”.] >> >> This is the terminology from RFC 5890 section 2.2: DNS-Related Terminology. >> It is the characters between periods; the period itself is not included in >> the component. See https://tools.ietf.org/html/rfc5890#section-2.2 >> <https://tools.ietf.org/html/rfc5890#section-2.2> >> >> >> Domain Name: A set of one or more Domain Labels, each separated by a single >> full stop character ("."). Fully-Qualified Domain Names and Wildcard Domain >> Names are Domain Names. >> >> [Again, somewhat circular – Domain Label says it’s a component of a Domain >> Name, and Domain Name says it’s made up of Domain Labels… never fully >> defined. >> >> Also, saying that FQDNs and Wildcard DNs are DNs might work, but need to >> study the rest of the text. >> >> Also, this definition does not require a domain name to end in a gTLD or >> ccTLD, so server1.mail qualifies as a Domain Name? Might cause trouble with >> other definitions.] >> >> >> You are correct, “server1.mail” is a Domain Name. I’m open to refining this >> definition to avoid the circular terminology. >> >> >> >> >> Domain Namespace: The set of all possible Domain Names that are subordinate >> to a single node in the Domain Name System. >> >> [Unclear – “subordinate to a single node in the Domain Name System”. So for >> server1.mail.example.com <http://server1.mail.example.com/>, is “com” part >> of the Domain Namespace, or only server1.mail.example? Also, you say in the >> definition of Domain Name that an FQDN is a Domain Name, so under the >> Definition of Domain Namespace, is the entire FQDN (including .com) meant to >> be subordinate to a single node in the Domain Name System? Would that >> require server1.mail.example.com. <http://server1.mail.example.com.com/>com >> <http://server1.mail.example.com.com/>, with the second “.com” being the >> single node? >> >> In the example server1.mail.example.com <http://server1.mail.example.com/>, >> “server1” and “mail” are subordinate to “example”, so does that mean >> “server1.mail” is a Domain Namespace that is subordinate to the node >> “example”? >> >> Also – we never use Domain Namespace in the rest of the definitions. Where >> is it used, and does this definition make sense there?] >> >> This definition is from the current BRs and is unmodified in this ballot. >> >> >> >> >> Fully-Qualified Domain Name: A Domain Name that includes the Domain Labels >> of all superior nodes in the Internet Domain Name System. >> >> [Again unclear. The reference to “all superior nodes” begs the question – >> superior to what? A gTLD or ccTLD? In the example server1.mail.example.com >> <http://server1.mail.example.com/>, is “server1.mail.example” itself an >> FQDN, because it includes all “superior nodes” to .com? Or did you mean to >> include .com as well to make it an FQDN?] >> >> This definition is from the current BRs and is unmodified in this ballot. >> >> >> >> >> >> Wildcard Domain Name: A Domain Name consisting of a single asterisk >> character ("*") followed by a single full stop character (".") followed by a >> Fully-Qualified Domain Name. >> >> [This is confusing because it starts with Domain Name, then talks about an >> FQDN – the “*” itself doesn’t turn a Domain Name into an FQDN so why are you >> using both terms? ] >> >> Yes, a Wildcard Domain Name is a type of Domain Name. It is made up of “*.” >> + a FQDN. For example “*.blogspot.com <http://blogspot.com/>” or >> “*.signin.aws.amazon.com <http://signin.aws.amazon.com/>" >> >> Base Domain Name: The portion of an applied-for Domain Name that is the >> first domain name node left of a registry-controlled or public suffix plus >> the registry-controlled or public suffix (e.g. "example.co.uk >> <http://example.co.uk/>" or "example.com <http://example.com/>"). >> For Domain Names where the right-most domain name node is a gTLD having >> ICANN Specification 13 in its registry agreement, the gTLD itself may be >> used as the Base Domain Name. >> >> [Ballot 190 stripped out “requested” in front of FQDN wherever it existed, >> as it seems to get into a CA’s business processes – what the customer >> requests, as opposed to a domain the CA decides to validate - and adds >> nothing but confusion. I recall discussion that used the word “requested” >> to limit what a CA could do – e.g., using “requested” might limit CA so they >> could only verify an FQDN the customer “requested” (server1.mail.example.com >> <http://server1.mail.example.com/>) and not the FQDN the CA wanted to verify >> to fill the customer’s order (example.com <http://example.com/>). Now we >> see the words “applied for” – take it out, it’s not relevant and could >> restrict what CAs can do.] >> >> This definition is from the current BRs and is unmodified in this ballot. >> We can change it in Ballot 190, as you suggest, but I don’t think modifying >> it in this ballot makes sense. >> >> >> >> >> >> Authorization Domain Name: The Domain Name used to obtain authorization for >> certificate issuance for a given Domain Name. >> The CA may use the FQDN returned from a DNS CNAME lookup as the Domain Name >> for the purposes of domain validation. >> If the Domain Name is a Wildcard Domain Name, then the CA MUST remove “*.” >> from the left most portion of requestedDomain Name. >> The CA may prune zero or more labels from left to right until encountering a >> Base Domain Name and may use any one of the intermediate values for the >> purpose of domain validation. >> >> [First, the word “authorization” does not seem correct – validation (used in >> BR 3.2.2.4) might make more sense. A simple WhoIs lookup by itself doesn’t >> seem like authorization, only validation of a request. >> >> The first sentence is somewhat circular by using Domain Name twice in one >> sentence. The Domain Name used… for a given Domain Name. ?? >> >> Assuming that server1.mail is a Domain Name, can it be an Authorization >> Domain Name for something? >> >> The second sentence again goes from FQDN to Domain Name – not clear why. >> >> The third sentence again talks about the “requested Domain Name” – requested >> by the customer? Please remove “requested”. Also, why are you saying the * >> must be removed – do you mean to add something at the end of the sentence >> like “before the validation is obtained”, or “before a certificate is >> issued”, or..? I don’t understand the purpose of this sentence in this >> definition. >> >> The final sentence is unclear as to what domain name is being pruned – the >> Authorization Domain Name? (The sentence is in that definition.) Or is the >> requested domain name being pruned (probably). This might be one place >> where it makes sense to use “requested” simply to show a CA can choose to >> prune and then validate what’s left. But why is this rule in the definition >> of Authorization Domain Name? Shouldn’t it be in BR 3.2.2.4 itself?] >> >> Authorization Domain Name is already defined in the current BRs. The >> current definition in the BRs is: >> >> "The Domain Name used to obtain authorization for certificate issuance for a >> given FQDN. The CA may use the FQDN returned from a DNS CNAME lookup as the >> FQDN for the purposes of domain validation. If the FQDN contains a wildcard >> character, then the CA MUST remove all wildcard labels from the left most >> portion of requested FQDN. The CA may prune zero or more labels from left to >> right until encountering a Base Domain Name and may use any one of the >> intermediate values for the purpose of domain validation." >> >> The term “authorization” is in the current BRs and is unmodified. The term >> “requested” is in the current BRs and is unmodified. The third sentence is >> almost identical to the existing language but says “*.” instead of “wildcard >> labels”. The last sentence is unmodified from the current BRs. >> >> I appreciate that some of the existing language is could use improvement, >> but the objective of Ballot 202 is not to clean up every issue in the BRs. >> We still have Ballot 190 to go and we can have further changes in future >> ballots. I tried hard to keep the scope of Ballot 202 constrained, and I >> hope the above explanations help demonstrate the constrained nature. >> >> Thanks, >> Peter >> >> >> >> _______________________________________________ >> Public mailing list >> [email protected] <mailto:[email protected]> >> https://cabforum.org/mailman/listinfo/public >> <https://cabforum.org/mailman/listinfo/public> >> >> >> >> _______________________________________________ >> Public mailing list >> [email protected] <mailto:[email protected]> >> https://cabforum.org/mailman/listinfo/public >> <https://cabforum.org/mailman/listinfo/public> > > _______________________________________________ > Public mailing list > [email protected] <mailto:[email protected]> > https://cabforum.org/mailman/listinfo/public > <https://cabforum.org/mailman/listinfo/public>
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
