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

Ryan Sleevi sleevi at google.com
Mon Dec 16 19:02:47 MST 2013


On Mon, Dec 16, 2013 at 5:52 PM, kirk_hall at trendmicro.com <
kirk_hall at trendmicro.com> wrote:

>  As we all know, internal server name certs are being phase out under BR
> 9.2.1.  In re-reading that section plus the BR Definitions, I think our
> Definition of an Internal Server Name is erroneous, and reaches too far.
>
>
>
> 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.]
>
>
>
>
>
> I don’t really understand the existing definition, and I believe the
> definition should be *changed* to read as follows:
>
>
>
> *Internal Server Name: *A Server Name that is an Unregistered Domain Name.
>
>
>
> In my opinion, whether or not a Server Name is resolvable using the public
> DNS is irrelevant to the definition.  There are cases where a customer
> registers a domain name with a registrar and it can be viewed on WhoIs, but
> the customer only uses the domain name for internal communications
> purposes, and so the Server Name / domain name is “not resolvable using the
> public DNS”.  (Or, the customer has registered the domain but not started
> using it yet, but wants to order certs for it.)
>
>
>
> Even though the domain is not resolvable using the public DNS when the
> cert is ordered, the domain *can* be fully and vetted by a CA uniquely
> back to the customer (either through Manual Vetting that examines the WhoIs
> entry and matches it to the customer’s name, or through the automatic email
> method using one of the contact email addresses listed in the WhoIs
> record).
>
>
>
> So long as the Server Name / domain name is properly registered by a
> customer with a registrar (whether or not the domain is presently
> resolvable using the public DNS), that means a hacker can’t get a cert for
> the same domain from the CA or from another CA – which is the whole point
> of sunsetting Internal Server Names under BR 9.2.1 (i.e., to prevent
> hackers from getting certs for .mail, etc. which can’t be uniquely vetted
> to any single domain owner).
>
>
>
> Does anyone disagree with changing the definition of Internal Server Name
> to read as follows?
>
>
>
> *Internal Server Name: *A Server Name that is an Unregistered Domain Name.
>
>

>
> If not, I will propose a ballot.
>
>
>
> *NOTE* - I am posting this on the public list so that we can receive
> input from all interested parties – but I understand that some CAB Forum
> members think my narrow question (about how to interpret Internal Server
> Names for the purpose of the sunsetting under BR 9.2.1 – which today is
> ambiguous) is a great starting point for fixing lots of inconsistent
> wording in the Baseline Requirements and maybe the EV Guidelines concerning
> the terms “domain names,”, “server names,” “FQDNs”, etc.
>
>
>
> I’m all in favor of a comprehensive review of these other issues – but not
> if it delays reaching a solution to the way ISNs are defined as it may
> apply to BR 9.2.1.  If the discussion seems to go become too broad and will
> delay resolution of this narrow issue, I will likely propose a ballot soon
> that deals only with the definition of ISN as outlined above, and leave the
> rest of the work to a later ballot.
>
>
>
> *Kirk R. Hall*
>
> Operations Director, Trust Services
>
> Trend Micro
>
> +1.503.753.3088
>
>
>
> 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
>
>
Thanks for raising this issue, Kirk. This has indeed been a source of
confusion for some.

Within Chromium's implementation, we've long interpreted Internal Server
Name exactly as you describe, and that has been our primary concern with
the deprecation of such names.

The one caveat I would propose that, as we seek to improve wording, we also
ensure that the name that has been registered with a Domain Name Registar
authorized by the ICANN-assigned Registry for that domain name space.

The only reason I highlight this is that there exists the reality of
"alternative Domain Name Systems" that seek to replace or ignore the
ICANN-defined registration process, and I would hate to see a CA use such a
system as a "reliable data source".

That is, we have zero security concerns or objections with CAs issuing
certificates for so-called "split-horizon" DNS namespaces, provided that
the CA has performed the required due diligence to ensure that the
requester of such certificates are authorized to request such certificates
within the registerable portion of that domain name space (aka, Section
11.1)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20131216/2d6e15ca/attachment-0001.html 


More information about the Public mailing list