crypto/x509: does not expose URIs in SubjectAltName extension

[gopherbot]

by jonas.p:

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/

[agl]

Comment 2:

What's the use case? (crypto/x509 doesn't try to serve everyone, but if there's
something sufficiently common that needs this then I agree that it can be added.)

[gopherbot]

Comment 3 by jonas.p:

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).

[agl]

Comment 4:

Owner changed to @agl.

[agl]

Comment 5:

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.

[rsc]

Comment 6:

Labels changed: added priority-later, go1.2maybe, removed priority-triage.

Status changed to Accepted.

[rsc]

Comment 7:

Labels changed: added feature.

[robpike]

Comment 8:

Not for 1.2.

Labels changed: removed go1.2maybe.

[agl]

Comment 9:

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.