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

[David Woodhouse]

On Tue, 2016-11-22 at 15:26 -0500, Thomas Francis, Jr. wrote:
> On 11/22/16 2:37 PM, David Woodhouse wrote:
> > 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.

Ewww.

I have to confess that I'm mostly disinclined to care. I'll just go
back to your first sentence cited above, and "clarify" my original
statement to "the PEM that we *support* is ASCII".

But if people *really* expect it to work... would you seriously suggest
that this abomination (at least the EBCDIC and UTF-16+BOM variants) is
something that applications ought to support automatically? If so,
perhaps you'd be arguing that I should update my draft at
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html to
mandate support for it? I suppose checking for a BOM and eating UTF-16
really *isn't* that complicated for an application.

As things stand I suppose I should at least mention it, but I'm
inclined to say that applications MAY support these variants but are
not required to.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161123/4f5d63fe/attachment-0001.bin>