Communication to CAs about .int TLD
Kathleen Wilson
root certificates included in NSS. Feedback is welcome.
---
Dear Certification Authority,
On behalf of Mozilla I am contacting you in regards to root
certificates that you currently have included by default in Mozilla
products, such as the Firefox browser.
It has come to our attention that some Certification Authorities may
have mistakenly issued SSL certificates to non-existent .int domain
names. This appears to have happened because the .int domain may have
been confused with internal domain names, and not all of the CAs and
RAs may be aware that .int is an ICANN approved TLD. (http://
www.icann.org/en/registries/top-level-domains.htm)
Note that the current Mozilla CA Certificate Policy is silent with
respect to the practice of CAs issuing certificates for internal
domains. There are various problems associated with issuing
certificates for servers on internal networks under the same CA
hierarchy as certificates for servers on public networks, so in the
future Mozilla may elect to change the CA Certificate Policy to add
more explicit requirements on this practice, or even to disallow it
altogether.
In the light of the current situation, Mozilla requests that you take
the following actions.
1) Perform an internal audit to look for certificates that have been
issued within your CA hierarchy which have .int domain names in the
Common Name and/or as DNS Names in the subjectAlternativeName. For
each of these certificates, check to see if the certificate subscriber
owns/controls that domain name, and revoke the certificate if they do
not own/control that domain name.
2) Review your controls/procedures (both internally and your RAs) for
correct identification of internal and external domain names and
verification that subscribers own/control the domain name to be
included in their certificate. Please refer to these documents:
a) Section 7 of Mozilla’s CA Certificate Policy (http://
www.mozilla.org/projects/security/certs/policy/), which states that
CAs need to take reasonable measures to verify that the entity
submitting the certificate signing request owns/controls the domain to
be referenced in the certificate.
b) https://wiki.mozilla.org/CA:Recommended_Practices
c) https://wiki.mozilla.org/CA:Problematic_Practices
Mozilla also recommends that you
1) Update your training procedures to ensure that all validation staff
are aware of this situation.
2) Implement automated checks to signal a red flag for domains such
as .int and null characters in the Common Name and
subjectAlternativeName of certificates.
3) Track the ICANN list of TLDs and update your procedures as
necessary when new TLDs are approved. (http://www.icann.org/en/
registries/top-level-domains.htm)
Mozilla strongly encourages you to take prompt action in order to
ensure the continued security and trust-ability of your CA service.
Kathleen Wilson
--
Eddy Nigg
I am going to email the following communication to the CAs who have root certificates included in NSS. Feedback is welcome.
Note that the current Mozilla CA Certificate Policy is silent with respect to the practice of CAs issuing certificates for internal domains.
I can't see anywhere anything which suggests cases where there is no registered domain name. More than that, the policy explicitly states "has registered the domain(s) referenced in the certificate".
The reason that hostnames, non-valid TLDs and (internal) IP addresses were previously accepted by Mozilla must be found elsewhere - it's not a policy issue.
There are various problems associated with issuing certificates for servers on internal networks under the same CA hierarchy as certificates for servers on public networks, so in the future Mozilla may elect to change the CA Certificate Policy to add more explicit requirements on this practice, or even to disallow it altogether.
Mozilla strongly encourages you to take prompt action in order to ensure the continued security and trust-ability of your CA service.
How "prompt"? :-)
ipsCA "prompt"? Or a different one kind of "prompt"? LOL
Just joking, have been in a good mood today...
-- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP: star...@startcom.org Blog: http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg
Kathleen Wilson
> Note that the current Mozilla CA Certificate Policy is silent with
> respect to the practice of CAs issuing certificates for internal
> certificates for servers on internal networks under the same CA
> hierarchy as certificates for servers on public networks, so in the
> future Mozilla may elect to change the CA Certificate Policy to add
> more explicit requirements on this practice, or even to disallow it
> altogether.
There are various problems associated with issuing certificates for
servers on internal networks under the same CA hierarchy as
Certificate Policy (http://www.mozilla.org/projects/security/certs/
policy/) states that CAs need to take “reasonable measures to verify
that the entity submitting the certificate signing request has
registered the domain(s) referenced in the certificate.” Internal
domain names such as non-valid TLDs, hostnames, and IP addresses
technically do not meet this requirement. However, for business
reasons there have been situations where these types of internal
domain names have been allowed. In the future Mozilla may elect to
update the enforcement of its policies and/or update the CA
Certificate Policy to more specifically disallow internal (non-
registered) domain names in SSL certificates.
> Define "prompt"? :-)
> How "prompt"? :-)
> ipsCA "prompt"? Or a different one kind of "prompt"? LOL
> Just joking, have been in a good mood today...
Point taken.
Glad to hear you're in a good mood today. :-)
Eddy Nigg
> Thanks for your feedback. How about changing this paragraph:
>
>> Note that the current Mozilla CA Certificate Policy is silent with
>> respect to the practice of CAs issuing certificates for internal
>> domains. There are various problems associated with issuing
>> certificates for servers on internal networks under the same CA
>> hierarchy as certificates for servers on public networks, so in the
>> future Mozilla may elect to change the CA Certificate Policy to add
>> more explicit requirements on this practice, or even to disallow it
>> altogether.
>>
> To:
> There are various problems associated with issuing certificates for
> servers on internal networks under the same CA hierarchy as
> certificates for servers on public networks. Section 7 of Mozilla’s CA
> Certificate Policy (http://www.mozilla.org/projects/security/certs/
> policy/) states that CAs need to take “reasonable measures to verify
> that the entity submitting the certificate signing request has
> registered the domain(s) referenced in the certificate.” Internal
> domain names such as non-valid TLDs, hostnames, and IP addresses
> technically do not meet this requirement. However, for business
> reasons there have been situations where these types of internal
> domain names have been allowed. In the future Mozilla may elect to
> update the enforcement of its policies and/or update the CA
> Certificate Policy to more specifically disallow internal (non-
> registered) domain names in SSL certificates.
>
Sounds good.
> Point taken.
> Glad to hear you're in a good mood today. :-)
>
Join as long as it lasts ;-)
Kyle Hamilton
<kathle...@yahoo.com> wrote:
> To:
> There are various problems associated with issuing certificates for
> servers on internal networks under the same CA hierarchy as
> certificates for servers on public networks. Section 7 of Mozilla’s CA
> Certificate Policy (http://www.mozilla.org/projects/security/certs/
> policy/) states that CAs need to take “reasonable measures to verify
> that the entity submitting the certificate signing request has
> registered the domain(s) referenced in the certificate.” Internal
> domain names such as non-valid TLDs, hostnames, and IP addresses
> technically do not meet this requirement. However, for business
> reasons there have been situations where these types of internal
> domain names have been allowed. In the future Mozilla may elect to
> update the enforcement of its policies and/or update the CA
> Certificate Policy to more specifically disallow internal (non-
> registered) domain names in SSL certificates.
I think that this is appropriate.
I would also request that Mozilla contact Microsoft and ask what
precisely the requirements for the "Unified Communications
Certificate" are, and more specifically if the bare NETBIOS name is
actually required in the sAN. Specifically, the whitepaper I saw
recommended it, but it did not state that it was actually mandated. I
would like a bit more information before trying to figure out if
they're needed or not -- if they are, then Mozilla is going to have to
be more flexible in its policy or else roots will have to choose
between Mozilla and Microsoft -- and Mozilla will lose, because
Microsoft has the market share (in messaging servers, at the least).
>> Define "prompt"? :-)
>> How "prompt"? :-)
>> ipsCA "prompt"? Or a different one kind of "prompt"? LOL
>> Just joking, have been in a good mood today...
>
> Point taken.
> Glad to hear you're in a good mood today. :-)
I'd like to see 'prompt' be between 30 and 60 days. I certainly would
expect it to be "less than one business quarter".
(And I'm glad Eddy's in a good mood, too. :))
-Kyle H
Rob Stradling
technically do not meet this requirement".
I think it depends on your definition of the word "domain", and AFAICT the
Mozilla CA Certificate Policy doesn't currently offer a definition.
In the absence of a clear definition, I don't think it's unreasonable to
interpret "domain" as meaning an Internet-registrable domain name. And with
this definition, a certificate for a non-valid TLD, hostname or IP address
doesn't violate section 7 (because all zero of the "domains" in such a
certificate have been registered!)
I would welcome a move from Mozilla to "update the CA Certificate Policy to
more specifically" indicate what is and what isn't allowed.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Rob Stradling
Senior Research & Development Scientist
C·O·M·O·D·O - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Eddy Nigg
"Internal domain names such as non-valid TLDs, hostnames, and IP addresses technically do not meet this requirement". I think it depends on your definition of the word "domain", and AFAICT the Mozilla CA Certificate Policy doesn't currently offer a definition.
for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;
I would welcome a move from Mozilla to "update the CA Certificate Policy to more specifically" indicate what is and what isn't allowed.
Kyle Hamilton
> I think it depends on your definition of the word "domain", and AFAICT the
> Mozilla CA Certificate Policy doesn't currently offer a definition.
The current CA policy doesn't include it, but I will offer a
suggestion: A domain is an entry in DNS for which NS records exist in
its TLD zone, which is globally accessible, and for which the SOA
record is controlled by the named and registered technical contact for
the domain. A domain, for this definition, should also be viewed as
any possible entry in the global root zone controlled by ICANN, and
all of their subdomains. (Remember, we're dealing with the globe, not
simply a controlled environment... and the globe can change
overnight.)
> In the absence of a clear definition, I don't think it's unreasonable to
> interpret "domain" as meaning an Internet-registrable domain name. And with
> this definition, a certificate for a non-valid TLD, hostname or IP address
> doesn't violate section 7 (because all zero of the "domains" in such a
> certificate have been registered!)
The problem with this is that a certifying authority cannot actually
make things up (and if it does, it should be untrusted immediately).
If you certify that a given machine has a specific hostname and
domainname, you are certifying that its hostname is unique in the
realm of the domainname, and that the domainname can be looked up via
an external 3rd party authority as well (that the person who named the
machine has a REGISTERED domain, which can be verified with the
registrar and thus certified by the CA). If you issue to made-up
TLDs, you're essentially stating that you accept that that customer of
yours is the registrar for that TLD. Since the entire world of TLDs
is now available (excepting the ones reserved via RFC), *no*
currently-unregistered TLD is safe. (You're essentially allowing your
customers to put non-existent entries into the root zone that clients
can access, and that specific root zone is definitely NOT controlled
by them. If you looked up the Network Time Protocol, you'd see that
there are two concepts for the sources of the time: 'truechimers' (the
ones which do have the One True Time), and 'falsetickers' (which
don't). ICANN has, for better or worse, the truechimer root zone.
Anyone who creates an internal TLD has a falseticker root zone.)
> I would welcome a move from Mozilla to "update the CA Certificate Policy to
> more specifically" indicate what is and what isn't allowed.
I propose that my aforementioned thought be evaluated, masticated, sat
upon, ruminated upon, and considered when considering any change to
describe what a "domain" is.
-Kyle H
>
> Rob Stradling
> Senior Research & Development Scientist
> C·O·M·O·D·O - Creating Trust Online
> Office Tel: +44.(0)1274.730505
> Office Fax: +44.(0)1274.730909
> www.comodo.com
>
> Comodo CA Limited, Registered in England No. 04058690
> Registered Office:
> 3rd Floor, 26 Office Village, Exchange Quay,
> Trafford Road, Salford, Manchester M5 3EQ
>
> This e-mail and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender by replying
> to the e-mail containing this attachment. Replies to this email may be
> monitored by Comodo for operational or business reasons. Whilst every
> endeavour is taken to ensure that e-mails are free from viruses, no liability
> can be accepted and the recipient is requested to use their own virus checking
> software.
Didn't you say you were going to stop including this text in your
emails to this list? It's huge, and completely worthless in any kind
of open discussion setting (though the 'replies may be monitored by
Comodo' is a good thing to note, as it produces the expectation that
the communication, even if sent only to you, is not necessarily
private.)
Rob Stradling
> On 11/21/2009 12:06 AM, Rob Stradling:
> > "Internal domain names such as non-valid TLDs, hostnames, and IP
> > addresses technically do not meet this requirement".
> >
> > I think it depends on your definition of the word "domain", and AFAICT
> > the Mozilla CA Certificate Policy doesn't currently offer a definition.
>
> Policy speaks clearly about registered domain names:
Eddy, I don't think you understood my point. Yes, the Mozilla CA Certificate
Policy (MCCP) says that domains must be registered, but it doesn't say what a
"domain" is.
I think there are 4 groups of names that are or could be considered to be
"domains":
1. Currently registered.
2. Currently registrable (but not actually registered).
3. Potentially registrable in the future (via new global TLDs).
4. Never registrable (hostnames with no TLDs, IP addresses).
The MCCP is clear that 1 and 2 are "domains", and that 1 is allowed and 2 is
disallowed. (Since 2 is disallowed, the mis-issued .int certs that were
recently discovered did violate the MCCP).
The MCCP is not clear about 3 or 4, IMHO and (I presume) in the opinions of
all the major CAs who issue certs to these kinds of names.
I am not stating an opinion about whether 3 and/or 4 should be allowed or
disallowed by a revised MCCP. All I am saying is that I would welcome
clarity.
(By the way, I hope you're still in a good mood ;-) ).
> for a certificate to be used for SSL-enabled servers, the CA takes
> reasonable measures to *verify* that the entity submitting the
> certificate signing request has *registered the domain(s)*
> referenced in the certificate /or/ has been authorized by the
> *domain registrant* to act on the registrant's behalf;
>
> > I would welcome a move from Mozilla to "update the CA Certificate Policy
> > to more specifically" indicate what is and what isn't allowed.
>
> How should be this improved to make it even clearer than the above? I
> think that's a hard task....
>
Rob Stradling
Eddy Nigg
Eddy, I don't think you understood my point. Yes, the Mozilla CA Certificate Policy (MCCP) says that domains must be registered, but it doesn't say what a "domain" is.
Nevertheless I try to help you....
A REGISTERED domain is any domain which you can register, assumable at a registrar authorized to so (by IANA/ICANN). Here is the complete list as published by IANA: http://www.iana.org/domains/root/db/
You can't register a hostname without a TLD at a registrar. You can't register an IP address at a registrar. You can't register a domain name for which no TLD exists. So a valid domain name boils down to:
1. Currently registered. <= Yes 2. Currently registrable (but not actually registered). <= No, because you can't verify that (another portion of the policy), but it might become a registered domain in the future. 3. Potentially registrable in the future (via new global TLDs). <= No, you can't verify the registration either, so it's not a valid domain, it might be in the future. 4. Never registrable (hostnames with no TLDs, IP addresses). <= No, becauese you can't verify the registration either. Those are certainly no registered domains anyway. The MCCP is not clear about 3 or 4, IMHO and (I presume) in the opinions of all the major CAs who issue certs to these kinds of names.
How can you verify that? You perhaps can verify that the TLD doesn't exist at the moment. However you can't verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant.
So this is crystal clear IMO.
(By the way, I hope you're still in a good mood ;-) ).
Ian G
> I am going to email the following communication to the CAs who have
> root certificates included in NSS. Feedback is welcome.
> ---
> Dear Certification Authority,
>
> On behalf of Mozilla I am contacting you in regards to root
> certificates that you currently have included by default in Mozilla
> products, such as the Firefox browser.
>
> It has come to our attention that some Certification Authorities may
> have mistakenly issued SSL certificates to non-existent .int domain
> names. This appears to have happened because the .int domain may have
> been confused with internal domain names, and not all of the CAs and
> RAs may be aware that .int is an ICANN approved TLD. (http://
> www.icann.org/en/registries/top-level-domains.htm)
>
> Note that the current Mozilla CA Certificate Policy is silent with
> respect to the practice of CAs issuing certificates for internal
> domains. There are various problems associated with issuing
> certificates for servers on internal networks under the same CA
> hierarchy as certificates for servers on public networks, so in the
> future Mozilla may elect to change the CA Certificate Policy to add
> more explicit requirements on this practice, or even to disallow it
> altogether.
I would suggest the latter part (",so in the") change to:
and Mozilla is currently discussing a change in the CA Certificate
Policy to add more explicit requirements on this practice, or even to
disallow it altogether.
> In the light of the current situation, Mozilla requests that you take
> the following actions.
>
> 1) Perform an internal audit to look for certificates that have been
> issued within your CA hierarchy which have .int domain names in the
> Common Name and/or as DNS Names in the subjectAlternativeName. For
> each of these certificates, check to see if the certificate subscriber
> owns/controls that domain name, and revoke the certificate if they do
> not own/control that domain name.
Suggest, add:
If there is a valuable business reason for this practice, please advise
of the logic of this business.
> 2) Review your controls/procedures (both internally and your RAs) for
> correct identification of internal and external domain names and
> verification that subscribers own/control the domain name to be
> included in their certificate. Please refer to these documents:
> a) Section 7 of Mozilla�s CA Certificate Policy (http://
> www.mozilla.org/projects/security/certs/policy/), which states that
> CAs need to take reasonable measures to verify that the entity
> submitting the certificate signing request owns/controls the domain to
> be referenced in the certificate.
> b) https://wiki.mozilla.org/CA:Recommended_Practices
> c) https://wiki.mozilla.org/CA:Problematic_Practices
>
> Mozilla also recommends that you
> 1) Update your training procedures to ensure that all validation staff
> are aware of this situation.
> 2) Implement automated checks to signal a red flag for domains such
> as .int and null characters in the Common Name and
> subjectAlternativeName of certificates.
> 3) Track the ICANN list of TLDs and update your procedures as
> necessary when new TLDs are approved. (http://www.icann.org/en/
> registries/top-level-domains.htm)
>
> Mozilla strongly encourages you to take prompt action in order to
> ensure the continued security and trust-ability of your CA service.
The rest, fine. I prefer the first text. The message is clear.
I see no positive value in defining "prompt" and similar things.
I recall some dude saying, "walk softly and carry a big stick."
iang
Ian G
> On 11/21/2009 12:06 AM, Rob Stradling:
>> "Internal domain names such as non-valid TLDs, hostnames, and IP addresses
>> technically do not meet this requirement".
>>
>> I think it depends on your definition of the word "domain", and AFAICT the
>> Mozilla CA Certificate Policy doesn't currently offer a definition.
>>
>
Not really. Registered with who?
Some of us are old enough to remember "alternate" domain registrars.
Some of us are even old enough to remember when domains were not global.
Some of us edit /etc/hosts. Some of us even know about that
historical oddity called the open source internetworking code. There
might even be some of us who remember "domains" using the ! not the .
and how we had to do our own routing :P
There is no law nor contract in place here. There is only custom. It
requires a simple sentance being added somewhere, and frankly, it's
easier to add the sentance here, now, in the policy, and establish the
IP required, than to make a mistake later on and have to deal in court.
Another way of putting it is that it really doesn't matter what those
who agree think.
What matters is what those who disagree think.
iang
Eddy Nigg
> necessary when new TLDs are approved. (http://www.icann.org/en/
> registries/top-level-domains.htm)
>
This just jumped to my eyes during re-reading some of the messages of
today...
For those following this mailing list, I suggest to make it a practice
to manage a list of TLDs which are eligible to be used for domains in
certificates and not the other way around. If and when a new TLD is
created by IANA, the TLD must be explicitly added in order to be used -
instead of adding it in order not to be used.
In short, steering clear from anything then registered and approved TLDs
is a safe bet and one step less vulnerable to misuse...
Eddy Nigg
> On 20/11/2009 23:39, Eddy Nigg wrote:
>> On 11/21/2009 12:06 AM, Rob Stradling:
>>> "Internal domain names such as non-valid TLDs, hostnames, and IP
>>> addresses
>>> technically do not meet this requirement".
>>>
>>> I think it depends on your definition of the word "domain", and
>>> AFAICT the
>>> Mozilla CA Certificate Policy doesn't currently offer a definition.
>>>
>>
>> Is *registered domain* not a clear definition for you?
>
>
> Not really. Registered with who?
>
I'm ignoring you like you are ignoring everything else :-)
Eddy Nigg
> On 11/21/2009 04:41 AM, Ian G:
>> On 20/11/2009 23:39, Eddy Nigg wrote:
>>> On 11/21/2009 12:06 AM, Rob Stradling:
>>>> "Internal domain names such as non-valid TLDs, hostnames, and IP
>>>> addresses
>>>> technically do not meet this requirement".
>>>>
>>>> I think it depends on your definition of the word "domain", and
>>>> AFAICT the
>>>> Mozilla CA Certificate Policy doesn't currently offer a definition.
>>>>
>>>
>>> Is *registered domain* not a clear definition for you?
>>
>>
>> Not really. Registered with who?
>>
>
> I'm ignoring you like you are ignoring everything else :-)
>
Maybe that was a bit harsh... but c'mon...nobody edits host files
anymore except for testing. Discussions regarding the established orders
(omitting "law" for you) should be perhaps held at ICANN, not here. It
simply distracts from what we are trying to focus here...it's just some
theoretical thinking not connected to the realities on the ground (or on
the wire).
Florian Weimer
> On Fri, Nov 20, 2009 at 2:06 PM, Rob Stradling <rob.st...@comodo.com> wrote:
>> I think it depends on your definition of the word "domain", and AFAICT the
>> Mozilla CA Certificate Policy doesn't currently offer a definition.
>
> The current CA policy doesn't include it, but I will offer a
> suggestion: A domain is an entry in DNS for which NS records exist in
> its TLD zone,
This part is problematic. It rules out NOMINET.CO.UK because the
delegation is from CO.UK, not UK (the TLD). It's also problematic for
zones which are not delegation-centric, like DE.
> which is globally accessible, and for which the SOA
> record is controlled by the named and registered technical contact for
> the domain.
This also rules out certain domain hosting solutions where the domain
owner lacks control over SOA contents (even if the zone is delegated
from a TLD).
There are several policy choices here. Does someone who owns
WWW.CS.EXAMPLE.EDU need approval from the owner of EXAMPLE.EDU before
she can get a certificate? What about non-TLD public suffixes such as
DE.COM, DE.VU etc.? Browsing the public suffix list will be give you
some idea of the challenges.
I suppose it's sufficient to say that the full domain must exist, as
determined by DNS starting from the ICANN root, and that there must be
a process that ensures that the domain owner and the certificate owner
end up the same, and that the process must be documented in the CPS,
and that all data sources which are used in the process are subject to
the audit requirements, with the exception of WHOIS DNS, and official
(state) company registers.
(Unfortunately, we can't demand that the domain owner and certificate
owner must be the same because CAs apparently cannot write this into
their CPS, probably because it's non-auditable.)
Eddy Nigg
>> The current CA policy doesn't include it, but I will offer a
>> suggestion: A domain is an entry in DNS for which NS records exist in
>> its TLD zone,
>>
> This part is problematic. It rules out NOMINET.CO.UK because the
> delegation is from CO.UK, not UK (the TLD).
That's obviously not correct. CO.UK is a valid TLD handled by the .UK
registrar. You can register it and check the WHOIS records.
> It's also problematic for zones which are not delegation-centric, like DE.
>
What the problem here? Isn't this a contradiction of the above?
> There are several policy choices here. Does someone who owns
> WWW.CS.EXAMPLE.EDU need approval from the owner of EXAMPLE.EDU before
> she can get a certificate?
Yes. You don't "own" EXAMPLE.EDU, somebody else owns it and perhaps gave
you the rights to use it a certain portion of the name space. You don't
control neither the domain nor the DNS.
> What about non-TLD public suffixes such as
> DE.COM, DE.VU etc.?
>
Those are not valid TLDs, don't use it, buy a real domain.
> (Unfortunately, we can't demand that the domain owner and certificate
> owner must be the same because CAs apparently cannot write this into
> their CPS, probably because it's non-auditable.)
>
That's mostly due to the fact that some are authorized to act on behalf
of the domain owner, hence the term domain control. Hosting providers
are many times those that control the domain, the actual owner might
have no clue about what to do with either the site, DNS and certainly
not SSL.
Ian G
...
> There are several policy choices here. Does someone who owns
> WWW.CS.EXAMPLE.EDU need approval from the owner of EXAMPLE.EDU before
> DE.COM, DE.VU etc.? Browsing the public suffix list will be give you
> some idea of the challenges.
This is technically solved in the policy by requiring ownership *OR*
control. Which is the standard business approach.
Where it runs into flak is that typically ownership is downgraded, for
whatever reason, and control is insisted upon. So it doesn't really
meet the full expressive needs of business.
...
> (Unfortunately, we can't demand that the domain owner and certificate
> owner must be the same because CAs apparently cannot write this into
> their CPS, probably because it's non-auditable.)
Well, that makes sense to me. Firstly, ownership isn't usage or more
locally, control. Ownership gives the right to delegate control.
Frequently and properly businesses will separate this out (ownership is
by the business, control is by an employee).
Secondly, ownership isn't a binary switch. It is best seen as a bundle
of rights, which are passed out piecemeal in contracts. So what can
happen is that the "right to a cert" is passed to one person and the
"right to email" is passed to another. E.g., if we think about a
crypto-proxy service where plaintext email from within the organisation
gets encrypted and decrypted at the gateway only, we have a scenario
where an employee has an email address, but the IT department has the
cert. This sort of thing you'll possibly find in securities markets,
where for example, all mail has to be kept for internal review, but it
all has to be encrypted to stop snooping.
And, regardless of other sins, auditors are creatures of the normal
business world, so they know all this stuff, and any simplifications
such as "owner must be the same" will have them shaking their heads and
wondering which planet that came from...
iang
Florian Weimer
> On 11/22/2009 05:11 PM, Florian Weimer:
>>> The current CA policy doesn't include it, but I will offer a
>>> suggestion: A domain is an entry in DNS for which NS records exist in
>>> its TLD zone,
>>>
>> This part is problematic. It rules out NOMINET.CO.UK because the
>> delegation is from CO.UK, not UK (the TLD).
>
> That's obviously not correct. CO.UK is a valid TLD handled by the .UK
> registrar. You can register it and check the WHOIS records.
CO.UK is not a TLD because it has got two labels.
>> It's also problematic for zones which are not delegation-centric, like DE.
>>
>
> What the problem here? Isn't this a contradiction of the above?
There are no NS records in the TLD zone in some cases, e.g. 4351.DE.
>> There are several policy choices here. Does someone who owns
>> WWW.CS.EXAMPLE.EDU need approval from the owner of EXAMPLE.EDU before
>> she can get a certificate?
>
> Yes. You don't "own" EXAMPLE.EDU, somebody else owns it and perhaps
> gave you the rights to use it a certain portion of the name space. You
> don't control neither the domain nor the DNS.
This seems to be slightly impractical to me and not what CAs and their
customers generally want.
Eddy Nigg
>> That's obviously not correct. CO.UK is a valid TLD handled by the .UK
>> registrar. You can register it and check the WHOIS records.
>>
> CO.UK is not a TLD because it has got two labels.
>
For our purpose I consider this a TLD, even though you are right that
it's second level domain. However it's handled by a registrar and under
the authority of the TLD. That's as much as I care really...
> There are no NS records in the TLD zone in some cases, e.g. 4351.DE.
>
Name: 4351.DE
Address: 78.47.190.236
???
>> Yes. You don't "own" EXAMPLE.EDU, somebody else owns it and perhaps
>> gave you the rights to use it a certain portion of the name space. You
>> don't control neither the domain nor the DNS.
>>
> This seems to be slightly impractical to me and not what CAs and their
> customers generally want.
>
HA! First of all SSL isn't practical really, but if we'd allow what CAs
and their customers wanted we simply could skip this part and use our
time for more useful things :-)
PS. The above policy works - extremely well at that! It just needs CAs
to enforce it, the rest comes by itself mostly. I'm proving it on a
daily basis a few hundred times a day...
Kathleen Wilson
final email is going to be:
Dear Certification Authority,
On behalf of Mozilla I am contacting you in regards to root
certificates that you currently have included by default in Mozilla
products, such as the Firefox browser.
It has come to our attention that some Certification Authorities may
have mistakenly issued SSL certificates to non-existent .int domain
names. This appears to have happened because the .int domain may have
been confused with internal domain names, and not all of the CAs and
RAs may be aware that .int is an ICANN approved TLD.
Section 7 of Mozilla’s CA Certificate Policy states that CAs need to
take “reasonable measures to verify that the entity submitting the
certificate signing request has registered the domain(s) referenced in
the certificate.” There are different interpretations as to what this
means in regards to internal domain names such as non-valid TLDs,
hostnames, and IP addresses. However, there is consensus that there
are problems associated with issuing certificates for servers on
internal networks under the same CA hierarchy as certificates for
servers on public networks. Mozilla is currently discussing whether
the CA Certificate Policy should be updated to add more explicit
requirements on this practice, or even to disallow it altogether.
In the light of the current situation, Mozilla requests that you take
the following actions.
1) Perform an internal audit to look for certificates that have been
issued within your CA hierarchy which have .int domain names in the
Common Name and/or as DNS Names in the subjectAlternativeName. For
each of these certificates, check to see if the certificate subscriber
owns/controls that domain name, and revoke the certificate if they do
not own/control that domain name.
2) Review your controls/procedures (both internally and your RAs) for
correct identification of internal and external domain names and
verification that subscribers own/control the domain name to be
included in their certificate. Please refer to these documents:
a) Section 7 of Mozilla’s CA Certificate Policy
(http://www.mozilla.org/projects/security/certs/policy/)
b) https://wiki.mozilla.org/CA:Recommended_Practices
c) https://wiki.mozilla.org/CA:Problematic_Practices
Mozilla also recommends that you
1) Update your training procedures to ensure that all validation staff
are aware of this situation.
2) Implement automated checks to signal a red flag for domains such
as .int and null characters in the Common Name and
subjectAlternativeName of certificates.
3) Maintain your own list of ICANN approved TLDs that are eligible to
be used for domains in certificates issued within your CA hierarchy.
If a new TLD is created by IANA, make an explicit decision whether or
not to add the new TLD to your list.
(http://www.icann.org/en/registries/top-level-domains.htm)
Mozilla strongly encourages you to take prompt action in order to
ensure the continued security and trust-ability of your CA service.
Kathleen Wilson
--
Eddy Nigg
> Thank you all for your thoughtful feedback. Here's what I think the
> final email is going to be:
>
Double ++ from me.
Ian G
> Thank you all for your thoughtful feedback. Here's what I think the
> final email is going to be:
>
> Dear Certification Authority,
Great!
iang
Rob Stradling
> On 11/21/2009 01:49 AM, Rob Stradling:
> > Eddy, I don't think you understood my point. Yes, the Mozilla CA
> > Certificate Policy (MCCP) says that domains must be registered, but it
> > doesn't say what a "domain" is.
>
> Rob, you are far more intelligent than you pretend to be at the moment,
> but don't think that makes us stupid :-)
lol
Eddy, Kathleen has acknowledged that there are "different interpretations as
to what this means in regards to internal domain names such as non-valid TLDs,
hostnames, and IP addresses".
I don't understand why you won't acknowledge the existence of interpretations
other than your own, but I don't feel the need to continue this conversation.
> Nevertheless I try to help you....
>
> A REGISTERED domain is any domain which you can register, assumable at a
> registrar authorized to so (by IANA/ICANN). Here is the complete list as
> published by IANA: http://www.iana.org/domains/root/db/
>
> You can't register a hostname without a TLD at a registrar. You can't
> register an IP address at a registrar. You can't register a domain name
>
> for which no TLD exists. So a valid domain name boils down to:
> > 1. Currently registered.<= Yes
> > 2. Currently registrable (but not actually registered).<= No, because you
> > can't verify that (another portion of the policy), but it might become a
> > registered domain in the future. 3. Potentially registrable in the future
> > (via new global TLDs).<= No, you can't verify the registration either, so
> > it's not a valid domain, it might be in the future. 4. Never registrable
> > (hostnames with no TLDs, IP addresses).<= No, becauese you can't verify
> > the registration either. Those are certainly no registered domains
> > anyway.
> >
> > The MCCP is not clear about 3 or 4, IMHO and (I presume) in the opinions
> > of all the major CAs who issue certs to these kinds of names.
>
> How can you verify that? You perhaps can verify that the TLD doesn't
> exist at the moment. However you can't verify that the entity submitting
> the certificate signing request *has registered the domain*(s)
> referenced in the certificate /or/ has been authorized by the *domain
> registrant*.
>
> So this is crystal clear IMO.
>
> > (By the way, I hope you're still in a good mood ;-) ).
>
> Of course, can't you see that? ;-)
>
Rob Stradling
Eddy Nigg
> On Saturday 21 November 2009 00:15:23 Eddy Nigg wrote:
>
>> On 11/21/2009 01:49 AM, Rob Stradling:
>>
>>> Eddy, I don't think you understood my point. Yes, the Mozilla CA
>>> Certificate Policy (MCCP) says that domains must be registered, but it
>>> doesn't say what a "domain" is.
>>>
>> Rob, you are far more intelligent than you pretend to be at the moment,
>> but don't think that makes us stupid :-)
>>
> lol
>
> Eddy, Kathleen has acknowledged that there are "different interpretations as
> to what this means in regards to internal domain names such as non-valid TLDs,
> hostnames, and IP addresses".
>
The different interpretations are probable due to the fact that you do
one thing and I do something else. Apparently we both have different
agendas, therefore your arguments are different than mine. This is
natural IMO - which however doesn't makes it right.
IIRC Kathleen also acknowledged that there is consensus that there are
problems associated with issuing certificates for servers on internal
networks under the same CA hierarchy as certificates for servers on
public networks. :-)
> I don't understand why you won't acknowledge the existence of interpretations
> other than your own, but I don't feel the need to continue this conversation.
>
I don't have a problem that you, or others, try to interpret something
which seems to be very clear, differently. That doesn't mean I can't
argue that you are wrong. Probably it's up to you in which camp you are
going to be....
Rob Stradling
> On 11/23/2009 11:33 AM, Rob Stradling:
> > On Saturday 21 November 2009 00:15:23 Eddy Nigg wrote:
> >> On 11/21/2009 01:49 AM, Rob Stradling:
> >>> Eddy, I don't think you understood my point. Yes, the Mozilla CA
> >>> Certificate Policy (MCCP) says that domains must be registered, but it
> >>> doesn't say what a "domain" is.
> >>
> >> Rob, you are far more intelligent than you pretend to be at the moment,
> >> but don't think that makes us stupid :-)
> >
> > lol
> >
> > Eddy, Kathleen has acknowledged that there are "different interpretations
> > as to what this means in regards to internal domain names such as
> > non-valid TLDs, hostnames, and IP addresses".
>
> The different interpretations
Ah, so you do acknowledge that other people have different interpretations.
:-)
> are probable due to the fact that you do
> one thing and I do something else. Apparently we both have different
> agendas, therefore your arguments
Please re-read my earlier message in which I clearly stated "I am not stating
an opinion".
> are different than mine. This is natural IMO - which however doesn't makes
> it right.
>
> IIRC Kathleen also acknowledged that there is consensus that there are
> problems associated with issuing certificates for servers on internal
> networks under the same CA hierarchy as certificates for servers on
> public networks. :-)
>
> > I don't understand why you won't acknowledge the existence of
> > interpretations other than your own, but I don't feel the need to
> > continue this conversation.
>
> I don't have a problem that you, or others, try to interpret something
> which seems to be very clear, differently. That doesn't mean I can't
> argue that you are wrong. Probably it's up to you in which camp you are
> going to be....
>
Rob Stradling
Eddy Nigg
The different interpretationsAh, so you do acknowledge that other people have different interpretations. :-)
Kathleen merely stated the fact that there ARE apparently different interpretations, she doesn't acknowledge that the interpretations are even valid....but lets leave it for now.... :-)
Have a fantastic week!
Frank Hecker
> Is *registered domain* not a clear definition for you? The Mozilla CA
Since I don't have time right now to read the whole thread, I'll make my
comments here:
When the Mozilla CA certificate policy was created, we assumed that the
standard and only case for SSL/TLS-enabled servers was that they would
be reachable from the public Internet and have public domain names
registered in the usual way. However we did *not* explicitly make a
decision that roots should not issue certificates for internal hostnames
and IP addresses; we didn't think that about that case at all (at least
not to my recollection).
So you (Eddy) are correct that the Mozilla policy is written to assume
public domain names, but Rob does have a point in that we never made an
explicit decision to disallow internal names, and thus have been
implicitly allowing CAs to issue certs including them.
Now that the issue has arisen we may want to clarify the policy either
to disallow issuance of certs with internal names (and IP addresses), or
to allow them under some conditions. If we do decide to disallow
internal names (and I myself am sympathetic to that position) then we
need to figure out a transition plan to deal with CAs that mix internal
and public names under the same hierarchy.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Frank Hecker
> However we did *not* explicitly make a
> decision that roots should not issue certificates for internal hostnames
> and IP addresses; we didn't think that about that case at all (at least
> not to my recollection).
I'm sorry, I meant to write "... we didn't think about that case
[internal names/IP addresses] at all ..."
Frank Hecker
> Thank you all for your thoughtful feedback. Here's what I think the
> final email is going to be:
If Eddy and Ian agree (!) then how could I disagree :-)
(Seriously, this looks fine to me.)
Ian G
> When the Mozilla CA certificate policy was created, we assumed that the
> standard and only case for SSL/TLS-enabled servers was that they would
> be reachable from the public Internet and have public domain names
> registered in the usual way. However we did *not* explicitly make a
> decision that roots should not issue certificates for internal hostnames
> and IP addresses; we didn't think that about that case at all (at least
> not to my recollection).
Not to my recollection either.
...
> Now that the issue has arisen we may want to clarify the policy either
> to disallow issuance of certs with internal names (and IP addresses), or
> to allow them under some conditions. If we do decide to disallow
> internal names (and I myself am sympathetic to that position) then we
> need to figure out a transition plan to deal with CAs that mix internal
> and public names under the same hierarchy.
I think the first step is underway: write to all the CAs and flag the
issue strongly. Then, any CAs that feel they can justify a good
business reason for this will have their chance. There are CAs
obviously doing this, so that remains a distinct possibility.
Once that's done, we have some more facts on the table, and we can proceed.
iang
Gervase Markham
> Maybe that was a bit harsh...
It was. Can we all please try and remain professional?
> but c'mon...nobody edits host files
> anymore except for testing.
However, the point about alternate roots is a good one. Sadly, the ICANN
root is not the only one out there. I think alternate roots are a recipe
for all sorts of problems, but we can't deny their existence. We just
have to work out whether we are going to try and deny them certificates.
Gerv
Gervase Markham
> That's obviously not correct. CO.UK is a valid TLD handled by the .UK
> registrar. You can register it and check the WHOIS records.
Perhaps using the phrase "public suffix" instead of "TLD" would clear up
the terminological confusion here.
http://www.publicsuffix.org/
Gerv
Eddy Nigg
> Eddy Nigg wrote:
>> Is *registered domain* not a clear definition for you? The Mozilla CA
>> Policy speaks clearly about registered domain names:
>
> Since I don't have time right now to read the whole thread, I'll make
> my comments here:
>
> When the Mozilla CA certificate policy was created, we assumed that
> the standard and only case for SSL/TLS-enabled servers was that they
> would be reachable from the public Internet and have public domain
> names registered in the usual way. However we did *not* explicitly
> make a decision that roots should not issue certificates for internal
> hostnames and IP addresses; we didn't think that about that case at
> all (at least not to my recollection).
>
> So you (Eddy) are correct that the Mozilla policy is written to assume
> public domain names, but Rob does have a point in that we never made
> an explicit decision to disallow internal names, and thus have been
> implicitly allowing CAs to issue certs including them.
I think that's mostly due to the fact that during the first years of the
policy and inclusions of CAs this hasn't been enforced and perhaps not
looked at at all. I admit and it might be of interest that StartCom was
admitted too with a policy which allowed for internal hostnames and IP
addresses. And so were scores of others including Comodo, Godaddy and a
bunch of others.
I believe that this isn't correct for various reasons (which have been
mentioned already). I also believe that the policy may remain as it is,
the policy should be however enforced. The only exception which I would
suggest for the policy are IP addresses in case the entity submitting
the certificate signing request has been verified to own the particular
IP block. But we can also live without that.
>
> Now that the issue has arisen we may want to clarify the policy either
> to disallow issuance of certs with internal names (and IP addresses),
> or to allow them under some conditions. If we do decide to disallow
> internal names (and I myself am sympathetic to that position) then we
> need to figure out a transition plan to deal with CAs that mix
> internal and public names under the same hierarchy.
>
Sounds good. I suggest to consider a reasonable time to allow CAs to
adjust to it. What's reasonable I leave to you folks, I prefer to get it
going!
Needless to say that StartCom (by giving a (good) example) has modified
its policies and implementations during the last few years. These steps
didn't hurt StartCom in any way - perhaps quite the opposite, it
protected from mistakes and other worries.
Ian G
> If Eddy and Ian agree (!) then how could I disagree :-)
Neo: Whoa. D�j� vu.
Cipher: What happened?
Neo: A black cat went past us, and then another that looked just like it.
:-)
Ian G
> If Eddy and Ian agree (!) then how could I disagree :-)
Eddy Nigg
>
>> but c'mon...nobody edits host files
>> anymore except for testing.
>
> However, the point about alternate roots is a good one. Sadly, the
> ICANN root is not the only one out there. I think alternate roots are
> a recipe for all sorts of problems, but we can't deny their existence.
> We just have to work out whether we are going to try and deny them
> certificates.
Gerv, lets think about what one billion users on the Internet do and
use. OK? Basically I don't care about other roots for the moment because
they no impact whatsoever. Unfortunately I can't tell you to write an
extension to the Mozilla CA Policy for those which use different DNS
roots. Or perhaps that's what I should suggest...?
Anyway, lets focus on what the common and practical understandings are.
If we have to discuss and evaluate each and every exceptional
implementation and behavior going back to the 70's and 80's(exceptional
from the established and commonly used and practical de-facto standards)
we'll get nowhere ever. This is what sometimes makes me loose my temper,
sorry for that.
I'm interested in getting things achieved - there is a common
understanding and common practice established on the (open?) web and the
IANA/ICANN and the public CAs are part of that establishment. Lets
concentrate on that, OK?
Eddy Nigg
> On 23/11/2009 16:35, Frank Hecker wrote:
>
>> If Eddy and Ian agree (!) then how could I disagree :-)
>
>
>
> Cipher: What happened?
> Neo: A black cat went past us, and then another that looked just like it.
>
> :-)
LOL
Varga Viktor
> up
> the terminological confusion here.
> http://www.publicsuffix.org/
Is that a problem if a CA refuses these stupid suffixes? :D
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________
Kathleen Wilson
The communication has been sent.
In addition to this communication about the .int issue, I will also be
sending email to the CAs who have root certificates in NSS that have
an outdated signature algorithm (MD2, MD5) and/or a low modulus length
(1024). In this email I will be requesting that each CA provide a high
level description and timeline of their plan to phase out the
corresponding root certificates. I won't be sending this communication
to CAs who have already requested that their corresponding roots be
removed or disabled.
Thanks,
Kathleen
Kyle Hamilton
> On 20/11/2009 23:39, Eddy Nigg wrote:
>> Is *registered domain* not a clear definition for you?
>
>
Registered within the DNS system that the vast majority of Mozilla's
users use. Remember, the users must be considered -- and in this
case, they are a very strong argument toward defining "registered
domain" as "registered with ICANN and its accredited TLD registrars",
since the users use the DNS system that ICANN manages.
> Some of us are old enough to remember "alternate" domain registrars. Some of
> us are even old enough to remember when domains were not global. Some of us
> edit /etc/hosts. Some of us even know about that historical oddity called
> the open source internetworking code. There might even be some of us who
> remember "domains" using the ! not the . and how we had to do our own
> routing :P
(off-topic observations)
I'm glad new.net never gained much traction, though the resistance to
ICANN (a predominantly US corporation, charged by the US government to
manage the internet -- without adequate representation by the rest of
the world and its needs) was very strong. I am glad that OpenDNS
existed, since it did make a very many valid points. (Eventually,
ICANN relegated it to irrelevance, once they came out with the policy
that any TLD should be registerable.)
UUCP bang-pathing was never something I actually used, though I have
done something fairly similar with a messaging and file-sharing
network (NOT the first "this file exists farther away than I can get
it, can you fetch it for me?" network that existed off of ARPAnet, but
the first one that existed that was compatible with what I needed) of
BBSes which could often (but not always) need manual source-routing of
packets through nodes that were known to have higher bandwidth or
more-frequent communications between them.
> There is no law nor contract in place here. There is only custom. It
> requires a simple sentance being added somewhere, and frankly, it's easier
> to add the sentance here, now, in the policy, and establish the IP required,
> than to make a mistake later on and have to deal in court.
>
> Another way of putting it is that it really doesn't matter what those who
> agree think.
>
> What matters is what those who disagree think.
Well, here's my opinion:
The Mozilla Foundation is bound, due to its charter, in everything
that it does to think of its users first. Almost all users are using
the ICANN roots; therefore, everything that MoFo creates (including )
expects that ICANN's root policy (including its admittance of new
TLDs, and registration of 2LDs with at a minimum 2 NS glue records in
the zone and maintenance of Owner/Registrant, Administrative, and
Technical contacts) will be followed.
Certifying Authorities can only certify -- that is, attest to --
something that they know, that does not contradict anything else that
they know. In this case, a CA can know that a company is using a
particular TLD which does not currently exist in ICANN registration.
It is conceivable that the TLD that they do use will be registered by
someone else, and the "internal" domain that the CA issued (perhaps
long-lived) certificates to will be registered by yet someone else.
ICANN's policy is clear on this: ICANN keeps records, and someone who
has records is much more likely to win in any arbitration than someone
who doesn't. It is, by US law at least, the second-to-final arbiter
of who is allowed to have a given domain name. It's very unlikely
that either ICANN's arbiters or the US court system is going to look
kindly on someone who didn't file a claim against the TLD
registration, and then comes filing a claim against someone' using the
same 2LD, that they' actually paid the registrar to register, with the
claim saying "we've been using this domain for years internally at our
organization". (Among other things, ICANN's roots are publicly
available, and such a claim would impose an artificial limit on the
number of domains that would be publicly available. ICANN doesn't run
things for internal company usage.)
The net effect of the aforementioned situation, in the eyes of the CA,
is going to be that the CA may not even know there's an issue during
the life of the certificate, thus not revoke anything that it has
asserted and certified, but not registered or verifiable. (What can
be trusted in that? Thawte's owned by Verisign, which wants to become
the "trusted brand" of the internet.)
Balancing this with the fact that *the only entity authorized to add
entries to the root zone that Mozilla's users use is ICANN*, the fact
that Rob is even asking about "what is a domain?" smacks of either
ignorance of its purpose (to the end-user, as contemplated by Mozilla
policy) or the desire to undermine ICANN's rules and find a way to
register new TLDs itself.
Either way, I define a domain as "a named entity within the DNS tree
rooted at ICANN, which has been properly registered with an
ICANN-accredited registrar, which exists in whois, and for which the
SOA record can be looked up on all of its glue nameserver addresses."
This is the minimum political and technical requirement on what a
domain is that I can see.
Ian, what would *you* define a domain as? For that matter, Rob, what
would you define a domain as?
-Kyle H
Ian G
> On Fri, Nov 20, 2009 at 6:41 PM, Ian G<ia...@iang.org> wrote:
>> On 20/11/2009 23:39, Eddy Nigg wrote:
>>> Is *registered domain* not a clear definition for you?
>>
>>
>> Not really. Registered with who?
>
> Registered within the DNS system that the vast majority of Mozilla's
> users use.
This is a good starting point. The vast majority of Mozilla's users are
public end-users. These people use the public DNS, or as much of it as
their ISPs let them use.
But then there is a small minority of corporate users. These people use
the internal corporation DNS, which most often is the same as the public
DNS. Where it differs is in places like the DoD network, which runs its
own net (or so sayetht the press). I don't know the details, but if I
was running the DoD, I'd be thinking about some non-publically routable
stuff. E.g., issuing these tlds: .army, .usn, .usaf, .corp, .sac,
.log, .... which are routable around their approx 3 million people, and
not routable to their approx 1 billion outsiders.
Of course this is all speculation about DoD. The point is, in classical
internetworking engineering, there isn't a sole, unique piece of
property called "the DNS". There is the public DNS as administered by
Dept of Commerce (or whoever it is these days) and then there are the
private DNSs. The point of the internetworking, and the reason so many
people piled in the early days was that you needed no permission to use
the network.
ICANN and IANA are the unravelling of that dream. Remember when IANA
and ICANN were one person? I recall when we mailed him and asked for a
number, and he mailed it back that day. I gave it back a few years later.
My point here would be, we might think it is time to move on from the
past. But I wouldn't be so hasty as to slam the door on it. That past
built the network, not today's prejudices.
> Remember, the users must be considered -- and in this
> case, they are a very strong argument toward defining "registered
> domain" as "registered with ICANN and its accredited TLD registrars",
> since the users use the DNS system that ICANN manages.
Yes, there is a very strong case for it. Unfortunately, we never made
the case. And it seems that at least one CA didn't like it, and others
also like to use internal TLDs. And, these are so far the silent
majority of CAs, also the more powerful ones.
I for one think there should be a reasonable expectation to be able to
use such things. (Note that this isn't the same thing as saying we must
permit a CA to issue a cert over an internal domain for thing.int.)
>> Some of us are old enough to remember "alternate" domain registrars. Some of
>> us are even old enough to remember when domains were not global. Some of us
>> edit /etc/hosts. Some of us even know about that historical oddity called
>> the open source internetworking code. There might even be some of us who
>> remember "domains" using the ! not the . and how we had to do our own
>> routing :P
>
> (off-topic observations)
> I'm glad new.net never gained much traction, though the resistance to
> ICANN (a predominantly US corporation, charged by the US government to
> manage the internet -- without adequate representation by the rest of
> the world and its needs) was very strong. I am glad that OpenDNS
> existed, since it did make a very many valid points. (Eventually,
> ICANN relegated it to irrelevance, once they came out with the policy
> that any TLD should be registerable.)
Right. These things are important in keeping the US Dept of Commerce,
and it's little plaything, ICANN, honest. They look mickey mouse, until
ICANN starts to look too dictatorial, and then their our cause celebres!
They're a useful part of the ecosystem.
>> There is no law nor contract in place here. There is only custom. It
>> requires a simple sentance being added somewhere, and frankly, it's easier
>> to add the sentance here, now, in the policy, and establish the IP required,
>> than to make a mistake later on and have to deal in court.
>>
>> Another way of putting it is that it really doesn't matter what those who
>> agree think.
>>
>> What matters is what those who disagree think.
>
> Well, here's my opinion:
>
> The Mozilla Foundation is bound, due to its charter, in everything
> that it does to think of its users first.
Some users are more equal than others ;)
> Almost all users are using
> the ICANN roots; therefore, everything that MoFo creates (including )
> expects that ICANN's root policy (including its admittance of new
> TLDs, and registration of 2LDs with at a minimum 2 NS glue records in
> the zone and maintenance of Owner/Registrant, Administrative, and
> Technical contacts) will be followed.
Right. Almost all however does not mean that mofo is bound to ICANN.
Certainly this would be convenient; but remember that ICANN is no
angel, and to the extent that MoFo follows the ICANN lead "for the time
being" that is a useful thing. But if MoFo starts handing over all the
power to control the IP of TLDs to ICANN, without question, this hands
them another thoughtless warrior. Today's ally is tomorrow's enemy.
(As far as I know, the arguments are still going on as to whether the
various countries and regions can wrest the power from ICANN to at least
manage their own spaces without interference. It's far too political
for me to follow in depth...)
> Certifying Authorities can only certify -- that is, attest to --
> something that they know, that does not contradict anything else that
> they know. In this case, a CA can know that a company is using a
> particular TLD which does not currently exist in ICANN registration.
> It is conceivable that the TLD that they do use will be registered by
> someone else, and the "internal" domain that the CA issued (perhaps
> long-lived) certificates to will be registered by yet someone else.
Yes, so if (thought experiment here) we were to allow/encourage CAs to
register domains that might overtly compete with an ICANN registered
domain, then we'd want them to add in a field in the certificate that
said words to effect "non-ICANN-rooted". So something like:
superRegistry = {ICANN, XYZ, new.net, OpenDNS}
This of course is unlikely to ever work, but it's maybe what would be
needed.
The problem with discussing the existance of not-yet-ICANN-granted TLDs
is that, if we accept that all unallocated space also, already belongs
to ICANN, this in itself hands the entire space for the entire tree to
ICANN. This is the last piece in the puzzle for the DNS IP creation.
That means for example if South Tyrolia acquires its long treasured
dream of separating from their Italian overlords, it has to get the
Americans to give it permission (via ICANN) to establish its national
identity. Same for the Basques, Taiwanese in reverse, etc etc.
Keeping ICANN honest is no small issue. And note that MoFo is now an
overtly political player, by dint of entering into the EU v. Mozilla
wars. There's no going back.
> ICANN's policy is clear on this: ICANN keeps records, and someone who
> has records is much more likely to win in any arbitration than someone
> who doesn't. It is, by US law at least, the second-to-final arbiter
> of who is allowed to have a given domain name. It's very unlikely
> that either ICANN's arbiters or the US court system is going to look
> kindly on someone who didn't file a claim against the TLD
> registration, and then comes filing a claim against someone' using the
> same 2LD, that they' actually paid the registrar to register, with the
> claim saying "we've been using this domain for years internally at our
> organization". (Among other things, ICANN's roots are publicly
> available, and such a claim would impose an artificial limit on the
> number of domains that would be publicly available. ICANN doesn't run
> things for internal company usage.)
That's a fair observation. The "custom" that has been established is
now so interwoven with records and contracts that likely it would be
strong in US court. (What about the new Supreme Court of Free Tyrol?)
> The net effect of the aforementioned situation, in the eyes of the CA,
> is going to be that the CA may not even know there's an issue during
> the life of the certificate, thus not revoke anything that it has
> asserted and certified, but not registered or verifiable.
Yeah .. I think it would be an extraordinary thing if a CA could
convince us that a certificate over an internal domain with the same TLD
as a registered ICANN one were ... valid. Like the thing.int case.
Then, there is the unallocated space, and the (3?) never-allocated ones.
So for example, if a company called Apple were to allocate all its
internal domains as hr.apple, tech.apple, and marketing.apple, and then
ask a CA to issue certs for all that ... I would say that is a good
thing. I would even consider it a reasonable risk that there are two
Apples, and they frequently end up together before the judge.
And, because hr.apple is non publically-DNS'able, there's even a good
reason to do this, and the two Apples can live happily in harmony as
long as they don't join in any routing tricks.
And I'd even consider it a reasonable risk for them if yet a third Apple
managed to purchase the property known as .Apple from ICANN. It's a
risk that all three Apples can take, *and* they take it on behalf of
their employees and shareholders.
(This is all just thought experiments ... "in absence of any real
investigation" ... maybe there is a killer argument why not.)
> (What can
> be trusted in that? Thawte's owned by Verisign, which wants to become
> the "trusted brand" of the internet.)
My general rule of thumb is that the word "trust" is never a positive
contribution to any conversation in this space :)
> Balancing this with the fact that *the only entity authorized to add
> entries to the root zone that Mozilla's users use is ICANN*, the fact
> that Rob is even asking about "what is a domain?" smacks of either
> ignorance of its purpose (to the end-user, as contemplated by Mozilla
> policy) or the desire to undermine ICANN's rules and find a way to
> register new TLDs itself.
Yes. Or a skepticism in letting ICANN take over the whole patch.
Perhaps what has been forgotten is the wars in the 1990s over Network
Solutions and its pieces of IP known as .com, .net, .org. The notion
that these hot properties were handed out to trusted friends of
"someone" has always upset many people, and not a few governments.
ICANN to some extent inherits that mistrust.
> Either way, I define a domain as "a named entity within the DNS tree
> rooted at ICANN, which has been properly registered with an
> ICANN-accredited registrar, which exists in whois, and for which the
> SOA record can be looked up on all of its glue nameserver addresses."
> This is the minimum political and technical requirement on what a
> domain is that I can see.
>
> Ian, what would *you* define a domain as?
Me, I define it as a series of words and dots that is interpretable by
the DNS to return an IP#, according to some rules. Perhaps because
that's what the paper I read in 1983 or so said. Obviously, those names
had to be registered somewhere in order to turn them into more precise
routing info.
Then, there is the public domain space, which registers domains
centrally rooted up to a single place. Then there are corporate or
university registries that might do things on a local level.