On 11/22/16 2:37 PM, David Woodhouse wrote:
On Tue, 2016-11-22 at 18:29 +0000, Salz, Rich wrote:
<snip>
And the locale / character set issue is not relevant here. ASN.1 is binary, PEM is ASCII.
PEM should be ASCII; in practice it is not necessarily ASCII. There are several products that produce "PEM files" in various EBCDIC character sets. Other products produce them in ASCII, but then transfer them with an EBCDIC to ASCII conversion. And in still others, it's the customer who transfers it manually, converting from EBCDIC to ASCII when the file was ASCII. These latter two are less common in my limited experience, which is fortunate, because recovering from that is very difficult.
I've also seen some windows products that will produce "unicode" pem files, which may or may not have a BOM at the beginning, and other products which produce the files with the UTF-8 BOM at the beginning, too.
While it's easy for me to say these files are malformed, the customer doesn't care. They have the file; they expect it to work.
In most of those cases, the user will open the file, and see exactly what they expect, a PEM header, followed by what looks like base64 encoded data, and a matching footer. It's very difficult to convince a customer the file is incorrect in the face of that. Even if you get them to acknowledge the file isn't in the expected format, again they don't care. They have the file, usually from some very expensive software or process, your much less important software had better use it (yup, I've had those conversations with customers, fortunately with tech support filtering my side of the conversation :) ).
In any event, I don't think it's OpenSSL's job to detect and fix these kinds of issues. Although probably 90% of them could be fixed with a simple EBCDIC->ASCII converter, ignoring BOMs and recognizing the Windows "unicode" format. :)
TOM -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
