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

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Tue Dec 17 01:52:06 UTC 2013


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


<table class="TM_EMAIL_NOTICE"><tr><td><pre>
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.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131217/c1fe64cd/attachment-0002.html>


More information about the Public mailing list