非官方中文译本声明：本页为 IETF RFC 6698《The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc6698。

RFC 6698《基于 DNS 的命名实体认证（DANE）：TLSA 记录》中文译本

IETF · RFC 6698 · 标准跟踪（Standards Track）· 2012 年 8 月

摘要

互联网上的加密通信常使用传输层安全（TLS）协议，而 TLS 依赖第三方来为其所用的密钥背书。本文档改进了这一状况：它使域名的管理员能够指定该域名下 TLS 服务器所使用的密钥。这需要 TLS 客户端软件作出相应的配套改进，但无需改动 TLS 服务器软件。

1. 引言

1.1. 背景与动机

通过互联网进行通信的应用往往需要防止其通信被窃听、篡改或伪造。传输层安全（TLS）协议使用信道加密，在互联网上提供了这类通信安全能力。

加密系统的安全属性在很大程度上取决于其所使用的密钥。如果私钥被泄露，或者公钥可以被替换为伪造密钥（即与证书中所标识实体不相对应的密钥），那么这些系统所提供的安全性就微乎其微、甚至荡然无存。

TLS 使用证书来绑定密钥与名称。证书把一个公布的密钥与其他信息（例如使用该密钥的服务名称）结合在一起，并由另一个密钥对这一组合进行数字签名。只有在人们信任那个为证书签名的另一密钥时，证书中的密钥才有意义。如果那个密钥本身也被泄露或被替换，那么它的签名对于证明第一个密钥的任何属性都毫无价值。

在互联网上，多年来这一问题一直由称为「证书颁发机构」（Certification Authorities，CA）的实体来解决。CA 严密保护自己的私钥，同时把公钥提供给构建 TLS 客户端的软件厂商。随后 CA 签发证书，并将其提供给 TLS 服务器。TLS 客户端软件把这一组 CA 密钥用作「信任锚」（trust anchors），以校验其从 TLS 服务器收到的证书上的签名。客户端软件通常允许任何 CA 为任何其他证书签名并使之生效。

TLS 所依赖的公共 CA 模型存在根本性的脆弱之处，因为它允许其中任何一个 CA 为任何域名签发证书。只要有一个受信任的 CA 背弃其所受托付——无论是主动为之，还是因为对其秘密与能力的保护不够严密——都可能瓦解任何 TLS 所用证书所提供的安全性。这一问题之所以产生，是因为被攻陷的 CA 可以签发一份包含伪造密钥的替换证书。近来针对 CA 或其受信任合作伙伴的攻陷事件已经导致了非常严重的安全问题，例如多国政府试图对数百万用户所信赖的主流 TLS 保护网站进行监听和/或颠覆。

DNS 安全扩展（DNSSEC）提供了一个类似的模型：由受信任的密钥为不受信任的密钥的信息签名。然而，DNSSEC 带来了三项重要改进。其一，密钥被绑定到域名系统（DNS）中的名称上，而不是绑定到任意的标识字符串上；这对互联网协议而言更为便利。其二，任何域名的已签名密钥都可以通过标准 DNSSEC 协议的一次直接查询在线获取，因此不存在分发已签名密钥的难题。最重要的是，与某个域名相关联的密钥只能由与该域名的父域相关联的密钥来签名；例如，"example.com" 的密钥只能由 "com" 的密钥签名，而 "com" 的密钥只能由 DNS 根来签名。这就阻止了不可信的签名者去攻陷其自身子域之外的任何人的密钥。与 TLS 类似，DNSSEC 也依赖内置于 DNSSEC 客户端软件中的公钥，但这些密钥仅来自单一的根域，而非来自众多的 CA。

基于 DNS 的命名实体认证（DANE）提供了这样一种选择：利用 DNSSEC 基础设施来存储并签名 TLS 所使用的密钥与证书。DANE 被设想为把公钥绑定到 DNS 名称的一种更可取的基础，因为为「公钥数据与 DNS 名称之绑定」作担保的实体，恰恰就是负责管理相应 DNS 名称的实体。虽然由此形成的体系仍存在残余的安全脆弱性，但它把任一实体所能作出的断言范围加以限制，使之与 DNS 层级所施加的命名范围相一致。因此，DANE 体现了当前公共 CA 模型所缺失的「最小特权原则」这一安全理念。

1.2. 保护域名与服务器证书之间的关联

TLS 客户端通过与 TLS 服务器交换消息来发起连接。对许多应用协议而言，客户端会使用 DNS 查询服务器的名称，以获得与该名称关联的互联网协议（IP）地址。随后它向该地址上的特定端口发起连接，并在那里发送初始消息。然而，客户端此时尚不知道是否有攻击者在其通信到达 TLS 服务器之前对其加以拦截和/或篡改。它甚至无从知晓与该域名关联的真实 TLS 服务器是否曾收到过它的初始消息。

TLS 中来自服务器的首个响应可能包含一份证书。为使 TLS 客户端能够认证自己正在与预期的 TLS 服务器通信，客户端必须验证这份证书与其用于访问该服务器的域名相关联。当前，客户端必须从证书中提取域名，并且必须成功地验证该证书，包括将其链接到某个信任锚。

还有另一种方式，可以在不信任外部 CA 的情况下认证服务器证书与预期域名之间的关联。既然某域名的 DNS 管理员被授权给出该区（zone）的标识信息，那么允许该管理员同时在域名与「可能被该域名下某台主机所使用的证书」之间建立权威性绑定，也就顺理成章。实现这一点最简便的办法就是使用 DNS，并以 DNSSEC 来保护该绑定。

此类功能有诸多用例。[RFC6394] 列出了本文档所定义的 DNS RRtype 所适用的那些用例。[RFC6394] 还列出了许多需求，本文档被认为满足其中的大部分。第 5 节详细阐述了本文档对这些用例的适用性。本文档中的协议一般可称为「DANE TLSA」协议。（"TLSA" 并不是任何缩写，它只是该 RRtype 的名称。）

本文档同时适用于 TLS [RFC5246] 与数据报 TLS（DTLS）[RFC6347]。为使文档更易读，正文大多只提及 "TLS"，但在所有情形下，其含义均为「TLS 或 DTLS」。虽然本段中的引用指向 TLS 与 DTLS 的 1.2 版本，但 DANE TLSA 协议同样可以与更早版本的 TLS 和 DTLS 一起使用。

本文档仅涉及如何将 TLS 与 DTLS 的证书安全地与主机名相关联；从 DNS 中为其他协议获取证书的问题由其他文档处理。例如，IPsec 的密钥由 [RFC4025] 涵盖，安全外壳（SSH）的密钥由 [RFC4255] 涵盖。

1.3. 保护证书关联的方法

「证书关联」（certificate association）由两部分构成：一段用于标识某证书的信息，以及服务器应用所运行的域名。信任锚与域名的组合也可以构成一个证书关联。

一次 DNS 查询可以返回多个证书关联，例如在服务器正从一份证书切换到另一份证书的情形下（详见附录 A.4）。

本文档仅适用于 PKIX [RFC5280] 证书，不适用于其他格式的证书。

本文档定义了一种安全方法，用以借助 DNS 把从 TLS 服务器获得的证书与某个域名相关联；这些 DNS 信息需要受到 DNSSEC 的保护。由于证书关联是基于一次 DNS 查询而取得的，查询中的域名按定义即与该证书相关联。请注意，本文档不涉及如何为那些依赖 SRV、NAPTR 及类似 DNS 资源记录的应用协议把证书与域名相关联。预期将来会有文档涵盖建立此类关联的方法，那些文档可能需要、也可能不需要更新本文档。

DNSSEC 定义于 [RFC4033]、[RFC4034] 与 [RFC4035]，它使用加密密钥与数字签名来提供对 DNS 数据的认证。从 DNS 中取得并经 DNSSEC 验证通过的信息，由此被证明是权威数据。为确保数据来源的证明成立，需要对所有使用 DNSSEC 的响应校验其 DNSSEC 签名。

本文档不规定 DNSSEC 验证如何进行，因为对于客户端如何获得经验证的 DNSSEC 结果，存在许多不同的方案，例如：来自在应用内部实现的 DNSSEC 感知解析器；来自运行该应用的机器上的可信 DNSSEC 解析器；或者来自应用通过经认证且受完整性保护的信道或网络与之通信的可信 DNSSEC 解析器。这在 [RFC4033] 的第 7 节中有更详细的描述。

本文档仅涉及如何使用 DNSSEC 安全地获取证书关联的 DNS 信息；其他安全 DNS 机制不在本文范围之内。

1.4. 术语

本文档中的关键词 "MUST"（必须）、"MUST NOT"（不得）、"REQUIRED"（需要）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（应当）、"SHOULD NOT"（不应）、"RECOMMENDED"（推荐）、"MAY"（可以）和 "OPTIONAL"（可选）应按照 RFC 2119 [RFC2119] 中的描述进行解释。

本文档还使用了标准的 PKIX、DNSSEC、TLS 与 DNS 术语。这些术语分别参见 [RFC5280]、[RFC4033]、[RFC5246] 以及 STD 13 [RFC1034] [RFC1035]。此外，与受 TLS 保护的应用服务及 DNS 名称相关的术语取自 [RFC6125]。

2. TLSA 资源记录

TLSA DNS 资源记录（RR）用于把一份 TLS 服务器证书或公钥与该记录所在的域名相关联，从而构成一个「TLSA 证书关联」。TLSA RR 如何被解释，其语义在本文档后续部分给出。

TLSA RR 类型的类型值定义于第 7.1 节。

TLSA RR 与类（class）无关。

TLSA RR 对生存时间（TTL）没有特殊要求。

2.1. TLSA RDATA 线格式

TLSA RR 的 RDATA 由一个单字节的证书用途字段、一个单字节的选择器字段、一个单字节的匹配类型字段，以及证书关联数据字段构成。

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Cert. Usage  |   Selector    | Matching Type |               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
/                                                               /
/                 Certificate Association Data                  /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.1. 证书用途字段

一个单字节值，称为「证书用途」（certificate usage），用以指定所提供的关联将如何与 TLS 握手中出示的证书进行匹配。该值定义在一个新的 IANA 注册表中（参见第 7.2 节），以便将来更容易增补新的证书用途。本文档定义的证书用途如下：

本文档所定义的证书用途明确地仅适用于以 DER 编码 [X.690] 表示的 PKIX 格式证书。如果 TLS 日后允许其他格式，或者对本 RRtype 作出的扩展接受了其他格式的证书，那么这些证书将需要各自专属的证书用途取值。

2.1.2. 选择器字段

一个单字节值，称为「选择器」（selector），用以指定服务器所出示的 TLS 证书中的哪一部分将与关联数据进行匹配。该值定义在一个新的 IANA 注册表中（参见第 7.3 节）。本文档定义的选择器如下：

（请注意，本文档中「选择器」（selector）一词的用法，与域名密钥标识邮件（DKIM）[RFC6376] 中「选择器」一词的用法完全无关。）

2.1.3. 匹配类型字段

一个单字节值，称为「匹配类型」（matching type），用以指定证书关联以何种形式呈现。该值定义在一个新的 IANA 注册表中（参见第 7.4 节）。本文档定义的类型如下：

如果 TLSA 记录的匹配类型为某种散列，那么让该记录使用与证书签名中所用相同的散列算法（在可能的情况下），将有助于那些只支持少量散列算法的客户端。

2.1.4. 证书关联数据字段

本字段指定待匹配的「证书关联数据」。对于匹配类型 0，这些字节是原始数据（即完整证书或其 SubjectPublicKeyInfo，取决于选择器）；对于匹配类型 1 与 2，则是原始数据的散列值。这些数据所指的是该关联中的证书，而非 TLS 的 ASN.1 Certificate 对象。

2.2. TLSA RR 呈现格式

RDATA 部分的呈现格式（如 [RFC1035] 所定义）如下：

2.3. TLSA RR 示例

在下列示例中，域名依照第 3 节的规则构成。

一份 PKIX CA 证书的散列（SHA-256）关联示例：

_443._tcp.www.example.com. IN TLSA (
   0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
         7983a1d16e8a410e4561cb106618e971 )

一份 PKIX 端实体证书的主体公钥散列（SHA-512）关联示例：

_443._tcp.www.example.com. IN TLSA (
   1 1 2 92003ba34942dc74152e2f2c408d29ec
         a5a520e7f2e06bb944f4dca346baf63c
         1b177615d466f6c4b71c216a50292bd5
         8c9ebdd2f74e38fe51ffd48c43326cbc )

一份 PKIX 端实体证书的完整证书关联示例：

_443._tcp.www.example.com. IN TLSA (
   3 0 0 30820307308201efa003020102020... )

3. 用于 TLSA 证书关联的域名

