摘要

  • RFC 1485 处理的是“已知 DN 如何变成可传递文本”，而不是从不完整人名寻找条目。
  • 换行、逗号或分号、引号、OID、十六进制值和多值 RDN 都说明显示形式并不唯一。
  • 后来的 LDAP 规范明确拒绝单一规范字符串；DN 是否相等要执行 schema-aware 匹配，条目是否可信则还要更多证据。

先有树，后有字串

1993 年的难题很朴素。X.500 把 Distinguished Name 作为名录条目的主键，用 ASN.1 表达；人却要把名称印到名片上、写进邮件里，交给没有运行名录协议的另一个人。RFC 1485 为这个出口定义了面向用户的字符串。RFC Editor 记录显示它发布于 1993 年 7 月，今天已列为 Historic。

这里的先后顺序很重要：DN 已经存在，字符串随后产生。RFC 1484 的 User Friendly Name 恰好相反，它从人类给出的 purported name 出发，在本地环境和目录状态中寻找候选项。上一篇文章已占有那条解析路径；RFC 1485 占有的是结构到文本的边界。

好看的常用形式旁边留着“难看的”通道

规范希望格式无歧义、直观、普遍适用，还能做漂亮排版。常见属性获得 CN、L、ST、O、OU、C 等短标签。不常见的类型可以退回 OID.2.6.53 一类点分标识；不能舒服显示的值可以写成十六进制。RFC 1485 坦白把后者称为 ugly，并预计只在病理性案例中使用。

这不是设计失败，而是边界证据。共同规范不必把每个例外伪装成自然语言；它只需保证例外仍可传递、可逆、可验证。可读性属于常用路径，完整性由逃生通道兜底。

同一个结构可以有不同纸面

RFC 1485 把最具体的 RDN 写在前面。RDN 之间可用逗号或分号，周围可有空格，长名称可折行，在行文中还可放进尖括号。特殊标点、连续空格及首尾空格需要引号或转义。一个多值 RDN 用 + 连接多个 Attribute Value Assertion。

于是，横排与折行、逗号与分号并不自动产生两个 DN。反过来，一枚没有正确转义的逗号可能把值切成新的 RDN。肉眼相似性既不是充分条件，也不是必要条件。

RFC 4512把底层结构说得更清楚：RDN 是无序 AVA 集合，DN 则按树路径连接多个 RDN。加号两边的 AVA 调换显示顺序，不会凭空增加身份含义；RDN 在序列中的位置却有结构意义。

版本是字符串的一部分，只是没有印在里面

RFC 1779 的记录确认它取代 RFC 1485；正文改进转义并不鼓励混用分隔符。RFC 2253把 DN 字符串带入 LDAPv3 和 UTF-8，其记录又指向后继规范。今天的 LDAP 形式来自 RFC 4514及其状态记录。

这条演进线意味着，归档一条 DN 文本时也要归档语法版本、字符编码、属性描述符注册表和 schema。分号是否被接受、某个短名称指向哪个 OID、字符如何解码，都不是字形自己能回答的问题。

RFC 4514 还提醒，人机界面往往会把属性标签翻译成本地语言，而不是原样展示协议字符串。屏幕上的自然语言属于呈现层；互操作合同在其下方。

“没有规范字符串”不是缺陷

RFC 4514 明说：它不定义 DN 的 canonical string representation。它给出推荐编码算法，也允许其他算法生成符合解析语法的字符串。DN 相等必须依照 RFC 4517中的 distinguishedNameMatch。

这条规则按位置比较 RDN；在同一 RDN 内忽略 AVA 顺序；每个属性值再交给该属性类型的相等规则。RFC 4518负责国际化字符串准备，包括映射、兼容性组合、禁用码点和对空格的规则化处理。必要比较无法定义时，最终结果还可能是 Undefined。

因此，直接把原始字符串设为数据库唯一键，其实偷偷安装了另一套政策。它会把本应相等的 DN 拆成两份，也可能在 schema 不同的系统之间把相似文本错误合并。速度没有替代语义，只是把错误更快固化。

CN=Sam 没有保存自己的全部来历

RFC 4514 给出一个极具穿透力的例子。一个 X.501 属性值采用 TeletexString，另一个采用 PrintableString，两者都包含 Sam；LDAP 显示都可能成为 CN=Sam。从可读字符串反推，不一定能恢复原来的 BER 或 DER。需要精确 DER 的应用——例如证书验证中的某些步骤——应使用前缀为 # 的十六进制形式。

这把三个目标拆开：恢复 DN 结构、按规则判断 DN 相等、逐字节保存原编码。不能因为一个界面只显示一行，就假设三张收据都已取得。

名称指向条目，不替条目担保

RFC 4512 说，DN 在目录树中无歧义地指向一个条目。条目根据 schema 保存关于所代表对象的属性。这里仍然没有证明字符串由谁发送、键盘前的人是否控制条目、属性是否最新、证书是否有效或动作是否获准。

RFC 4514 还指出 DN 常含姓名、邮件或网络地址、地理位置和组织隶属，可能泄露敏感信息。RFC 1485 的安全章节只说没有讨论安全。语法的严整外观不能填补认证、访问控制与隐私的空白。

Heng Lu 关于运行代码优先、最小初始规范与本地决策和现实层次的笔记，为这段历史提供了约束：共同层只负责可交换结构；schema 负责含义；名录负责条目；应用另行认证、授权并留下结果收据。

RFC 1485 让名称走出了名录协议。真正延续它的方式，是不让走出来的字符串反过来统治其背后的现实。

来源