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

encoding/asn1: ASN.1 GeneralizedTime syntax can include fraction-of-second details #20864

vanbroup opened this issue Jun 30, 2017 · 2 comments


Copy link

@vanbroup vanbroup commented Jun 30, 2017

The problem has been reported before as issue #15732, where @agl states that rfc5280 prohibits the use of fraction-of-second details in a UTCTime. I fully agree that this is the case for rfc5280 and some other standards, but not all.

I created this issue as we encounter the same problem with GeneralizedTime when parsing timestamp messages with

asn1: time did not serialize back to the original value and may be invalid: given "20120824102207.46225Z", but serialized as "20120824102207Z"

Can the encoding/asn1 package be updated to follow the official encoding instead of one implementation that is using the package and putting some restrictions on the format?

Updating encoding/asn1 will not harm any other implementation.

Copy link

@agl agl commented Jul 7, 2017

encoding/asn1 was a mistake, I'm afraid. We're committed to supporting the existing API, but I think it should be frozen. cryptobyte is a start of something that hopefully doesn't end up in such a bad place, code-wise. It doesn't look like it parses fractional time values either, but that would be reasonable there.

@agl agl closed this Jul 7, 2017
Copy link
Contributor Author

@vanbroup vanbroup commented Jul 8, 2017

encoding/asn1 is used in critical parts of the core go language, are you planning to replace that with a new internal/external package?

It doesn't look like a simple package to phase out (as in it shouldn't have been included). I did notice some significant performance implications with encoding/asn1 so it would be good to have something better. But while the package is part of the core go language (and not officially deprecated like log/syslog) and used by other core packages it wouldn't it make sense to keep updating it until there is something new?

This parsing check is something that would be simple to fix, so why not?

@golang golang locked and limited conversation to collaborators Jul 8, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.