跳到主要内容

3.6 密钥管理和表示

3.6. 密钥管理和表示​

签名应用需要一定程度地保证验证公钥与所声明的 Signer 相关联. 许多应用通过使用受信任第三方签发的公钥证书来实现这一点. 然而, DKIM 只需让 Verifier 查询所声称 Signer 的 DNS 条目 (或某种安全性等价机制) 来取得公钥, 即可达到足够的安全级别, 同时显著增强可扩展性.

DKIM key 可以存储在多种类型的 key server 中, 并采用多种格式. key 的存储和格式与 DKIM 算法其余部分无关.

key 查找算法的参数包括查找类型 ("q=" tag), Signer 的域 (DKIM-Signature header field 的 "d=" tag), 以及 selector ("s=" tag).

public_key = dkim_find_key(q_val, d_val, s_val)

本文档定义一个绑定, 使用 DNS TXT RR 分发 key. 将来可以定义其他绑定.

3.6.1. 文本表示​

预期许多 key server 会选择以其他方面非结构化的文本格式呈现 key (例如, 为此目的, XML 形式不会被视为非结构化文本). 对于以其他方面非结构化文本形式表示的任何 DKIM key, MUST 使用以下定义.

总体语法是 Section 3.2 中描述的 tag-list. 当前有效 tag 如下所述. 其他 tag MAY 存在, 并且任何不理解它们的实现 MUST 忽略它们.

v= DKIM key record 的版本 (plain-text; RECOMMENDED, 默认值为 "DKIM1"). 如果指定, 此 tag MUST 设置为 "DKIM1" (不含引号). 此 tag MUST 是 record 中的第一个 tag. 以 "v=" tag 开头且值为其他任何内容的 record MUST 被丢弃. 注意, Verifier 必须对此值执行字符串比较; 例如, "DKIM1" 不同于 "DKIM1.0".

ABNF:

key-v-tag    = %x76 [FWS] "=" [FWS] %x44.4B.49.4D.31

h= 可接受的哈希算法 (plain-text; OPTIONAL, 默认允许所有算法). 这是一个以冒号分隔的可用哈希算法列表. 未识别算法 MUST 被忽略. 关于 Signer 和 Verifier 实现的哈希算法, 见 Section 3.3 的讨论. 每个 record 中此 tag 列出的算法集合是 Signer 作出的操作性选择.

ABNF:

key-h-tag       = %x68 [FWS] "=" [FWS] key-h-tag-alg
                  *( [FWS] ":" [FWS] key-h-tag-alg )
key-h-tag-alg   = "sha1" / "sha256" / x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word   ; for future extension

k= Key 类型 (plain-text; OPTIONAL, 默认值为 "rsa"). Signer 和 Verifier MUST 支持 "rsa" key 类型. "rsa" key 类型表示 "p=" tag 中使用 ASN.1 DER 编码 [ITU-X660-1997] 的 RSAPublicKey (见 [RFC3447] 的 Section 3.1 和 A.1.1). (注意: "p=" tag 还会使用 base64 算法对该值进一步编码.) 未识别 key 类型 MUST 被忽略.

ABNF:

key-k-tag        = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type   = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word   ; for future extension

n= 可能对人类有用的注记 (qp-section; OPTIONAL, 默认值为空). 任何程序都不会解释它. 在有空间限制的任何 key server 机制中 (尤其是 DNS), 应谨慎使用此 tag. 它面向管理员使用, 而非最终用户.

ABNF:

key-n-tag    = %x6e [FWS] "=" [FWS] qp-section

p= 公钥数据 (base64; REQUIRED). 空值表示此公钥已被撤销. 此 tag 值在 base64 编码前的语法和语义由 "k=" tag 定义.

INFORMATIVE RATIONALE: 如果私钥已泄露或因其他原因被禁用 (例如外包合同已终止), Signer 可能希望明确声明它知道该 selector, 但所有使用该 selector 的消息都应验证失败. 对于 selector 引用已撤销 key 的任何 DKIM-Signature header field, Verifier SHOULD 返回错误代码. (详见 Section 6.1.2.)

ABNF:

key-p-tag    = %x70 [FWS] "=" [ [FWS] base64string]

INFORMATIVE NOTE: base64string 允许在任意位置包含空白 (FWS); 但是, 任何 CRLF 后都必须跟随至少一个 WSP 字符. 提醒实现者和管理员确保 selector TXT RR 符合本规范.

s= 服务类型 (plain-text; OPTIONAL; 默认值为 "*"). 这是一个以冒号分隔的服务类型列表, 指明此 record 适用的服务类型. 对于给定服务类型的 Verifier, 如果未列出相应类型, MUST 忽略此 record. 未识别服务类型 MUST 被忽略. 当前定义的服务类型如下:

  • * 匹配所有服务类型
  • email 电子邮件 (不一定限于 SMTP)

如果未来其他服务定义 DKIM 的使用方式, 此 tag 旨在约束 key 用于其他目的.

ABNF:

key-s-tag        = %x73 [FWS] "=" [FWS] key-s-tag-type
                   *( [FWS] ":" [FWS] key-s-tag-type )
key-s-tag-type   = "email" / "*" / x-key-s-tag-type
x-key-s-tag-type = hyphenated-word   ; for future extension

t= 标志, 表示为以冒号分隔的名称列表 (plain-text; OPTIONAL, 默认不设置标志). 未识别标志 MUST 被忽略. 已定义标志如下:

  • y 此域正在测试 DKIM. 即使签名验证失败, Verifier MUST NOT 以不同于未签名电子邮件的方式处理来自测试模式 Signer 的消息. Verifier MAY 希望跟踪测试模式结果以协助 Signer.

  • s 任何使用 "i=" tag 的 DKIM-Signature header field, 其 "i=" tag 中 "@" 右侧的域值 MUST 与 "d=" tag 的值相同. 也就是说, "i=" 域 MUST NOT 是 "d=" 的子域. 除非需要子域化, 否则 RECOMMENDED 使用此标志.

ABNF:

key-t-tag        = %x74 [FWS] "=" [FWS] key-t-tag-flag
                   *( [FWS] ":" [FWS] key-t-tag-flag )
key-t-tag-flag   = "y" / "s" / x-key-t-tag-flag
x-key-t-tag-flag = hyphenated-word   ; for future extension

3.6.2. DNS 绑定​

此处定义一种使用 DNS TXT RR 作为 key 服务的绑定. 所有实现 MUST 支持此绑定.

3.6.2.1. 命名空间​

所有 DKIM key 都存储在名为 "_domainkey" 的子域中. 给定一个 DKIM-Signature 字段, 其 "d=" tag 为 "example.com", "s=" tag 为 "foo.bar", 则 DNS 查询目标为 "foo.bar._domainkey.example.com".

3.6.2.2. 用于 key 存储的资源记录类型​

使用的 DNS Resource Record 类型由 query-type ("q=") tag 的一个选项指定. 本基础规范中定义的唯一选项是 "txt", 表示使用 TXT RR. 此标准的后续扩展可以定义其他 RR 类型.

TXT RR 中的字符串在使用前 MUST 拼接在一起, 中间不得插入空白. 对于特定 selector 名称, TXT RR MUST 唯一; 也就是说, 如果 RRset 中存在多个 record, 则结果未定义.

TXT RR 按 Section 3.6.1 中的描述进行编码.

最后于 更新