Consider doing PEM reads with unified code in the new certificate loader

[bartonjs]

The new certificate loader tests have shown some platform differences in corner cases when it comes to PEM-encoded contents.

• Windows will accept a final line of -----END CERTIFICATE-----text, but Linux/OpenSSL requires a newline between the 5th hyphen and subsequent text.
• Windows and OpenSSL both accept -----END CERTIFICATE-----\n<binary data>, but macOS does not.

Pros:

• Will reduce platform-specific behaviors.

Cons:

• Linux/OpenSSL "FromFile" operations use BIO_new_file to try both DER and PEM, unifying requires having the contents available for inspection in managed code; either after the DER load fails, or switching to a "memory only" interaction with OpenSSL and not doing file-based work at all.
• Windows "FromFile" may also need to move to a "memory only" interpretation, as -----END CERTIFICATE-----text is currently not permitted by our PemEncoding class.
  • Or we could observe that the ABNF doesn't require a newline at the end of the message, and change our implementation to permit what Windows does.
• Will require enhancing the PemEncoding class to work with ASCII/UTF-8.
• Will require carrying (or exporting) PemEncoding in Microsoft.Bcl.Cryptography for netfx/netstandard.

[dotnet-policy-service[bot]]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones See info in area-owners.md if you want to be subscribed.

[vcsjones]

I think the part that will help guide a decision here is how the behavior matches with GetCertContentType. In .NET, that's easy, we can just make GetCertContentType do whatever we want it to do.

In .NET Framework, we can't change that behavior. It would be weird for GetCertContentType to say "I don't know what that is" but the loader loads it anyway. Or the opposite, where GetCertContentType says "This is a X.509 certificate" and the loader says "I cannot load that".

With that in mind, I would want the answer to be "Do what Windows does". Some experimentation shows that Windows PEM reader just looks for PEM encapsulation boundaries regardless of surrounding data. That said, my proposal would be

1. Change PemEncoding to not require white space before the PreEB.
2. Change PemEncoding to not require white space after the PostEB.
   1. Since these are relaxing the reader, I don't think it is a breaking change.
3. We should add UTF-8 to PemEncoding (#99614) but I do not think it needs to be exposed in M.BCL.Cryptography. It can carry an internal non-public version.
   1. Making this somewhat complicated is the fact that PemEncoding now leans on the Base64 class to do all of the Base64 reading and validation. The version used in M.B.C will need to be an older version of PemEncoding that carries its own Base64 validation.
4. I don't think we need to consider UTF8 PemEncoding blocking for API review purposes. If we can make it public in time, great. But since the consumer of it is ourselves, and M.B.C will need a copy regardless, it can stay internal until we have it through API review.
5. Fixup other platforms to agree with Windows.