[Bug]: X509 decoder fails to handle OtherName with value of an IA5String

[BrianSipos]

Contact Details

brian.sipos@gmail.com

Version

5.8.4

Description

The X509 component fails to decode any certificate with a SAN with value Other Name having a value that is an IA5String. It looks like Other Name values of UTF8String are handled correctly (although not visualized in a tool such as wolfssl x509 ..., which is fine).

This happens with online (D)TLS certificate exchange as well as with offline tool such as wolfssl x509 ... so it's easily isolated and tested.

It appears that the Other Name value is only considered value for a few specific types, when the definition in RFC 5280 allows the value to be any type:

   OtherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id }

Reproduction steps

1. Get a certificate conforming to RFC 9174, specifically having a Subject Alt Name extension with an item of type Other Name, and an Other Name value that is an IA5String. A dummy example is attached node-transport.pem.
2. Attempt to process the certificate using wolfssl x509 -noout -text -in node-transport.pem
3. Observe the tool fails to process.
4. Convert to DER form and process using dumpasn1 tool and see it succeed, so the contents are well-formed ASN1.
5. Attempt to process the same file using openssl x509 ... and see it succeed, so the contents are valid PKIX cert.

The relevant portion from dumpasn1 is:

251  54:         SEQUENCE {
253   3:           OBJECT IDENTIFIER subjectAltName (2 5 29 17)
258  47:           OCTET STRING, encapsulates {
260  45:             SEQUENCE {
262  28:               [0] {
264   8:                 OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 11'
274  16:                 [0] {
276  14:                   IA5String 'dtn://node000/'
       :                   }
       :                 }
292  13:               [2] 'node000.local'
       :               }
       :             }
       :           }

Relevant log output

When wolfssl is configured with `--enable-debug` and `-DWOLFSSL_DEBUG_ASN_TEMPLATE` the following is output.

wolfSSL Entering DecodeAltNames
TEMPLATE: altNameASN
wolfSSL Entering GetASN_Items
 0:    2   28    [0]             
TEMPLATE: otherNameASN
wolfSSL Entering GetASN_Items
 0:    4    8    OBJECT ID       
 1:   14   16 +  [0]             
More data in constructed item at depth: 0

[BrianSipos]

An existing passing test of handling SAN Other Name in certs/rid-cert.der uses a UTF8String value which it appears is one of the types explicitly handled. So a workaround in this specific case is to allow IA5String value as well as UTF8String value.

[BrianSipos]

To be clear about my issue: I don't need wolfssl to handle the valid Other Name in any particular way, just need it to accept the certificate as valid (per RFC 5280) and do normal path validation up to a trusted root CA. The application using wolfssl can handle the Other Name form from the raw certificate DER.