Unix AsnEncodedData.Format does not match Windows AsnEncodedData.Format

[bartonjs]

(Apparently I missed this when moving x-plat crypto bugs from TFS to github back in April. Ouch.)

The biggest example that people will notice would have to do with Subject Alternative Names. The examples below are sanExtension.Format(true)

Windows en-US:

DNS Name=dns1.subject.example.org
DNS Name=dns2.subject.example.org
RFC822 Name=sanemail1@example.org
RFC822 Name=sanemail2@example.org
Other Name:
     Principal Name=subjectupn1@example.org
Other Name:
     Principal Name=subjectupn2@example.org
URL=http://uri1.subject.example.org/
URL=http://uri2.subject.example.org/

Unix (non-localized):

DNS:dns1.subject.example.org, DNS:dns2.subject.example.org, email:sanemail1@example.org, email:sanemail2@example.org, othername:<unsupported>, othername:<unsupported>, URI:http://uri1.subject.example.org/, URI:http://uri2.subject.example.org/

And, for good measure, showing that Windows localizes this:
Windows es-ES

Nombre DNS=dns1.subject.example.org
Nombre DNS=dns2.subject.example.org
Nombre RFC822=sanemail1@example.org
Nombre RFC822=sanemail2@example.org
Otro nombre:
     Nombre de entidad de seguridad=subjectupn1@example.org
Otro nombre:
     Nombre de entidad de seguridad=subjectupn2@example.org
Dirección URL=http://uri1.subject.example.org/
Dirección URL=http://uri2.subject.example.org/

Windows ja-JP:

DNS Name=dns1.subject.example.org
DNS Name=dns2.subject.example.org
RFC822 Name=sanemail1@example.org
RFC822 Name=sanemail2@example.org
Other Name:
     プリンシパル名=subjectupn1@example.org
Other Name:
     プリンシパル名=subjectupn2@example.org
URL=http://uri1.subject.example.org/
URL=http://uri2.subject.example.org/

[karelz]

Unknown complexity of implemenation

[atanasa]

Do you know of any workaround other than implementing a parser for the raw data? Is there a parser type in .Net standard that can be reused to parse the raw format (in the AsnEncodedData.RawData)? I assume you would add a new API for this, as the Format method's intention was probably to present it to a user instead of produce text to be parsed.

[bartonjs]

For the general case we do want to expose an ASN.1 BER/CER/DER reader. The current state of implementation exists at https://github.com/dotnet/corefx/blob/master/src/Common/src/System/Security/Cryptography/AsnReader.cs. It's not currently public API, but could be a useful start if you need to go this route. (This extension isn't too bad)

For SAN in particular we want to expose rich API, but that also isn't done yet (https://github.com/dotnet/corefx/issues/22068). The tradition of parsing the text can be found in places like WCF, which addressed the incompatibilities by doing a test at startup to determine what the platform delimiter is. https://github.com/dotnet/wcf/blob/a9984490334fdc7d7382cae3c7bc0c8783eacd16/src/System.Private.ServiceModel/src/System/IdentityModel/Claims/X509CertificateClaimSet.cs#L297 and https://github.com/dotnet/wcf/blob/a9984490334fdc7d7382cae3c7bc0c8783eacd16/src/System.Private.ServiceModel/src/System/IdentityModel/Claims/X509CertificateClaimSet.cs#L431, which may also be useful to your goals.

[filipnavara]

Is there any interest in pursuing this? I have already started the work as part of Mono PR, but I can port it to CoreFX if there is interest (mono/mono#9250).

[CarrieYang]

Thanks a lot for the fix, it works already in the latest powersell core.