<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<title>Microsoft Word - SAC057 SSAC Advisory Internal Name Certificates 15 March 2013.docx</title>
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: Calibri, sans-serif; ">
<div>Posted today on the SSAC site @ <a href="http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf">http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf</a>.</div>
<div><br>
</div>
<div>Worth reading, especially if you have internal namespace (and associated internally generated SSL certificates) that overlaps with a new gTLD name. From the exec summary & intro:</div>
<div>
<div class="page" title="Page 4">
<div class="section">
<div class="layoutArea">
<div class="column">
<p><span style="font-size: 16.000000pt; font-family: 'Helvetica'; font-weight: 700">Executive Summary
</span></p>
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">The SSAC has identified a Certificate Authority (CA) practice that, if widely exploited, could pose a significant risk to the privacy and integrity of secure Internet communications.
This CA practice could impact the new gTLD program. The SSAC thus advises ICANN take immediate steps to mitigate the risks.
</span></p>
<p><span style="font-size: 16.000000pt; font-family: 'Helvetica'; font-weight: 700">1. Introduction
</span></p>
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">Certificate Authorities, also known as Certification Authorities, (CAs) are organizations that issue digital certificates. These digital certificates certify the ownership of a public
key by the named subject of the certificate. This allows others to rely upon signatures or assertions made by the private key that corresponds to the certified public key.
</span></p>
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">The CAs typically validate the identities of requestors before they issue certificates. For example, when Internet users browse to https://www.myicann.org/, their browsers know it is
the real myicann.org because GoDaddy, a CA, has vouched the registered holder of myicann.org and issued a certificate to it. This system breaks down, however, if CAs are unable to validate the applicants they vouch for and their authority over the domain name
for which the certificate is applied. </span></p>
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">One such instance is the “Internal Name” certificate (also known as “non-fully qualified domain names” or non-FQDNs). An Internal Name certificate contains a name that is not currently
resolvable using the public Domain Name System (DNS) and which is assumed to be for private use only.
</span></p>
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">An internal name is a domain or Internet Protocol (IP) address that is part of a private network. These internal names are not allocated to any specific organization and therefore cannot
be verified. Common examples of internal names are: </span></p>
<ul>
<li style="font-size: 12.000000pt; font-family: 'Symbol'">
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">Any server name with a non-public domain name suffix. For example, www.company.local or server1.company.corp.
</span></p>
</li><li style="font-size: 12.000000pt; font-family: 'Symbol'">
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">NetBIOS names or short hostnames, anything without a public domain. For example, Web1, ExchCAS1, or Frodo.
</span></p>
</li><li style="font-size: 12.000000pt; font-family: 'Symbol'">
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">Any IP address in the RFC1918</span><span style="font-size: 6.000000pt; font-family: 'TimesNewRomanPSMT'; vertical-align: 5.000000pt">1
</span><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">range. These addresses are reserved for private networks only.
</span></p>
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">Internal names are not verifiable by CAs because it is not possible to look up who owns them. When determining whether a certificate application is for internal use or not, CAs often
rely on the list of currently delegated Top Level Domains (TLDs) and not, for instance, against the list of the TLDs applied for in ICANN’s new Generic TLD (gTLD) program. For instance, although
</span><span style="font-size: 12.000000pt; font-family: 'CourierNewPSMT'">www.exampletld
</span><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">is currently an internal name, </span><span style="font-size: 12pt; font-family: CourierNewPSMT; ">exampletld
</span><span style="font-size: 12pt; font-family: TimesNewRomanPSMT; ">could be an applied-for-TLD and
</span><span style="font-size: 12pt; font-family: CourierNewPSMT; ">www.exampletld
</span><span style="font-size: 12pt; font-family: TimesNewRomanPSMT; ">may later become operational.</span></p>
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'"><span style="font-size: 12pt; ">In this advisory, the SSAC examines the prevalence of internal name certificates, analyzes the security risk it imposes, and advises ICANN to take a few
mitigation steps. The SSAC also wishes to highlight that although this practice has immediate impact to new gTLDs, it has larger security ramifications.</span> </span></p>
</li></ul>
</div>
</div>
</div>
</div>
</div>
<div>Full doc @ <a href="http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf">http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf</a></div>
<div><br>
</div>
<div><br>
</div>
<div>- Jason</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div><br>
</div>
</div>
</body>
</html>