This section defines the syntax and semantics of the encapsulated
header fields to be added to messages in the course of privacy
enhancement processing.
The fields are presented in three groups. Normally, the groups will
appear in encapsulated headers in the order in which they are shown,
though not all fields in each group will appear in all messages. The
following figures show the appearance of small example encapsulated
messages. Figure 2 assumes the use of symmetric cryptography for key
management. Figure 3 illustrates an example encapsulated ENCRYPTED
message in which asymmetric key management is used.
Figure 4 illustrates an example encapsulated MIC-ONLY message in
which asymmetric key management is used; since no per-recipient keys
are involved in preparation of asymmetric-case MIC-ONLY messages,
this example should be processable for test purposes by arbitrary PEM
implementations.
Fully-qualified domain names (FQDNs) for hosts, appearing in the
mailbox names found in entity identifier subfields of "Originator-
ID-Symmetric:" and "Recipient-ID-Symmetric:" fields, are processed in
a case-insensitive fashion. Unless specified to the contrary, other
field arguments (including the user name components of mailbox names)
are to be processed in a case-sensitive fashion.
In most cases, numeric quantities are represented in header fields as
contiguous strings of hexadecimal digits, where each digit is
represented by a character from the ranges "0"-"9" or upper case
"A"-"F". Since public-key certificates and quantities encrypted
using asymmetric algorithms are large in size, use of a more space-
efficient encoding technique is appropriate for such quantities, and
the encoding mechanism defined in Section 4.3.2.4 of this RFC,
representing 6 bits per printed character, is adopted for this
purpose.
Encapsulated headers of PEM messages are folded using whitespace per
RFC 822 header folding conventions; no PEM-specific conventions are
defined for encapsulated header folding. The example shown in Figure
4 shows (in its "MIC-Info:" field) an asymmetrically encrypted
quantity in its printably encoded representation, illustrating the
use of RFC 822 folding.
In contrast to the encapsulated header representations defined in RFC
1113 and its precursors, the field identifiers adopted in this RFC do
not begin with the prefix "X-" (for example, the field previously
denoted "X-Key-Info:" is now denoted "Key-Info:") and such prefixes
are not to be emitted by implementations conformant to this RFC. To
simplify transition and interoperability with earlier
implementations, it is suggested that implementations based on this
RFC accept incoming encapsulated header fields carrying the "X-"
prefix and act on such fields as if the "X-" were not present.
