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

Fri Mar 14 08:48:58 UTC 2014

I do also prefer Proposal 2, so the proposed Motion, IMO is the right one.

So, "YES", we vote in favor.

-- 
*Chema López*
*Gestor de Proyectos - Departamento Técnico*
*AC Firmaprofesional, S.A.*

Edificio ESADECREAPOLIS - 1B13
08173 Sant Cugat del Vallès, Barcelona.
T.  934 774 245
M. 666 429 224

On Sun, Mar 9, 2014 at 9: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
>
>
>
> _______________________________________________
> 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/20140314/c72cc442/attachment-0003.html>