Security and Stability Advisory Committee (SSAC)

The SSAC is a volunteer group of specialists in the technical security field that provides advice and insight to the ICANN community and the Board.

Контент доступен только на следующих языках

  • English

SAC057 | Executive Summary for SSAC Advisory on Internal Name Certificates

[PDF, 1.14 MB]

This advisory examines the prevalence of internal name certificates, analyzes their security risks, and recommends guidelines for a risk mitigation plan that ICANN should implement. This report arose out of the potential immediate security impacts related to the 2012 New gTLD Program. 

Certificate Authorities (CAs) are organizations that issue digital certificates verifying the ownership of a public key, often relying on the list of currently delegated Top Level Domains (TLDs). However, CAs do not validate the identities for applicants of applied-for gTLDs, which may include internal names not currently resolvable using the public Domain Name System (DNS). As such, domain names with an “internal certification” may result in privacy vulnerabilities allowing a person not associated with the applied-for TLD to obtain a certificate for the TLD with little or no validation. 

Recommendations

  • Recommendation 1: The ICANN Security Team should immediately develop and execute a risk mitigation plan.
    The mitigation plan should include at least:
    • Outreach to the CA/B (Certificate Authority/Browser) forum and CAs (Certificate Authorities), requesting that they treat applied for new gTLDs as if they were delegated TLDs as soon as possible, as well as discussing the broader implications and mitigation steps.
      In doing so, ICANN should seek to create trust relationships between ICANN and CA/B Forum and CAs. Because of the potential for collateral harm to users if disclosure is made public before mitigation is effected, the SSAC believes it is important to conduct correspondence confidentially.
    • A Disclosure Policy as informed by industry best practices for vulnerability disclosure (e.g. CERT / CC vulnerability disclosure). Such a policy should take into consideration that once the disclosure is public, it is trivial to exploit the vulnerability.
    • A communication plan on informing affected parties as determined by the disclosure policy.
    • A contingency plan to be executed if the vulnerability is leaked to the public prematurely, as well as a proactive vulnerability disclosure plan.