(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]> *Date: *Tuesday, July 18, 2017 at 7:01 PM*To: *Wayne Thayer <[email protected]>, CA/Browser Forum Public Discussion List <[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.2I 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.2I’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]] *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 – “Inmail.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 forserver1.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 besubordinate to a single node in the Domain Name System? Would that requireserver1.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 exampleserver1.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 exampleserver1.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 obtainauthorizationfor 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 ofrequestedDomain 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 _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
