[release/6.0] Fix SignedCms certificate collection modification with attribute certificates #80209
Conversation
…ificates. When adding or removing certificates from the certificateSet collection, we assumed that the collection would only contain X.509 certificates. This changes the implementation so that when looking for duplicates, we skip over choices that are not an X.509 certificate when looking for a duplicate. The tests peek in to the SignedData ASN.1 to ensure that the attribute certificates are preserved during a round trip when encoding and decoding a CMS.
ghost
assigned 
|
Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones Issue DetailsBackport of #79940 and #80195 to release/6.0 Customer ImpactReported by a partner for TestingThis introduces tests to validate behavior of a CMS that contains attribute certificates to prevent regressions. RiskLow. The changes are isolated and well understood. IMPORTANT: Is this backport for a servicing release? Yes.
|
vcsjones
changed the title
|
@carlossanlop the CI failures look unrelated. I think those failures are caused by the upgrade to macOS 12 in the In that PR, the same tests failed. |
bartonjs
added
Servicing-consider
|
Approved by Tactics (6.0.14). |
Backport of #79940 and #80195 to release/6.0
Customer Impact
Reported by a partner for
dotnet/signat #79935. When usingSignedCmswith a CMS that contains an attribute certificate, such as an RFC3161 timestamp issued by Azure Codesigning, theAddCertificateandRemoveCertificateAPIs would raise an exception when adding or removing an X.509 certificate because they did not know how to process the attribute certificate. The impact of this is that these two APIs cannot function in the presence of an attribute certificate.Testing
This introduces tests to validate behavior of a CMS that contains attribute certificates to prevent regressions.
Risk
Low. The changes are isolated and well understood.
IMPORTANT: Is this backport for a servicing release? Yes.