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
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