除非存在与本文档不同的、针对特定协议的规范，TLSA 资源记录均存放于带前缀的 DNS 域名之下。该前缀按以下方式构造：

  1. 假定某项基于 TLS 的服务所在端口号的十进制表示，前置一个下划线字符（"_"），成为所构造域名中最左侧的标签。该数字不含前导零。
  2. 假定某项基于 TLS 的服务所在传输层的协议名称，前置一个下划线字符（"_"），成为所构造域名中左起第二个标签。本协议所定义的传输名称为 "tcp"、"udp" 与 "sctp"。
  3. 把基础域名追加到步骤 2 的结果之后，即构成完整的域名。基础域名是该 TLS 服务器的完全限定 DNS 域名 [RFC1035]，并附加一项限制：每个标签都必须（MUST）符合 [RFC0952] 的规则。后一项限制意味着，若查询针对的是国际化域名，则必须（MUST）使用 [RFC5890] 所定义的 A-label 形式。

例如，若要为运行在 "www.example.com" 的 443 端口上、启用 TLS 的 HTTP 服务器请求 TLSA 资源记录，则在请求中使用 "_443._tcp.www.example.com"。若要为运行在 "mail.example.com" 的 25 端口上、使用 STARTTLS 协议的 SMTP 服务器请求 TLSA 资源记录，则使用 "_25._tcp.mail.example.com"。

4. TLSA 记录在 TLS 中的使用

本文档第 2.1 节定义了强制性的匹配规则，用于比对来自 TLSA 证书关联的数据与从 TLS 服务器收到的证书。

待建立的 TLS 会话必须（MUST）对应于 TLSA 查询中所给出的特定端口号与传输名称。

某些运行于 TLS 之上的应用的规范（例如面向 HTTP 的 [RFC2818]）要求服务器证书带有与客户端所期望的主机名相匹配的域名。另一些规范（例如 [RFC6125]）则详细说明了如何将 PKIX 证书中给出的身份标识与用户所期望的身份标识进行匹配。

如果某条 TLSA 记录的证书用途为 2，则相应的 TLS 服务器应当（SHOULD）像当前发送中间证书那样，把被引用的那份证书一并发出。

4.1. 可用的证书关联

本协议的实现会针对 TLSA 记录发起 DNS 查询，使用 DNSSEC 验证这些记录，并依据所得到的 TLSA 记录及其验证状态来调整自己对 TLS 服务器的响应。

判定某个 TLSA RRSet 是否可用，必须（MUST）基于其 DNSSEC 验证状态（如 [RFC4033] 所定义）。

自行验证 DNSSEC 签名的客户端必须（MUST）使用标准的 DNSSEC 验证流程。依赖其他实体执行 DNSSEC 签名验证的客户端，必须（MUST）在自身与验证方之间使用安全机制。与其他主机之间安全传输的示例包括 TSIG [RFC2845]、SIG(0) [RFC2931] 以及 IPsec [RFC6071]。请注意，仅仅与一台不做 DNSSEC 签名验证的 DNS 解析器之间使用安全传输是不够的。有关外部验证方的更多安全考虑，参见第 8.3 节。

如果某个证书关联所含的证书用途、选择器或匹配类型是 TLS 客户端所无法理解的，则该证书关联必须（MUST）被视为不可用。如果某份证书的比对数据格式有误，则该证书关联必须（MUST）被视为不可用。

如果某个证书关联所含的匹配类型或证书关联数据使用了按 TLS 客户端策略判定为过弱的密码算法，则该证书关联必须（MUST）被视为不可用。

如果应用从一次 DNS 请求或其缓存中得到的可用证书关联数量为零，则它按常规方式处理 TLS，不接受 TLSA 记录的任何输入。如果应用得到了一个或多个可用的证书关联，则它会尝试将每个证书关联与 TLS 服务器的端实体证书进行匹配，直至找到一次成功匹配为止。在 TLS 握手期间，如果没有任何证书关联与 TLS 服务器所给出的证书相匹配，则 TLS 客户端必须（MUST）中止该握手。

能够把用户导向其所控制服务器的攻击者，很可能也有能力阻断用户发出的 DNS 请求或发往用户的 DNS 响应。因此，为了从证书用途 0 或 1 中获得任何安全收益，发送 TLSA 记录请求的应用需要取得以下两者之一：包含 TLSA 记录的有效签名响应，或者「该域名处于不安全或不确定状态」的确证。如果一次 TLSA 记录请求未能满足上述两项标准之一，而应用仍然继续进行 TLS 握手，那么该应用并未从 TLSA 中获得任何收益，并且不应（SHOULD NOT）作出任何表明「已应用 TLSA」的内部或外部指示。如果某应用具有已开启 TLSA 使用的配置项，或存在任何表明 TLSA 正在使用中的迹象（无论其是否可配置），那么在上述两项标准均未被满足时，该应用要么不得（MUST NOT）发起 TLS 连接，要么必须（MUST）中止 TLS 握手。

应用可以在发起 TLS 握手之前执行 TLSA 查找，也可以在 TLS 握手期间进行：选择权在客户端。

5. TLSA 与 DANE 的用例及需求

TLSA 中定义的各类证书关联与 [RFC6394] 的相应章节一一对应。[RFC6394] 第 3 节中的用例在本文档中的覆盖情况如下：

[RFC6394] 第 4 节中的需求在本文档中的覆盖情况如下：

6. 强制实现的特性

符合本规范的 TLS 客户端必须（MUST）能够正确解释证书用途为 0、1、2 与 3 的 TLSA 记录。符合本规范的 TLS 客户端必须（MUST）能够使用选择器类型 0 与 1、以及匹配类型 0（不使用散列）与匹配类型 1（SHA-256），把证书关联与 TLS 握手中的证书进行比对，并且应当（SHOULD）能够使用匹配类型 2（SHA-512）进行此类比对。

7. IANA 考虑

IANA 已完成本节所述的各项分配。

在以下各节中，TLSA 证书用途选择了 "RFC Required"（需要 RFC）策略，而选择器与匹配类型选择了 "Specification Required"（需要规范）策略；这是因为相较于新的选择器与匹配类型，实现者要正确实现新的证书用途，很可能需要更大篇幅的细节说明。

7.1. TLSA RRtype

本文档使用了一种新的 DNS RR 类型 TLSA，其取值（52）由 IANA 从「域名系统（DNS）参数」注册表的「资源记录（RR）类型」子注册表中分配。

