Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
crypto/x509: multi-value RDN sequence is not properly DER-ordered #24254
RFC 5280 defines RelativeDistinguishedName as:
With RDN being a ‘SET OF’ AttributeTypeAndValue this means that RDNSequence should be encoded as an ordered sequence.
Note while this rule is not stating explicitly length-ordered, it ends up being firstly ordered by length since the length octet will be the first differing octect to be compared, and the shorter length will be a lower value.
The RDNSequence supporting functions (ToRDNSequence() and appendRDNs()) currently do not perform any ordering by length or otherwise and accept RDNs in the provided order.
The correctly ordered encoding would look like:
This can become an issue when using golang-created certificates containing multi-value RDNs against implementations that adhere to the SET OF encoding rules (like GnuTLS/libtasn1). In the case of GnuTLS, it performs a re-encoding of the certificate when acting as a TLS client, resulting in the “fixing” of the subject RDNs into an ordered set, leading to a changed certificate and thus signature invalidation.
This was referenced
Mar 5, 2018
Note: in case of equal length a comparison by byte of the values would have to be done.
Also note: the GNUTLS client is being fixed to account for this kind of broken client certs,
added a commit
Mar 7, 2018
This is an encoding/asn1 issue, it should order all SET OFs before encoding them since that's what DER specifies. (Can't tell exactly how SETs should be ordered though.)
I can fix this, but I'd like first confirmation from @agl that encoding/asn1 doesn't guarantee an
The first problem is that there is no SET OF support in encoding/asn1 and that structure is defined to be a SEQUENCE instead of a SET OF, they are identical on the wire so this is not immediately evident and it generally won't show as an issue.
You will need to tolerate unordered on receiving because otherwise you will break compatibility with your older self.
The ordering is done on the encoded octet, so you need to encode the set and then order its members. See the ITU-T spec and the workaround we have in Openshift (see links above) to get it right for now.
encoding/asn1 does support SET and SET OF via a struct tag or when the type name ends in SET (see the
Agreed that we'll have to keep tolerating this here, but I was curious what the default stance on DER parsing is in encoding/asn1.
Not ordered the same as a SET OF, but SET does have an ordering specified in X.690, Section 10.3, which applies to DER (which then references X.680):
Section 8.6 of X.680 states: