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

crypto/x509: does not expose URIs in SubjectAltName extension #5752

Closed
gopherbot opened this issue Jun 22, 2013 · 8 comments
Closed

crypto/x509: does not expose URIs in SubjectAltName extension #5752

gopherbot opened this issue Jun 22, 2013 · 8 comments

Comments

@gopherbot
Copy link

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

agl commented Jul 22, 2013

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

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

agl commented Jul 29, 2013

Comment 4:

Owner changed to @agl.

@agl
Copy link
Contributor

agl commented Jul 29, 2013

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

rsc commented Jul 30, 2013

Comment 6:

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

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 7:

Labels changed: added feature.

@robpike
Copy link
Contributor

robpike commented Aug 30, 2013

Comment 8:

Not for 1.2.

Labels changed: removed go1.2maybe.

@agl
Copy link
Contributor

agl commented Aug 30, 2013

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.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants