Printable `BMPString` in subject DN fields marked as failing lint `e_subject_dn_not_printable_characters`

[cwjnkins]

This concerns changes introduced by PR #249, specifically lint e_subject_dn_not_printable_characters. Some attribute values for subject DNs are declared as DirectoryString types, such as X520CommonName

-- Naming attributes of type X520CommonName:
--   X520CommonName ::= DirectoryName (SIZE (1..ub-common-name))
--
-- Expanded to avoid parameterized type:
X520CommonName ::= CHOICE {
  teletexString     TeletexString   (SIZE (1..ub-common-name)),
  printableString   PrintableString (SIZE (1..ub-common-name)),
  universalString   UniversalString (SIZE (1..ub-common-name)),
  utf8String        UTF8String      (SIZE (1..ub-common-name)),
  bmpString         BMPString       (SIZE (1..ub-common-name)) }

which in particular includes the non-UTF8 encoded strings BMPString (a subset of UTF16) and UniversalString.

Here is an example of a certificate using BMPString, for which I have confirmed ZLint (v3.6.1) flags as failing this lint. The X520CommonName decodes to "SSL_Self_Signed_Fallback", with each codepoint consisting of two bytes where the leading byte is 0x00. I suspect that the culprit is that utf8.DecodeRune (used in the lint) treats the leading 0x00 byte as its own codepoint, and that the fix should be to decode with UTF16 when BMPString is encountered.

Alternatively, Section 7.1 of RFC5280 states that while support for PrintableString and UTF8String is required of conforming implementations, support for the other DirectoryString types is optional, so a new lint could be introduced that flags the optional string types.

I do not have an example on hand for UniversalString, but I suspect it could also cause an issue.

[cardonator]

I believe at the time I last touched this lint, the focus of it was more targeted at specific problems seen in public PKI certs. Splitting into different buckets took place later. I agree with your argument that the RFC lint should be able to handle a wider range of data compliant with RFC 5280. Check the linked PR to see changes that will fix the problem for the cert in question but some other examples would be helpful. As usual, generating the test data to use as a basis for testing the changes is the hardest part 😄

[cwjnkins]

but some other examples would be helpful.

I only have two others, this one with common name "172_19_32_13" and another with the same common name "SSL_Self_Signed_Fallback" (both are BMPString).

From the recent discussion on PR #819, I take it the plan will be to add a lint for prohibiting the optional string encoding types based on restrictions from the CA/B forum (seems sensible to me!), so hopefully these certs will be useful as test cases for that.