Skip to content

crypto/x509/pkix: Name.String() hex-encodes string-type ExtraNames #33093

Closed
Closed
crypto/x509/pkix: Name.String() hex-encodes string-type ExtraNames#33093
Assignees
odeke-em
Labels
NeedsFixThe path to resolution is known, but the work has not been done.
Milestone
Go1.27

Description

@rittneje
rittneje
opened on Jul 13, 2019

What version of Go are you using (go version)?

$ go version
go version go1.12.6 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jrittner/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jrittner/go-workspace"
GOPROXY=""
GORACE=""
GOROOT="/home/jrittner/go"
GOTMPDIR=""
GOTOOLDIR="/home/jrittner/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build691331496=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I created a pkix.Name containing a custom ExtraName, and converted it to a string.

https://play.golang.org/p/1hyqwP_RTBs

What did you expect to see?

1.2.3.4=sample,CN=foobar

What did you see instead?

1.2.3.4=#130673616d706c65,CN=foobar

This is because Go always hex-encodes the asn.1 encoding of the value, even though RFC 2253 states that the value is supposed to just be used as its own string encoding. https://tools.ietf.org/html/rfc2253#section-2.4

Otherwise, if the AttributeValue is of a type which has a string
representation, the value is converted first to a UTF-8 string
according to its syntax specification (see for example section 6 of
[4]).

Note that OpenSSL gives the expected output when viewing a certificate or CSR with a custom name.

Activity

  1. dmitshur commented on Jul 15, 2019

    @dmitshur
    dmitshur
    on Jul 15, 2019
    Member

    /cc @FiloSottile

  2. dmitshur
    added
    NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.
    on Jul 15, 2019
  3. dmitshur
    added this to the Go1.14 milestone on Jul 15, 2019

  4. FiloSottile commented on Oct 1, 2019

    @FiloSottile
    FiloSottile
    on Oct 1, 2019
    Contributor

    I read the previous spec paragraph as saying that this is the correct form when the type is unknown and expressed as a dotted decimal.

       If the AttributeValue is of a type which does not have a string
   representation defined for it, then it is simply encoded as an
   octothorpe character ('#' ASCII 35) followed by the hexadecimal
   representation of each of the bytes of the BER encoding of the X.500
   AttributeValue.  This form SHOULD be used if the AttributeType is of
   the dotted-decimal form.

    There is even an example for it in Section 5.

       1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB

    Can you provide an example certificate?

  5. FiloSottile
    modified the milestones: Go1.14, Unplanned on Oct 1, 2019

  6. rittneje commented on Oct 2, 2019

    @rittneje
    rittneje
    on Oct 2, 2019
    ContributorAuthor

    Here is a sample CSR:

    -----BEGIN CERTIFICATE REQUEST-----
MIIBYTCBywIBADAiMQ8wDQYDVQQDEwZmb29iYXIxDzANBgMqAwQTBnNhbXBsZTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtDs1ygEixq27qFrGGh4pXIbg5Q6U
kzNRLRVo4STAkYl6looxjPf7u77/6TwYAVnu6zT6VULf+lyk4g7l2AwnxfQ+a6V/
KBqvnMhNI8NbPfouqnqvJekTNUGhnAwfCgthZXuYywlJASsBKcudHwkk+MNJWBUQ
kCU1JyXsFyHdr1sCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4GBAHF/6Hin8itNP/Uv
JW3tvUCkxaFXmL2UjA6Ed+UM4AXnPqSpGXx3hgccOcRJD63uQnl/yUbcpo7xIdFk
i/m6v0HX/8aRHBFM6o8zO8ellcidP0a4K5TzBhbJv6Dpy4HJOPkHZ9Mzi6Dprwj2
0gX/y4r5wM5d0/oOXPHS5N1DgEiK
-----END CERTIFICATE REQUEST-----

    OpenSSL shows the custom distinguished name as a string:

    $ openssl req -in sample.csr -subject -noout
