-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Description
Background and motivation
Over at #103924 we had a discussion about how we wanted to handle duplicate attributes on a PKCS12 bag that was being loaded as part of the safer loader limits.
At the time we decided to always reject a PKCS#12 that contained duplicate attributes, believing that occurrences of this would be epsilon.
However at least one popular library produces PKCS#12 with duplicate attributes: BouncyCastle. BC will apply the attribute 2.16.840.1.113894.746875.1.1
which will contain multiple attrValues
. This attribute is used by Java and their keytool software.
#113726 highlights a need for users to at least be able to allow the duplicate attributes without dropping all of the way down to DangerousNoLimits
.
API Proposal
namespace System.Security.Cryptography.X509Certificates;
public sealed partial class Pkcs12LoaderLimits {
// Property already exists, just changing it to public
// get and set like other properties, will respect the read-only status of the limits instance.
+ public bool AllowDuplicateAttributes { get; set; }
}
API Usage
Pkcs12LoaderLimits limits = new();
limits.AllowDuplicateAttributes = true;
using X509Certificate2 cert = X509CertificateLoader.LoadPkcs12(
myPkcs12BytesFromBouncyCastle,
"hunter2",
loaderLimits: limits);
Alternative Designs
Technically there are two things we are using the property for. Duplicate attributes by OID, and the number of values each attribute can contain. This property relaxes both. I don't think we need to independently control both as that overly nuanced, I think.
Risks
No response