Ampersands in intermediates' PrintableString

[J.C. Jones]

All,

Just an interesting heads up:

While we were doing some maintenance on the CCADB, Chris Henderson found
Golang could not process several of Wells Fargo's intermediate CAs, such as:

- sha256sum =
3B8812E6F851B6F933DC23ED764082FB5F50DE3C2DDDEBCC9CA240B7ACACE4D1
<https://censys.io/certificates/3b8812e6f851b6f933dc23ed764082fb5f50de3c2dddebcc9ca240b7acace4d1>
- https://crt.sh/?id=250864705&opt=x509lint
- sha256sum =
3B8812E6F851B6F933DC23ED764082FB5F50DE3C2DDDEBCC9CA240B7ACACE4D1
<https://censys.io/certificates/3b8812e6f851b6f933dc23ed764082fb5f50de3c2dddebcc9ca240b7acace4d1>
- https://crt.sh/?id=250864704&opt=x509lint
- sha256sum =
D8D7627D0F5D0AD09155B2C9347307925EF3E7F6364F231969C0D2E4C71962F0
<https://censys.io/certificates/d8d7627d0f5d0ad09155b2c9347307925ef3e7f6364f231969c0d2e4c71962f0>
- https://crt.sh/?id=254024589&opt=ocsp,x509lint

This is because the organizationName field is typed as a PrintableString
but contains a character illegal in that type, the ampersand. This is
surely just a template typo during the issuance process, and since most
software is permissive to ASN.1 mistakes like this, it wouldn't have been
caught by casual inspection.

Notably, some of the intermediates are UTF8String, and thus compliant:

- sha256sum =
CF7CFA4F9DBCCBCA6D20EFDEBEAD4E173B34E76BDA1EB1E619F44E06E95FC208
<https://censys.io/certificates/cf7cfa4f9dbccbca6d20efdebead4e173b34e76bda1eb1e619f44e06e95fc208>
- https://crt.sh/?asn1=254978692

It also appears that the end-entity certificates issued from Wells Fargo's
intermediates are compliant.

Since Golang is very strict, it caught the constraint error. Chris has
opened Issue #22970 <https://github.com/golang/go/issues/22970> for Golang
to decide if it should be permissive or selectively permissive for this
case. (Interestingly, a year ago, Adam Langley scanned CT for these errrors
<https://github.com/golang/go/issues/14017#issuecomment-176238628> and
found that ampersand is the big offender.)

Note that x509lint already catches this -- as is shown on the crt.sh links
above.

I'd encourage everyone in the Mozilla Root Program to use tools like
x509lint on certificates before making them operational. I think it'd also
be a good idea to, in the future, run these kinds of linting tools on new
intermediates added to the CCADB, and require remediation of some sort for
errors.

Cheers,
J.C.

[Ryan Sleevi]

Note that Chrome recently had to alter its certificate parsing for client
certificates, after it was discovered ComSign had issued a reported 500,000
client certificates with an invalid encoding - notably, the @ sign in the
PrintableString. This was at
https://bugs.chromium.org/p/chromium/issues/detail?id=770323

In addition to needing to introduce this workaround for selecting client
certificates, we also discovered some Enterprise software does the same.
Notably, the Cisco Network Setup Assistant similarly produces certificates
with the @ sign in the PrintableString -
https://bugs.chromium.org/p/chromium/issues/detail?id=788655

In addition to the advice J.C. raises here, which is excellent advice, all
CAs should be ensuring that their certificates - whether TLS server certs,
client certs, S/MIME, code signing, or other - similarly comply with the
X.509 standard and RFC 5280.

Certlint ( https://github.com/awslabs/certlint ), built upon asn1c (
https://github.com/vlm/asn1c ) to build an asn1validator (
https://github.com/awslabs/certlint/tree/master/ext ) is one such way to do
so.

In the specific case of PrintableString, Chrome has decided to only enable
such workarounds for client certs, and only for a limited time (
https://bugs.chromium.org/p/chromium/issues/detail?id=791106 ). There are
no plans to enable it for CA certificates or TLS server certificates, and
they will be treated as misissuance.