Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: crypto/x509: implement TextMarshaler for *Certificate #33888

Closed
kevinburke1 opened this issue Aug 27, 2019 · 6 comments
Closed

proposal: crypto/x509: implement TextMarshaler for *Certificate #33888

kevinburke1 opened this issue Aug 27, 2019 · 6 comments
Labels
FeatureRequest FrozenDueToAge Proposal Proposal-Crypto Proposal related to crypto packages or other security issues
Milestone

Comments

@kevinburke1
Copy link

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 FiloSottile added FeatureRequest NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Aug 28, 2019
@FiloSottile FiloSottile added this to the Unplanned milestone Aug 28, 2019
@FiloSottile
Copy link
Contributor

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?

@FiloSottile FiloSottile added the Proposal-Crypto Proposal related to crypto packages or other security issues label Dec 4, 2019
@FiloSottile FiloSottile changed the title crypto/x509: implement TextMarshaler for *Certificate proposal: crypto/x509: implement TextMarshaler for *Certificate Dec 4, 2019
@gopherbot gopherbot added Proposal and removed NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Dec 4, 2019
@rsc
Copy link
Contributor

rsc commented Feb 11, 2020

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
Copy link
Contributor

rsc commented Feb 12, 2020

Adding to proposal minutes but seems headed for likely decline.

@kevinburke1
Copy link
Author

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

@rsc
Copy link
Contributor

rsc commented Feb 26, 2020

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 rsc moved this from Active to Likely Decline in Proposals (old) Feb 26, 2020
@rsc
Copy link
Contributor

rsc commented Mar 4, 2020

No change in consensus, so declined.

@rsc rsc closed this as completed Mar 4, 2020
@rsc rsc moved this from Likely Decline to Declined in Proposals (old) Mar 4, 2020
@golang golang locked and limited conversation to collaborators Mar 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FeatureRequest FrozenDueToAge Proposal Proposal-Crypto Proposal related to crypto packages or other security issues
Projects
No open projects
Development

No branches or pull requests

4 participants