This repository was archived by the owner on Jan 23, 2023. It is now read-only.
[release/3.1] Permit incorrectly DER sorted SET for decoding X500 names. #42873
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a cherry-pick of dotnet/runtime@b12c901 to port the fix from dotnet/runtime#32558 in to the 3.1 release branch.
/cc @bartonjs @danmosemsft
Description
X500DistinguishedNamevalues that do not follow the specified sort order decode as the empty string on .NET Core 3.0+ on Linux, but work on Windows. This change makes the Linux build match the Windows behavior.The fix is to simply skip a specific data conformance validation check, which only has a visible impact on non-conforming values now being accepted.
Customer Impact
Reported by Pivotal. Customers that encounter X.509 certificates with a subject name, or issuer name, that contains a segment that is not canonically encoded will see that subject name (or issuer name) as the empty string on .NET Core 3.1 on Linux.
This problem only applies to X500DistinguishedName values that use a "multi-RDN" value, which is not very common (the CA/Browser forum Baseline Recommendations do not explicitly say to not use this encoding, but their description of distinguished name values uses "single-value" terminology).
Regression
Yes, from 2.1. The underlying data reader was replaced during 3.0, with the new reader validating by default and the old reader not validating.
Testing
Added a unit test to verify that non-conforming data decodes the same on all platforms.
Risk
Low. The change merely bypasses a conformance check, explicitly choosing to accept non-conforming data. The unit tests confirms that the same answer is given for Windows and Linux.