7.2. TLSA 证书用途

本文档创建了一个新的注册表「TLSA Certificate Usages」（TLSA 证书用途）。该注册表的策略为 "RFC Required"。注册表的初始条目为：

Value    Short description                       Reference
----------------------------------------------------------
0        CA constraint                           RFC 6698
1        Service certificate constraint          RFC 6698
2        Trust anchor assertion                  RFC 6698
3        Domain-issued certificate               RFC 6698
4-254    Unassigned
255      Private use

向该注册表提交的申请可以请求尚未分配的特定取值。

7.3. TLSA 选择器

本文档创建了一个新的注册表「TLSA Selectors」（TLSA 选择器）。该注册表的策略为 "Specification Required"。注册表的初始条目为：

Value    Short description                       Reference
----------------------------------------------------------
0        Full certificate                        RFC 6698
1        SubjectPublicKeyInfo                    RFC 6698
2-254    Unassigned
255      Private use

向该注册表提交的申请可以请求尚未分配的特定取值。

7.4. TLSA 匹配类型

本文档创建了一个新的注册表「TLSA Matching Types」（TLSA 匹配类型）。该注册表的策略为 "Specification Required"。注册表的初始条目为：

Value    Short description                       Reference
----------------------------------------------------------
0        No hash used                            RFC 6698
1        SHA-256                                 RFC 6234
2        SHA-512                                 RFC 6234
3-254    Unassigned
255      Private use

向该注册表提交的申请可以请求尚未分配的特定取值。

8. 安全考虑

本文档所描述的 DNS RRtype，其安全性依赖于 DNSSEC 的安全性，以核实 TLSA 记录未被篡改。

一个恶意的 DNS 管理员如果更改了某域名的 A、AAAA 和/或 TLSA 记录，就可能使客户端访问到一台未经授权、却显得已获授权的服务器——除非客户端执行 PKIX 证书路径验证并拒绝该证书。反正该管理员多半也能从某个 CA 那里弄到一份签发的证书，因此这并不构成额外的威胁。

如果在区中添加或更改 TLSA 数据的认证机制弱于更改 A 和/或 AAAA 记录的认证机制，那么一个能够把流量重定向到自己站点的中间人，只要能利用那个较弱的认证机制，就有可能在 TLS 中冒充被攻击的主机。对 DNS 进行认证的更好设计，应当是对某一域名的所有 DNS 增改操作采用同等级别的认证。

安全套接层（SSL）代理有时会充当 TLS 客户端的中间人。在这类场景中，客户端会添加一个新的信任锚，其私钥保存在 SSL 代理上；代理拦截 TLS 请求，与目标主机建立新的 TLS 会话，并使用一份链接到「由代理安装在客户端中的信任锚」的证书与客户端建立 TLS 会话。在此类环境中，使用 TLSA 记录将使 SSL 代理无法按预期工作，因为 TLS 客户端会从 DNS 得到一个证书关联，而它与 SSL 代理对客户端所使用的证书并不匹配。客户端看到代理为所谓目的地出示的新证书后，将不会建立 TLS 会话。

客户端如何处理信任锚中所含的任何信息，属于本地策略事项。本规范并不强制要求服务器的域名管理员对此类信息进行检查或验证。

如果服务器的证书被吊销，或者服务器与某信任锚之间证书链上的某个中间 CA 的证书被吊销，那么一条证书用途为 2、且与被吊销证书相匹配的 TLSA 记录，实质上会使该吊销失效——因为客户端会把这份被吊销的证书当作信任锚，从而不去检查其吊销状态。有鉴于此，域名管理员需要负起责任，确保证书用途为 2 的 TLSA 记录中所用的密钥或证书确实能够充当可靠的信任锚。

以证书用途 2 通过 TLSA 交付的证书，从根本上改变了 TLS 服务器端实体证书的评估方式。例如，服务器的证书可能经由一个带有某些策略限制的中间 CA 链接到某个既有 CA，而该证书无法通过这些策略限制，因而通常会被拒绝。那个中间 CA 可以给自己签发一份不含这些策略限制的新证书，并告知其客户以证书用途 2 使用这份证书。这实质上使得一个中间 CA 得以成为信任锚，去为那些最终用户本以为会链接到某个既有信任锚的证书背书。

如果管理员希望停止使用某条 TLSA 记录，只需将其从 DNS 中移除即可。常规客户端会在 TTL 过期后停止使用该 TLSA 记录。在被移除的 TLSA 记录之 RRsig 的到期日之后，针对该 TLSA 记录的重放攻击将不再可能。

TLSA 记录的生成者应当意识到，客户端是否完全信任从 TLSA 记录中取得的证书关联，可能取决于本地策略。虽然此类信任仅限于发起 TLSA 查询时所针对的特定域名、协议与端口，但本地策略仍可能拒绝接受该证书（例如出于密码强度过弱之类的原因）——这与 PKIX 信任锚的情形是一样的。

8.1. DANE 与公共 CA 的比较

如上所述，本文档所描述的 DNS RRtype，其安全性依赖于 DNSSEC 的安全性，以核实 TLSA 记录未被篡改。本节阐述公共 CA 的安全性与 TLSA 的安全性在哪些方面相似、在哪些方面不同。本节同样适用于其他与安全相关的 DNS RRtype，例如用于 IPsec 与 SSH 的密钥记录。

DNSSEC 通过把 DNSKEY、DS 或 DLV 资源记录与相应的 RRSIG 记录相结合，来构成「证书」（即身份与密钥的绑定）。这些记录随后形成一条签名链，从客户端的信任锚一直延伸到所关注的那条 RR。

尽管 DNSSEC 协议并未强制要求，DNSKEY 通常会带有 SEP 标志，用以指示该密钥是区签名密钥（ZSK）还是密钥签名密钥（KSK）。ZSK 保护区内的记录（包括 DS 与 DLV 记录），而 KSK 保护 ZSK 的 DNSKEY 记录。这使得 KSK 可以离线存放。

TLSA RRtype 使得来自 DNSSEC PKI 层级的密钥能够为「封装在 PKIX 证书中、面向特定主机名、协议与端口的密钥」提供认证。

除 DLV RRtype 之外，上述所有「证书」都会把它们所标识的密钥约束在为该证书签名的区所辖范围内的名称上。为使某个域的 DLV 资源记录被采信，该域必须被配置为 DLV 域，并且该域的 DNSKEY 必须被配置为信任锚或本身即为可信 [RFC5074]。

