proposal: crypto/x509: implement TextMarshaler for *Certificate

[kevinburke1]

Working with x509 certificates is currently a pain because most of the formats that certificates are stored in hide the actual data that you need to understand what the certificate is. Certificates encode even the most basic information in PEM or ASN.1 format, to base64 decode this you have to strip the header and footer and even then you get a mix of text (the host names, organization names, common names) and raw bytes (the actual certs).

It would be nice if there was a format for marshaling certificates to plain text (and potentially reading them back from that format). The basic format I have in mind is something like what you get from openssl x509 -text. We could discuss what format would be the most appropriate or maybe just copy that format.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            59:ab:bd:90:f3:e3:0d:27:0f:e9:8d:3d:0e:53:0a:74
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: O=Acme Co
        Validity
            Not Before: Aug 27 22:29:54 2019 GMT
            Not After : Aug 26 22:29:54 2020 GMT
        Subject: O=Acme Co
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:ae:4e:08:ae:98:fa:7c:8f:03:16:7b:fa:48:10:
                    40:96:f7:ed:78:af:98:34:9d:36:fb:9f:83:67:77:
                    43:ab:4e:f4:98:22:a6:55:f5:f3:c2:9c:a5:6b:1c:
                    42:9b:89:be:83:49:9f:e9:88:b2:86:dd:e5:71:bb:
                    0c:c5:10:76:56
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Alternative Name:
                DNS:google.test
    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:21:00:ec:ce:26:fc:cc:97:c6:69:9e:2b:8a:0f:24:
         19:d9:2d:76:a2:7d:30:44:55:e7:84:9e:ba:07:b4:cb:44:40:
         c7:02:20:60:b4:83:d7:57:a5:3d:b0:8d:ae:6e:d0:bb:5c:4c:
         c2:c6:d7:07:cf:43:b5:f0:91:27:48:dc:d1:9c:58:b1:bb
-----BEGIN CERTIFICATE-----
MIIBbzCCARWgAwIBAgIQWau9kPPjDScP6Y09DlMKdDAKBggqhkjOPQQDAjASMRAw
DgYDVQQKEwdBY21lIENvMB4XDTE5MDgyNzIyMjk1NFoXDTIwMDgyNjIyMjk1NFow
EjEQMA4GA1UEChMHQWNtZSBDbzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABK5O
CK6Y+nyPAxZ7+kgQQJb37XivmDSdNvufg2d3Q6tO9JgiplX188KcpWscQpuJvoNJ
n+mIsobd5XG7DMUQdlajTTBLMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggr
BgEFBQcDATAMBgNVHRMBAf8EAjAAMBYGA1UdEQQPMA2CC2dvb2dsZS50ZXN0MAoG
CCqGSM49BAMCA0gAMEUCIQDszib8zJfGaZ4rig8kGdktdqJ9MERV54Seuge0y0RA
xwIgYLSD11elPbCNrm7Qu1xMwsbXB89DtfCRJ0jc0ZxYsbs=
-----END CERTIFICATE-----

[FiloSottile]

I am a fan of the openssl x509 -text format, but I'm not sure we need it in the standard library. (It's not trivial to implement and maintain with new OID names etc.) Wouldn't an external module work just as well, even if the type won't implement TextMarshaler?

[rsc]

A text dump is not a marshalled encoding. That would imply we needed to parse it during Unmarshal as well. A helper in x509 might be fine but not a TextMarshal method but it would require x509 taking on the OID -> Name mapping. This really seems like something to put in an external package.

[rsc]

Adding to proposal minutes but seems headed for likely decline.

[kevinburke1]

I was thinking maybe something like golang.org/x/crypto/x509util.DumpCertificate but I'm not super happy with that either.

[rsc]

Based on the discussion above, this is a likely decline.

@kevinburkemeter, it would probably help to start with your own package and see how useful it turns out to be.

[rsc]

No change in consensus, so declined.