[openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Thomas Francis, Jr.]

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