draft-ietf-pem-algorithms-01.txt   rfc1423.txt 
Network Working Group David Balenson (TIS) Network Working Group D. Balenson
INTERNET DRAFT IAB IRTF PSRG, IETF PEM WG Request for Comments: 1423 TIS
3 September 1992 Obsoletes: 1115 IAB IRTF PSRG, IETF PEM WG
February 1993
Privacy Enhancement for Internet Electronic Mail: Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, and Identifiers Part III: Algorithms, Modes, and Identifiers
Status of This Memo Status of This Memo
This document is an Internet Draft. Internet Drafts are working This RFC specifies an IAB standards track protocol for the Internet
documents of the Internet Engineering Task Force (IETF), its Areas, community, and requests discussion and suggestions for improvements.
and its Working Groups. Note that other groups may also distribute Please refer to the current edition of the "IAB Official Protocol
working documents as Internet Drafts. Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the Internet Drafts abstract listing contained in each
Internet Drafts directory to learn the current status of this or any
other Internet Draft.
This document will be submitted to the RFC editor as a proposed
standard document, and will be submitted as a successor to current
RFC 1115. References within the text of this Internet Draft to this
document as an RFC, or to other related Internet Drafts cited as
RFCs, are not intended to carry any connotation about the progression
of these Internet Drafts through the IAB standards-track review
cycle. Distribution of this draft is unlimited. Comments should be
sent to the PEM Developer's mailing list <pem-dev@tis.com>.
Abstract Abstract
This document provides definitions, formats, references, and This document provides definitions, formats, references, and
citations for cryptographic algorithms, usage modes, and associated citations for cryptographic algorithms, usage modes, and associated
identifiers and parameters used in support of Privacy Enhanced Mail identifiers and parameters used in support of Privacy Enhanced Mail
(PEM) in the Internet community. It is intended to become one member (PEM) in the Internet community. It is intended to become one member
of the set of related PEM RFCs. This document is organized into four of the set of related PEM RFCs. This document is organized into four
primary sections, dealing with message encryption algorithms, message primary sections, dealing with message encryption algorithms, message
integrity check algorithms, symmetric key management algorithms, and integrity check algorithms, symmetric key management algorithms, and
asymmetric key management algorithms (including both asymmetric asymmetric key management algorithms (including both asymmetric
encryption and asymmetric signature algorithms). encryption and asymmetric signature algorithms).
Some parts of this material are cited by other documents and it is Some parts of this material are cited by other documents and it is
anticipated that some of the material herein may be changed, added, anticipated that some of the material herein may be changed, added,
or replaced without affecting the citing documents. Therefore, or replaced without affecting the citing documents. Therefore,
algorithm-specific material has been placed into this separate algorithm-specific material has been placed into this separate
document. Use of other algorithms and/or modes will require case- document.
by-case study to determine applicability and constraints. Additional
algorithms and modes approved for use in PEM in this context will be
specified in successors to this document.
Acknowledgment Use of other algorithms and/or modes will require case-by-case study
to determine applicability and constraints. The use of additional
algorithms may be documented first in Prototype or Experimental RFCs.
As experience is gained, these protocols may be considered for
incorporation into the standard. Additional algorithms and modes
approved for use in PEM in this context will be specified in
successors to this document.
Acknowledgments
This specification was initially developed by the Internet Research This specification was initially developed by the Internet Research
Task Force's Privacy and Security Research Group (IRTF PSRG) and Task Force's Privacy and Security Research Group (IRTF PSRG) and
subsequently refined based on discussion in the Internet Engineering subsequently refined based on discussion in the Internet Engineering
Task Force's Privacy Enhanced Mail Working Group (IETF PEM WG). John Task Force's Privacy Enhanced Mail Working Group (IETF PEM WG). John
Linn contributed significantly to the predecessor of this document Linn contributed significantly to the predecessor of this document
(RFC 1115). I would like to thank the members of the PSRG and PEM (RFC 1115). I would like to thank the members of the PSRG and PEM
WG, as well as all participants in discussions on the "pem- WG, as well as all participants in discussions on the "pem-
dev@tis.com" mailing list, for their contributions to this document. dev@tis.com" mailing list, for their contributions to this document.
Table of Contents Table of Contents
1. Message Encryption Algorithms ....................... 3 1. Message Encryption Algorithms ....................... 2
1.1 DES in CBC Mode (DES-CBC) .......................... 3 1.1 DES in CBC Mode (DES-CBC) .......................... 2
2. Message Integrity Check Algorithms .................. 4
2. Message Integrity Check Algorithms .................. 4 2.1 RSA-MD2 Message Digest Algorithm ................... 4
2.1 Message Authentication Code (MAC) .................. 5 2.2 RSA-MD5 Message Digest Algorithm ................... 5
2.2 RSA-MD2 Message Digest Algorithm ................... 6 3. Symmetric Key Management Algorithms ................. 6
2.3 RSA-MD5 Message Digest Algorithm ................... 7 3.1 DES in ECB mode (DES-ECB) .......................... 6
3.2 DES in EDE mode (DES-EDE) .......................... 7
3. Symmetric Key Management Algorithms ................. 8 4. Asymmetric Key Management Algorithms ................ 7
3.1 DES in ECB mode (DES-ECB) .......................... 9 4.1 Asymmetric Keys .................................... 7
3.2 DES in EDE mode (DES-EDE) .......................... 9 4.1.1 RSA Keys ......................................... 7
4.2 Asymmetric Encryption Algorithms .................. 9
4. Asymmetric Key Management Algorithms ................ 9 4.2.1 RSAEncryption ................................... 9
4.1 Asymmetric Keys .................................... 9 4.3 Asymmetric Signature Algorithms ................... 10
4.1.1 RSA Keys ........................................ 10 4.3.1 md2WithRSAEncryption ............................ 11
4.2 Asymmetric Encryption Algorithms .................. 11 5. Descriptive Grammar ................................ 11
4.2.1 RSAEncryption ................................... 11 References ............................................. 12
4.3 Asymmetric Signature Algorithms ................... 13 Patent Statement ....................................... 13
4.3.1 md2WithRSAEncryption ............................ 13 Security Considerations ................................ 14
Author's Address ....................................... 14
5. Descriptive Grammar ................................ 14
References ............................................. 15
1 Message Encryption Algorithms 1. Message Encryption Algorithms
This section identifies the alternative message encryption algorithms This section identifies the alternative message encryption algorithms
and modes that shall be used to encrypt message text and, when and modes that shall be used to encrypt message text and, when
asymmetric key management is employed in an ENCRYPTED PEM message, asymmetric key management is employed in an ENCRYPTED PEM message, for
for encryption of message signatures. Character string identifiers encryption of message signatures. Character string identifiers are
are assigned and any parameters required by the message encryption assigned and any parameters required by the message encryption
algorithm are defined for incorporation in an encapsulated "DEK- algorithm are defined for incorporation in an encapsulated "DEK-
Info:" header field. Info:" header field.
Only one alternative is currently defined in this category. Only one alternative is currently defined in this category.
1.1 DES in CBC Mode (DES-CBC) 1.1 DES in CBC Mode (DES-CBC)
Message text and, if required, message signatures are encrypted using Message text and, if required, message signatures are encrypted using
the Data Encryption Standard (DES) algorithm in the Cipher Block the Data Encryption Standard (DES) algorithm in the Cipher Block
Chaining (CBC) mode of operation. The DES algorithm is defined in Chaining (CBC) mode of operation. The DES algorithm is defined in
skipping to change at page 3, line 41 skipping to change at page 3, line 21
in octets of the input. Pad the input by appending 8-(n mod 8) in octets of the input. Pad the input by appending 8-(n mod 8)
octets to the end of the message, each having the value 8-(n mod 8), octets to the end of the message, each having the value 8-(n mod 8),
the number of octets being added. In hexadecimal, the possible the number of octets being added. In hexadecimal, the possible
paddings are: 01, 0202, 030303, 04040404, 0505050505, 060606060606, paddings are: 01, 0202, 030303, 04040404, 0505050505, 060606060606,
07070707070707, and 0808080808080808. All input is padded with 1 to 07070707070707, and 0808080808080808. All input is padded with 1 to
8 octets to produce a multiple of 8 octets in length. The padding 8 octets to produce a multiple of 8 octets in length. The padding
can be removed unambiguously after decryption. can be removed unambiguously after decryption.
The DES CBC encryption process requires a 64-bit cryptographic key. The DES CBC encryption process requires a 64-bit cryptographic key.
A new, pseudorandom key shall be generated for each ENCRYPTED PEM A new, pseudorandom key shall be generated for each ENCRYPTED PEM
message or for each MIC-CLEAR or MIC-ONLY message which employs a MIC message. Of the 64 bits, 56 are used directly by the DES CBC
algorithm that requires a cryptographic key (e.g., MAC). Of the 64 process, and 8 are odd parity bits, with one parity bit occupying the
bits, 56 are used directly by the DES CBC process, and 8 are odd right-most bit of each octet. When symmetric key management is
parity bits, with one parity bit occupying the right-most bit of each employed, the setting and checking of odd parity bits is encouraged,
octet. When symmetric key management is employed, the setting and since these bits could detect an error in the decryption of a DES key
checking of odd parity bits is encouraged, since these bits could encrypted under a symmetric key management algorithm (e.g., DES ECB).
detect an error in the decryption of a DES key encrypted under a When asymmetric key management is employed, the setting of odd parity
symmetric key management algorithm (e.g., DES ECB). When asymmetric bits is encouraged, but the checking of odd parity bits is
key management is employed, the setting of odd parity bits is discouraged, in order to facilitate interoperability, and since an
encouraged, but the checking of odd parity bits is discouraged, in error in the decryption of a DES key can be detected by other means
order to facilitate interoperability, and since an error in the (e.g., an incorrect PKCS #1 encryption-block format). In all cases,
decryption of a DES key can be detected by other means (e.g., an the encrypted form of a DES key shall carry all 64 bits of the key,
incorrect PKCS #1 encryption-block format). In all cases, the
encrypted form of a DES key shall carry all 64 bits of the key,
including the 8 parity bits, though those bits may have no meaning. including the 8 parity bits, though those bits may have no meaning.
The DES CBC encryption process also requires a 64-bit Initialization The DES CBC encryption process also requires a 64-bit Initialization
Vector (IV). A new, pseudorandom IV shall be generated for each Vector (IV). A new, pseudorandom IV shall be generated for each
ENCRYPTED PEM message. Section 4.3.1 of [7] provides rationale for ENCRYPTED PEM message. Section 4.3.1 of [7] provides rationale for
this requirement, even given the fact that individual DES keys are this requirement, even given the fact that individual DES keys are
generated for individual messages. The IV is transmitted with the generated for individual messages. The IV is transmitted with the
message within an encapsulated PEM header field. message within an encapsulated PEM header field.
When this algorithm/mode combination is used for message text When this algorithm/mode combination is used for message text
skipping to change at page 4, line 32 skipping to change at page 4, line 11
When symmetric key management is employed with this algorithm/mode When symmetric key management is employed with this algorithm/mode
combination, a symmetrically encrypted DES key will be represented in combination, a symmetrically encrypted DES key will be represented in
the third argument of a "Key-Info:" header field as a contiguous the third argument of a "Key-Info:" header field as a contiguous
string of 16 ASCII hexadecimal digits (corresponding to a 64-bit string of 16 ASCII hexadecimal digits (corresponding to a 64-bit
key). key).
To avoid any potential ambiguity regarding the ordering of the octets To avoid any potential ambiguity regarding the ordering of the octets
of a DES key that is input as a data value to another encryption of a DES key that is input as a data value to another encryption
process (e.g., RSAEncryption), the following holds true. The first process (e.g., RSAEncryption), the following holds true. The first
(or left-most displayed, if one thinks in terms of a key's "print" (or left-most displayed, if one thinks in terms of a key's "print"
representation (1)) octet of the key (i.e., bits 1-8 per FIPS PUB representation) (For purposes of discussion in this document, data
46-1), when considered as a data value, has numerical weight 2**56. values are normalized in terms of their "print" representation. For a
The last (or right-most displayed) octet (i.e., bits 57-64 per FIPS octet stream, the "first" octet would appear as the one on the "left",
PUB 46-1) has numerical weight 2**0. and the "last" octet would appear on the "right".) octet of the key
(i.e., bits 1-8 per FIPS PUB 46-1), when considered as a data value,
has numerical weight 2**56. The last (or right-most displayed) octet
(i.e., bits 57-64 per FIPS PUB 46-1) has numerical weight 2**0.
2 Message Integrity Check Algorithms 2. Message Integrity Check Algorithms
This section identifies the alternative algorithms that shall be used This section identifies the alternative algorithms that shall be used
to compute Message Integrity Check (MIC) values for PEM messages. to compute Message Integrity Check (MIC) values for PEM messages.
Character string identifiers and ASN.1 object identifiers are Character string identifiers and ASN.1 object identifiers are
assigned for incorporation in encapsulated "MIC-Info:" and "Key- assigned for incorporation in encapsulated "MIC-Info:" and "Key-
Info:" header fields to indicate the choice of MIC algorithm Info:" header fields to indicate the choice of MIC algorithm
employed. employed.
_______________
(1) For purposes of discussion in this document, data values are
normalized in terms of their "print" representation. For a octet
stream, the "first" octet would appear as the one on the "left",
and the "last" octet would appear on the "right".
A compliant PEM implementation shall be able to process all of the A compliant PEM implementation shall be able to process all of the
alternative MIC algorithms defined here on incoming messages. It is alternative MIC algorithms defined here on incoming messages. It is
a sender option as to which alternative is employed on an outbound a sender option as to which alternative is employed on an outbound
message. message.
2.1 Message Authentication Code (MAC) 2.1 RSA-MD2 Message Digest Algorithm
A message authentication code (MAC) is computed using DES in the CBC
mode of operation (with an IV of all zeros) in the manner defined in
Appendix F of FIPS PUB 81 [3] and in FIPS PUB 113 [9]. The MAC is
taken as all 8 octets (i.e., 64 bits) of the final output block (On,
read "O-sub-n", as denoted in FIPS PUB 113). The character string
"MAC" within an encapsulated PEM header field indicates the use of
this algorithm. Also, as defined in NIST Special Publication 500-183
[10], the ASN.1 object identifier
desMAC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 10
}
identifies this algorithm. A single parameter, the length of the MAC
in bits, is defined for the MAC algorithm, hence, when this object
identifier is used with the ASN.1 type AlgorithmIdentifier, the
parameters component of that type is the length of the MAC, in the
case of PEM, 64 bits, ASN.1 encoded as an INTEGER.
The MAC algorithm accepts as input a message of any length. The
input is padded at the end, per FIPS PUB 113, with zero-valued octets
as needed in order to form an integral number of 8-octet encryption
quanta. These padding octets are inserted implicitly and are not
transmitted with a message.
The MAC algorithm requires a 64-bit cryptographic key. For purposes
of PEM, this key is derived as a variant of the DEK used for message
text encryption (see [14] for the rationale behind this requirement).
The variant shall be formed by exclusive-OR'ing the 8-octet
hexadecimal quantity F0F0F0F0F0F0F0F0 to the 64-bit message DEK.
Note that when the MAC algorithm is used in a non-ENCRYPTED PEM
message (e.g., a MIC-CLEAR or MIC-ONLY PEM message), it is necessary
to generate and transmit a message DEK from which the MAC key can be
derived.
When symmetric key management is employed with this MIC algorithm,
the symmetrically encrypted MAC is represented in a "Key-Info:"
header field as a contiguous string of 16 ASCII hexadecimal digits
(corresponding to a 64-bit MAC).
To avoid any potential ambiguity regarding the ordering of the octets
of a MAC that is input as a data value to another encryption process
(e.g., RSAEncryption), the following holds true. The first (or
left-most displayed, if one thinks in terms of a MAC's "print"
representation) octet of the MAC, when considered as an RSA data
value, has numerical weight 2**56. The last (or right-most
displayed) octet has numerical weight 2**0.
Use of MAC is strongly discouraged for messages sent to more than a
single recipient. Also, use of MAC does not provide non-repudiation
of origin, even when asymmetric key management is employed. The
reason for these statements is that the use of MAC fails to prevent
recipients of a message from tampering with the message in a manner
which preserves the message's appearance as an authentic message from
the original sender. In other words, use of MAC on mail provides
source authentication at the granularity of membership in the
message's authorized address list (plus the sender) rather than at a
finer (and more desirable) granularity authenticating only the
individual sender.
2.2 RSA-MD2 Message Digest Algorithm
The RSA-MD2 message digest is computed using the algorithm defined in The RSA-MD2 message digest is computed using the algorithm defined in
RFC 1319 [11] (2). The character string "RSA-MD2" within an RFC 1319 [9]. ( An error has been identified in RFC 1319. The
encapsulated PEM header field indicates the use of this algorithm. statement in the text of Section 3.2 which reads "Set C[j] to S[c xor
Also, as defined in RFC 1319, the ASN.1 object identifier L]" should read "Set C[j] to S[c xor L] xor C[j]". Note that the C
source code in the appendix of RFC 1319 is correct.) The character
string "RSA-MD2" within an encapsulated PEM header field indicates the
use of this algorithm. Also, as defined in RFC 1319, the ASN.1 object
identifier
md2 OBJECT IDENTIFIER ::= { md2 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) iso(1) member-body(2) US(840) rsadsi(113549)
digestAlgorithm(2) 2 digestAlgorithm(2) 2
} }
identifies this algorithm. When this object identifier is used with identifies this algorithm. When this object identifier is used with
the ASN.1 type AlgorithmIdentifier, the parameters component of that the ASN.1 type AlgorithmIdentifier, the parameters component of that
type is the ASN.1 type NULL. type is the ASN.1 type NULL.
The RSA-MD2 message digest algorithm accepts as input a message of The RSA-MD2 message digest algorithm accepts as input a message of
any length and produces as output a 16-octet quantity. When any length and produces as output a 16-octet quantity. When
symmetric key management is employed, an RSA-MD2 MIC is encrypted by symmetric key management is employed, an RSA-MD2 MIC is encrypted by
splitting the MIC into two 8-octet halves, independently encrypting splitting the MIC into two 8-octet halves, independently encrypting
each half, and concatenating the results. each half, and concatenating the results.
_______________
(2) An error has been identified in RFC 1319. The statement in
the text of Section 3.2 which reads "Set C[j] to S[c xor L]"
should read "Set C[j] to S[c xor L] xor C[j]". Note that the C
source code in the appendix of RFC 1319 is correct.
When symmetric key management is employed with this MIC algorithm, When symmetric key management is employed with this MIC algorithm,
the symmetrically encrypted MD2 message digest is represented in a the symmetrically encrypted MD2 message digest is represented in a
the fourth argument of a "Key-Info:" header field as a contiguous the fourth argument of a "Key-Info:" header field as a contiguous
string of 32 ASCII hexadecimal digits (corresponding to a 128-bit MD2 string of 32 ASCII hexadecimal digits (corresponding to a 128-bit MD2
message digest). message digest).
To avoid any potential ambiguity regarding the ordering of the octets To avoid any potential ambiguity regarding the ordering of the octets
of an MD2 message digest that is input as a data value to another of an MD2 message digest that is input as a data value to another
encryption process (e.g., RSAEncryption), the following holds true. encryption process (e.g., RSAEncryption), the following holds true.
The first (or left-most displayed, if one thinks in terms of a The first (or left-most displayed, if one thinks in terms of a
digest's "print" representation) octet of the digest (i.e., digest[0] digest's "print" representation) octet of the digest (i.e., digest[0]
as specified in RFC 1319), when considered as an RSA data value, has as specified in RFC 1319), when considered as an RSA data value, has
numerical weight 2**120. The last (or right-most displayed) octet numerical weight 2**120. The last (or right-most displayed) octet
(i.e., digest[15] as specified in RFC 1319) has numerical weight (i.e., digest[15] as specified in RFC 1319) has numerical weight
2**0. 2**0.
This algorithm may be used as a MIC algorithm whenever a message is 2.2 RSA-MD5 Message Digest Algorithm
addressed to multiple recipients as well as to a single recipient.
The use of this algorithm in conjunction with asymmetric key
management does provide for non-repudiation of origin.
2.3 RSA-MD5 Message Digest Algorithm
The RSA-MD5 message digest is computed using the algorithm defined in The RSA-MD5 message digest is computed using the algorithm defined in
RFC 1321 [12]. The character string "RSA-MD5" within an encapsulated RFC 1321 [10]. The character string "RSA-MD5" within an encapsulated
PEM header field indicates the use of this algorithm. Also, as PEM header field indicates the use of this algorithm. Also, as
defined in RFC 1321, the object identifier defined in RFC 1321, the object identifier
md5 OBJECT IDENTIFIER ::= { md5 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) iso(1) member-body(2) US(840) rsadsi(113549)
digestAlgorithm(2) 5 digestAlgorithm(2) 5
} }
identifies this algorithm. When this object identifier is used with identifies this algorithm. When this object identifier is used with
the ASN.1 type AlgorithmIdentifier, the parameters component of that the ASN.1 type AlgorithmIdentifier, the parameters component of that
skipping to change at page 8, line 15 skipping to change at page 6, line 16
To avoid any potential ambiguity regarding the ordering of the octets To avoid any potential ambiguity regarding the ordering of the octets
of a MD5 message digest that is input as an RSA data value to the RSA of a MD5 message digest that is input as an RSA data value to the RSA
encryption process, the following holds true. The first (or left- encryption process, the following holds true. The first (or left-
most displayed, if one thinks in terms of a digest's "print" most displayed, if one thinks in terms of a digest's "print"
representation) octet of the digest (i.e., the low-order octet of A representation) octet of the digest (i.e., the low-order octet of A
as specified in RFC 1321), when considered as an RSA data value, has as specified in RFC 1321), when considered as an RSA data value, has
numerical weight 2**120. The last (or right-most displayed) octet numerical weight 2**120. The last (or right-most displayed) octet
(i.e., the high-order octet of D as specified in RFC 1321) has (i.e., the high-order octet of D as specified in RFC 1321) has
numerical weight 2**0. numerical weight 2**0.
This algorithm may be used as a MIC algorithm whenever a message is 3. Symmetric Key Management Algorithms
addressed to multiple recipients as well as to a single recipient.
The use of this algorithm in conjunction with asymmetric key
management does provide for non-repudiation of origin.
3 Symmetric Key Management Algorithms
This section identifies the alternative algorithms and modes that This section identifies the alternative algorithms and modes that
shall be used when symmetric key management is employed, to encrypt shall be used when symmetric key management is employed, to encrypt
data encryption keys (DEKs) and message integrity check (MIC) values. data encryption keys (DEKs) and message integrity check (MIC) values.
Character string identifiers are assigned for incorporation in Character string identifiers are assigned for incorporation in
encapsulated "Key-Info:" header fields to indicate the choice of encapsulated "Key-Info:" header fields to indicate the choice of
algorithm employed. algorithm employed.
All alternatives presently defined in this category correspond to All alternatives presently defined in this category correspond to
different usage modes of the DES algorithm, rather than to other different usage modes of the DES algorithm, rather than to other
skipping to change at page 9, line 27 skipping to change at page 7, line 17
The DES algorithm in Encrypt-Decrypt-Encrypt (EDE) multiple The DES algorithm in Encrypt-Decrypt-Encrypt (EDE) multiple
encryption mode, as defined by ANSI X9.17 [6] for encryption and encryption mode, as defined by ANSI X9.17 [6] for encryption and
decryption with pairs of 64-bit keys, may be used for DEK and MIC decryption with pairs of 64-bit keys, may be used for DEK and MIC
encryption when symmetric key management is employed. The character encryption when symmetric key management is employed. The character
string "DES-EDE" within an encapsulated a PEM header field indicates string "DES-EDE" within an encapsulated a PEM header field indicates
use of this algorithm/mode combination. use of this algorithm/mode combination.
A compliant PEM implementation supporting symmetric key management A compliant PEM implementation supporting symmetric key management
may optionally support this algorithm/mode combination. may optionally support this algorithm/mode combination.
4 Asymmetric Key Management Algorithms 4. Asymmetric Key Management Algorithms
This section identifies the alternative asymmetric keys and the This section identifies the alternative asymmetric keys and the
alternative asymmetric key management algorithms with which those alternative asymmetric key management algorithms with which those
keys shall be used, namely the asymmetric encryption algorithms with keys shall be used, namely the asymmetric encryption algorithms with
which DEKs and MICs are encrypted, and the asymmetric signature which DEKs and MICs are encrypted, and the asymmetric signature
algorithms with which certificates and certificate revocation lists algorithms with which certificates and certificate revocation lists
(CRLs) are signed. (CRLs) are signed.
4.1 Asymmetric Keys 4.1 Asymmetric Keys
skipping to change at page 10, line 27 skipping to change at page 8, line 8
multiplications are required to effect exponentiation. As an multiplications are required to effect exponentiation. As an
alternative, the number three (3) can be employed as the value for e, alternative, the number three (3) can be employed as the value for e,
requiring even less octets for transmission and yielding even faster requiring even less octets for transmission and yielding even faster
exponentiation. For purposes of PEM, the value of e shall be either exponentiation. For purposes of PEM, the value of e shall be either
F4 or the number three (3). The use of the number three (3) for the F4 or the number three (3). The use of the number three (3) for the
value of e is encouraged, to permit rapid certificate validation. value of e is encouraged, to permit rapid certificate validation.
An RSA private key consists of a decryption exponent d, which should An RSA private key consists of a decryption exponent d, which should
be kept secret, and the arithmetic modulus n. Other values may be be kept secret, and the arithmetic modulus n. Other values may be
stored with a private key to facilitate efficient private key stored with a private key to facilitate efficient private key
operations (see PKCS #1 [13]). operations (see PKCS #1 [11]).
For purposes of PEM, the modulus n may vary in size from 508 to 1024 For purposes of PEM, the modulus n may vary in size from 508 to 1024
bits. bits.
Two ASN.1 object identifiers have been defined to identify RSA public Two ASN.1 object identifiers have been defined to identify RSA public
keys. In Annex H of X.509 [8], the object identifier keys. In Annex H of X.509 [8], the object identifier
rsa OBJECT IDENTIFIER ::= { rsa OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) algorithm(8) joint-iso-ccitt(2) ds(5) algorithm(8)
encryptionAlgorithm(1) 1 encryptionAlgorithm(1) 1
} }
is defined to identify an RSA public key. A single parameter, is defined to identify an RSA public key. A single parameter,
KeySize, the length of the public key modulus in bits, is defined for KeySize, the length of the public key modulus in bits, is defined for
use in conjunction with this object identifier. When this object use in conjunction with this object identifier. When this object
identifier is used with the ASN.1 type AlgorithmIdentifier, the identifier is used with the ASN.1 type AlgorithmIdentifier, the
parameters component of that type is the number of bits in the parameters component of that type is the number of bits in the
modulus, ASN.1 encoded as an INTEGER. modulus, ASN.1 encoded as an INTEGER.
Alternatively, in PKCS #1 [13], the ASN.1 object identifier Alternatively, in PKCS #1 [11], the ASN.1 object identifier
rsaEncryption OBJECT IDENTIFIER ::= { rsaEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 1 pkcs-1(1) 1
} }
is defined to identify both an RSA public key and the RSAEncryption is defined to identify both an RSA public key and the RSAEncryption
process. There are no parameters defined in conjunction with this process. There are no parameters defined in conjunction with this
object identifier, hence, when it is used with the ASN.1 type object identifier, hence, when it is used with the ASN.1 type
AlgorithmIdentifier, the parameters component of that type is the AlgorithmIdentifier, the parameters component of that type is the
ASN.1 type NULL. ASN.1 type NULL.
A compliant PEM implementation may optionally generate an RSA A compliant PEM implementation may optionally generate an RSA
public-key certificate that identifies the enclosed RSA public key public-key certificate that identifies the enclosed RSA public key
(within the SubjectPublicKeyInformation component) with either the (within the SubjectPublicKeyInformation component) with either the
"rsa" or the "rsaEncryption" object identifier. Use of the "rsa" "rsa" or the "rsaEncryption" object identifier. Use of the "rsa"
object identifier is encouraged, since it is, in some sense, more object identifier is encouraged, since it is, in some sense, more
generic in its identification of a key, without indicating how the generic in its identification of a key, without indicating how the
key will be used. However, to facilitate interoperability, a key will be used. However, to facilitate interoperability, a
compliant PEM implementation shall accept RSA public-key compliant PEM implementation shall accept RSA public-key certificates
certificates that identify the enclosed RSA public key with either that identify the enclosed RSA public key with either the "rsa" or
the "rsa" or the "rsaEncryption" object identifier. In all cases, the "rsaEncryption" object identifier. In all cases, an RSA public
an RSA public key identified in an RSA public-key certificate with key identified in an RSA public-key certificate with either the "rsa"
either the "rsa" or "rsaEncryption" object identifier, shall be used or "rsaEncryption" object identifier, shall be used according to the
according to the procedures defined below for asymmetric encryption procedures defined below for asymmetric encryption algorithms and
algorithms and asymmetric signature algorithms. asymmetric signature algorithms.
4.2 Asymmetric Encryption Algorithms 4.2 Asymmetric Encryption Algorithms
This section identifies the alternative algorithms that shall be used This section identifies the alternative algorithms that shall be used
when asymmetric key management is employed, to encrypt DEKs and MICs. when asymmetric key management is employed, to encrypt DEKs and MICs.
Character string identifiers are assigned for incorporation in "MIC- Character string identifiers are assigned for incorporation in "MIC-
Info:" and "Key-Info:" header fields to indicate the choice of Info:" and "Key-Info:" header fields to indicate the choice of
algorithm employed. algorithm employed.
Only one alternative is presently defined in this category. Only one alternative is presently defined in this category.
4.2.1 RSAEncryption 4.2.1 RSAEncryption
The RSAEncryption public-key encryption algorithm, defined in PKCS #1 The RSAEncryption public-key encryption algorithm, defined in PKCS #1
[13], is used for DEK and MIC encryption when asymmetric key [11], is used for DEK and MIC encryption when asymmetric key
management is employed. The character string "RSA" within a "MIC- management is employed. The character string "RSA" within a "MIC-
Info:" or "Key-Info:" header field indicates the use of this Info:" or "Key-Info:" header field indicates the use of this
algorithm. algorithm.
All PEM implementations supporting asymmetric key management shall All PEM implementations supporting asymmetric key management shall
support this algorithm. support this algorithm.
As described in PKCS #1, all quantities input as data values to the As described in PKCS #1, all quantities input as data values to the
RSAEncryption process shall be properly justified and padded to the RSAEncryption process shall be properly justified and padded to the
length of the modulus prior to the encryption process. In general, length of the modulus prior to the encryption process. In general,
skipping to change at page 12, line 53 skipping to change at page 10, line 34
} }
An RSA input block is encrypted using the RSA algorithm with the An RSA input block is encrypted using the RSA algorithm with the
first (or left-most) octet taken as the most significant octet, and first (or left-most) octet taken as the most significant octet, and
the last (or right-most) octet taken as the least significant octet. the last (or right-most) octet taken as the least significant octet.
The resulting RSA output block is interpreted in a similar manner. The resulting RSA output block is interpreted in a similar manner.
When RSAEncryption is used to encrypt a DEK, the second argument in a When RSAEncryption is used to encrypt a DEK, the second argument in a
"MIC-Info:" header field, an asymmetrically encrypted DEK, is "MIC-Info:" header field, an asymmetrically encrypted DEK, is
represented using the printable encoding technique defined in Section represented using the printable encoding technique defined in Section
4.3.2.4 of RFC [1113ID]. 4.3.2.4 of RFC 1421 [12].
When RSAEncryption is used to sign a MIC, the third argument in a When RSAEncryption is used to sign a MIC, the third argument in a
"MIC-Info:" header field, an asymmetrically signed MIC, is "MIC-Info:" header field, an asymmetrically signed MIC, is
represented using the printable encoding technique defined in Section represented using the printable encoding technique defined in Section
4.3.2.4 of RFC [1113ID]. 4.3.2.4 of RFC 1421.
4.3 Asymmetric Signature Algorithms 4.3 Asymmetric Signature Algorithms
This section identifies the alternative algorithms which shall be This section identifies the alternative algorithms which shall be
used to asymmetrically sign certificates and certificate revocation used to asymmetrically sign certificates and certificate revocation
lists (CRLs) in accordance with the SIGNED macro defined in Annex G lists (CRLs) in accordance with the SIGNED macro defined in Annex G
of X.509. ASN.1 object identifiers are identified for incorporation of X.509. ASN.1 object identifiers are identified for incorporation
in certificates and CRLs to indicate the choice of algorithm in certificates and CRLs to indicate the choice of algorithm
employed. employed.
Only one alternative is presently defined in this category. Only one alternative is presently defined in this category.
4.3.1 md2WithRSAEncryption 4.3.1 md2WithRSAEncryption
The md2WithRSAEncryption signature algorithm is used to sign The md2WithRSAEncryption signature algorithm is used to sign
certificates and CRLs. The algorithm is defined in PKCS #1 [13]. It certificates and CRLs. The algorithm is defined in PKCS #1 [11]. It
combines the RSA-MD2 message digest algorithm described here in combines the RSA-MD2 message digest algorithm described here in
Section 2.2 with the RSAEncryption asymmetric encryption algorithm Section 2.2 with the RSAEncryption asymmetric encryption algorithm
described here in Section 4.2.1. As defined in PKCS #1, the ASN.1 described here in Section 4.2.1. As defined in PKCS #1, the ASN.1
object identifier object identifier
md2WithRSAEncryption OBJECT IDENTIFIER ::= { md2WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 2 pkcs-1(1) 2
} }
skipping to change at page 14, line 5 skipping to change at page 11, line 31
type is the ASN.1 type NULL. type is the ASN.1 type NULL.
There is some ambiguity in X.509 regarding the definition of the There is some ambiguity in X.509 regarding the definition of the
SIGNED macro and, in particular, the representation of a signature in SIGNED macro and, in particular, the representation of a signature in
a certificate or a CRL. The interpretation selected for PEM requires a certificate or a CRL. The interpretation selected for PEM requires
that the data to be signed (in our case, an MD2 message digest) is that the data to be signed (in our case, an MD2 message digest) is
first ASN.1 encoded as an OCTET STRING and the result is encrypted first ASN.1 encoded as an OCTET STRING and the result is encrypted
(in our case, using RSAEncryption) to form the signed quantity, which (in our case, using RSAEncryption) to form the signed quantity, which
is then ASN.1 encoded as a BIT STRING. is then ASN.1 encoded as a BIT STRING.
5 Descriptive Grammar 5. Descriptive Grammar
; Addendum to PEM BNF representation, using RFC 822 notation ; Addendum to PEM BNF representation, using RFC 822 notation
; Provides specification for official PEM cryptographic algorithms, ; Provides specification for official PEM cryptographic algorithms,
; modes, identifiers and formats. ; modes, identifiers and formats.
; Imports <hexchar> and <encbin> from RFC [1113ID] ; Imports <hexchar> and <encbin> from RFC [1421]
<dekalgid> ::= "DES-CBC" <dekalgid> ::= "DES-CBC"
<ikalgid> ::= "DES-EDE" / "DES-ECB" / "RSA" <ikalgid> ::= "DES-EDE" / "DES-ECB" / "RSA"
<sigalgid> ::= "RSA" <sigalgid> ::= "RSA"
<micalgid> ::= "MAC" / "RSA-MD2" / "RSA-MD5" <micalgid> ::= "RSA-MD2" / "RSA-MD5"
<dekparameters> ::= <DESCBCparameters> <dekparameters> ::= <DESCBCparameters>
<DESCBCparameters> ::= <IV> <DESCBCparameters> ::= <IV>
<IV> ::= <hexchar16> <IV> ::= <hexchar16>
<symencdek> ::= <DESECBencDESCBC> / <DESEDEencDESCBC> <symencdek> ::= <DESECBencDESCBC> / <DESEDEencDESCBC>
<DESECBencDESCBC> ::= <hexchar16> <DESECBencDESCBC> ::= <hexchar16>
<DESEDEencDESCBC> ::= <hexchar16> <DESEDEencDESCBC> ::= <hexchar16>
<symencmic> ::= <DESECBencMAC> / <DESECBencRSAMD2> / <DESECBencRSAMD5> <symencmic> ::= <DESECBencRSAMD2> / <DESECBencRSAMD5>
<DESECBencMAC> ::= <hexchar16>
<DESECBencRSAMD2> ::= 2*2<hexchar16> <DESECBencRSAMD2> ::= 2*2<hexchar16>
<DESECBencRSAMD5> ::= 2*2<hexchar16> <DESECBencRSAMD5> ::= 2*2<hexchar16>
<asymsignmic> ::= <RSAsignmic> <asymsignmic> ::= <RSAsignmic>
<RSAsignmic> ::= <encbin> <RSAsignmic> ::= <encbin>
<asymencdek> ::= <RSAencdek> <asymencdek> ::= <RSAencdek>
<RSAencdek> ::= <encbin> <RSAencdek> ::= <encbin>
<hexchar16> ::= 16*16<hexchar> <hexchar16> ::= 16*16<hexchar>
References: References
[1] Federal Information Processing Standards Publication (FIPS [1] Federal Information Processing Standards Publication (FIPS PUB)
PUB) 46-1, Data Encryption Standard, Reaffirmed 1988 January 46-1, Data Encryption Standard, Reaffirmed 1988 January 22
22 (supersedes FIPS PUB 46, 1977 January 15). (supersedes FIPS PUB 46, 1977 January 15).
[2] ANSI X3.92-1981, American National Standard Data Encryption [2] ANSI X3.92-1981, American National Standard Data Encryption
Algorithm, American National Standards Institute, Approved 30 Algorithm, American National Standards Institute, Approved 30
December 1980. December 1980.
[3] Federal Information Processing Standards Publication (FIPS [3] Federal Information Processing Standards Publication (FIPS PUB)
PUB) 81, DES Modes of Operation, 1980 December 2. 81, DES Modes of Operation, 1980 December 2.
[4] ANSI X3.106-1983, American National Standard for Information [4] ANSI X3.106-1983, American National Standard for Information
Systems - Data Encryption Algorithm - Modes of Operation, Systems - Data Encryption Algorithm - Modes of Operation,
American National Standards Institute, Approved 16 May 1983. American National Standards Institute, Approved 16 May 1983.
[5] ISO 8372, Information Processing Systems: Data Encipherment: [5] ISO 8372, Information Processing Systems: Data Encipherment:
Modes of Operation of a 64-bit Block Cipher. Modes of Operation of a 64-bit Block Cipher.
[6] ANSI X9.17-1985, American National Standard, Financial [6] ANSI X9.17-1985, American National Standard, Financial
Institution Key Management (Wholesale), American Bankers Institution Key Management (Wholesale), American Bankers
Association, April 4, 1985, Section 7.2. Association, April 4, 1985, Section 7.2.
[7] Voydock, V. L. and Kent, S. T., "Security Mechanisms in High- [7] Voydock, V. L. and Kent, S. T., "Security Mechanisms in High-
Level Network Protocols", ACM Computing Surveys, Vol. 15, No. Level Network Protocols", ACM Computing Surveys, Vol. 15, No. 2,
2, June 1983, pp. 135-171. June 1983, pp. 135-171.
[8] CCITT Recommendation X.509, "The Directory - Authentication [8] CCITT Recommendation X.509, "The Directory - Authentication
Framework", November 1988, (Developed in collaboration, and Framework", November 1988, (Developed in collaboration, and
technically aligned, with ISO 9594-8). technically aligned, with ISO 9594-8).
[9] Federal Information Processing Standards Publication (FIPS [9] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, RSA
PUB) 113, Computer Data Authentication, 1985 May 30. Laboratories, April 1992.
[10] NIST Special Publication 500-183, Stable Implementation [10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
Agreements for Open Systems Interconnection Protocols, Version Laboratory for Computer Science and RSA Data Security, Inc.,
5, Edition 1, Part 11, December 1991. April 1992.
[11] Kaliski, B., The MD2 Message-Digest Algorithm (RFC 1319), [11] PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data Security,
April 1992. Inc., June 3, 1991.
[12] Rivest, R., The MD5 Message-Digest Algorithm (RFC 1321), April [12] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
1992. I: Message Encryption and Authentication Procedures", RFC 1421,
DEC, February 1993.
[13] PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data [13] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part
Security, Inc., June 3, 1991. II: Certificate-Based Key Management", RFC 1422, BBN, February
1993.
[14] Jueneman, R.R., S.M. Matyas and C.M. Meyer, "Message [14] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:
Authentication With Manipulation Detection Codes", Proceedings Part IV: Key Certification and Related Services", RFC 1424, RSA
1983 IEEE Symposium on Security and Privacy, April 1983, Laboratories, February 1993.
Oakland, CA, IEEE Computer Society, 1983, pp. 33-54.
Author's Address: Patent Statement
David Balenson This version of Privacy Enhanced Mail (PEM) relies on the use of
Trusted Information Systems patented public key encryption technology for authentication and
3060 Washington Road encryption. The Internet Standards Process as defined in RFC 1310
Glenwood, Maryland 21738 requires a written statement from the Patent holder that a license
will be made available to applicants under reasonable terms and
conditions prior to approving a specification as a Proposed, Draft or
Internet Standard.
Phone: 301-854-6889 The Massachusetts Institute of Technology and the Board of Trustees
of the Leland Stanford Junior University have granted Public Key
Partners (PKP) exclusive sub-licensing rights to the following
patents issued in the United States, and all of their corresponding
foreign patents:
EMail: balenson@tis.com Cryptographic Apparatus and Method
("Diffie-Hellman")............................... No. 4,200,770
Public Key Cryptographic Apparatus
and Method ("Hellman-Merkle").................... No. 4,218,582
Cryptographic Communications System and
Method ("RSA")................................... No. 4,405,829
Exponential Cryptographic Apparatus
and Method ("Hellman-Pohlig").................... No. 4,424,414
These patents are stated by PKP to cover all known methods of
practicing the art of Public Key encryption, including the variations
collectively known as El Gamal.
Public Key Partners has provided written assurance to the Internet
Society that parties will be able to obtain, under reasonable,
nondiscriminatory terms, the right to use the technology covered by
these patents. This assurance is documented in RFC 1170 titled
"Public Key Standards and Licenses". A copy of the written assurance
dated April 20, 1990, may be obtained from the Internet Assigned
Number Authority (IANA).
The Internet Society, Internet Architecture Board, Internet
Engineering Steering Group and the Corporation for National Research
Initiatives take no position on the validity or scope of the patents
and patent applications, nor on the appropriateness of the terms of
the assurance. The Internet Society and other groups mentioned above
have not made any determination as to any other intellectual property
rights which may apply to the practice of this standard. Any further
consideration of these matters is the user's own responsibility.
Security Considerations
This entire document is about security.
Author's Address
David Balenson
Trusted Information Systems
3060 Washington Road
Glenwood, Maryland 21738
Phone: 301-854-6889
EMail: balenson@tis.com
 End of changes. 49 change blocks. 
234 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/