8.1.1. 密钥被攻陷的风险

某份具有有效签名链的证书为伪造证书的风险，与以下因素相关：能够参与该证书验证过程的密钥数量、每把私钥所获保护的质量、每把密钥对攻击者的价值，以及伪造该证书所能带来的价值。

DNSSEC 允许把任意一组域配置为信任锚和/或 DLV，但大多数客户端很可能只把根区作为其唯一的信任锚。此外，由于一把给定的 DNSKEY 只能为其所属区的资源记录签名，能够攻陷某条给定 TLSA 资源记录的私钥数量，仅限于该 TLSA 资源记录与最近的信任锚之间的区数量，再加上任何已配置的 DLV 域。通常这将是六把密钥，其中半数为 KSK。

PKIX 只描述了如何基于客户端所选定的一组信任锚来验证证书，但对于应使用多少个信任锚、以及应如何对其加以约束则只字未提。就目前的部署情况而言，大多数 PKIX 客户端使用随客户端或操作系统软件一同提供的大量信任锚。这些信任锚经过审慎筛选，但同时也追求广泛的互操作性。公共 CA 的信任锚与 CA 证书极少施加名称约束。

技术防护、流程控制与人员经验的综合作用，共同决定了密钥所获安全保障的质量。

8.1.2. 密钥被攻陷的影响

密钥被攻陷所造成的影响，在两种模型之间存在显著差异。

由于 TLSA 证书关联被约束在与之关联的名称、协议与端口之上，即便为该 PKIX 证书签名的公共 CA（如果有的话）不受约束，该 PKIX 证书也同样受到了相应的约束。

8.1.3. 密钥被攻陷的检测

如果某把密钥被攻陷，快速而可靠的检测对于限制其影响至关重要。在这一点上，只要必要的密钥已被攻陷，两种模型都无法阻止攻击者近乎无形地攻击其目标。

如果某个公共 CA 被攻陷，通常只有受害者会看到那份伪造证书，因为一般并不存在可供检视的、公开可访问的「某 CA 已签发全部证书」的目录。DNS 资源记录通常是公开发布的。然而，攻击者同样可以让未被篡改的记录照常向互联网发布，而只向受害者提供一份被篡改的 DNS 视图，从而达到相同的效果。

8.1.4. 伪造主机名

某些 CA 实施了技术管控措施，以确保不向「与热门且易受攻击的域名相似」的域名签发证书。当然，攻击者可以设法找到一个仍愿意签发该证书的 CA，以规避这一限制。然而，借助 DNSSEC 与 TLSA，攻击者可以完全绕开这项检查。

8.2. DNS 缓存

本协议的实现严重依赖 DNS，因而容易遭受基于「蓄意错误关联 TLSA 记录与 DNS 名称」的安全攻击。实现在假定某个 TLSA 记录与某个 DNS 名称之间的关联持续有效时，需要保持审慎。

具体而言，实现应当（SHOULD）依靠其 DNS 解析器来确认 TLSA 记录与 DNS 名称之间的关联，而不是缓存先前域名查找的结果。许多平台本来就能够在适当时候于本地缓存域名查找结果，并且应当（SHOULD）被配置为这样做。不过，只有当 DNS 所报告的 TTL（生存时间）信息表明被缓存的信息很可能仍然有用时，缓存这些查找结果才是恰当的。

如果实现为提升性能而缓存域名查找的结果，则必须（MUST）遵守 DNS 所报告的 TTL 信息。未能遵循此规则的实现，可能在先前访问过的服务器之 TLSA 记录发生变化时（例如在证书轮换期间）被欺骗或遭到拒绝访问。

8.3. 外部 DNSSEC 验证方

由于当今部署最广泛的存根解析器普遍缺乏 DNSSEC 支持，一些 ISP 已开始在其提供给客户的递归解析器中检查 DNSSEC，并酌情设置「可信数据」（AD）标志。具备 DNSSEC 感知能力的客户端可以使用这些数据，而忽略 DNSSEC 数据是在外部完成验证这一事实。由于客户端与递归解析器之间通常既没有对递归解析器的认证，也没有对数据与 AD 标志的完整性保护，这一点可被攻击者轻易伪造。

然而，即便主机与外部验证解析器之间的通信是安全的，仍存在外部验证方本身被攻陷的风险。除非客户端自行检查 DNSSEC 数据（那样一来外部验证方也就没有必要了），否则没有任何机制能够阻止一个被攻陷的外部 DNSSEC 验证方宣称其提供的所有记录都是安全的——哪怕这些数据是伪造的。

出于这一原因，即使存在通往外部验证方的安全路径，DNSSEC 验证仍以在本机执行为佳。

9. 致谢

本文档中的许多想法已被讨论多年。较近以来，作者与其他人以更为聚焦的方式对这些想法展开了讨论。特别地，此处的一些想法与文字最初来自 Paul Vixie、Dan Kaminsky、Jeff Hodges、Phillip Hallam-Baker、Simon Josefsson、Warren Kumari、Adam Langley、Ben Laurie、Ilari Liusvaara、Ondrej Mikle、Scott Schmit、Ondrej Sury、Richard Barnes、Jim Schaad、Stephen Farrell、Suresh Krishnaswamy、Peter Palfrader、Pieter Lexis、Wouter Wijngaards、John Gilmore 以及 Murray Kucherawy。

本文档还得益于 DANE 工作组众多积极参与者的大力帮助。

10. 参考文献

10.1. 规范性参考文献

10.2. 资料性参考文献

附录 A. 部署 TLSA 记录的运维考虑

A.1. 创建 TLSA 记录

创建 TLSA 记录时，必须小心避免配置错误。本文档第 4 节规定：验证状态为「安全」的 TLSA RRSet 必须（MUST）被使用。这意味着此类 RRSet 的存在，实际上会使其他形式的名称与路径验证失效。一个配置错误的 TLSA RRSet 将实际上使所有符合规范的客户端都无法访问该 TLS 服务器，而本文档并未提供任何逐步过渡到使用 TLSA 的手段。

在创建证书用途为 0（CA 证书）或用途为 2（信任锚）的 TLSA 记录时，需要理解在选择器类型 0（完整证书）与 1（SubjectPublicKeyInfo）之间作出选择所带来的影响。之所以需要审慎选择，是因为不同的 TLS 客户端会使用不同的方法来构建信任链。下文概述了应当留意的各种情形，并讨论了选择器类型选择所带来的影响。

