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]] Sent: Monday, July 17, 2017 4:56 PM To: Kirk Hall <[email protected]>; CA/Browser Forum Public Discussion List <[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 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
