[cabfpub] [EXTERNAL]Re: Problems with Ballot 202
Adriano Santoni
adriano.santoni at staff.aruba.it
Wed Jul 19 08:09:01 MST 2017
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 <pzb at amzn.com>
> *Date: *Tuesday, July 18, 2017 at 7:01 PM
> *To: *Wayne Thayer <wthayer at godaddy.com>, CA/Browser Forum Public
> Discussion List <public at cabforum.org>
> *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
> <public at cabforum.org <mailto:public at cabforum.org>> 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 <public-bounces at cabforum.org
> <mailto:public-bounces at cabforum.org>> on behalf of Peter Bowen via
> Public <public at cabforum.org <mailto:public at cabforum.org>>
> *Reply-To: *Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>>,
> CA/Browser Forum Public Discussion List <public at cabforum.org
> <mailto:public at cabforum.org>>
> *Date: *Monday, July 17, 2017 at 6:48 PM
> *To: *Kirk Hall <Kirk.Hall at entrustdatacard.com
> <mailto:Kirk.Hall at entrustdatacard.com>>
> *Cc: *CA/Browser Forum Public Discussion List <public at cabforum.org
> <mailto:public at cabforum.org>>
> *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
> <Kirk.Hall at entrustdatacard.com
> <mailto:Kirk.Hall at entrustdatacard.com>> 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:pzb at amzn.com]
> *Sent:*Monday, July 17, 2017 4:56 PM
> *To:*Kirk Hall <Kirk.Hall at entrustdatacard.com
> <mailto:Kirk.Hall at entrustdatacard.com>>; CA/Browser Forum
> Public Discussion List <public at cabforum.org
> <mailto:public at cabforum.org>>
> *Subject:*[EXTERNAL]Re: [cabfpub] Problems with Ballot 202
>
> On Jul 17, 2017, at 3:28 PM, Kirk Hall via Public
> <public at cabforum.org <mailto:public at cabforum.org>> 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 be
> subordinate 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
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170719/8f1315bd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4025 bytes
Desc: Firma crittografica S/MIME
URL: <http://cabforum.org/pipermail/public/attachments/20170719/8f1315bd/attachment-0001.p7s>
More information about the Public
mailing list