Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
SUGGESTION: Please Make AsnReader And AnsWriter Public #1147
I have a real need for the internl classes that are being used in .NET Core 2.x. I need a Asn reader and writer and I've recently discovered the AsnReader and AsnWriter as internal classes. Can these classes become public within .NET Standard? My products are built upon .NET Standard exclusively and not .NET Core or .NET.
In my case, I need them to create certificate revocation lists (CRL) and translate online certificate status protocol (OCSP) requests and responses. I've used BouncyCastle as part of my solution, but I feel it is a poor implementation because of its cryptic design and the fact that I must give it unadulterated access to my private keys (which is a serious FIPS security concern).
My goal is to use out-of-process signing like Azure. But in order to do that, I need a solution that allows me to generate Asn data without third party tools like BouncyCastle.
@rashadrivera New types aren't added to dotnet/standard until they've already shipped in a .NET platform (now .NET Core is the usual source of new types) - https://github.com/dotnet/standard/tree/master/docs/governance#inclusion-principles.
These types are available via a permanent-prerelease NuGet package (https://dotnet.myget.org/feed/dotnet-corefxlab/package/nuget/System.Security.Cryptography.Asn1.Experimental).
Before they can go public in .NET Core they need to go through an API review. Since they're not critical to already-promised features for .NET Core 3.0 they're too low of priority to make it through API review in the next several weeks. Once it makes it through API review there'll be a question of the distribution of the types... if they're considered platform then they'll be in .NET Core only until they get added to a future .NET Standard, then they'll spread to other .NET platforms as they adopt newer .NET Standard versions. Or they'll go out as a (stable) NuGet package potentially targeting some .NET Standard version(s).
But, no matter what, dotnet/corefx#21833 is the issue to follow / comment on.
Closing this issue as the corefx one is more appropriate.