encoding/asn1: allow the user to specify the time format used to unmarshal

[ChrisPortman]

Fixes #29069
Introduces a timeFormat field flag allowing the user to nominate a time format to be used in place of the traditional defaults when unmarshalling received data. E.g.:

TimeStamp    time.Time    `asn1:"generalized,timeFormat:20060102150405.000000Z0700"`

[gopherbot]

This PR (HEAD: 4da144f) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/152117 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

[gopherbot]

Message from Rob Pike:

Patch Set 1:

Is this necessary? This is deliberately only a subset of ASN1 and we have resisted giving it more general capabilities so far.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/152117.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Brad Fitzpatrick:

Patch Set 1:

(1 comment)

I think this package is basically frozen, in favor of the cryptobyte package.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/152117.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Chris Portman:

Patch Set 1:

Patch Set 1:

(1 comment)

I think this package is basically frozen, in favor of the cryptobyte package.

I'm not sure I understand what the motivation here is. There is an "encodings" module that contains various de/serialization mechanisms. It seems entirely consistent to have a general use case asn1 package in there for de/serializing data to/from ASN.1.

Compared to the ASN.1 implementation that's bundled with crypto, I would expect that the encoding/asn1 package be much more applicable to general use cases while the crypto implementation would specifically support only the design goals of the crypto package, it's corner cases and nothing else.

In fact, I would even go so far as to expect that proposals extending the functionality of the ASN1 package within crypto, in a way that was not required by crypto, would be rejected. Why complicate a package beyond its purpose.

If the strategic intention is to consolidate onto a single ASN.1 library, then wouldn't it make more sense to deprecate the crypto implementation, and refactor crypto to leverage encoding/asn1.

In addition, having looked at the cryptobyte doc, it looks far less friendly and/or scalable to use in general use cases with large and dynamic data structures compared to encodings/asn1. The included examples are based on very simple data structures, and yet much harder to read than examples of encoding/asn1 that use bigger structures (IMO).

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/152117.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

This PR (HEAD: 825130b) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/152117 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

[gopherbot]

Message from Chris Portman:

Patch Set 2:

(1 comment)

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/152117.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Rob Pike:

Patch Set 2: Code-Review-1

Hold pending resolution of the issue, and because we are in a feature freeze.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/152117.
After addressing review feedback, remember to publish your drafts!