You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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?
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 https://github.com/digitorus/timestamp.
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.
The text was updated successfully, but these errors were encountered: