/ go Public
crypto/x509/pkix: Name type does not sensibly generate RDNs #40876
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
What version of Go are you using (
1.14.7, specifically, the playground.
Does this issue reproduce with the latest release?
It reproduces on the playground, which uses the "latest stable release"
What operating system and processor architecture are you using (
What did you do?
What did you expect to see / what you saw instead?
First understand RDNs; LDAPwiki is a good source, particularly,
In practice, Relative Distinguished Name containing multiple name-value pairs (called "Multi-Valued RDNs") are rare, but they can be useful at times when either there is no unique attribute in the entry or you want to ensure that the entry's Distinguished Name contains some useful identifying information.
The above program uses >1 entry in the
pkix.Nameencodes this into an
RDNSequence, either through calling
ToRDNSequenceor by simply printing it, go will encode all the given OUs as a single multi-valued RDN; the source code to
pkixeven explicity notes this,
Such RDNs are always invalid, though; in an RDN, each
AttributeTypeAndValuemust have a different
AttributeType. From X.501¹,
Regardless, an RDN represents a hierarchical reference to an entity of some sort. Multiple OUs, in particular, is going to refer to one OU nested inside of another.
pkix.Name's layout doesn't preserve ordering of the input RDN; not only will it fail to round trip an RDNSequence with two RDNs containing the same AttributeType, it also can't even round-trip the example from the standard:
The package sort of notes this,
But it hands a most likely unaware user a loaded gun of an API. E.g.,
cert-manager, a project to issues certificates in Kubernetes clusters, adopted the structure of
pkix.Namenearly verbatim to represent RDN sequences. Since it uses
pkix.Namenearly directly, it suffers all the same flaws: some RDN sequences are impossible to input, and some input result in invalid nonsensical RDN sequences. A high-level API should not guide the user towards code that produces incorrect results.
¹Note that this is a superseded version of the standard; as X.501 is not an open standard, it is not possible to link to it.
The text was updated successfully, but these errors were encountered: