Skip to main content
Resources

批准的董事会决议 | ICANN 董事会特殊会议

本页面还提供其他语种:

本文档已翻译为多种语言,仅供参考之用。原始官方版本(英文版)可在以下位置找到:https://www.icann.org/resources/board-material/resolutions-2020-04-16-en

  1. 主要议程:
    1. 密钥签名密钥仪式的应急计划
    2. 公共利益注册管理机构 (PIR) 控制权变更
  1. 主要议程:

    1. 密钥签名密钥仪式的应急计划

      鉴于 ICANN 必须通过其附属 PTI 定期生成加密签名,以允许使用 DNSSEC 对根区进行适当的验证。目前,这项工作采用“密钥仪式”的形式每三个月进行一次,来自全球各地的受托社群代表将参与仪式,此工作受到 DNSSEC 实践声明的约束。

      鉴于 2019 年 12 月,一种引发 COVID-19 疾病的新型冠状病毒出现,并在 2020 年 1 月 30 日被世界卫生组织 (WHO) 宣布为国际关注的突发公共卫生事件。2020 年 3 月 11 日,WHO 公开宣布 COVID-19 为全球大流行病。

      鉴于国际旅行限制令以及政府和卫生当局发布了限制聚会的指令,COVID-19 疫情给 ICANN 依照政策举行密钥仪式带来了挑战。

      鉴于为了应对 COVID-19 疫情,ICANN 制定了几项应急计划,决定采用一套渐进式的方法来举行密钥仪式,最初的方案会尽量让更多人员参与,如果无法参与,则会制定一系列渐进式的替代方案。

      鉴于能否在今年晚些时候有序地举办随后的仪式仍然具有很大的不确定性,我们正在考虑其他一些方案,即举办仪式来生成涵盖更长一段时间的加密签名,从而降低此风险。

      兹此发布第 2020.04.16.01 号决议:董事会认为应急计划符合 ICANN 的最佳利益,并符合全球公共利益,董事会授权总裁兼首席执行官或其指定人员在与 PTI 总裁协商后,采取所有必要步骤按照应急计划所述举行密钥签名仪式。

      第 2020.04.16.01 号决议的理由

      1. 简介

        根区密钥签名密钥(根 KSK)使用一种系统进行管理,该系统会故意从逻辑和地理层面分散多个受托角色,以此作为一种安全措施,目的是降低不同的相关方执行意外活动造成冲突的风险。在正常情况下,许多受托角色扮演者需要在 ICANN 管理的两个站点(安全密钥管理设施,缩写为 KMF)之一汇合以举行“仪式”,在仪式上,他们将履行职责执行必要的 KSK 程序,仪式通常每三个月举行一次。

        由于 2020 年的新冠疫情,ICANN 组织员工的流动性受到了限制,提供这些受托角色的其他公司也在颁布类似的政策。此外,各国政府也相继出台了旅行限制令,这同样减少了人员的流动性。有一个很大的风险是,这些事件使参与者的人数低于最低人数要求,进而会损害 KSK 的管理。如果缺乏有效的应急计划,便无法成功执行 KSK 操作,最终将导致 DNS 出现大规模的灾难性故障。

      2. 董事会职权范围

        董事会对此问题所采取的行动与先前对 DNSSEC 密钥签名密钥的运作所做的决策保持一致,可能会给社群带来广泛的影响。过去,ICANN 曾采纳过一项决议,授权继续进行首次密钥签名密钥轮转。

      3. 提案

        董事会目前采取的行动是,授权总裁兼首席执行官与 PTI 总裁协商,采取所有必要措施来实施以下应急计划中所述的密钥签名仪式。应急计划中的仪式管理方法包含两个关键部分:

        1. 采用渐进式的方法举行仪式,最初的方案会尽量让更多人员参与,如果无法参与,则会制定一系列渐进式的替代方案。

        2. 力求实施一项应急计划,在下次的仪式上为更多季度提供签名,这将给运营提供一定的弹性,以应对充满不确定性的形势。

        在 2020 年 4 月 6 日召开的 ICANN 政策管理机构会议上,更新了相关程序和政策以反映这些新程序。具体而言,DNSSEC 实践声明1 (DPS) 正式规定了执行 KSK 管理的方式,并经过了修改,以允许在获得管理层的适当授权后实施呈递的方案。

        3.1 举行第 41 次 KSK 仪式的计划方案

        渐进式方法包含四个方案,按最理想的情况到最不理想的情况排列。每个方案都设有相关的条件和批准流程,满足后才能转至下一个方案:

        3.1.1 方案 A:按原定计划举办 2020 年 4 月的仪式

        第 41 次 KSK 仪式目前定于 4 月 23 日在弗吉尼亚州库尔佩珀举行。如果出席人数达到最低人数要求,其中应包含三名受托社群代表,则可按照正常程序继续在该日期举行仪式。

        主要风险:仪式是否可按原定计划举行取决于受托社群代表的国际流动性,目前他们的出行均受到了严重影响,而这些出行限制在今后会如何变化也难以预测。员工在国内的流动性也受到了影响。

        转为方案 B:如果根据 PTI 总裁的判断,虽然形势无法稳定下来,但能够高度确定仪式可以如期举办,那么方案 B 将成为首选。

        3.1.2 方案 B:举行仪式,并且只选择美国的人员参加

        在库尔佩珀举行的仪式中,七个受托社群代表中有三个位于美国,其中两个位于东海岸,一个位于西海岸。三位中只有两位可以参加在选定日期举行的仪式,因此这个方案将确定一个备选日期,以便三人均可参加。

        主要风险:此方案取决于受托社群代表和员工在国内的持续流动性。还必须假定必要人员不会生病或因其他原因不能参加,因为该方案没有制定有人缺席时的备用计划。

        转为方案 C:如果根据 ICANN 总裁的判断,可以高度确定仪式无法举办或者因为其他原因无法在 5 月 8 日前举办,那么方案 C 将成为首选。

        3.1.3 方案 C:举行仪式,并且只选择位于洛杉矶的人员参加,而且出席人数刚好达到最低人数要求。

        KMF 被特意设计为允许在灾难恢复仪式中只需工作人员出席仪式,以确保能够根据需要举办密钥仪式。达到最低人数要求的工作人员可以在短时间内在埃尔塞贡 KMF 举行密钥仪式。然而,这个方案对受信社群代表亲自出席的人数不做限制。

        主要风险:此方案对工作人员和承包商亲自参与(即未丧失行动能力或行动未受限)的人数设有最低要求。它违反了参加密钥仪式的标准要求,但在灾难恢复程序范围内,它被视为其中的一个方案。

        转为方案 D:如果仪式不能在 6 月 19 日之前举行,则方案 D 将成为最终选择。ICANN 董事会将做出采用方案 D 的最终决定。

        3.1.4 方案 D:暂停签署 DNS 根区

        如果想不到任何方法来激活 KSK 并执行签名操作,那么这是最后的选择。必须立即进行大规模的教育活动,指导解析器运营商禁用 DNSSEC 验证。由于无法确保在全球范围内实施,因此出现大规模中断的风险很高,而高风险将对 DNSSEC 作为一种技术所受到的信任造成致命性的伤害。

        大家都认为此方案实施的可能性很低,尽管如此,这确实是最终方案。如果不执行方案,在没有进行成功的密钥签名仪式的情况下,从 2020 年 7 月起,DNSSEC 验证将失败。

        3.2 签署涵盖两个季度的密钥材料

        一次标准的密钥仪式一般会生成涵盖一个季度(3 个月)的签名。在本次密钥仪式中生成涵盖更多季度的签名,将在未来充满不确定性的时期为根区运营提供更大的弹性。如果出现了长期威胁,我们可视需要利用这段时间考虑对当前的密钥仪式模式进行长期更改。根据受托社群代表的反馈,我们预计将为三个季度、共计九个月生成签名。这样一来,在 2020 年剩余时间内将无需举行密钥签名仪式,而且下一次签名仪式在 2021 年 2 月左右举行即可。额外季度的密钥材料将由 ICANN 安全保管,并根据正常的时间表发给根区维护人。

      4. 利益相关方协商

        在筹备这个方法的过程中,工作人员与以下人员或机构进行了互动:

        • 计划参加 2020 年 4 月仪式的人员;
        • 第三方审计机构;
        • 根区维护人;
        • 支持密钥仪式的供应商;
        • 受托社群代表和之前出席仪式的人员;
        • ICANN 的根区发展审核委员会,该委员会的成员包括来自 ICANN 各主办组织和咨询委员会的代表;以及
        • DNS-OARC 运营电子邮件清单;以及
        • KSK 轮转项目电子邮件清单。

        此方法的例行通知也发到了我们的公告电子邮件清单,该清单中大约有 700 个对根 KSK 管理感兴趣的订阅者。讨论的焦点是提案要素的可行性,它们对运营和控制环境的影响,以及为了保持 ICANN 在管理 KSK 方面所享有的较高信任度而需采取的措施。

      5. 财务影响

        除了与 KSK 管理有关的正常运营成本外,该提案预计不会对财务产生重大影响。

      6. 公众协商要求

        此问题与 IANA 域名职能运营有关,根据与 ICANN 签订的合同由 PTI 执行。在 KSK 运营中使用的程序必须获得政策管理机构的批准,该机构是 ICANN 组织内部的一个委员会。没有制定正式的公众意见要求,但是 IANA 工作人员将继续与受托社群代表及其他利益相关方协商,以实施和适当修改这些计划。我们将制定一项沟通策略,帮助大家了解任何运营上的变化和影响。

      7. 公共利益

        董事会的行动符合公共利益和 ICANN 的使命,因为它有助于继续确保互联网唯一标识符系统的稳定和安全运营。无法举行下一次密钥仪式将导致从 2020 年 7 月开始,全球的 DNS 解析出现大规模的失败,因为 DNSSEC 将停止运行。董事会的行动有助于确保启用 DNSSEC 的设备能够解析任何域名。

      8. 主要风险

        董事会在审议此行动时考虑了以下风险因素。

        8.1 参与者的出行受到限制

        该计划要解决的主要风险是参与者无法出席密钥仪式。建议的解决方案是采用渐进式的方法,采用不同的方案举办仪式,包括仅与洛杉矶都会区的工作人员举行仪式,这样一来便无需搭乘飞机或跨州出行。

        8.2 设施运营商暂时不准任何人进入设施

        为 KMF 提供设施的公司可能会因为疫情的关系而暂时不准任何人进入设施。建议的解决方案是向其高级管理层(如有必要,可通过受信任的代理人)提出建议,将其作为一个例外,理由是需要举行这一仪式以支持关键的互联网基础设施和互联网运作。ICANN 已经在和美国政府讨论,如果有必要保留举行密钥仪式所需的访问权限,则颁布特殊指导意见。

        8.3 政府暂时不准许进入设施,及/或限制出行

        各级政府可能会对旅行或聚会实行限制,这会妨碍我们举行仪式。ICANN 可以通过适当的渠道建议政府作出例外处理(如上一节所述),并指出需要举行这一仪式以支持关键的互联网基础设施和互联网运作。特别是,ICANN 可以利用与政府之间建立的关系来寻求此类豁免。

        8.4 工作人员生病或身体不适

        如果因为工作人员生病、被隔离或无法出席,导致未能达到工作人员的最低人数要求,则无法举行仪式。主要的解决方案是,PTI 工作人员和其他来自 ICANN 组织的支持人员从 2020 年 3 月开始,便一直在遵守保持社交距离的指令,以限制潜在的疾病传播。此外,大约有三个月的窗口期可用来审阅所提出的备选方案,并有足够的时间来调整每个备选方案中的确切日期,以允许恢复和继续举行。

        8.5 方案 C 破坏了社群对 KSK 管理权的信任

        在没有采取标准保护措施(包括第三方社群见证人亲自出席 KMF)的情况下,举行仪式可能会降低社群对 KSK 管理和管理权的信任度。为了解决这个问题,仪式将在第三方审计员的监督下按照审计标准举行,且所有材料(包括综合审计录像和仪式上所用的材料)将按标准在线发布。我们将提供并优化仪式的现场直播,让不能到场的人员观看并提出问题或疑问。我们已就如何举行方案 C 的仪式咨询了 TCR 及其他利益相关方,所以仪式已经在有必要限制的情况下,最大限度满足了他们的要求。我们将努力获得 TCR 及其他利益相关方的认同,让他们知道这个方案已经是备选方案中的最佳方案了。

    2. 公共利益注册管理机构 (PIR) 控制权变更

      该议项已从议程中删除。


1 https://www.iana.org/dnssec/dps

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."