Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
crypto/x509: does not expose URIs in SubjectAltName extension #5752
What steps will reproduce the problem? try to get Subject Alternative Name URIs in the same way you can access DNSNames, EmailAddresses and IPAddresses http://play.golang.org/p/by0PoVfPyd What is the expected output? URIs returns the subject alternative name URIs of a certificate What do you see instead? URIs is not available Which version are you using? (run 'go version') go version devel +eec7eca4b11a Mon Jun 17 14:56:45 2013 -0700 linux/amd64 Please provide any additional information below. possible implementation: https://golang.org/cl/7501043/
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-188.8.131.52 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).
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.