allow tag 19 in dn strings?

[zmstone]

Describe the bug

Certificates from some devices encode the DC (DomainComponent) attribute as PrintableString (ASN.1 tag 19) instead of IA5String (tag 22). This causes public_key decode to crash with:

{wrong_tag,{{expected,22},{got,19,{19,<<"...">>}}}}

OTP already tolerates similar spec violations for countryName (utf8 instead of printable) and emailAddress (utf8 instead of ia5), but DomainComponent has no such workaround. So I suppose it's reasonable to request tolerance for DC.

Another issue we encountered before was SerialNumber was encoded as 'utf8-string' (tag 12) rather than a 'restricted-string' (tag 19), please kindly consider if this can be tolerated too.

To Reproduce

Create a self-signed certificate with DC encoded as PrintableString using OpenSSL, then binary-patch the DER:

%% 1. Generate a normal cert with DC in subject
os:cmd("openssl req -x509 -newkey rsa:2048 -keyout /tmp/key.pem -out /tmp/cert.pem "
"-days 365 -nodes -subj '/DC=example/CN=test'"),

%% 2. Read and patch: change IA5String tag (0x16) to PrintableString tag (0x13) for DC value
{ok, Pem} = file:read_file("/tmp/cert.pem"),
[{_, Der, _}] = public_key:pem_decode(Pem),
Bad = binary:replace(Der, <<16#16, 7, "example">>, <<16#13, 7, "example">>),

%% 3. Decode crashes
public_key:pkix_decode_cert(Bad, otp).
%% ** {wrong_tag,{{expected,22},{got,19,{19,<<"example">>}}}}

Note: the patched cert has an invalid signature, but the crash occurs during ASN.1 decoding before signature verification.

Expected behavior

Allow PrintableString for DC.

Affected versions
The OTP versions that are affected by this bug.

Additional context

In dec_DomainComponent/2, try decoding as IA5String (tag 22) first, and if that fails with wrong_tag, fall back to PrintableString (tag 19). Mirrors the existing workarounds for X520countryName and EmailAddress

[IngelaAndin]

I think all these workarounds due to other software not adhering to the specs are quite annoying, although as a smaller player we often have to be pragmatic. Converting IA5String to PrintableString is quite unproblematic as it both variants of ASCCII.
Changing to utf8-encodeing maybe code ought to check that value still is ASCCII. Alas I do not think the the old workarounds do that (and the old workarounds use to be only when decoding before rewrite and maybe that was an oversight when the rewrite was done). Anyway we do not have a time to fiddle with this right now, but you can make PR if you think it is worth it.