Privacy-Enhanced Mail (PEM) Privacy Enhancement for Internet Electronic Mail
小结
1、
加密基本流程
本地格式
标准格式
认证（填充与完整性检查）与加密
可打印编码
Privacy-Enhanced Mail (PEM)
RFC 2313 - PKCS #1: RSA Encryption Version 1.5 https://tools.ietf.org/html/rfc2313
This document describes a method for encrypting data using the RSA
public-key cryptosystem. Its intended use is in the construction of
digital signatures and digital envelopes, as described in PKCS #7:
o For digital signatures, the content to be signed
is first reduced to a message digest with a
message-digest algorithm (such as MD5), and then
an octet string containing the message digest is
encrypted with the RSA private key of the signer
of the content. The content and the encrypted
message digest are represented together according
to the syntax in PKCS #7 to yield a digital
signature. This application is compatible with
Privacy-Enhanced Mail (PEM) methods.
o For digital envelopes, the content to be enveloped
is first encrypted under a content-encryption key
with a content-encryption algorithm (such as DES),
and then the content-encryption key is encrypted
with the RSA public keys of the recipients of the
content. The encrypted content and the encrypted
Kaliski Informational [Page 1]
RFC 2313 PKCS #1: RSA Encryption March 1998 content-encryption key are represented together according to the syntax in PKCS #7 to yield a digital envelope. This application is also compatible with PEM methods.
RFC 1421 - Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures https://tools.ietf.org/html/rfc1421
4.1.1 Types of Keys
A two-level keying hierarchy is used to support PEM transmission:
1. Data Encrypting Keys (DEKs) are used for encryption of
message text and (with certain choices among a set of
alternative algorithms) for computation of message integrity
check (MIC) quantities. In the asymmetric key management
environment, DEKs are also used to encrypt the signed
representations of MICs in PEM messages to which
confidentiality has been applied. DEKs are generated
individually for each transmitted message; no
predistribution of DEKs is needed to support PEM
transmission.
2. Interchange Keys (IKs) are used to encrypt DEKs for
transmission within messages. Ordinarily, the same IK will
be used for all messages sent from a given originator to a
given recipient over a period of time. Each transmitted
message includes a representation of the DEK(s) used for
message encryption and/or MIC computation, encrypted under
an individual IK per named recipient. The representation is
Linn [Page 6]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993 associated with Originator-ID and Recipient-ID fields (defined in different forms so as to distinguish symmetric from asymmetric cases), which allow each individual recipient to identify the IK used to encrypt DEKs and/or MICs for that recipient's use. Given an appropriate IK, a recipient can decrypt the corresponding transmitted DEK representation, yielding the DEK required for message text decryption and/or MIC validation. The definition of an IK differs depending on whether symmetric or asymmetric cryptography is used for DEK encryption: 2a. When symmetric cryptography is used for DEK encryption, an IK is a single symmetric key shared between an originator and a recipient. In this case, the same IK is used to encrypt MICs as well as DEKs for transmission. Version/expiration information and IA identification associated with the originator and with the recipient must be concatenated in order to fully qualify a symmetric IK. 2b. When asymmetric cryptography is used, the IK component used for DEK encryption is the public component [8] of the recipient. The IK component used for MIC encryption is the private component of the originator, and therefore only one encrypted MIC representation need be included per message, rather than one per recipient. Each of these IK components can be fully qualified in a Recipient-ID or Originator-ID field, respectively. Alternatively, an originator's IK component may be determined from a certificate carried in an "Originator-Certificate:" field.
4.3 Privacy Enhancement Message Transformations
4.3.1 Constraints
An electronic mail encryption mechanism must be compatible with the
transparency constraints of its underlying electronic mail
facilities. These constraints are generally established based on
expected user requirements and on the characteristics of anticipated
endpoint and transport facilities. An encryption mechanism must also
be compatible with the local conventions of the computer systems
which it interconnects. Our approach uses a canonicalization step to
abstract out local conventions and a subsequent encoding step to
Linn [Page 10]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993 conform to the characteristics of the underlying mail transport medium (SMTP). The encoding conforms to SMTP constraints. Section 4.5 of RFC 821 [2] details SMTP's transparency constraints. To prepare a message for SMTP transmission, the following requirements must be met: 1. All characters must be members of the 7-bit ASCII character set. 2. Text lines, delimited by the character pair <CR><LF>, must be no more than 1000 characters long. 3. Since the string <CR><LF>.<CR><LF> indicates the end of a message, it must not occur in text prior to the end of a message. Although SMTP specifies a standard representation for line delimiters (ASCII <CR><LF>), numerous systems in the Internet use a different native representation to delimit lines. For example, the <CR><LF> sequences delimiting lines in mail inbound to UNIX systems are transformed to single <LF>s as mail is written into local mailbox files. Lines in mail incoming to record-oriented systems (such as VAX VMS) may be converted to appropriate records by the destination SMTP server [3]. As a result, if the encryption process generated <CR>s or <LF>s, those characters might not be accessible to a recipient UA program at a destination which uses different line delimiting conventions. It is also possible that conversion between tabs and spaces may be performed in the course of mapping between inter-SMTP and local format; this is a matter of local option. If such transformations changed the form of transmitted ciphertext, decryption would fail to regenerate the transmitted plaintext, and a transmitted MIC would fail to compare with that computed at the destination. The conversion performed by an SMTP server at a system with EBCDIC as a native character set has even more severe impact, since the conversion from EBCDIC into ASCII is an information-losing transformation. In principle, the transformation function mapping between inter-SMTP canonical ASCII message representation and local format could be moved from the SMTP server up to the UA, given a means to direct that the SMTP server should no longer perform that transformation. This approach has a major disadvantage: internal file (e.g., mailbox) formats would be incompatible with the native forms used on the systems where they reside. Further, it would require modification to SMTP servers, as mail would be passed to SMTP in a different representation than it is passed at present. Linn [Page 11]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
4.3.2 Approach
Our approach to supporting PEM across an environment in which
intermediate conversions may occur defines an encoding for mail which
is uniformly representable across the set of PEM UAs regardless of
their systems' native character sets. This encoded form is used (for
specified PEM message types) to represent mail text in transit from
originator to recipient, but the encoding is not applied to enclosing
MTS headers or to encapsulated headers inserted to carry control
information between PEM UAs. The encoding's characteristics are such
that the transformations anticipated between originator and recipient
UAs will not prevent an encoded message from being decoded properly
at its destination.
Four transformation steps, described in the following four
subsections, apply to outbound PEM message processing:
4.3.2.1 Step 1: Local Form
This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and
MIC-CLEAR. The message text is created in the system's native
character set, with lines delimited in accordance with local
convention.
4.3.2.2 Step 2: Canonical Form
This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and
MIC-CLEAR. The message text is converted to a universal canonical
form, similar to the inter-SMTP representation [4] as defined in RFC
821 [2] and RFC 822 [5]. The procedures performed in order to
accomplish this conversion are dependent on the characteristics of
the local form and so are not specified in this RFC.
PEM canonicalization assures that the message text is represented
with the ASCII character set and "<CR><LF>" line delimiters, but does
not perform the dot-stuffing transformation discussed in RFC 821,
Section 4.5.2. Since a message is converted to a standard character
set and representation before encryption, a transferred PEM message
can be decrypted and its MIC can be validated at any type of
destination host computer. Decryption and MIC validation is
performed before any conversions which may be necessary to transform
the message into a destination-specific local form.
4.3.2.3 Step 3: Authentication and Encryption
Authentication processing is applicable to PEM message types
ENCRYPTED, MIC-ONLY, and MIC-CLEAR. The canonical form is input to
the selected MIC computation algorithm in order to compute an
Linn [Page 12]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993 integrity check quantity for the message. No padding is added to the canonical form before submission to the MIC computation algorithm, although certain MIC algorithms will apply their own padding in the course of computing a MIC. Encryption processing is applicable only to PEM message type ENCRYPTED. RFC 1423 defines the padding technique used to support encryption of the canonically-encoded message text.
4.3.2.4 Step 4: Printable Encoding
This printable encoding step is applicable to PEM message types
ENCRYPTED and MIC-ONLY. The same processing is also employed in
representation of certain specifically identified PEM encapsulated
header field quantities as cited in Section 4.6. Proceeding from
left to right, the bit string resulting from step 3 is encoded into
characters which are universally representable at all sites, though
not necessarily with the same bit patterns (e.g., although the
character "E" is represented in an ASCII-based system as hexadecimal
45 and as hexadecimal C5 in an EBCDIC-based system, the local
significance of the two representations is equivalent).
A 64-character subset of International Alphabet IA5 is used, enabling
6 bits to be represented per printable character. (The proposed
subset of characters is represented identically in IA5 and ASCII.)
The character "=" signifies a special processing function used for
padding within the printable encoding procedure.
To represent the encapsulated text of a PEM message, the encoding
function's output is delimited into text lines (using local
conventions), with each line except the last containing exactly 64
printable characters and the final line containing 64 or fewer
printable characters. (This line length is easily printable and is
guaranteed to satisfy SMTP's 1000-character transmitted line length
limit.) This folding requirement does not apply when the encoding
procedure is used to represent PEM header field quantities; Section
4.6 discusses folding of PEM encapsulated header fields.
The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters. Proceeding from left to right across
a 24-bit input group extracted from the output of step 3, each 6-bit
group is used as an index into an array of 64 printable characters.
The character referenced by the index is placed in the output string.
These characters, identified in Table 1, are selected so as to be
universally representable, and the set excludes characters with
particular significance to SMTP (e.g., ".", "<CR>", "<LF>").
Linn [Page 13]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993 Special processing is performed if fewer than 24 bits are available in an input group at the end of a message. A full encoding quantum is always completed at the end of a message. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Output character positions which are not required to represent actual input data are set to the character "=". Since all canonically encoded output is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character. Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y Printable Encoding Characters Table 1
4.3.2.5 Summary of Transformations
In summary, the outbound message is subjected to the following
composition of transformations (or, for some PEM message types, a
subset thereof):
Transmit_Form = Encode(Encrypt(Canonicalize(Local_Form)))
Linn [Page 14]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993 The inverse transformations are performed, in reverse order, to process inbound PEM messages: Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form))) Note that the local form and the functions to transform messages to and from canonical form may vary between the originator and recipient systems without loss of information.
