[cabfpub] Ballot 112 - Replace Definition of "Internal Server Name" with "Internal Name"

Ryan Sleevi sleevi at google.com
Fri Mar 21 15:05:52 UTC 2014


On Mar 21, 2014 7:57 AM, "Gervase Markham" <gerv at mozilla.org> wrote:
>
> On 21/03/14 14:46, Ryan Sleevi wrote:
>>
>> Um, does that not do the opposite of what you want?
>>
>> And internal server name is the name that CANNOT be verified as globally
>> unique, because the last label is absent from the Root Zone Database.
>>
>> Your proposal would seem to have the effect of ALLOWING contracted names
>> to be considered unique, before their delegation event - which seems
>> like the proposal deferred.
>
>
> My understanding is that this is the status quo is that an Internal
Server Name stops being an Internal Server Name (and therefore triggers the
cert revocation clock) when the TLD concerned is _contracted_. I get that
from 11.1.4 of BR 1.1.6:
>
> "Within 30 days after ICANN has approved a new gTLD for operation, as
evidenced by publication of a contract with the gTLD operator on [
www.ICANN.org]..."
>
> The deferred ballot wishes to change "contracted" to "delegated".
>
> So, my proposed wording is to try and make the new definition of ISN
match the former - i.e. something stops being an ISN at contract signing
rather than at delegation.
>
> Was my wording bad? Or have I misunderstood the status quo? Or something
else?
>
> Gerv

Ah, I see.

The clause regarding revocation still remains unchanged. That is, the event
for revocation is still triggered by ICANN contracting a domain, which is
why I was not bothered by the change and willing to endorse.

I agree with the spirit of your change, except I don't and didn't see it as
a concern, exactly because of 11.1.4.

The risk of your change would be in seemingly allowing new certs to be
issued from the moment of contracting - rather than the current status quo
of requiring delegation in the Root Zone Database. That is why I prefer the
current wording, in that you're lumped into "internal" until such time that
the gTLD is assigned, delegated, and globally visible (a minimum in order
for the applicant to demonstrate control).

I think we're approaching the problem from different angles, but with the
same goal. I prefer the current language because 11.1.4 covers the
transition period of contracted-but-not-delegated and revocation, and the
proposed modification above ensures that it is only names in the public
namespace that are eligible for "split-horizon" considerations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140321/dfcffdc4/attachment-0003.html>


More information about the Public mailing list