Historically, people have been bad at getting ASN.1 encoding right. It seems like this is still true. Our parser is generally quite strict. In most cases we try to follow the specification to the letter, in order to avoid cases where we accept weirdly encoded values that other implementations would reject or parse differently.
In some cases, this isn't the ideal approach for users, who are generally unable to work around our strict parsing rules, for instance when a certificate has been widely deployed in a way where it cannot be reasonably re-issued or updated (i.e. embedded in firmware in deployed hardware).
It may be worth considering adding a GODEBUG that lets users disable specific parsing rules, e.g. GODEBUG=laxasn1parsing=[a-z]+(,[a-z])*.
The first of these rules would be one which disable the checks for specific characters in the various string types. Some of the types, such as PrintableStrings, technically support the full ASCII character set, but the specification limits which characters are actually allowed (notably, the underscore _). This is problematic when people encode DNS names (or other attributes) in certificates, but picked the wrong ASN.1 type, and used an implementation which let them use disallowed characters when encoding it.
Historically, people have been bad at getting ASN.1 encoding right. It seems like this is still true. Our parser is generally quite strict. In most cases we try to follow the specification to the letter, in order to avoid cases where we accept weirdly encoded values that other implementations would reject or parse differently.
In some cases, this isn't the ideal approach for users, who are generally unable to work around our strict parsing rules, for instance when a certificate has been widely deployed in a way where it cannot be reasonably re-issued or updated (i.e. embedded in firmware in deployed hardware).
It may be worth considering adding a GODEBUG that lets users disable specific parsing rules, e.g.
GODEBUG=laxasn1parsing=[a-z]+(,[a-z])*.The first of these rules would be one which disable the checks for specific characters in the various string types. Some of the types, such as PrintableStrings, technically support the full ASCII character set, but the specification limits which characters are actually allowed (notably, the underscore
_). This is problematic when people encode DNS names (or other attributes) in certificates, but picked the wrong ASN.1 type, and used an implementation which let them use disallowed characters when encoding it.