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

Ben Wilson ben at digicert.com
Sun Mar 9 20:01:50 UTC 2014


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] 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] 
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] 
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] 
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/20140309/fd437a20/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BRv1.1.7-Ballot-112.pdf
Type: application/pdf
Size: 66332 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140309/fd437a20/attachment-0003.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5453 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140309/fd437a20/attachment-0001.p7s>


More information about the Public mailing list