Incorrect warning on multiple attributes in one RDN

[YuryStrozhevsky]

In your code you have this warning on having "multiple attributes in one RDN" in one certificate. In fact I do not understand the warning and why you made it.

As from initial type definition we have this:

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

And nothing stops us from having multiple AttributeTypeAndValue - could be (1..MAX) values inside one RelativeDistinguishedName.

So, could you describe why you made the warning in zlint?

[justinbastress]

@YuryStrozhevsky from the Source (https://github.com/zmap/zlint/blob/master/lints/lint_subject_multiple_rdn.go#L52), it appear this was pulled from the AWSLabs certlint -- and there doesn't seem to be any I don't see any further reference to a specification there (https://github.com/awslabs/certlint/blob/25d5957f8c36dafcbd82870df57a8367b49650be/lib/certlint/namelint.rb#L121).

[rmhrisk]

@pzb can you elaborate?

[pzb]

Certlint warns about it because I observed that the majority of multiple attribute RDNs are due to bugs. A surprising number of certificates includes all the attributes in a single RDN by mistake. I'm assuming this was because of a poor API to create Names where an array of attributes becomes a single RDN rather than becoming a sequence of RDNs with one attribute each.

In certlint Warnings (W) are advisory only. It will warn on things that seem "odd" even if they can be correct; another example is leading/trailing whitespace in attribute values. That can be completely valid, but also can be an indication of a bug

[zakird]

It might be worth downgrading this from a warning to a notice. We typically use warnings to denote practices that aren't consistent with community guidelines (e.g., a SHOULD clause in an RFC).

[dadrian]

Are client API's equipped to deal with RDN's of size > 1? Offhand, I know that at least Golang pushes the extra attributes to a grab-bag []Names for certain values, including CommonName and SerialNumber. If many clients don't expose these values, it may be worth leaving the notice as a warning.

https://golang.org/src/crypto/x509/pkix/pkix.go?s=3333:3386#L123

[pzb]

Ruby also has issues:

https://github.com/ruby/openssl/blob/master/lib/openssl/x509.rb#L127 (parsing string into Name)

https://github.com/ruby/openssl/blob/master/ext/openssl/ossl_x509name.c#L332 (name converts to Array of Attributes, not Array of Array of Attributes); if to do OpenSSL::X509::Name.new(cert.subject.to_a) in Ruby, you will get a new name with each attribute as its own RDN. Ruby has no way to construct a name with a multiple attribute RDN

[zakird]

@dadrian thanks for noting that. I think this is generally the type of case that we try to catch with a Notice. There aren't very many in general (see https://github.com/zmap/ztag/blob/master/ztag/schema.py#L940).

We've tried to stick pretty religiously to needing a document to point to (e.g., RFC or CA/B Forum clause) in order for something to rise up to be a Warning or Error.

[dadrian]

Sounds like we should make this a notice, and then get the BR's changed. 🤪

[rmhrisk]

It seems, based on Ruby's behavior, a client that wants to interoperate with poorly done implementations should default to the other form. It also seems in the context of zlint this should be a Notice.

[pzb]

Certlint is usually uses notice versus warning for software incompatibilities; I should probably the multi-attribute message to be a notice as well:

https://github.com/awslabs/certlint/blob/master/lib/certlint/certlint.rb#L278
https://github.com/awslabs/certlint/blob/master/lib/certlint/certlint.rb#L406

[YuryStrozhevsky]

@pzb BTW I made same issue for certlint. So, probably would be better to just reference this issue from certlint's issue.