-
Notifications
You must be signed in to change notification settings - Fork 18k
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
crypto/x509: does not expose URIs in SubjectAltName extension #5752
Labels
Comments
My use case is the authentication mechanism called WebID+TLS (rebranded from FOAF+SSL), https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html . It uses an SubjectAltName URI entry to point to a document containing a public key. It is only a draft, so it probably isn't anything I would call sufficiently common. But I would argue that crypto/x509 is the right place to expose URIs in the SubjectAltName x509 extension. Here are my arguments: 1. URIs in SubjectAltName is part of the spec, http://tools.ietf.org/html/rfc3280#section-4.2.1.7 and if crypto/x509 tries to follow the spec it is the correct place to expose URIs in the same way other SubjectAltNames are exposed. 2. The proposed patch is only mirroring how SAN EmailAddresses are handled. It doesn't add any new fundamentals in how crypto/x509 is used. 3. Actually x509.Certificate already exposes all the certificate content via Raw. But it is ASN.1 encoded, so to get the SubjectAltName URI i would have to decode and parse the certificate, effectively duplicating parts of crypto/x509 (which is what I do currently). |
Owner changed to @agl. |
Can you take a look at https://golang.org/cl/12056043/ and let me know if that serves for you? You would still need to duplicate and alter the parsing of the SAN extension, but hopefully that's much smaller than the code that you currently have. |
I'm going to call this fixed by https://code.google.com/p/go/source/detail?r=564ce4b5cc75 Not, perhaps, the solution that you were looking for but it allows this case to be handled without too much pain and without handling every possible use case in the core library. Status changed to Fixed. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by jonas.p:
The text was updated successfully, but these errors were encountered: