crypto/x509: no support for BitString

[TxI5]

Go version

1.23.1

Output of go env in your module/workspace:

-

What did you do?

Read x509 cert containing a BitString

What did you see happen?

unsupported string type: 3 BitString

What did you expect to see?

Support for bitstring https://go.dev/src/crypto/x509/parser.go line 60

[mateusz834]

Are you able to share with us the X509 certificate you are parsing?
In which place the cert contains a BitString?

[TxI5]

Im not able to share the cert unfortunately.

Its under RDNSequence,
Relative distinguished name item
oid: 2.5.4.45 - id-at-uniqueIdentifier

If that helps.
Same issue as #48171 but with type 3

[mateusz834]

RFC 5280 permits the use of following attributes in an RDNSequence:

Standard sets of attributes have been defined in the X.500 series of
specifications [X.520]. Implementations of this specification MUST
be prepared to receive the following standard attribute types in
issuer and subject (Section 4.1.2.6) names:

 * country,
 * organization,
 * organizational unit,
 * distinguished name qualifier,
 * state or province name,
 * common name (e.g., "Susan Housley"), and
 * serial number.

In addition, implementations of this specification SHOULD be prepared
to receive the following standard attribute types in issuer and
subject names:

 * locality,
 * title,
 * surname,
 * given name,
 * initials,
 * pseudonym, and
 * generation qualifier (e.g., "Jr.", "3rd", or "IV").

id-at-uniqueIdentifier is not mentioned in the spec.

CC @FiloSottile @rolandshoemaker @golang/security

[TxI5]

Also

The type of the component AttributeValue is determined by the AttributeType; in general it will be a DirectoryString.
...
This specification does not restrict the set of attribute types that may appear in names. However, conforming implementations MUST be prepared to receive certificates with issuer names containing the set of attribute types defined below. This specification RECOMMENDS support for additional attribute types.

It certainly is not optimal but i cant change the cert.

[rolandshoemaker]

Is this certificate produced or used by some widely used software? The crypto/x509 package explicitly implements a restricted set of X.509 features, necessary for supporting publicly trusted certificates. (per the package documentation, "There is minimal support for features outside of these profiles, as the primary goal of the package is to provide compatibility with the publicly trusted TLS certificate ecosystem and its policies and constraints.")

Without relatively widespread usage of this feature, especially in publicly trusted certificates, we're unlikely to add support for it.

[TxI5]

This specific cert is only used in my organisation with a couple of thousand users. Its not publicly available and therefore not widespread.
We want it to be read and accepted by Caddy web server wich uses this lib.

[jethrogb]

Related #48371

[jethrogb]

The 2.5.4.45 attribute does appear in some publicly available Certification Practice Statements:
https://cca.gov.in/sites/files/pdf/Licensed-CA/CADC-CA-CPSv10.pdf
https://emdha.sa/Downloads/L2_-_emdha_eSign_CA_CP-CPS_v20_31JAN22.pdf

[phbnf]

For what it's worth, I just ran into this parsing this certificate: https://crt.sh/?sha256=b41d516a5351d42deea191fa6edf2a67dee2f36dc969012c76669e616b900ddf

This CA cert will expire in a few weeks, and looking at CCADB, is only included in the Microsoft Root Store, in which it's also disabled. Therefore, I don't think it's super important to parse this certificate (especially with regards to #69463 (comment)), but now at least this issue references an example certificate.