On Tue, Jan 28, 2020 at 02:17:21AM +0000, Douglas Morris via openssl-users wrote:
> I expect from RFC 8555 that an ACME server issues a full chain
> certificate as a reply body in the PEM format. The media type is
> 'application/pem-certificate-chain'.
https://www.iana.org/assignments/media-types/application/pem-certificate-chain
Encoding considerations: 7bit
https://tools.ietf.org/html/rfc8555#section-9
A file of this type contains one or more certificates encoded with
the PEM textual encoding, according to [RFC7468]. The textual
encoding of certificates in this file MUST use the strict encoding
and MUST NOT include explanatory text. The ABNF for this format is
as follows, where "stricttextualmsg" and "eol" are as defined in
Section 3 of RFC 7468:
certchain = stricttextualmsg *(eol stricttextualmsg)
https://tools.ietf.org/html/rfc7468#section-3
eol = CRLF / CR / LF
> I can only guess from RFC 1421, sec. 4.3.1 that the byte encoding of
> the certificate necessarily uses <CR><LF> line breaks.
The canonical format of a MIME media type on the wire need not match its
local representation on disk. For example, HTTP transmits textual
content with CRLF line endings, but user agents generally store text
with using host platform's line endings.
> I get US-ASCII from encguess <file>.pem.
No need to guess, it is just the base64 (ASCII) payload beween
a simple ASCII preamble and postamble.
> Paging PEM files with less
> does NOT show ^M at the end of each or any line.
None are expected on a Unix system, and on Windows you'd need
to elect to view the content as a binary file.
> Are PEM files, e.g. the private key pair files and certificate files
> needed by Web servers, necessarily in US-ASCII?
See above, but note that "explanatory text" can contain data in some
unspecified local encoding, e.g. UTF-8.
https://tools.ietf.org/html/rfc7468#section-5.2
> Are PEM files typically/conventionally stored in the line break
> encoding of the native operating system?
Yes.
> Should PEM files always or normally be transmitted with the <CR><LF>
> line break encoding?
The spec seems to allow any of CRLF/LF/CR, but my guess is that
CRL is safest for the wire form.
--
Viktor.
