Wrong C509 to X509 encoding for otherName

[shmset]

While testing the Rust encoding tool with cargo r l, I noticed that one of the certificates could not be encoded and reconstructed. The encoding for the Extension > GeneralName > OtherName seems to be wrong, in my case this was a PermanentIdentifer.

The DER encoded value of the x509 certificate is:

SEQUENCE: (2 elem)
  [0]: (2 elem)
    OBJECT_IDENTIFIER: 1.3.6.1.5.5.7.8.3|permanentIdentifier
    [0] : (1 elem)
      SEQUENCE: (2 elem)
        UTF8String: c85...
        OBJECT_IDENTIFIER: 2.23.133.12.2
  [0]: (2 elem)
    OBJECT_IDENTIFIER: 1.3.6.1.5.5.7.8.4|hwModuleName
    [0] : (1 elem)
      SEQUENCE : (2 elem)
        OBJECT_IDENTIFIER: 2.23.133.1.2
        OCTET_STRING: (57 byte)|4942...

After encoding it to CBOR and back, the value is this:

SEQUENCE: (2 elem)
  SEQUENCE : (2 elem)
    OBJECT_IDENTIFIER 1.3.6.1.5.5.7.8.3|permanentIdentifier
    SEQUENCE: (2 elem)
      UTF8String: c85...
      OBJECT_IDENTIFIER: 2.23.133.12.2
  [0] : (2 elem)
    OBJECT_IDENTIFIER: 1.3.6.1.5.5.7.8.4|hwModuleName
    [0]: (1 elem)
      SEQUENCE: (2 elem)
        OBJECT_IDENTIFIER: 2.23.133.1.2
        OCTET_STRING: (57 byte)|4942...

It seem the value of otherName is correctly encoded structure is not for the permanentIdentifier. The hwModuleName however is correct. From RFC 5280:

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

I created another certificate to confirm this in Python, which resulted in the same behaviour described above.

Extension creation:

custom_oid = x509.ObjectIdentifier("1.2.3.4.5.6")
other_name_asn = OctetString( b"custom-identifier")
other_name = x509.OtherName(custom_oid, other_name_asn.dump())
cert_builder = cert_builder.add_extension(
    x509.SubjectAlternativeName([
        other_name
    ]), critical=False)

I'm unsure if the problem is in the X509 to C509 conversion or when converting it back.

[gselander]

Thanks for posting! F.y.i. - currently there is only low intensity maintenance of this code. We are looking for alternatives in terms of maintainers and other code basis. Any suggestions are welcome.

[shmset]

Thanks for the quick reply and report of the maintenance of the code! I would have created a PR but I'm unfamiliar with rust, but might look into it.

[gselander]

Contributions are welcome!

[shmset]

@gselander Quick ping for visibility. Seems that your comment arrived at the same time as my PR.

[emanjon]

Would be good to make sure that this is an problem with the code and not with the specification.

[shmset]

@emanjon Good point. I didn't think of that. I'll have a look at it once I get around it and will post my findings.

[shmset]

@emanjon I did some investigation. The section 9.12 C509 General Names Registry specifies how the generalName should be encoded:

   +-------+-----------------------------------------------------------+
   |     0 | Name:            otherName                                |
   |       | Comments:                                                 |
   |       | GeneralNameValue:  [ ~oid, bytes ]                        |
   +-------+-----------------------------------------------------------+

The ASN.1 definition for otherName is as follows:

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

So the mapping is straight forward: [ type-id, value ]

In my testing I have this DER encoded otherName extension:

A0 47 06 08 2B 06 01 05 05 07 08 03 *A0 3B* 30 39 0C 30 36 37 65 61 63 65 61 66 36 31 32 62 36 64 30 64 30 64 38 37 31 38 61 66 38 64 38 30 38 31 39 37 65 61 64 31 61 63 35 38 31 36 31 39 38 64 30 61 06 05 67 81 05 0C 02

or more readable:

[0] (2 elem)
  OBJECT_IDENTIFIER: 1.3.6.1.5.5.7.8.3|permanentIdentifier|PKIX other name
  [0]  (1 elem)
    SEQUENCE (2 elem)
      UTF8String: 67eaceaf612b6d0d0d8718af8d808197ead1ac5816198d0a
      OBJECT_IDENTIFIER: 2.23.133.12.2

Compare this to the (not fixed) variant of c509, especially the 59 bytes in the end:

00                             # unsigned(0)
   82                             # array(2)
      48                          # bytes(8)
         2B06010505070803         # "+\u0006\u0001\u0005\u0005\u0007\b\u0003"
      58 3B                       # bytes(59)        

30390C3036376561636561663631326236643064306438373138616638643830383139376561643161633538313631393864306106056781050C02

The bytes should also encode the [0] EXPLICIT ANY tag as this is part of the ASN.1 definition of the otherName encoding. Therefore the specification is correct, but the implementation fails to add the bytes *A0 3B*.

Hope that made sense. I'll gladly elaborate more if required.