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

Fri Mar 14 16:45:28 UTC 2014

Thanks, Chema.  So I have at least one person willing to endorse the ballot.  On the issue that Ryan raised “because it's now *permitted* to not revoke, by demonstrating that control” -- I am willing to fine-tune the language that is creating a problem, but as I understood the discussion that Rick raised during the F2F, it was that it would be good if CAs were able somehow to establish continuity of control during the delegation process so that they don’t have to revoke a certificate unnecessarily.  If the process as actually implemented requires revocation, then maybe there is nothing we can do about it.  However, under the existing BRs, the intention is clear that CAs would be able to avoid revoking a certificate if the Subscriber could demonstrate the right to control the domain name (rather than having to wait in limbo until actual registration and delegation occurred).  

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Chema López González
Sent: Friday, March 14, 2014 2:49 AM
To: Ben Wilson
Cc: CABFPub
Subject: Re: [cabfpub] Proposal for change of definition of Internal Server Name in the BRs

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

_______________________________________________
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/c0e81ca6/attachment-0003.html>
-------------- 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/20140314/c0e81ca6/attachment-0001.p7s>