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]]
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
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