subject=/CN=foobar/1.2.3.4=sample

    The OpenSSL output is preferable over the current Go output because it is human readable.

  7. rittneje commented on Mar 19, 2021

    @rittneje
    rittneje
    on Mar 19, 2021
    ContributorAuthor

    @FiloSottile Wanted to follow up on this.

    The example you copied is specifically for an "octet string", hence the 04 prefix. However, the custom DN in my example is actually a "printable string", hence the 13 prefix. It should thus be used as its own string representation

  8. rittneje commented on Jul 29, 2021

    @rittneje
    rittneje
    on Jul 29, 2021
    ContributorAuthor

    ping @FiloSottile

  9. rittneje commented on Aug 22, 2021

    @rittneje
    rittneje
    on Aug 22, 2021
    ContributorAuthor

    @FiloSottile Is this something you will consider fixing, given what I mentioned?

  10. rittneje commented on Oct 19, 2021

    @rittneje
    rittneje
    on Oct 19, 2021
    ContributorAuthor

    @FiloSottile is there someone else I should CC?

  11. bjanders commented on Apr 21, 2022

    @bjanders
    bjanders
    on Apr 21, 2022

    I agree with @rittneje . Here is a simple example. Create a certificate with openssl:

    openssl req -new -x509 -subj '/UID=foobar/' -nodes -outform DER -out cert.crt

    The ASN.1 structure of the Subject DN in cert.crt:

    SEQUENCE (1 elem)
      SET (1 elem)
        SEQUENCE (2 elem)
          OBJECT IDENTIFIER 0.9.2342.19200300.100.1.1 userID
          UTF8String foobar

    The type is UTF8String (not for example an octect string). Requoting @rittneje from RFC 2253:

    Otherwise, if the AttributeValue is of a type which has a string
    representation, the value is converted first to a UTF-8 string
    according to its syntax specification (see for example section 6 of
    [4]).

    UTF8String has a string representation and does not even need conversion, so it should be printed as:

    0.9.2342.19200300.100.1.1=foobar

    Not like go1.18.1 does:

    0.9.2342.19200300.100.1.1=#1306666f6f626172

    In #39924 @FiloSottile says:

    Unfortunately, we are bound to the RFC 2253 format by the docs and that format requires any non-standard attribute to be printed as a dotted OID and hex-encoded value.

    But this is not what RFC 2253 says. RFC 2253 does not mention "non-standard attributes"; it says "does not have a string representation" which is a different thing:

    If the AttributeValue is of a type which does not have a string
    representation defined for it, then it is simply encoded as an
    octothorpe character ('#' ASCII 35) followed by the hexadecimal
    representation

  12. rittneje commented on Jun 28, 2022

    @rittneje
    rittneje
    on Jun 28, 2022
    ContributorAuthor

    cc @rolandshoemaker

  13. rittneje commented on Jan 16, 2023

    @rittneje
    rittneje
    on Jan 16, 2023
    ContributorAuthor

    ping @FiloSottile

  14. bjanders commented on Jan 16, 2023

    @bjanders
    bjanders
    on Jan 16, 2023

    ping @FiloSottile

    I don't think @FiloSottile is working on this project anymore. I guess the fastest way to fix this is to fix it ourselves and request a pull.

  15. 12 remaining items

  16. gopherbot
    modified the milestones: Go1.23, Go1.24 on Aug 13, 2024
  17. gopherbot
    modified the milestones: Go1.24, Go1.25 on Feb 11, 2025
  18. gopherbot
    modified the milestones: Go1.25, Go1.26 on Aug 12, 2025

  19. odeke-em commented on Dec 18, 2025

    @odeke-em
    odeke-em
    on Dec 18, 2025
    Member

    Rolling over to Go1.27 as the CL didn't get a review.

  20. odeke-em
    modified the milestones: Go1.26, Go1.27 on Dec 18, 2025

  21. gopherbot commented on May 4, 2026

    @gopherbot
    gopherbot
    on May 4, 2026
    Contributor

    Change https://go.dev/cl/773800 mentions this issue: crypto/x509/pkix: make Name.String correctly print ASN1 printable strings

  22. gopherbot
    closed this as completedin 978f00aon May 6, 2026
  23. github-project-automation
    moved this to Done in @FiloSottile's Go planson May 6, 2026
  24. pull
    added a commit that references this issue on May 6, 2026

    crypto/x509/pkix: render string-typed attribute values as strings

    978f00a
  25. dmitshur
    added
    NeedsFixThe path to resolution is known, but the work has not been done.
    and removed
    NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.
    on May 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

NeedsFixThe path to resolution is known, but the work has not been done.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions