PEM does not mandate DER for transmission, but encourages it.
In a previous message, Ray Lau found some citations in the RFCs which
suggest that DER is required. Following is an excerpt from his message.
- Jeff
However, from 1421, I don't think I have to worry about BER encodings:
For the asymmetric key management case, the IA identifier subfield
will be formed from the ASN.1 BER representation of the distinguished
name of the issuing organization or organizational unit. The
distinguished encoding rules specified in Clause 8.7 of
Recommendation X.509 ("X.509 DER") are to be employed in generating
this representation. The encoded binary result will be represented
for inclusion in a transmitted header using the procedure defined in
Section 4.3.2.4 of this RFC.
This suggests DER only for the Originator-ID-Asymmetric and
Recipient-ID-Asymmetric cases.
Of course, the *example* given mentions only BER in its caption but
I assume that was due to definition overloading. :-)
Similarly for Originator-Certificate:
The "Originator-Certificate:" encapsulated header field is used only
when asymmetric key management is employed for one or more of a
message's recipients. To facilitate processing by recipients (at
least in advance of general directory server availability), inclusion
of this field in all messages is strongly recommended. The field
transfers an originator's certificate as a numeric quantity,
comprised of the certificate's DER encoding, represented in the
header field with the encoding mechanism defined in Section 4.3.2.4
of this RFC. The semantics of a certificate are discussed in RFC
1422.
And for Issuer-Certificate:
The certificate is represented in the same manner as defined for the
"Originator-Certificate:" field (transporting an encoded
representation of the certificate in X.509 [7] DER form), and any
"Issuer-Certificate:" fields will ordinarily follow the "Originator-
Certificate:" field directly.