当端实体证书与信任锚证书为同一份证书时，证书用途 2 不受不同链构建方式的影响。

A.1.1. TLS 客户端构建信任链时的歧义与边角情形

TLS 客户端可以实现自己的链构建代码，而不依赖 TLS 服务器所出示的链。这意味着，除端实体证书之外，所建议链中出现的任何证书，都可能出现、也可能不出现在客户端最终构建出的链之中。

客户端可用来替换原始链中证书的证书包括：

CA 经常会重新签发证书，改动其有效期、签名算法（例如签名算法中使用不同的散列算法）、CA 密钥对（例如用于交叉证书），或 PKIX 扩展，而公钥与主体保持不变。这些被重新签发的证书，正是 TLS 客户端可以用来替代原始证书的那些证书。

已知客户端会替换或移除某些证书，而这可能导致依赖完整证书的 TLSA 证书关联匹配失败。例如：

A.1.2. 选择器类型的选择

在本节中，「假阴性失败」（false-negative failure）指客户端不接受由 DNS 管理员所指定证书的 TLSA 证书关联。同样，「假阳性接受」（false-positive acceptance）指客户端接受了一个并非由 DNS 管理员所指定证书的 TLSA 关联。

A.1.2.1. 选择器类型 0（完整证书）

「完整证书」选择器提供了对 TLSA 证书关联最为精确的指定，涵盖 PKIX 证书的所有字段。对 DNS 管理员而言，使用该选择器时避免客户端出现假阴性失败的最佳做法是：

  1. 如果某个 CA 签发了替换证书，不要关联到那些签名算法所用散列被本地策略视为薄弱的 CA 证书。
  2. 使用全新安装的客户端（即本地证书缓存为空的状态），确定常见客户端应用如何处理该 TLSA 证书关联。
A.1.2.2. 选择器类型 1（SubjectPublicKeyInfo）

SubjectPublicKeyInfo 选择器在规避某些由客户端信任链构建算法所引发的假阴性失败方面，提供了更大的灵活性。

有一个具体用例值得注意：为直接签发了服务器端实体证书 S1 的 CA 证书 I1 创建 TLSA 证书关联。该情形可用下图说明：

        +----+                      +----+
        | I1 |                      | I2 |
        +----+                      +----+
           |                           |
           v                           v
        +----+                      +----+
        | S1 |                      | S1 |
        +----+                      +----+
Certificate chain sent by    A different validation path
server in TLS handshake      built by the TLS client

其中 I2 是 CA 证书 I1 的重新签发版本（即其签名算法中的散列不同）。

在上述场景中，为 S1 签名的两份证书 I1 与 I2 必须具有完全相同的 SubjectPublicKeyInfo 字段，因为用于为 S1 签名的密钥是固定的。在这种情况下，与 SubjectPublicKeyInfo 的关联（选择器类型 1）总能成功匹配；而与完整证书的关联（选择器类型 0）则可能因假阴性失败而无法奏效。

与「完整证书」选择器相比，其攻击面略为宽泛：DNS 管理员可能会无意中指定一个会导致假阳性接受的关联。

是否使用 SubjectPublicKeyInfo 选择器去关联 I1 之上链中的某份证书，需要视具体情况而定：基于签发 CA 的各种做法，可能性实在太多。除非管理员已充分理解此类关联的全部影响，否则从安全角度看，使用选择器类型 0 是更好的选择。

A.2. 在 DNS 中配备 TLSA 记录

A.2.1. 结合别名配备 TLSA 记录

TLSA 资源记录在 DNS 中并无特殊之处；它的行为与任何其他「被查询名称在基础名称之前带有一个或多个标签前缀」的 RRtype 完全一致，例如 SRV RRtype [RFC2782]。这会影响到在 DNS 中使用别名时 TLSA 资源记录的使用方式。

请注意，IETF 有时会在 DNS 中新增别名类型。如果将来出现这种情况，那些别名可能会影响 TLSA 记录——但愿是以好的方式。

A.2.1.1. 结合 CNAME 记录配备 TLSA 记录

在 DNS 中使用 CNAME 作别名，只会为所给出的确切名称建立别名，而不会覆盖该名称之下的任何区域。例如，假设某区文件中只有如下内容：

sub1.example.com.          IN CNAME sub2.example.com.

在这种情况下，针对 "bottom.sub1.example.com" 的 A 记录请求不会返回任何记录，因为所给出的 CNAME 只为该名称本身建立了别名。反之，假设区文件中有如下内容：

sub3.example.com.          IN CNAME sub4.example.com.
bottom.sub3.example.com.   IN CNAME bottom.sub4.example.com.

在这种情况下，针对 bottom.sub3.example.com 的 A 记录请求实际上会返回 bottom.sub4.example.com 处 A 记录的取值。

应用实现与全服务解析器使用会自动跟随 CNAME（以及 DNAME）别名的库来请求 DNS 记录。这使得主机既可以把 TLSA 记录放在自己的区中，也可以使用 CNAME 来做重定向。

如果原始域名的所有者希望为其自身设置 TLSA 记录，只需在既定前缀之下录入即可：

; No TLSA record in target domain
;
sub5.example.com.            IN CNAME sub6.example.com.
_443._tcp.sub5.example.com.  IN TLSA 1 1 1 308202c5308201ab...
sub6.example.com.            IN A 192.0.2.1
sub6.example.com.            IN AAAA 2001:db8::1

如果原始域名的所有者希望由目标域名来托管该 TLSA 记录，则原始域名使用一条 CNAME 记录：

; TLSA record for original domain has CNAME to target domain
;
sub5.example.com.            IN CNAME sub6.example.com.
_443._tcp.sub5.example.com.  IN CNAME _443._tcp.sub6.example.com.
sub6.example.com.            IN A 192.0.2.1
sub6.example.com.            IN AAAA 2001:db8::1
_443._tcp.sub6.example.com.  IN TLSA 1 1 1 536a570ac49d9ba4...

请注意，原始域名与目标域名同时拥有 TLSA 记录是可以接受的，但这两条记录彼此无关。考虑以下情形：

; TLSA record in both the original and target domain
;
sub5.example.com.            IN CNAME sub6.example.com.
_443._tcp.sub5.example.com.  IN TLSA 1 1 1 308202c5308201ab...
sub6.example.com.            IN A 192.0.2.1
sub6.example.com.            IN AAAA 2001:db8::1
_443._tcp.sub6.example.com.  IN TLSA 1 1 1 ac49d9ba4570ac49...

