What if x509.ParseCertificates would just return the error in combination
with the parsed certificate?

This would allow you to make an educated decision based on the error
message. While this could become a problem when you run into multiple
errors and it would make it more important for developers to actually check
the error message. But at least it would prevent us from having X
number ParseCertificate(s) functions.
On Thursday, 19 March 2015 12:20:09 UTC+1, Adrià Casajús wrote:

That would be ok. But would that work if I use that cert to connect via
TLS to a go server. The server wouldn't probably use that to load the certs
received from the wire. Could we add that option also to the tls.Config
struct (I mean the extra oids)?

On Sunday, March 15, 2015 at 2:37:02 AM UTC+1, agl wrote:
On Friday, March 13, 2015 at 7:43:31 AM UTC-7, Adrià Casajús wrote:

Can I go ahead with this?
You are likely to be the only ever user of this, so I'm more inclined to
think about solving the more general problem. What if there was a
x509.ParseCertificateWithKnownExtensions(asn1Data []byte, oids
[]asn1.ObjectIdentifer)? (That name is sadly long but it's the best I can
come up with at the moment.) The given OIDs would be accepted, even if
critical, and stored in Certificate.Extensions as normal. From there, you
could parse anything you need outside of the standard libraries.

(Does ParseCertificateWithOIDs work as a name I wonder?)


You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 16 | next ›
Discussion Overview
groupgolang-nuts @
postedMar 2, '15 at 12:14p
activeApr 30, '15 at 5:24p



site design / logo © 2022 Grokbase