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” 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]> > 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’. > > 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]> on behalf of Peter Bowen via > Public <[email protected]> > Reply-To: Peter Bowen <[email protected]>, CA/Browser Forum Public Discussion > List <[email protected]> > Date: Monday, July 17, 2017 at 6:48 PM > To: Kirk Hall <[email protected]> > Cc: CA/Browser Forum Public Discussion List <[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] > https://cabforum.org/mailman/listinfo/public
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
