CA 认证签名过程中 RDN 属性的排序

Question

我很难理解 RDN (RelativeDistinguishedName) 中属性 (AttributeTypeAndValue) 的顺序。

以下是相关的 ASN.1 定义（摘自 www.in2eps.com）：

TBSCertificate

TBSCertificate ::= SEQUENCE {
    [...]
    subject    Name,
    [...]
}

姓名

Name ::= CHOICE {
    rdnSequence RDNSequence
}

RDNSequence

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName

RelativeDistinguishedName ::= SET SIZE (1 .. MAX) OF AttributeTypeAndValue

AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
    type AttributeType,
    value AttributeValue
}

属性类型

AttributeType ::= OBJECT IDENTIFIER

属性值

AttributeValue ::= ANY -- DEFINED BY AttributeType

如果我创建一个包含“/CN=CommonNameX/O=OrganizationX/...”的 CSR（按此特定顺序），CA 如何以此构建证书？

将subject设置为“.../O=OrganizationX/CN=CommonNameX/”（倒序同），证书将如何构造？

据我所知，RDN 属性的顺序在验证证书链时很重要。因此，我假设必须有一些详细的规范可用？

更重要的是，我还想知道是否有不同的 CA 使用不同的顺序。如果是这样，有人可以指出一些 CA 吗？

编辑：

阅读第一个答案后，我意识到我要求的东西与预期的非常不同。简而言之：预期的问题是，RDN 序列 中元素的顺序是否重要。

抱歉打扰了，我会在后面更正问题的标题...

Answer 1

这是预期的行为。 RDN 属性是 X.500 可分辨名称的一部分，它是一棵树。该树是从根节点开始并通过添加嵌套子节点构建的。例如，主题 CN=John Wayne, OU=IT Department, DC=contoso, DC=com 将构建如下：

Root/top-level 节点：com
根 node/domain 中的子节点：contoso
域内的组织单位：IT 部门
通用名称、最终实体或委托人：John Wayne

这就是 RDN 以相反顺序放置的原因。为方便起见，证书查看器反转 RDN 属性顺序，首先显示主体名称。

If I create a CSR containing "/CN=CommonNameX/O=OrganizationX/..." (in this specific order), how does a CA constructs a certificate out of this?

CA 不会更改主题名称中的 RDN 属性顺序，因为它们已在证书请求中颠倒过来。您可以在任何 ASN.1 查看器中打开生成的请求文件，以获取二进制请求中 RDN 属性的实际顺序。

More importantly, I would also like to know if there are different CAs using different orderings. If so, can someone point me to some available CAs?

我使用的所有 CA 的行为都如上所述（编码 X.500 名称时使用反向排序）。

edit：专有名称的表示在 [RFC1779]

中定义

edit2（对RDN顺序重要性的问题）：前面已经说了，很重要。当 CA 签署证书时，它应将 RDN 放置在 Issuer 字段中，其顺序与它们在其自己的证书的 Subject 字段中出现的顺序相同。

Answer 2

（作为@CryptoGuy 对 DN 比较背景的回答的补充）

Internet X.509 Public 密钥基础设施证书 的基本 IETF 规范是 RFC 5280。

Section 7.1 中指定了比较专有名称的规则。他们是：

两个专有名称 DN1 和 DN2 匹配，如果它们具有相同数量的 RDN，对于 DN1 中的每个 RDN，都有一个匹配 RDN 在 DN2 中，匹配的 RDN 在两者中以相同的顺序出现 DN。
两个相关的专有名称如果 RDN1 和 RDN2 具有相同数量的命名属性，则匹配对于 RDN1 中的每个命名属性，都有一个匹配的命名 RDN2 中的属性。 (注：命名属性无先后顺序要求！)
如果属性类型相同且两个命名属性匹配属性的值在处理后完全匹配字符串准备算法。

因此，即使两个 DN 在某些匹配的相对专有名称中的命名属性顺序不同，也必须将其视为相等。

不幸的是，有相当数量的程序在这方面失败了。因此，为了安全起见，只需将一个命名属性放入每个 RDN。

关于@CryptoGuy 在他的回答中提到的树结构，在 7.1 节中更正式地定义如下：

专有名称 DN1 在由如果 DN1 至少包含与 DN2 一样多的 RDN，则识别名 DN2，当忽略 DN1 中的尾随 RDN 时，DN1 和 DN2 匹配。

Answer 3

If I create a CSR containing "/CN=CommonNameX/O=OrganizationX/..." (in this specific order), how does a CA constructs a certificate out of this?

一个体面的 CA 实际上应该忽略 CSR 中提交的 DN，并根据它已验证的信息构建主题 DN。也就是说，通常，他们会根据他们的 CA 策略放置自己的国家、组织、OU（等等）。他们会将 CN 更改为您申请的主机的 CN（例如，或根据证书类型与申请流程相关的任何其他内容）。 CSR 中的内容对于跟踪在申请过程中提交的 public 密钥的身份很有用，但最多只能用于管理目的。

As far as I know the ordering of the RDN attributes is important when verifying certificate chains. Therefore, I assume there must by some detailed specification available?

是的，顺序很重要 RDNSequence 确实是 SEQUENCE OF RelativeDistinguishedName。每个 RDN 本身就是一组（无序的）AVA（属性值断言/AttributeTypeAndValue）：SET SIZE (1 .. MAX) OF AttributeTypeAndValue.

每个RDN内容（AVA的集合）和每个DN（RDN的序列）的匹配规则定义在RFC 5280:

   Two naming attributes match if the attribute types are the same and
   the values of the attributes are an exact match after processing with
   the string preparation algorithm.  Two relative distinguished names
   RDN1 and RDN2 match if they have the same number of naming attributes
   and for each naming attribute in RDN1 there is a matching naming
   attribute in RDN2.  Two distinguished names DN1 and DN2 match if they
   have the same number of RDNs, for each RDN in DN1 there is a matching
   RDN in DN2, and the matching RDNs appear in the same order in both
   DNs.  A distinguished name DN1 is within the subtree defined by the
   distinguished name DN2 if DN1 contains at least as many RDNs as DN2,
   and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored.

本质上，DN 中的 RDN 需要以正确的顺序排列（SEQUENCE 已排序），但 AVA 的顺序不需要（SET 未排序）：“如果 RDN1 和 RDN2 具有相同数量的命名属性并且对于 RDN1 中的每个命名属性在 RDN2 中都有一个匹配的命名属性，则两个相对可分辨名称 RDN1 和 RDN2 匹配。"

实际上，大多数 CA 只为每个 RDN 使用一个属性值对。如果许多实现（不一定是 SSL/TLS 堆栈的一部分，而是说，authentication/authorisation 层在它上面）依赖于文本序列化（RFC 2253示例）会被多个 AVA 弄糊涂（更具体地说，它们的顺序在每个 RDN 中并不重要，因此您可以有两个不同的文本序列化，它们实际上是等价的）。

Answer 4

这个问题的主要答案是准确的，除了 DER-encoded (X.690) ASN.1 中 RDN 的排序。 SET OF ASN.1 构造类型的 DER 编码意味着您必须对所有 Attribute-Type-And-Value 项进行排序，比较它们的 DER 编码（较短的 DER 编码在比较时必须是 zero-filled）。来源：ITU-T X.690 11.6 'Set-of components'。请注意，绝大多数 X.509v3 证书今天确实 DER-encoded。

CA 认证签名过程中 RDN 属性的排序

Ordering of RDN attributes in a CA's certification sign process

ssl

certificate

ca

distinguishedname

x509