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/pkix: FillFromRDNSequence does not preserve multi-value RDNs #23069
Comments
CC @FiloSottile |
Clearly missed for Go 1.11. |
This is bad, also because it will lead to a parse-serialize cycle returning a semantically different result, but I can't see how to fix this without making a whole new set of APIs, which is not an option for such rare certificates. Unless anyone has any better idea, we should just document this behavior, maybe in FillFromRDNSequence. |
Change https://golang.org/cl/229864 mentions this issue: |
Previously, non-standard attributes in Name.Names were being omitted when printed using Name.String(). Now, any non-standard attributes that would not already be printed in Name.String() are being added temporarily to Name.ExtraNames to be printed. Fixes golang#33094 Fixes golang#23069 Change-Id: Id9829c20968e16db7194549f69c0eb5985044944 Reviewed-on: https://go-review.googlesource.com/c/go/+/229864 Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
What version of Go are you using (
go version
)?This issue affects Go 1.8 and later as a consequence of 809a1de to fix #16836 (and #12342).
Prior to Go 1.8 and that change, Go did not process multi-value RDNs -- it always assumed just one attribute and value (the first) per RDN.
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?The OS and architecture should not matter.
What did you do?
https://play.golang.org/p/7OIuhautCe
What did you expect to see?
The multi-value nature of any RDN is preserved. That is, the length of the subject (and issuer) RDNSequence before pkix.FillFromRDNSequence and after pkix.ToRDNSequence should match.
What did you see instead?
The multi-value nature of any RDN is not preserved by pkix.FillFromRDNSequence. That is, the length of the subject (and issuer) RDNSequence before pkix.FillFromRDNSequence and after pkix.ToRDNSequence do not match.
As previously noted in comments on 809a1de, the original Gerrit CR, and #12342, if this will not be fixed, then the behavior should be documented at a minimum.
The text was updated successfully, but these errors were encountered: