New draft RFC 1115 successor
balenson@tis.com Wed, 15 April 1992 13:33 UTC
Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01996; 15 Apr 92 9:33 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa08862; 15 Apr 92 9:36 EDT
Received: from TIS.COM by NRI.Reston.VA.US id aa08853; 15 Apr 92 9:36 EDT
Received: by TIS.COM (4.1/SUN-5.64) id AA21115; Wed, 15 Apr 92 09:35:06 EDT
Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA21106; Wed, 15 Apr 92 09:35:04 EDT
Message-Id: <9204151335.AA21106@TIS.COM>
To: pem-dev@tis.com
Subject: New draft RFC 1115 successor
Date: Wed, 15 Apr 1992 09:35:03 -0400
From: balenson@tis.com
Sender: pem-dev-relay@tis.com
Folks-
Here's the new revision to draft-ietf-pem-algorithms-00.txt, which was
dated August 1991. Aside from various editorial changes, there are two
important technical changes:
(1) The OBJECT IDENTIFIER for the MAC algorithm, taken from
the NIST OIW Security SIG, has been updated to reflect the
latest version of the OIW Stable Implementation Agreements.
(2) The "RSAEncryption" algorithm along with its encryption block
padding schemes and OBJECT IDENTIFIER (defined in PKCS #1) have
now been adopted for encryption of DEKs and MICs. Previously,
the PKCS #1 encryption block padding schemes and the straight
"rsa" algorithm and OBJECT IDENTIFIER (defined in Annex H of
X.509) were used for encryption of DEKs and MICs, and the
"RSAEncryption" algorithm was only used for certificate/CRL
signatures.
One consequence of (2) is that message and certificate/CRL signatures
are now formed and processed in an identical manner, simplifying both
the specification and resulting implementations.
Please email nits directly to me, and any other questions or comments
(especially concerns about any potential ambiguities in the
specification) you may have to the PEM-DEV list. Thanks!
-DB
-----
Network Working Group D. Balenson (TIS)
INTERNET-DRAFT IAB IRTF PSRG, IETF PEM WG
April 1992
Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, and Identifiers
STATUS OF THIS MEMO
This draft document will be submitted to the RFC editor as a
standards document, and is submitted as a proposed 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. This
specification was developed by the Internet Research Task Force's
Privacy and Security Research Group. Comments should be sent to
<pem-dev@tis.com>.
ACKNOWLEDGMENT
This document is the outgrowth of a series of meetings of the Privacy
and Security Research Group (PSRG) of the IRTF and the PEM Working
Group of the IETF. John Linn contributed significantly to the
predecessor of this document (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-dev@tis.com" mailing list, for their
contributions to this document.
Table of Contents
1. Executive Summary ................................... 2
2. Symmetric Message Encryption Algorithms ............. 2
2.1 DES in CBC Mode (DES-CBC) .......................... 2
3. Message Integrity Check Algorithms .................. 3
3.1 Message Authentication Code (MAC) .................. 4
3.2 RSA-MD2 Message Digest Algorithm ................... 5
3.3 RSA-MD5 Message Digest Algorithm ................... 6
4. Symmetric Key Management Algorithms ................. 6
4.1 DES in ECB mode (DES-ECB) .......................... 7
4.2 DES in EDE mode (DES-EDE) .......................... 7
5. Asymmetric Key Management Algorithms ................ 7
5.1 Asymmetric Encryption Algorithms ................... 8
5.1.1 RSAEncryption .................................... 8
Balenson [Page 1]
Internet-Draft PEM: Algorithms, Modes and Identifiers April 1992
5.2 Asymmetric Signature Algorithms ................... 10
5.2.1 md2WithRSAEncryption ............................ 10
References ............................................. 11
1 Executive Summary
This document provides definitions, references, and citations for
algorithms, usage modes, and associated identifiers and parameters
used in support of privacy-enhanced mail (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 primary sections,
dealing with symmetric message encryption algorithms, message
integrity check algorithms, symmetric key management algorithms, and
asymmetric key management algorithms, including both asymmetric
encryption and signature algorithms. Some parts of this material are
cited by other Internet-Drafts and it is anticipated that some of the
material herein may be changed, added, or replaced without affecting
the citing documents. Therefore, algorithm-specific material has
been placed into this separate document. Use of other algorithms
and/or modes will require case-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.
2 Symmetric Message Encryption Algorithms
This section identifies alternative symmetric message encryption
algorithms and modes that may be used to encrypt message text and,
whgen asymmetric key management is employed in an ENCRYPTED PEM
message, for encryption of message signatures. Character string
identifiers are assigned for incorporation in encapsulated PEM header
fields to indicate the choice of algorithm employed.
Only one alternative is currently defined in this category.
2.1 DES in CBC mode (DES-CBC)
Message text and, if required, message signatures are encrypted using
the Data Encryption Standard (DES) in the Cipher Block Chaining (CBC)
mode of operation. The DES is defined in FIPS PUB 46-1 [1], and is
equivalent to the Block Cipher Algorithm DEA-1 provided in ANSI
X3.92-1981 [2]. The CBC mode of operation of DES is defined in FIPS
PUB 81 [3], and is equivalent to those provided in ANSI X3.106 [4]
Balenson [Page 2]
Internet-Draft PEM: Algorithms, Modes and Identifiers April 1992
and in ISO IS 8372 [5]. The character string "DES-CBC" within an
encapsulated PEM header field indicates the use of this
algorithm/mode combination.
The input to the DES CBC encryption process must be padded to a
multiple of 8 octet, in the following manner. Let n be the length in
octets of the input. Pad the input by appending 8-(n mod 8) octet to
the end of the message, each having the value 8-(n mod 8), the number
of octets being added. In hexadecimal, the possible paddings are:
01, 0202, 030303, 04040404, 0505050505, 060606060606, 07070707070707,
and 0808080808080808. All input is padded with 1 to 8 octets to
produce a multiple of 8 octets in length. The padding can be removed
unambiguously after decryption.
The DES CBC encryption process requires a 64-bit Initialization
Vector (IV). A new, pseudorandom IV must be generated for each
ENCRYPTED PEM message. Section 4.3.1 of [7] provides rationale for
this requirement, even given the fact that individual DEKs are
generated for individual messages. The IV is transmitted with the
message within an encapsulated PEM header field.
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
process (e.g., RSA encryption), the following holds true. The first
(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
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.
3 Message Integrity Check Algorithms
This section identifies the alternative algorithms that may be used
to compute Message Integrity Check (MIC) values for PEM messages.
Character string identifiers and ASN.1 object identifiers are
assigned for incorporation in encapsulated PEM header fields to
indicate the choice of MIC algorithm employed.
For compatibility with this specification, a PEM implementation must
be able to process MAC, RSA-MD2, and RSA-MD5 MICs on incoming
messages. It is a sender option whether MAC, RSA-MD2, or RSA-MD5 is
employed on an outbound message.
_______________
(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".
Balenson [Page 3]
Internet-Draft PEM: Algorithms, Modes and Identifiers April 1992
3.1 Message Authentication Code (MAC)
A message authentication code (MAC) is computed using the DES CBC
mode of operation in the fashion defined 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
identifer 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 requires a 64-bit cryptographic key. For our
purposes, this key is derived as a variant of the DEK used for
message text encryption. See [14] for the rationale behind this
requirement. For our purposes, the variant is formed by modulo-2
addition of the 8-octet hexadecimal quantity F0F0F0F0F0F0F0F0 to the
message DEK.
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.
To avoid any potential ambiguity regarding the ordering of the octets
of a MAC that is input as a data value to the RSA encryption process,
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
Balenson [Page 4]
Internet-Draft PEM: Algorithms, Modes and Identifiers April 1992
finer (and more desirable) granularity authenticating only the
individual sender.
3.2 RSA-MD2 Message Digest Algorithm
The RSA-MD2 message digest is computed using the algorithm defined in
Internet Draft [MD2] [11]. The character string "RSA-MD2" within an
encapsulated PEM header field indicates the use of this algorithm.
Also, as defined in Internet Draft [MD2], the ASN.1 object identifier
md2 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549)
digestAlgorithm(2) 2
}
identifies this algorithm. When this object identifer is used with
the ASN.1 type AlgorithmIdentifier, the parameters component of that
type is the ASN.1 type NULL.
The RSA-MD2 message digest algorithm accepts as input a message of
any length and produces as output a 16-octet quantity. When
symmetric key management is employed, an RSA-MD2 MIC is encrypted by
splitting the MIC into two 8-octet halves, independently encrypting
each half, and concatenating the results.
To avoid any potential ambiguity regarding the ordering of the octets
of an MD2 message digest that is input as an RSA data value to the
RSA encryption process, the following holds true. The first (or
left-most displayed, if one thinks in terms of a digest's "print"
representation) octet of the digest (i.e., X[0] as specified in
Internet Draft [MD2]), when considered as an RSA data value, has
numerical weight 2**120. The last (or right-most displayed) octet
(i.e., X[15] as specified in Internet Draft [MD2]) has numerical
weight 2**0.
This algorithm may be used as a MIC algorithm whenever a message is
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.3 RSA-MD5 Message Digest Algorithm
The RSA-MD5 message digest is computed using the algorithm defined in
Internet Draft [MD5] [12]. The character string "RSA-MD5" within an
encapsulated PEM header field indicates the use of this algorithm.
Also, as defined in Internet Draft [MD5], the object identifier
Balenson [Page 5]
Internet-Draft PEM: Algorithms, Modes and Identifiers April 1992
md5 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549)
digestAlgorithm(2) 5
}
identifies this algorithm. When this object identifer is used with
the ASN.1 type AlgorithmIdentifier, the parameters component of that
type is the ASN.1 type NULL.
The RSA-MD5 message digest algorithm accepts as input a message of
any length and produces as output a 16-octet quantity. When
symmetric key management is employed, an RSA-MD5 MIC is encrypted by
splitting the MIC into two 8-octet halves, independently encrypting
each half, and concatenating the results.
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
encryption process, the following holds true. The first (or left-
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
as specified in Internet Draft [MD5]), when considered as an RSA data
value, has numerical weight 2**120. The last (or right-most
displayed) octet (i.e., the high-order octet of D as specified in
Internet Draft [MD5]) has numerical weight 2**0.
This algorithm may be used as a MIC algorithm whenever a message is
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.
4 Symmetric Key Management Algorithms
This section identifies alternative algorithms and modes that may be
used when symmetric key management is employed, to encrypt data
encryption keys (DEKs) and message integrity check (MIC) values.
Character string identifiers are assigned for incorporation in
encapsulated PEM header fields to indicate the choice of algorithm
employed.
All alternatives presently defined in this category correspond to
different usage modes of the DES algorithm, rather than to other
algorithms.
Since alternative MIC algorithms may produce MICs of varying lengths,
the use of the following symmetric encryption algorithms for MIC
encryption may differ depending on the MIC algorithm. Similarly,
since alternative message encryption algorithms may employ DEKs of
varying lengths, the use of the following symmetric encryption
Balenson [Page 6]
Internet-Draft PEM: Algorithms, Modes and Identifiers April 1992
algorithms for DEK encryption may differ depending on the message
encryption algorithm. The subsections on alternative message
encryption and MIC algorithms provide information on the proper
manner in which to use the following symmetric encryption algorithms
when the size of the DEK or MIC is not equal to the algorithm's input
block size.
4.1 DES in ECB mode (DES-ECB)
The DES algorithm in Electronic Codebook (ECB) mode [1][3] is used
for DEK and MIC encryption when symmetric key management is employed.
The character string "DES-ECB" within an encapsulated PEM header
field indicates use of this algorithm/mode combination.
All PEM implementations supporting symmetric key management must
support this algorithm/mode combination.
4.2 DES in EDE mode (DES-EDE)
The DES algorithm in Encrypt-Decrypt-Encrypt (EDE) mode, as defined
by ANSI X9.17 [6] for encryption and decryption with pairs of 64-bit
keys, is used for DEK and MIC encryption when symmetric key
management is employed. The character string "DES-EDE" within an
encapsulated PEM header field indicates use of this algorithm/mode
combination.
PEM implementations supporting symmetric key management may
optionally support this algorithm/mode combination.
5 Asymmetric Key Management Algorithms
This section identifies alternative asymmetric key management
algorithms, including asymmetric encryption algorithms used to to
encrypt DEKs and MICs, and digital signature algorithms used to sign
certificates and CRLS. Character string identifiers are assigned for
incorporation in encapsulated PEM header fields to indicate the
choice of algorithm employed. ASN.1 object identifiers are also
assigned for incorporation in public-key certificates to identify the
algorithm with which the respective public key is to be employed.
Balenson [Page 7]
Internet-Draft PEM: Algorithms, Modes and Identifiers April 1992
5.1 Asymmetric Encryption Algorithms
This section identifies alternative asymmetric encryption algorithms
to encrypt DEKs and MICs when asymmetric key management is employed.
Only one alternative is presently defined in this category.
5.1.1 RSAEncryption
The RSAEncryption public-key encryption algorithm, defined in PKCS #1
[13], is used for DEK and MIC encryption when asymmetric key
management is employed. The character string "RSA" within an
encapsulated PEM header field indicates the use of this algorithm.
As defined in PKCS #1, the ASN.1 object identifier
rsaEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 1
}
identifies a public key to be used with this algorithm. There are no
parameters defined by this algorithm, hence, when this object
identifier is used with the ASN.1 type AlgorithmIdentifier, the
parameters component of that type is the ASN.1 type NULL.
All PEM implementations supporting asymmetric key management must
support this algorithm.
A public key consists of an encryption exponent e and an arithmetic
modulus n, both public quantities which are typically carried in a
public-key certificate. For the value of e, Annex C to X.509
suggests the use of Fermat's Number F4 (65537 decimal, or 1+2**16) as
a value "common to the whole environment in order to reduce
transmission capacity and complexity of transformation", i.e., the
value can be transmitted as 3 octets and at most seventeen (17)
multiplications are required to effect exponentiation. As an
alternative, the number three (3) can be employed as the value for e,
requiring even less octets for transmission and yielding even faster
exponentiation. For purposes of PEM, the value of e must be either
F4 or the number three (3). The use of the value three (3) for
certificate validation is encouraged, to permit rapid certificate
validation.
A private key typically consists of a decryption exponent d, a secret
quantity, and the arithmetic modulus n.
Balenson [Page 8]
Internet-Draft PEM: Algorithms, Modes and Identifiers April 1992
For our purposes, the modulus n may vary in size from 508 to 1024
bits.
In accordance with PKCS #1, all quantities input as data values to
the RSA encryption process are properly justified and padded to the
length of the modulus prior to the encryption process. In general,
an RSA input value is formed by concatenating a block type BT, a
padding string PS, a NULL octet, and the data quantity D, that is,
RSA input value = BT || PS || 0x00 || D.
To prepare a MIC for RSAEncryption, the PKCS #1 "block type 01"
encryption-block formatting scheme is employed. The block type BT is
a single octet containing the value 0x01 and the padding string PS is
one or more octets (enough octets to make the length of the complete
RSA input value equal to the length of the modulus) each containing
the value 0xFF. The data quantity D is comprised of the MIC and the
MIC algorithm identifier which are ASN.1 encoded as the following
sequence.
SEQUENCE {
digestAlgorithm AlgorithmIdentifier,
digest OCTET STRING
}
The ASN.1 type AlgorithmIdentifier is defined in X.509 as follows.
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}
To prepare a DEK for RSAEncryption, the PKCS #1 "block type 02"
encryption-block formatting scheme is employed. The block type BT is
a single octet containing the value 0x02 and the padding string PS is
one or more octets (enough octets to make the length of the complete
RSA input value equal to the length of the modulus) each containing a
pseudorandomly generated, non-zero value. The data quantity D is the
DEK itself, which is right-justified within the RSA input such that
the last (or rightmost displayed, if one thinks in terms of the
"print" representation) octet of the DEK is aligned with the right-
most, or least-significant, octet of the RSA input. Proceeding to
the left, each of the remaining octets of the DEK, up through the
first (or left-most displayed) octet, are each aligned in the next
more significant octet of the RSA input.
An RSA input block is encrypted using the RSA algorithm with the
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 resulting RSA output is interpreted in a similar manner.
Balenson [Page 9]
Internet-Draft PEM: Algorithms, Modes and Identifiers April 1992
5.2 Asymmetric Signature Algorithms
This section identifies alternative signature algorithms which may be
used to sign certificates and certificate revocation lists (CRLs) in
accordance with the SIGNED macro defined in Annex G of X.509. ASN.1
object identifiers are assigned for incorporation in certificates and
CRLs to indicate the choice of algorithm employed.
Only one alternative is presently defined in this category.
5.2.1 md2WithRSAEncryption
The md2WithRSAEncryption algorithm combines the RSA-MD2 message
digest algorithm described in Section 3.2 and the RSAEncryption
asymmetric encryption algorithm described in Section 5.1.1. As
defined in PKCS #1, the ASN.1 object identifier
md2WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 2
}
identifies this algorithm. When this object identifer is used with
the ASN.1 type AlgorithmIdentifier, the parameters component of that
type is the ASN.1 type NULL.
There is some ambiguity in X.509 regarding the definition of the
SIGNED macro and, in particular, the representation of a signature in
a certificate or a CRL. The interpretation selected for PEM requires
that the data to be signed (in our case, a MD2 message digest) is
first ASN.1 encoded as an OCTET STRING and the result is encrypted
(in our case, using RSAEncryption) to form the signed quantity, which
is then ASN.1 encoded as a BIT STRING.
Balenson [Page 10]
Internet-Draft PEM: Algorithms, Modes and Identifiers April 1992
References:
[1] Federal Information Processing Standards Publication (FIPS
PUB) 46-1, Data Encryption Standard, Reaffirmed 1988 January
22 (supercedes FIPS PUB 46, 1977 January 15).
[2] ANSI X3.92-1981, American National Standard Data Encryption
Algorithm, American National Standards Institute, Approved 30
December 1980.
[3] Federal Information Processing Standards Publication (FIPS
PUB) 81, DES Modes of Operation, 1980 December 2.
[4] ANSI X3.106-1983, American National Standard for Information
Systems - Data Encryption Algorithm - Modes of Operation,
American National Standards Institute, Approved 16 May 1983.
[5] ISO 8372, Information Processing Systems: Data Encipherment:
Modes of Operation of a 64-bit Block Cipher.
[6] ANSI X9.17-1985, American National Standard, Financial
Institution Key Management (Wholesale), American Bankers
Association, April 4, 1985, Section 7.2.
[7] Voydock, V. L. and Kent, S. T., "Security Mechanisms in High-
Level Network Protocols", ACM Computing Surveys, Vol. 15, No.
2, June 1983, pp. 135-171.
[8] CCITT Recommendation X.509 (1988), "The Directory -
Authentication Framework".
[9] Federal Information Processing Standards Publication (FIPS
PUB) 113, Computer Data Authentication, 1985 May 30.
[10] NIST Special Publication 500-183, Stable Implementation
Agreements for Open Systems Interconnection Protocols, Version
5, Edition 1, Part 11, December 1991.
[11] Kaliski, B., The MD2 Message-Digest Algorithm, Internet Draft,
2 April 1992.
[12] Rivest, R., The MD5 Message-Digest Algorithm, Internet Draft,
2 April 1992.
[13] PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data
Security, Inc., June 3, 1991.
[14] Jueneman, R.R., S.M. Matyas and C.M. Meyer, "Message
Authentication With Manipulation Detection Codes, Proceedings
1983 IEEE Symposium on Security and Privacy, April 1983,
Balenson [Page 11]
Internet-Draft PEM: Algorithms, Modes and Identifiers April 1992
Oakland, CA, IEEE Computer Society, 1983, pp. 33-54.
Author's Address:
David Balenson
Trusted Information Systems
3060 Washington Road
Glenwood, Maryland 21738
Phone: 301-854-6889
EMail: balenson@tis.com
Balenson [Page 12]
- New draft RFC 1115 successor balenson