Posted today on the SSAC site @ http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf.
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: Executive Summary 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. 1. Introduction 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. 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. 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. 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: * Any server name with a non-public domain name suffix. For example, www.company.local or server1.company.corp. * NetBIOS names or short hostnames, anything without a public domain. For example, Web1, ExchCAS1, or Frodo. * Any IP address in the RFC19181 range. These addresses are reserved for private networks only. 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 www.exampletld is currently an internal name, exampletld could be an applied-for-TLD and www.exampletld may later become operational. 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. Full doc @ http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf - Jason
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
