[cabfpub] [EXTERNAL]Re: Problems with Ballot 202
Adriano Santoni
adriano.santoni at staff.aruba.it
Wed Jul 19 22:19:03 MST 2017
To me too.
Il 19/07/2017 23:10, Ben Wilson ha scritto:
>
> Looks good to me.
>
> *Ben Wilson, JD, CISA, CISSP*
>
> VP Compliance
>
> +1 801 701 9678
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of
> *Peter Bowen via Public
> *Sent:* Wednesday, July 19, 2017 12:07 PM
> *To:* Adriano Santoni <adriano.santoni at staff.aruba.it>; CA/Browser
> Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [cabfpub] [EXTERNAL]Re: Problems with Ballot 202
>
> Adriano,
>
> An earlier draft of this did call out the specific characters, but the
> feedback from Kirk was that adding the technical detail caused it to
> have “no meaning”.
>
> (https://cabforum.org/pipermail/public/2017-June/011361.html)
>
> Merging all the recent suggestions, we get something like:
>
> A string starting with "*." (U+002A ASTERISK, U+002E FULL STOP)
> immediately followed by a Fully-Qualified Domain Name.
>
>
>
> This clarifies that "⁎.” is not acceptable.
>
> What do people think?
>
> Thanks,
>
> Peter
>
> On Jul 19, 2017, at 8:09 AM, Adriano Santoni via Public
> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>
> 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> <mailto:pzb at amzn.com>
> *Date:*Tuesday, July 18, 2017 at 7:01 PM
> *To:*Wayne Thayer<wthayer at godaddy.com>
> <mailto:wthayer at godaddy.com>, CA/Browser Forum Public
> Discussion List<public at cabforum.org> <mailto: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 <mailto:Public at cabforum.org>
>
> https://cabforum.org/mailman/listinfo/public
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170720/d0b6dc9f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 6109 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170720/d0b6dc9f/attachment-0001.jpg>
-------------- 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/20170720/d0b6dc9f/attachment-0001.p7s>
More information about the Public
mailing list