在此例中，查找 sub5.example.com 之 TLSA 记录的人总会得到取值以 "308202c5308201ab" 开头的那条记录；而取值以 "ac49d9ba4570ac49" 开头的 TLSA 记录，只有在查找 sub6.example.com 的 TLSA 记录时才会被取到，绝不会在查找 sub5.example.com 时被取到。请注意，为位于同一 TLS 监听器上的多项服务部署不同证书，往往需要使用 TLS SNI（服务器名称指示）[RFC6066]。

请注意，上述方法使用的是 DNS 中借助 CNAME 作别名的常规方式：DNS 客户端请求它实际想要的那种记录类型。

A.2.1.2. 结合 DNAME 记录配备 TLSA 记录

使用 DNAME 记录，可使区所有者为持有该 DNAME 的名称之下的整棵子树建立别名。这使得诸如 TLSA、SRV 等带前缀的记录能够被整体别名化，而名称本身并不被别名化。不过，由于 DNAME 只能用于某个基础名称的子树，它极少被用来为「可能同时运行着 TLS 的单台主机」建立别名。

; TLSA record in target domain, visible in original domain via DNAME
;
sub5.example.com.            IN CNAME sub6.example.com.
_tcp.sub5.example.com.       IN DNAME _tcp.sub6.example.com.
sub6.example.com.            IN A 192.0.2.1
sub6.example.com.            IN AAAA 2001:db8::1
_443._tcp.sub6.example.com.  IN TLSA 1 1 1 536a570ac49d9ba4...
A.2.1.3. 结合通配符配备 TLSA 记录

对于需要前缀的 RRtype 而言，通配符通常并不十分有用，因为只能在主机名之下的层级使用通配符。例如，若希望 www.example.com 的每个 TCP 端口都使用同一条 TLSA 记录，结果可能是：

*._tcp.www.example.com.    IN TLSA 1 1 1 5c1502a6549c423b...

在某些场景下这可能有用，例如同一项服务在许多端口上提供，或者主机上的所有服务使用同一份证书和/或密钥。请注意，被查找的域名不一定与证书中出现的域名相关，因此不会使用查询请求中的通配符去查找一份含有通配符的证书。

A.3. 保护最后一跳

如第 4 节所述，处理 TLSA 记录的应用必须知晓这些记录的 DNSSEC 有效性。应用有许多方式可以安全地确定这一点，本规范并不强制指定任何单一方法。

应用获知 TLSA 记录 DNSSEC 有效性的一些常见方法包括：

A.4. 处理证书轮换

证书轮换的处理方式，与使用预发布密钥轮换方法 [RFC4641] 轮换 DNSSEC 区签名密钥的方式大体相同。假设 example.com 为 TCP 990 端口上的某项 TLS 服务拥有一条 TLSA 记录：

_990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...

要启动轮换流程，先获取或生成轮换后将要使用的新证书或 SubjectPublicKeyInfo，并生成新的 TLSA 记录。将该记录与旧记录并列添加：

_990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
_990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...

待新记录已传播至各权威名称服务器、且旧记录的 TTL 已过期之后，在 TLS 服务器上切换到新证书。一旦切换完成，即可移除旧的 TLSA 记录：

_990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...

至此，证书轮换完成。

附录 B. 使用 TLSA 的伪代码

本附录以伪代码形式描述本规范前文所给出的各项交互。如果下列步骤与文档前文的表述有出入，应以文档前文的步骤为准，并认为本处文字有误。

请注意，本伪代码比规范性文本更为严格。例如，它对各项判据的求值强加了顺序，而这在规范性文本中并非强制要求。

B.1. 辅助函数

// implement the function for exiting
function Finish (F) = {
  if (F == ABORT_TLS) {
    abort the TLS handshake or prevent TLS from starting
    exit
  }

  if (F == NO_TLSA) {
    fall back to non-TLSA certificate validation
    exit
  }

  if (F == ACCEPT) {
    accept the TLS connection
    exit
  }

  // unreachable
}

// implement the selector function
function Select (S, X) = {
  // Full certificate
  if (S == 0) {
    return X in DER encoding
  }

  // SubjectPublicKeyInfo
  if (S == 1) {
    return X.SubjectPublicKeyInfo in DER encoding
  }

  // unreachable
}

// implement the matching function
function Match (M, X, Y) {
  // Exact match on selected content
  if (M == 0) {
    return (X == Y)
  }

  // SHA-256 hash of selected content
  if (M == 1) {
    return (SHA-256(X) == Y)
  }

  // SHA-512 hash of selected content
  if (M == 2) {
    return (SHA-512(X) == Y)
  }

  // unreachable
}

B.2. TLSA 主伪代码

使用 [transport] 连接到 [name] 的 [port] 端口建立 TLS，并收到 TLS 服务器的端实体证书 C：

(TLSArecords, ValState) = DNSSECValidatedLookup(
  domainname=_[port]._[transport].[name], RRtype=TLSA)

// check for states that would change processing
if (ValState == BOGUS) {
  Finish(ABORT_TLS)
}
if ((ValState == INDETERMINATE) or (ValState == INSECURE)) {
  Finish(NO_TLSA)
}
// if here, ValState must be SECURE

for each R in TLSArecords {
  // unusable records include unknown certUsage, unknown
  // selectorType, unknown matchingType, erroneous RDATA, and
  // prohibited by local policy
  if (R is unusable) {
    remove R from TLSArecords
  }
}
if (length(TLSArecords) == 0) {
  Finish(NO_TLSA)
}

// A TLS client might have multiple trust anchors that it might use
//    when validating the TLS server's end entity (EE) certificate.
//    Also, there can be multiple PKIX certification paths for the
//    certificates given by the server in TLS.  Thus, there are
//    possibly many chains that might need to be tested during
//    PKIX path validation.

