Skip to content
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

SUGGESTION: Please Make AsnReader And AnsWriter Public #1147

rashadrivera opened this Issue Apr 16, 2019 · 2 comments


None yet
2 participants
Copy link

rashadrivera commented Apr 16, 2019


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 rashadrivera changed the title Please Make AsnReader And AnsWriter Public SUGGESTION: Please Make AsnReader And AnsWriter Public Apr 19, 2019


This comment has been minimized.

Copy link

rashadrivera commented Apr 19, 2019


I've pulled the AsnReader and AsnWritter into my project as a test and it work when creating CRL encoded content with very little modifications. I'm willing to put in a pull request make these two classes public.


This comment has been minimized.

Copy link

bartonjs commented Apr 19, 2019

@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) -

These types are available via a permanent-prerelease NuGet package (

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.

@bartonjs bartonjs closed this Apr 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.