[cabfpub] Proposal for change of definition of Internal Server Name in the BRs

Ryan Sleevi sleevi at google.com
Wed Mar 12 23:56:14 UTC 2014


Is the addition to Section 11.1.4 necessary for this ballot?

I'm all for tightening the definition of Internal Name, but the additions
to Section 11.1.4 seem to reflect the discussion at the F2F about weakening
the current revocation requirement. That is, by stating "will be in
violation of these requirements, unless...", there's a material change in
language, because it's now *permitted* to not revoke, by demonstrating that
control.

As such, in it's current form, I think we'd have a hard time supporting it,
but I'd like to make sure I'm not missing something.


On Sun, Mar 9, 2014 at 1:01 PM, Ben Wilson <ben at digicert.com> wrote:

> Thanks, Moudrick.  Here is a draft ballot for people to take a look at.
>
>
>
> Ballot 112 - Replace Definition of "Internal Server Name" with "Internal
> Name"
>
>
>
>
>
> Ben Wilson of DigiCert made the following motion, and ____ from _______
> and _________ from __________ endorsed it.
>
>
>
> The current definition of Internal Server Name is ambiguous.  It reads, "A
> Server Name (which may or may not include an Unregistered Domain Name) that
> is not resolvable using the public DNS."  "Internal Server Name" is used
> four times in the Baseline Requirements--three times in Section 9.2.1
> (Subject Alternative Name Extension) and once in Section 11.1.4 (New gTLD
> Domains).  Those provisions set forth the program by which the CA/B Forum
> will sunset the issuance of Certificates with Internal Server Names, so it
> is of high importance that the terminology used be clear.
>
>
>
>
>
> Motion Begins
>
>
>
> 1. REPLACE the Definition of "Internal Server Name" in the Baseline
> Requirements by DELETING the current definition and INSERTING the following:
>
>
>
> Internal Server Name:  A string of characters (not an IP address) in a
> Common Name or Subject Alternative Name field of a Certificate that cannot
> be verified as globally unique within the public DNS at the time of
> certificate issuance because it does not end with a Top Level Domain
> registered in IANA’s Root Zone Database.
>
>
>
> 2.  REPLACE "Internal Server Name" with "Internal Name" throughout the
> Baseline Requirements, including in the table of Relevant Compliance Dates,
> Section 9.2.1, and Section 11.1.4.
>
>
>
> 3.  At the end of the first paragraph in Section 11.1.4, INSERT the
> following:
>
>
>
> "When a gTLD is delegated by inclusion in the IANA Root Zone Database, the
> Internal Name becomes a Domain Name, and at such time, a Certificate with
> such gTLD, which may have complied with these Requirements at  the time it
> was issued, will be in a violation of these Requirements, unless the CA has
> verified the Subscriber’s rights in the Domain Name.  The provisions below
> are intended to prevent such violation from happening."
>
>
>
>
>
> Motion Ends
>
>
>
> The review period for this ballot shall commence at 2200 UTC on Monday, 10
> March 2014, and will close at 2200 UTC on Monday, 17 March 2014. Unless the
> motion is withdrawn during the review period, the voting period will start
> immediately thereafter and will close at 2200 UTC on Monday, 24 March 2014.
> Votes must be cast by posting an on-list reply to this thread.
>
>
>
> A vote in favor of the motion must indicate a clear 'yes' in the response.
> A vote against must indicate a clear 'no' in the response. A vote to
> abstain must indicate a clear 'abstain' in the response. Unclear responses
> will not be counted. The latest vote received from any representative of a
> voting member before the close of the voting period will be counted. Voting
> members are listed here:  https://cabforum.org/members/
>
>
>
> In order for the motion to be adopted, two thirds or more of the votes
> cast by members in the CA category and greater than 50% of the votes cast
> by members in the browser category must be in favor. Also, at least six
> members must participate in the ballot, either by voting in favor, voting
> against, or abstaining.
>
>
>
>
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
> Behalf Of *Moudrick M. Dadashov
> *Sent:* Saturday, March 08, 2014 11:16 PM
> *To:* ben at digicert.com; kirk_hall at trendmicro.com; 'Ryan Sleevi'
>
> *Cc:* 'CABFPub'
> *Subject:* Re: [cabfpub] Proposal for change of definition of Internal
> Server Name in the BRs
>
>
>
> Yes, IMO Proposal 2 sounds more pragmatic than the other two.
>
> Thanks,
> M.D.
>
>
> On 3/9/2014 6:48 AM, Ben Wilson wrote:
>
> As noted in an earlier email, this is draft will become Ballot 112.
>
>
>
> A.         Replace all instances of “Internal Server Name” with “Internal
> Name”.
>
>
>
> B.         Replace the definition of Internal Name with one of the
> following:
>
>
>
> Proposal 1 - Internal Name:  A non-IP-Address Common Name or Subject
> Alternative Name not ending in a TLD registered in the Root Zone.
>
>
>
> Proposal 2 - Internal Name:  A string of characters (not an IP address)
> that is located in a Common Name or Subject Alternative Name field of a
> Certificate that is incapable of being verified as globally unique within
> the DNS at the time of certificate issuance because it does not end with a
> Top Level Domain registered in IANA’s Root Zone Database.
>
>
>
> Proposal 3 –  Internal Name:  A server name that is an Unregistered Domain
> Name.   Unregistered Domain Name:  A Domain Name that is not a Registered
> Domain Name.  Registered Domain Name:   A Domain Name not reserved by IANA
> and containing a TLD registered by IANA in the Root Zone Database.   For
> domains that end in a gTLD, the Domain Name MUST be registered with an
> ICANN-accredited Registrar that is authorized to register domains with the
> ICANN-assigned gTLD Registry Operator (or an Affiliate or subcontractor
> thereof engaged in providing Registry Services).  For domains that end in a
> country-code or sponsored TLD, the Domain Name MUST be registered with a
> duly-authorized entity recognized by the Sponsoring Organization of the
> appropriate ccTLD.  If a Domain Name contains a TLD that is not in the Root
> Zone Database, then it is considered to be an Internal Name.”
>
>
>
> (Note that under Proposal 3 we need to add “not reserved by IANA” because
> IANA has reserved second level domains containing the word “example”.)
>
>
>
> As you can see, I have changed how I think we ought to approach “Internal
> Server Name”.    I prefer Proposals 1 and 2 because I don’t like the idea
> of defining “Internal Server Name” by calling it an “Unregistered Domain
> Name” and then defining it as anything that isn’t registered.   (I also
> don’t like the idea of tying down our existing definition of “registrar,”
> which works quite well for our purposes, with another set of embedded
> sub-definitions concerning ICANN-approved registrars.)
>
>
>
> Proposal 2 seems to be more in line with the gist of the complaints about
> Internal Names (concern about the non-uniqueness of names and not just
> registration vs. non-registration).  While I’m open to discussion on what
> threats/concerns we’re trying to address, I took a brief look at the
> internal name’s white paper- https://cabforum.org/internal-names/.   I’m
> also open to suggestions on rewording any of these proposals.
>
>
>
> We could also additionally mention in section 11.1.4 something like, “For
> clarification, a new gTLD previously “under consideration by ICANN” is no
> longer considered an “Internal Name” once it has been delegated by
> inclusion in the Root Zone Database, by which time any Certificate with
> such Internal Name should have been revoked, unless the CA has determined
> that the Subscriber is the registrant or has the right to control the
> Domain Name.”
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org<public-bounces at cabforum.org>]
> *On Behalf Of *Ben Wilson
> *Sent:* Wednesday, December 18, 2013 11:37 AM
> *To:* kirk_hall at trendmicro.com; 'Ryan Sleevi'
> *Cc:* 'CABFPub'
> *Subject:* Re: [cabfpub] Proposal for change of definition of Internal
> Server Name in the BRs
>
>
>
> Sure.
>
>
>
> *From:* kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com<kirk_hall at trendmicro.com>]
>
> *Sent:* Wednesday, December 18, 2013 11:21 AM
> *To:* Ryan Sleevi; ben at digicert.com
> *Cc:* CABFPub
> *Subject:* RE: [cabfpub] Proposal for change of definition of Internal
> Server Name in the BRs
>
>
>
> Ben, can you prepare a draft ballot incorporating all these changes?  We
> will be an endorser.
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com <sleevi at google.com>]
> *Sent:* Wednesday, December 18, 2013 12:47 PM
> *To:* ben at digicert.com
> *Cc:* Kirk Hall (RD-US); CABFPub
> *Subject:* RE: [cabfpub] Proposal for change of definition of Internal
> Server Name in the BRs
>
>
>
> Works for me, with a suitable definition of Registered Domain Name.
>
> On Dec 18, 2013 9:45 AM, "Ben Wilson" <ben at digicert.com> wrote:
>
> I would prefer that we distinguish between a domain namespace (which is
> registered) and the server name (which either includes or does not include,
> a registered domain name).  So “internal server name” could be defined as,
> “a name that does not include a Registered Domain Name, determined at the
> time of certificate issuance.”
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
> Behalf Of *kirk_hall at trendmicro.com
> *Sent:* Wednesday, December 18, 2013 8:14 AM
> *To:* Ryan Sleevi
> *Cc:* CABFPub (public at cabforum.org)
> *Subject:* Re: [cabfpub] Proposal for change of definition of Internal
> Server Name in the BRs
>
>
>
> Thanks, Ryan.  So if I understand correctly, the modified language to
> consider is shown below – correct?
>
>
>
> Does anyone object to making these changes?  If not, I’ll propose this in
> a ballot:
>
>
>
> Internal Server Name: A Server Name that is an Unregistered Domain Name.
>
>
>
> Registered Domain Name: A Domain Name that contains as the final level a
> valid domain according to the IANA Root Zone Database.  For domains that
> end in a gTLD, the Domain Name MUST be registered with an ICANN-accredited
> Registrar that is authorized to register domains with the ICANN-assigned
> gTLD Registry Operator (or an Affiliate or subtractor thereof engaged in
> providing Registry Surfaces).  For domains that end in a country-code or
> sponsored TLD, the Domain Name MUST be registered with a duly-authorized
> entity recognized by the Sponsoring Organization of the appropriate ccTLD.
>  No other forms of Root Zones are permitted to appear within a Registered
> Domain Name.
>
>
>
> [Unregistered Domain Name: A Domain Name that is not a Registered Domain
> Name.]
>
>
>
> As a reminder, right now, the definition for an ISN is as follows:
>
>
>
> *Internal Server Name: *A Server Name (which may or may not include an
> Unregistered Domain Name) that is not resolvable using the public DNS.
>
>
>
> *[There is no definition of Server Name in the BRs.]*
>
>
>
> [*Registered Domain Name: *A Domain Name that has been registered with a
> Domain Name Registrar.]
>
>
>
> [*Unregistered Domain Name: *A Domain Name that is not a Registered
> Domain Name.]
>
>
>
>
>
>
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com <sleevi at google.com>]
> *Sent:* Tuesday, December 17, 2013 3:10 PM
> *To:* Kirk Hall (RD-US)
> *Cc:* Gervase Markham; CABFPub (public at cabforum.org)
> *Subject:* Re: [cabfpub] Proposal for change of definition of Internal
> Server Name in the BRs
>
>
>
>
>
>
>
> On Tue, Dec 17, 2013 at 9:24 AM, kirk_hall at trendmicro.com <
> kirk_hall at trendmicro.com> wrote:
>
> So would it work to amend the definition of ISN and of Registered Domain
> Name to read as follows?
>
>
>
> Internal Server Name: A Server Name that is an Unregistered Domain Name.
>
>
>
> Registered Domain Name: A Domain Name that has been registered with an
> ICANN-assigned  Domain Name Registrar.
>
>
>
> [Unregistered Domain Name: A Domain Name that is not a Registered Domain
> Name.]
>
>
>
>
>
> Looks like we're mixing top and bottom posts again.
>
>
>
> I tried to make a distinction between Registry (that is, a party duly
> recognized and contracted with ICANN to a TLD within the valid list
> maintained by IANA) and a Registrar (an ICANN-accredited organization to
> interact with registrants)
>
>
>
> The goal of the wording should be two-fold
>
> 1) Ensure that Registered Domain Names means it is a name that is a valid
> TLD according to IANA
>
> 2) Ensure that the domain has been registered by a registrant with an
> ICANN-accredited registrar, for
>
>
>
> For what it's worth, here's the definition of "Registered Name" taken from
> the ICANN 2013 Registrar Accreditation Agreement  (
> http://www.icann.org/en/resources/registrars/raa/approved-with-specs-27jun13-en.htm)
>
>
> "
>
> 1.11 "gTLD" or "gTLDs" refers to the top-level domain(s) of the DNS
> delegated by ICANN pursuant to a registry agreement that is  in full force
> and effect, other than any country code TLD (ccTLD) or internationalized
> domain name (IDN) country code TLD.
>
>
>
> <snip>
>
>
>
> 1.15 "Registered Name" refers to a domain name within the domain of a
> gTLD, whether consisting of two (2) or more (e.g., john.smith.name)
> levels, about which a gTLD Registry Operator (or an Affiliate or
> subcontractor thereof engaged in providing Registry Services) maintains
> data in a Registry Database, arranges for such maintenance, or derives
> revenue from such maintenance. A name in a Registry Database may be a
> Registered Name even though it does not appear in a zone file (e.g., a
> registered but inactive name).
>
> 1.16 "Registered Name Holder" means the holder of a Registered Name.
>
> 1.17 The word "registrar," when appearing without an initial capital
> letter, refers to a person or entity that contracts with Registered Name
> Holders and with a Registry Operator and collects registration data about
> the Registered Name Holders and submits registration information for entry
> in the Registry Database."
>
>
>
>
>
> The above language doesn't quite handle the ccTLD case, but the IANA Root
> Zone Database does cover these - http://www.iana.org/domains/root/db
>
>
>
> Sorry for the nit-picking here, but I am hoping to avoid future questions.
>
>
>
> "Registered Domain Name: A Domain Name that contains as the final level a
> valid domain according to the IANA Root Zone Database. For domains that end
> in a gTLD, the Domain Name MUST be registered with an ICANN-accredited
> Registrar that is authorized to register domains with the ICANN-assigned
> gTLD Registry Operator (or an Affiliate or subtractor thereof engaged in
> providing Registry Surfaces). For domains that end in a country-code or
> sponsored TLD, the Domain Name MUST be registered with a duly-authorized
> entity recognized by the Sponsoring Organization of the appropriate ccTLD.
> No other forms of Root Zones are permitted to appear within a Registered
> Domain Name"
>
>
>
> I realize this is a significant expansion on the original language, and
> may be best suited by multiple additions to the glossary (to cover generic
> TLD, country-code TLD, and sponsored TLD), and while it should be plainly
> obvious as common sense, it avoids any ambiguity - and avoids any risk of
> alternate registries being used and there being naming collisions.
>
>
>
>
>
> TREND MICRO EMAIL NOTICE
>
> The information contained in this email and any attachments is confidential
>
> and may be subject to copyright or other intellectual property protection.
>
> If you are not the intended recipient, you are not authorized to use or
>
> disclose this information, and we request that you notify us by reply mail or
>
> telephone and delete the original message from your mail system.
>
>
>
>
>
> TREND MICRO EMAIL NOTICE
>
> The information contained in this email and any attachments is confidential
>
> and may be subject to copyright or other intellectual property protection.
>
> If you are not the intended recipient, you are not authorized to use or
>
> disclose this information, and we request that you notify us by reply mail or
>
> telephone and delete the original message from your mail system.
>
>
>
>
>
>
> _______________________________________________
>
> Public mailing list
>
> Public at cabforum.org
>
> https://cabforum.org/mailman/listinfo/public
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140312/398283df/attachment-0003.html>


More information about the Public mailing list