for each R in TLSArecords {

  // pass PKIX certificate validation and chain through a CA cert
  //    that comes from TLSA
  if (R.certUsage == 0) {
    for each PKIX certification path H {
      if (C passes PKIX certification path validation in H) {
        for each D in H {
          if ((D is a CA certificate) and
              Match(R.matchingType, Select(R.selectorType, D),
                    R.cert)) {
            Finish(ACCEPT)
          }
        }
      }
    }
  }

  // pass PKIX certificate validation and match EE cert from TLSA
  if (R.certUsage == 1) {
    for each PKIX certification path H {
      if ((C passes PKIX certificate validation in H) and
              Match(R.matchingType, Select(R.selectorType, C),
              R.cert)) {
          Finish(ACCEPT)
      }
    }
  }

  // pass PKIX certification validation using TLSA record as the
  //    trust anchor
  if (R.certUsage == 2) {
    // the following assert() is merely a formalization of the
    // "trust anchor" condition for a certificate D matching R
    assert(Match(R.matchingType, Select(R.selectorType, D), R.cert))

    for each PKIX certification path H that has certificate D
        matching R as the trust anchor {
      if (C passes PKIX validation in H) {
        Finish(ACCEPT);
      }
    }
  }

  // match the TLSA record and the TLS certificate
  if (R.certUsage == 3) {
    if Match(R.matchingType, Select(R.selectorType, C), R.cert)
      Finish(ACCEPT)
    }
  }

}

// if here, then none of the TLSA records ended in "Finish(ACCEPT)"
//   so abort TLS
Finish(ABORT_TLS)

附录 C. 示例

以下是使用各种选择器与匹配类型生成的自签名证书示例。它们由某一款软件生成，并由个人使用其他工具进行了验证。

其中 S = 选择器（Selector），M = 匹配类型（Matching Type）。以下关联数据为证书的原始十六进制编码，按原文原样保留：

S M Association Data
0 0 30820454308202BC020900AB58D24E77AD2AF6300D06092A86
    4886F70D0101050500306C310B3009060355040613024E4C31163014
    0603550408130D4E6F6F72642D486F6C6C616E643112301006035504
    071309416D7374657264616D310C300A060355040A13034F53333123
    30210603550403131A64616E652E6B6965762E70726163746963756D
    2E6F73332E6E6C301E170D3132303131363136353730335A170D3232
    303131333136353730335A306C310B3009060355040613024E4C3116
    30140603550408130D4E6F6F72642D486F6C6C616E64311230100603
    5504071309416D7374657264616D310C300A060355040A13034F5333
    312330210603550403131A64616E652E6B6965762E70726163746963
    756D2E6F73332E6E6C308201A2300D06092A864886F70D0101010500
    0382018F003082018A0282018100E62C84A5AFE59F0A2A6B250DEE68
    7AC8C5C604F57D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B
    6AD5DEA0C8771C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE
    281A68230B24B9DA1A98DCBE51195B60E42FD7517C328D983E26A827
    C877AB914EE4C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D5

    8C389CC3D6D8C20662E19CF768F32441B7F7D14AEA8966CE7C32A172
    2AB38623D008029A9E4702883F8B977A1A1E5292BF8AD72239D40393
    37B86A3AC60FA001290452177BF1798609A05A130F033457A5212629
    FBDDB8E70E2A9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D
    4BD77DFA34035563C126AA2C3328B900E7990AC9787F01DA82F74C3D
    4B6674CCECE1FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE775
    6213BD3D60831175BE290442B4AFC5AE6F46B769855A067C1097E617
    962529E166F22AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A44
    9C8D0D31BC683C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2
    DDFF6B4CAC050203010001300D06092A864886F70D01010505000382
    0181002B2ABE063E9C86AC4A1F7835372091079C8276A9C2C5D1EC57
    64DE523FDDABDEAB3FD34E6FE6CBA054580A6785A663595D90132B93
    D473929E81FA0887D2FFF78A81C7D014B97778AB6AC9E5E690F6F5A9
    E92BB5FBAB71B857AE69B6E18BDCCB0BA6FCD9D4B084A34F3635148C
    495D48FE635903B888EC1DEB2610548EDD48D63F86513A4562469831
    48C0D5DB82D73A4C350A42BB661D763430FC6C8E5F9D13EA1B76AA52
    A4C358E5EA04000F794618303AB6CEEA4E9A8E9C74D73C1B0B7BAF16
    DEDE7696B5E2F206F777100F5727E1684D4132F5E692F47AF6756EA8
    B421000BE031B5D8F0220E436B51FB154FE9595333C13A2403F9DE08
    E5DDC5A22FD6182E339593E26374450220BC14F3E40FF33F084526B0
    9C34250702E8A352B332CCCB0F9DE2CF2B338823B92AFC61C0B6B8AB
    DB5AF718ED8DDA97C298E46B82A01B14814868CFA4F2C36268BFFF4A
    591F42658BF75918902D3E426DFE1D5FF0FC6A212071F6DA8BD833FE
    2E560D87775E8EE9333C05B6FB8EB56589D910DB5EA903

0 1 EFDDF0D915C7BDC5782C0881E1B2A95AD099FBDD06D7B1F779
    82D9364338D955

0 2 81EE7F6C0ECC6B09B7785A9418F54432DE630DD54DC6EE9E3C
    49DE547708D236D4C413C3E97E44F969E635958AA410495844127C04
    883503E5B024CF7A8F6A94

1 0 308201A2300D06092A864886F70D01010105000382018F0030
    82018A0282018100E62C84A5AFE59F0A2A6B250DEE687AC8C5C604F5
    7D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B6AD5DEA0C877
    1C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE281A68230B24
    B9DA1A98DCBE51195B60E42FD7517C328D983E26A827C877AB914EE4
    C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D58C389CC3D6D8
    C20662E19CF768F32441B7F7D14AEA8966CE7C32A1722AB38623D008
    029A9E4702883F8B977A1A1E5292BF8AD72239D4039337B86A3AC60F
    A001290452177BF1798609A05A130F033457A5212629FBDDB8E70E2A
    9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D4BD77DFA3403
    5563C126AA2C3328B900E7990AC9787F01DA82F74C3D4B6674CCECE1
    FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE7756213BD3D6083
    1175BE290442B4AFC5AE6F46B769855A067C1097E617962529E166F2
    2AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A449C8D0D31BC68
    3C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2DDFF6B4CAC05
    0203010001

1 1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911
    D9E30A924138C4

1 2 D43165B4CDF8F8660AECCCC5344D9D9AE45FFD7E6AAB7AB9EE
    C169B58E11F227ED90C17330CC17B5CCEF0390066008C720CEC6AAE5
    33A934B3A2D7E232C94AB4

作者地址（Authors' Addresses）

Paul Hoffman
VPN Consortium

EMail: paul.hoffman@vpnc.org

Jakob Schlyter
Kirei AB

EMail: jakob@kirei.se