RFC1421 says: ... Two encapsulation boundaries (EB's) are defined for delimiting encapsulated PEM messages and for distinguishing encapsulated PEM
You can't read that alone; read the previous paragraph which references RFC 934; the boundaries are line-based.
Indeed, it is true. By the way BNF says it more clear than this paragraph:
=== 9. Descriptive Grammar === <preeb> ::= "-----BEGIN PRIVACY-ENHANCED MESSAGE-----" CRLF <posteb> ::= "-----END PRIVACY-ENHANCED MESSAGE-----" CRLF / <preeb> === cut ===
Which, by the way, has an additional property of supporting my original point: even on Unix, if you open a file with CRLF line termination in a text mode, you'll end up with "\r\n", but not "\n", which is [wrongly] expected by the parser (the code I've cited).
btw, this might also be of interest:
=== 4.6.1.1.3 A case of particular relevance arises for inbound SMTP processing on systems which delimit text lines with local native representations other than the SMTP-conventional <CR><LF>. When mail is delivered to a UA on such a system and presented for PEM processing, the <CR><LF> has already been translated to local form. In order to validate a MIC-CLEAR message's MIC in this situation, the PEM module must recanonicalize the incoming message in order to determine the inter- SMTP representation of the canonically encoded message (as defined in Section 4.3.2.2 of this RFC), and must compute the reference MIC based on that representation. ===
Generally, it says that PEM processor must recanonizalize the input data before processing. In Unix, make "\n" -> "\r\n" map, and process the message only after that. I am not advocating for that, as it is obviously superfluous, but it may be understood just as the PEM parsing must be prepared to accept both <CR>, <CR><LF> and <LF> forms.
As for \r\n vs \n, OpenSSL follows the ANSI/ISO C standard which makes \n be the line-ending character. Under Windows/DOS, etc., make sure to open your files in text (not binary) mode.
/r$
-- Lev Walkin [EMAIL PROTECTED]
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
