idnits 2.17.1 draft-ietf-pem-algorithms-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 1) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 550: '... ANY DEFINED BY algorithm OPTIONAL...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 184 has weird spacing: '... values are...' == Line 280 has weird spacing: '...9. The state...' == Line 281 has weird spacing: '...the text of ...' == Line 282 has weird spacing: '...te that the ...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (3 September 1992) is 11551 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 641 looks like a reference -- Missing reference section? '2' on line 645 looks like a reference -- Missing reference section? '3' on line 649 looks like a reference -- Missing reference section? '4' on line 652 looks like a reference -- Missing reference section? '5' on line 656 looks like a reference -- Missing reference section? '7' on line 663 looks like a reference -- Missing reference section? '9' on line 671 looks like a reference -- Missing reference section? '10' on line 674 looks like a reference -- Missing reference section? '14' on line 687 looks like a reference -- Missing reference section? '11' on line 678 looks like a reference -- Missing reference section? '0' on line 295 looks like a reference -- Missing reference section? '15' on line 298 looks like a reference -- Missing reference section? '12' on line 681 looks like a reference -- Missing reference section? '6' on line 659 looks like a reference -- Missing reference section? '13' on line 684 looks like a reference -- Missing reference section? '8' on line 667 looks like a reference -- Missing reference section? '1113ID' on line 611 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group David Balenson (TIS) 3 INTERNET DRAFT IAB IRTF PSRG, IETF PEM WG 4 3 September 1992 6 Privacy Enhancement for Internet Electronic Mail: 7 Part III: Algorithms, Modes, and Identifiers 9 Status of This Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress." 22 Please check the Internet Drafts abstract listing contained in each 23 Internet Drafts directory to learn the current status of this or any 24 other Internet Draft. 26 This document will be submitted to the RFC editor as a proposed 27 standard document, and will be submitted as a successor to current 28 RFC 1115. References within the text of this Internet Draft to this 29 document as an RFC, or to other related Internet Drafts cited as 30 RFCs, are not intended to carry any connotation about the progression 31 of these Internet Drafts through the IAB standards-track review 32 cycle. Distribution of this draft is unlimited. Comments should be 33 sent to the PEM Developer's mailing list . 35 Abstract 37 This document provides definitions, formats, references, and 38 citations for cryptographic algorithms, usage modes, and associated 39 identifiers and parameters used in support of Privacy Enhanced Mail 40 (PEM) in the Internet community. It is intended to become one member 41 of the set of related PEM RFCs. This document is organized into four 42 primary sections, dealing with message encryption algorithms, message 43 integrity check algorithms, symmetric key management algorithms, and 44 asymmetric key management algorithms (including both asymmetric 45 encryption and asymmetric signature algorithms). 47 Some parts of this material are cited by other documents and it is 48 anticipated that some of the material herein may be changed, added, 49 or replaced without affecting the citing documents. Therefore, 50 algorithm-specific material has been placed into this separate 51 document. Use of other algorithms and/or modes will require case- 52 by-case study to determine applicability and constraints. Additional 53 algorithms and modes approved for use in PEM in this context will be 54 specified in successors to this document. 56 Acknowledgment 58 This specification was initially developed by the Internet Research 59 Task Force's Privacy and Security Research Group (IRTF PSRG) and 60 subsequently refined based on discussion in the Internet Engineering 61 Task Force's Privacy Enhanced Mail Working Group (IETF PEM WG). John 62 Linn contributed significantly to the predecessor of this document 63 (RFC 1115). I would like to thank the members of the PSRG and PEM 64 WG, as well as all participants in discussions on the "pem- 65 dev@tis.com" mailing list, for their contributions to this document. 67 Table of Contents 69 1. Message Encryption Algorithms ....................... 3 70 1.1 DES in CBC Mode (DES-CBC) .......................... 3 72 2. Message Integrity Check Algorithms .................. 4 73 2.1 Message Authentication Code (MAC) .................. 5 74 2.2 RSA-MD2 Message Digest Algorithm ................... 6 75 2.3 RSA-MD5 Message Digest Algorithm ................... 7 77 3. Symmetric Key Management Algorithms ................. 8 78 3.1 DES in ECB mode (DES-ECB) .......................... 9 79 3.2 DES in EDE mode (DES-EDE) .......................... 9 81 4. Asymmetric Key Management Algorithms ................ 9 82 4.1 Asymmetric Keys .................................... 9 83 4.1.1 RSA Keys ........................................ 10 84 4.2 Asymmetric Encryption Algorithms .................. 11 85 4.2.1 RSAEncryption ................................... 11 86 4.3 Asymmetric Signature Algorithms ................... 13 87 4.3.1 md2WithRSAEncryption ............................ 13 89 5. Descriptive Grammar ................................ 14 91 References ............................................. 15 93 1 Message Encryption Algorithms 95 This section identifies the alternative message encryption algorithms 96 and modes that shall be used to encrypt message text and, when 97 asymmetric key management is employed in an ENCRYPTED PEM message, 98 for encryption of message signatures. Character string identifiers 99 are assigned and any parameters required by the message encryption 100 algorithm are defined for incorporation in an encapsulated "DEK- 101 Info:" header field. 103 Only one alternative is currently defined in this category. 105 1.1 DES in CBC Mode (DES-CBC) 107 Message text and, if required, message signatures are encrypted using 108 the Data Encryption Standard (DES) algorithm in the Cipher Block 109 Chaining (CBC) mode of operation. The DES algorithm is defined in 110 FIPS PUB 46-1 [1], and is equivalent to the Data Encryption Algorithm 111 (DEA) provided in ANSI X3.92-1981 [2]. The CBC mode of operation of 112 DES is defined in FIPS PUB 81 [3], and is equivalent to those 113 provided in ANSI X3.106 [4] and in ISO IS 8372 [5]. The character 114 string "DES-CBC" within an encapsulated PEM header field indicates 115 the use of this algorithm/mode combination. 117 The input to the DES CBC encryption process shall be padded to a 118 multiple of 8 octets, in the following manner. Let n be the length 119 in octets of the input. Pad the input by appending 8-(n mod 8) 120 octets to the end of the message, each having the value 8-(n mod 8), 121 the number of octets being added. In hexadecimal, the possible 122 paddings are: 01, 0202, 030303, 04040404, 0505050505, 060606060606, 123 07070707070707, and 0808080808080808. All input is padded with 1 to 124 8 octets to produce a multiple of 8 octets in length. The padding 125 can be removed unambiguously after decryption. 127 The DES CBC encryption process requires a 64-bit cryptographic key. 128 A new, pseudorandom key shall be generated for each ENCRYPTED PEM 129 message or for each MIC-CLEAR or MIC-ONLY message which employs a MIC 130 algorithm that requires a cryptographic key (e.g., MAC). Of the 64 131 bits, 56 are used directly by the DES CBC process, and 8 are odd 132 parity bits, with one parity bit occupying the right-most bit of each 133 octet. When symmetric key management is employed, the setting and 134 checking of odd parity bits is encouraged, since these bits could 135 detect an error in the decryption of a DES key encrypted under a 136 symmetric key management algorithm (e.g., DES ECB). When asymmetric 137 key management is employed, the setting of odd parity bits is 138 encouraged, but the checking of odd parity bits is discouraged, in 139 order to facilitate interoperability, and since an error in the 140 decryption of a DES key can be detected by other means (e.g., an 141 incorrect PKCS #1 encryption-block format). In all cases, the 142 encrypted form of a DES key shall carry all 64 bits of the key, 143 including the 8 parity bits, though those bits may have no meaning. 145 The DES CBC encryption process also requires a 64-bit Initialization 146 Vector (IV). A new, pseudorandom IV shall be generated for each 147 ENCRYPTED PEM message. Section 4.3.1 of [7] provides rationale for 148 this requirement, even given the fact that individual DES keys are 149 generated for individual messages. The IV is transmitted with the 150 message within an encapsulated PEM header field. 152 When this algorithm/mode combination is used for message text 153 encryption, the "DEK-Info:" header field carries exactly two 154 arguments. The first argument identifies the DES CBC algorithm/mode 155 using the character string defined above. The second argument 156 contains the IV, represented as a contiguous string of 16 ASCII 157 hexadecimal digits. 159 When symmetric key management is employed with this algorithm/mode 160 combination, a symmetrically encrypted DES key will be represented in 161 the third argument of a "Key-Info:" header field as a contiguous 162 string of 16 ASCII hexadecimal digits (corresponding to a 64-bit 163 key). 165 To avoid any potential ambiguity regarding the ordering of the octets 166 of a DES key that is input as a data value to another encryption 167 process (e.g., RSAEncryption), the following holds true. The first 168 (or left-most displayed, if one thinks in terms of a key's "print" 169 representation (1)) octet of the key (i.e., bits 1-8 per FIPS PUB 170 46-1), when considered as a data value, has numerical weight 2**56. 171 The last (or right-most displayed) octet (i.e., bits 57-64 per FIPS 172 PUB 46-1) has numerical weight 2**0. 174 2 Message Integrity Check Algorithms 176 This section identifies the alternative algorithms that shall be used 177 to compute Message Integrity Check (MIC) values for PEM messages. 178 Character string identifiers and ASN.1 object identifiers are 179 assigned for incorporation in encapsulated "MIC-Info:" and "Key- 180 Info:" header fields to indicate the choice of MIC algorithm 181 employed. 183 _______________ 184 (1) For purposes of discussion in this document, data values are 185 normalized in terms of their "print" representation. For a octet 186 stream, the "first" octet would appear as the one on the "left", 187 and the "last" octet would appear on the "right". 189 A compliant PEM implementation shall be able to process all of the 190 alternative MIC algorithms defined here on incoming messages. It is 191 a sender option as to which alternative is employed on an outbound 192 message. 194 2.1 Message Authentication Code (MAC) 196 A message authentication code (MAC) is computed using DES in the CBC 197 mode of operation (with an IV of all zeros) in the manner defined in 198 Appendix F of FIPS PUB 81 [3] and in FIPS PUB 113 [9]. The MAC is 199 taken as all 8 octets (i.e., 64 bits) of the final output block (On, 200 read "O-sub-n", as denoted in FIPS PUB 113). The character string 201 "MAC" within an encapsulated PEM header field indicates the use of 202 this algorithm. Also, as defined in NIST Special Publication 500-183 203 [10], the ASN.1 object identifier 205 desMAC OBJECT IDENTIFIER ::= { 206 iso(1) identified-organization(3) oiw(14) secsig(3) 207 algorithm(2) 10 208 } 210 identifies this algorithm. A single parameter, the length of the MAC 211 in bits, is defined for the MAC algorithm, hence, when this object 212 identifier is used with the ASN.1 type AlgorithmIdentifier, the 213 parameters component of that type is the length of the MAC, in the 214 case of PEM, 64 bits, ASN.1 encoded as an INTEGER. 216 The MAC algorithm accepts as input a message of any length. The 217 input is padded at the end, per FIPS PUB 113, with zero-valued octets 218 as needed in order to form an integral number of 8-octet encryption 219 quanta. These padding octets are inserted implicitly and are not 220 transmitted with a message. 222 The MAC algorithm requires a 64-bit cryptographic key. For purposes 223 of PEM, this key is derived as a variant of the DEK used for message 224 text encryption (see [14] for the rationale behind this requirement). 225 The variant shall be formed by exclusive-OR'ing the 8-octet 226 hexadecimal quantity F0F0F0F0F0F0F0F0 to the 64-bit message DEK. 227 Note that when the MAC algorithm is used in a non-ENCRYPTED PEM 228 message (e.g., a MIC-CLEAR or MIC-ONLY PEM message), it is necessary 229 to generate and transmit a message DEK from which the MAC key can be 230 derived. 232 When symmetric key management is employed with this MIC algorithm, 233 the symmetrically encrypted MAC is represented in a "Key-Info:" 234 header field as a contiguous string of 16 ASCII hexadecimal digits 235 (corresponding to a 64-bit MAC). 237 To avoid any potential ambiguity regarding the ordering of the octets 238 of a MAC that is input as a data value to another encryption process 239 (e.g., RSAEncryption), the following holds true. The first (or 240 left-most displayed, if one thinks in terms of a MAC's "print" 241 representation) octet of the MAC, when considered as an RSA data 242 value, has numerical weight 2**56. The last (or right-most 243 displayed) octet has numerical weight 2**0. 245 Use of MAC is strongly discouraged for messages sent to more than a 246 single recipient. Also, use of MAC does not provide non-repudiation 247 of origin, even when asymmetric key management is employed. The 248 reason for these statements is that the use of MAC fails to prevent 249 recipients of a message from tampering with the message in a manner 250 which preserves the message's appearance as an authentic message from 251 the original sender. In other words, use of MAC on mail provides 252 source authentication at the granularity of membership in the 253 message's authorized address list (plus the sender) rather than at a 254 finer (and more desirable) granularity authenticating only the 255 individual sender. 257 2.2 RSA-MD2 Message Digest Algorithm 259 The RSA-MD2 message digest is computed using the algorithm defined in 260 RFC 1319 [11] (2). The character string "RSA-MD2" within an 261 encapsulated PEM header field indicates the use of this algorithm. 262 Also, as defined in RFC 1319, the ASN.1 object identifier 264 md2 OBJECT IDENTIFIER ::= { 265 iso(1) member-body(2) US(840) rsadsi(113549) 266 digestAlgorithm(2) 2 267 } 269 identifies this algorithm. When this object identifier is used with 270 the ASN.1 type AlgorithmIdentifier, the parameters component of that 271 type is the ASN.1 type NULL. 273 The RSA-MD2 message digest algorithm accepts as input a message of 274 any length and produces as output a 16-octet quantity. When 275 symmetric key management is employed, an RSA-MD2 MIC is encrypted by 276 splitting the MIC into two 8-octet halves, independently encrypting 277 each half, and concatenating the results. 279 _______________ 280 (2) An error has been identified in RFC 1319. The statement in 281 the text of Section 3.2 which reads "Set C[j] to S[c xor L]" 282 should read "Set C[j] to S[c xor L] xor C[j]". Note that the C 283 source code in the appendix of RFC 1319 is correct. 285 When symmetric key management is employed with this MIC algorithm, 286 the symmetrically encrypted MD2 message digest is represented in a 287 the fourth argument of a "Key-Info:" header field as a contiguous 288 string of 32 ASCII hexadecimal digits (corresponding to a 128-bit MD2 289 message digest). 291 To avoid any potential ambiguity regarding the ordering of the octets 292 of an MD2 message digest that is input as a data value to another 293 encryption process (e.g., RSAEncryption), the following holds true. 294 The first (or left-most displayed, if one thinks in terms of a 295 digest's "print" representation) octet of the digest (i.e., digest[0] 296 as specified in RFC 1319), when considered as an RSA data value, has 297 numerical weight 2**120. The last (or right-most displayed) octet 298 (i.e., digest[15] as specified in RFC 1319) has numerical weight 299 2**0. 301 This algorithm may be used as a MIC algorithm whenever a message is 302 addressed to multiple recipients as well as to a single recipient. 303 The use of this algorithm in conjunction with asymmetric key 304 management does provide for non-repudiation of origin. 306 2.3 RSA-MD5 Message Digest Algorithm 308 The RSA-MD5 message digest is computed using the algorithm defined in 309 RFC 1321 [12]. The character string "RSA-MD5" within an encapsulated 310 PEM header field indicates the use of this algorithm. Also, as 311 defined in RFC 1321, the object identifier 313 md5 OBJECT IDENTIFIER ::= { 314 iso(1) member-body(2) US(840) rsadsi(113549) 315 digestAlgorithm(2) 5 316 } 318 identifies this algorithm. When this object identifier is used with 319 the ASN.1 type AlgorithmIdentifier, the parameters component of that 320 type is the ASN.1 type NULL. 322 The RSA-MD5 message digest algorithm accepts as input a message of 323 any length and produces as output a 16-octet quantity. When 324 symmetric key management is employed, an RSA-MD5 MIC is encrypted by 325 splitting the MIC into two 8-octet halves, independently encrypting 326 each half, and concatenating the results. 328 When symmetric key management is employed with this MIC algorithm, 329 the symmetrically encrypted MD5 message digest is represented in the 330 fourth argument of a "Key-Info:" header field as a contiguous string 331 of 32 ASCII hexadecimal digits (corresponding to a 128-bit MD5 332 message digest). 334 To avoid any potential ambiguity regarding the ordering of the octets 335 of a MD5 message digest that is input as an RSA data value to the RSA 336 encryption process, the following holds true. The first (or left- 337 most displayed, if one thinks in terms of a digest's "print" 338 representation) octet of the digest (i.e., the low-order octet of A 339 as specified in RFC 1321), when considered as an RSA data value, has 340 numerical weight 2**120. The last (or right-most displayed) octet 341 (i.e., the high-order octet of D as specified in RFC 1321) has 342 numerical weight 2**0. 344 This algorithm may be used as a MIC algorithm whenever a message is 345 addressed to multiple recipients as well as to a single recipient. 346 The use of this algorithm in conjunction with asymmetric key 347 management does provide for non-repudiation of origin. 349 3 Symmetric Key Management Algorithms 351 This section identifies the alternative algorithms and modes that 352 shall be used when symmetric key management is employed, to encrypt 353 data encryption keys (DEKs) and message integrity check (MIC) values. 354 Character string identifiers are assigned for incorporation in 355 encapsulated "Key-Info:" header fields to indicate the choice of 356 algorithm employed. 358 All alternatives presently defined in this category correspond to 359 different usage modes of the DES algorithm, rather than to other 360 algorithms. 362 When symmetric key management is employed, the symmetrically 363 encrypted DEK and MIC, carried in the third and fourth arguments of a 364 "Key-Info:" header field, respectively, are each represented as a 365 string of contiguous ASCII hexadecimal digits. The manner in which 366 to use the following symmetric encryption algorithms and the length 367 of the symmetrically encrypted DEK and MIC may vary depending on the 368 length of the underlying DEK and MIC. Section 1, Message Encryption 369 Algorithms, and Section 2, Message Integrity Check Algorithms, 370 provide information on the proper manner in which a DEK and MIC, 371 respectively, are symmetrically encrypted when the size of the DEK or 372 MIC is not equal to the symmetric encryption algorithm's input block 373 size. These sections also provide information on the proper format 374 and length of the symmetrically encrypted DEK and MIC, respectively. 376 3.1 DES in ECB Mode (DES-ECB) 378 The DES algorithm in Electronic Codebook (ECB) mode [1][3] is used 379 for DEK and MIC encryption when symmetric key management is employed. 380 The character string "DES-ECB" within an encapsulated PEM header 381 field indicates use of this algorithm/mode combination. 383 A compliant PEM implementation supporting symmetric key management 384 shall support this algorithm/mode combination. 386 3.2 DES in EDE Mode (DES-EDE) 388 The DES algorithm in Encrypt-Decrypt-Encrypt (EDE) multiple 389 encryption mode, as defined by ANSI X9.17 [6] for encryption and 390 decryption with pairs of 64-bit keys, may be used for DEK and MIC 391 encryption when symmetric key management is employed. The character 392 string "DES-EDE" within an encapsulated a PEM header field indicates 393 use of this algorithm/mode combination. 395 A compliant PEM implementation supporting symmetric key management 396 may optionally support this algorithm/mode combination. 398 4 Asymmetric Key Management Algorithms 400 This section identifies the alternative asymmetric keys and the 401 alternative asymmetric key management algorithms with which those 402 keys shall be used, namely the asymmetric encryption algorithms with 403 which DEKs and MICs are encrypted, and the asymmetric signature 404 algorithms with which certificates and certificate revocation lists 405 (CRLs) are signed. 407 4.1 Asymmetric Keys 409 This section describes the asymmetric keys that shall be used with 410 the asymmetric encryption algorithms and the signature algorithms 411 described later. ASN.1 object identifiers are identified for 412 incorporation in a public-key certificate to identify the 413 algorithm(s) with which the accompanying public key is to be 414 employed. 416 4.1.1 RSA Keys 418 An RSA asymmetric key pair is comprised of matching public and 419 private keys. 421 An RSA public key consists of an encryption exponent e and an 422 arithmetic modulus n, which are both public quantities typically 423 carried in a public-key certificate. For the value of e, Annex C to 424 X.509 suggests the use of Fermat's Number F4 (65537 decimal, or 425 1+2**16) as a value "common to the whole environment in order to 426 reduce transmission capacity and complexity of transformation", i.e., 427 the value can be transmitted as 3 octets and at most seventeen (17) 428 multiplications are required to effect exponentiation. As an 429 alternative, the number three (3) can be employed as the value for e, 430 requiring even less octets for transmission and yielding even faster 431 exponentiation. For purposes of PEM, the value of e shall be either 432 F4 or the number three (3). The use of the number three (3) for the 433 value of e is encouraged, to permit rapid certificate validation. 435 An RSA private key consists of a decryption exponent d, which should 436 be kept secret, and the arithmetic modulus n. Other values may be 437 stored with a private key to facilitate efficient private key 438 operations (see PKCS #1 [13]). 440 For purposes of PEM, the modulus n may vary in size from 508 to 1024 441 bits. 443 Two ASN.1 object identifiers have been defined to identify RSA public 444 keys. In Annex H of X.509 [8], the object identifier 446 rsa OBJECT IDENTIFIER ::= { 447 joint-iso-ccitt(2) ds(5) algorithm(8) 448 encryptionAlgorithm(1) 1 449 } 451 is defined to identify an RSA public key. A single parameter, 452 KeySize, the length of the public key modulus in bits, is defined for 453 use in conjunction with this object identifier. When this object 454 identifier is used with the ASN.1 type AlgorithmIdentifier, the 455 parameters component of that type is the number of bits in the 456 modulus, ASN.1 encoded as an INTEGER. 458 Alternatively, in PKCS #1 [13], the ASN.1 object identifier 460 rsaEncryption OBJECT IDENTIFIER ::= { 461 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 462 pkcs-1(1) 1 463 } 465 is defined to identify both an RSA public key and the RSAEncryption 466 process. There are no parameters defined in conjunction with this 467 object identifier, hence, when it is used with the ASN.1 type 468 AlgorithmIdentifier, the parameters component of that type is the 469 ASN.1 type NULL. 471 A compliant PEM implementation may optionally generate an RSA 472 public-key certificate that identifies the enclosed RSA public key 473 (within the SubjectPublicKeyInformation component) with either the 474 "rsa" or the "rsaEncryption" object identifier. Use of the "rsa" 475 object identifier is encouraged, since it is, in some sense, more 476 generic in its identification of a key, without indicating how the 477 key will be used. However, to facilitate interoperability, a 478 compliant PEM implementation shall accept RSA public-key 479 certificates that identify the enclosed RSA public key with either 480 the "rsa" or the "rsaEncryption" object identifier. In all cases, 481 an RSA public key identified in an RSA public-key certificate with 482 either the "rsa" or "rsaEncryption" object identifier, shall be used 483 according to the procedures defined below for asymmetric encryption 484 algorithms and asymmetric signature algorithms. 486 4.2 Asymmetric Encryption Algorithms 488 This section identifies the alternative algorithms that shall be used 489 when asymmetric key management is employed, to encrypt DEKs and MICs. 490 Character string identifiers are assigned for incorporation in "MIC- 491 Info:" and "Key-Info:" header fields to indicate the choice of 492 algorithm employed. 494 Only one alternative is presently defined in this category. 496 4.2.1 RSAEncryption 498 The RSAEncryption public-key encryption algorithm, defined in PKCS #1 499 [13], is used for DEK and MIC encryption when asymmetric key 500 management is employed. The character string "RSA" within a "MIC- 501 Info:" or "Key-Info:" header field indicates the use of this 502 algorithm. 504 All PEM implementations supporting asymmetric key management shall 505 support this algorithm. 507 As described in PKCS #1, all quantities input as data values to the 508 RSAEncryption process shall be properly justified and padded to the 509 length of the modulus prior to the encryption process. In general, 510 an RSAEncryption input value is formed by concatenating a leading 511 NULL octet, a block type BT, a padding string PS, a NULL octet, and 512 the data quantity D, that is, 514 RSA input value = 0x00 || BT || PS || 0x00 || D. 516 To prepare a DEK for RSAEncryption, the PKCS #1 "block type 02" 517 encryption-block formatting scheme is employed. The block type BT is 518 a single octet containing the value 0x02 and the padding string PS is 519 one or more octets (enough octets to make the length of the complete 520 RSA input value equal to the length of the modulus) each containing a 521 pseudorandomly generated, non-zero value. For multiple recipient 522 messages, a different, pseudorandom padding string should be used for 523 each recipient. The data quantity D is the DEK itself, which is 524 right-justified within the RSA input such that the last (or rightmost 525 displayed, if one thinks in terms of the "print" representation) 526 octet of the DEK is aligned with the right-most, or least- 527 significant, octet of the RSA input. Proceeding to the left, each of 528 the remaining octets of the DEK, up through the first (or left-most 529 displayed) octet, are each aligned in the next more significant octet 530 of the RSA input. 532 To prepare a MIC for RSAEncryption, the PKCS #1 "block type 01" 533 encryption-block formatting scheme is employed. The block type BT is 534 a single octet containing the value 0x01 and the padding string PS is 535 one or more octets (enough octets to make the length of the complete 536 RSA input value equal to the length of the modulus) each containing 537 the value 0xFF. The data quantity D is comprised of the MIC and the 538 MIC algorithm identifier which are ASN.1 encoded as the following 539 sequence. 541 SEQUENCE { 542 digestAlgorithm AlgorithmIdentifier, 543 digest OCTET STRING 544 } 546 The ASN.1 type AlgorithmIdentifier is defined in X.509 as follows. 548 AlgorithmIdentifier ::= SEQUENCE { 549 algorithm OBJECT IDENTIFIER, 550 parameters ANY DEFINED BY algorithm OPTIONAL 551 } 553 An RSA input block is encrypted using the RSA algorithm with the 554 first (or left-most) octet taken as the most significant octet, and 555 the last (or right-most) octet taken as the least significant octet. 556 The resulting RSA output block is interpreted in a similar manner. 558 When RSAEncryption is used to encrypt a DEK, the second argument in a 559 "MIC-Info:" header field, an asymmetrically encrypted DEK, is 560 represented using the printable encoding technique defined in Section 561 4.3.2.4 of RFC [1113ID]. 563 When RSAEncryption is used to sign a MIC, the third argument in a 564 "MIC-Info:" header field, an asymmetrically signed MIC, is 565 represented using the printable encoding technique defined in Section 566 4.3.2.4 of RFC [1113ID]. 568 4.3 Asymmetric Signature Algorithms 570 This section identifies the alternative algorithms which shall be 571 used to asymmetrically sign certificates and certificate revocation 572 lists (CRLs) in accordance with the SIGNED macro defined in Annex G 573 of X.509. ASN.1 object identifiers are identified for incorporation 574 in certificates and CRLs to indicate the choice of algorithm 575 employed. 577 Only one alternative is presently defined in this category. 579 4.3.1 md2WithRSAEncryption 581 The md2WithRSAEncryption signature algorithm is used to sign 582 certificates and CRLs. The algorithm is defined in PKCS #1 [13]. It 583 combines the RSA-MD2 message digest algorithm described here in 584 Section 2.2 with the RSAEncryption asymmetric encryption algorithm 585 described here in Section 4.2.1. As defined in PKCS #1, the ASN.1 586 object identifier 588 md2WithRSAEncryption OBJECT IDENTIFIER ::= { 589 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 590 pkcs-1(1) 2 591 } 593 identifies this algorithm. When this object identifier is used with 594 the ASN.1 type AlgorithmIdentifier, the parameters component of that 595 type is the ASN.1 type NULL. 597 There is some ambiguity in X.509 regarding the definition of the 598 SIGNED macro and, in particular, the representation of a signature in 599 a certificate or a CRL. The interpretation selected for PEM requires 600 that the data to be signed (in our case, an MD2 message digest) is 601 first ASN.1 encoded as an OCTET STRING and the result is encrypted 602 (in our case, using RSAEncryption) to form the signed quantity, which 603 is then ASN.1 encoded as a BIT STRING. 605 5 Descriptive Grammar 607 ; Addendum to PEM BNF representation, using RFC 822 notation 608 ; Provides specification for official PEM cryptographic algorithms, 609 ; modes, identifiers and formats. 611 ; Imports and from RFC [1113ID] 613 ::= "DES-CBC" 614 ::= "DES-EDE" / "DES-ECB" / "RSA" 615 ::= "RSA" 616 ::= "MAC" / "RSA-MD2" / "RSA-MD5" 618 ::= 619 ::= 620 ::= 622 ::= / 623 ::= 624 ::= 626 ::= / / 627 ::= 628 ::= 2*2 629 ::= 2*2 631 ::= 632 ::= 634 ::= 635 ::= 637 ::= 16*16 639 References: 641 [1] Federal Information Processing Standards Publication (FIPS 642 PUB) 46-1, Data Encryption Standard, Reaffirmed 1988 January 643 22 (supersedes FIPS PUB 46, 1977 January 15). 645 [2] ANSI X3.92-1981, American National Standard Data Encryption 646 Algorithm, American National Standards Institute, Approved 30 647 December 1980. 649 [3] Federal Information Processing Standards Publication (FIPS 650 PUB) 81, DES Modes of Operation, 1980 December 2. 652 [4] ANSI X3.106-1983, American National Standard for Information 653 Systems - Data Encryption Algorithm - Modes of Operation, 654 American National Standards Institute, Approved 16 May 1983. 656 [5] ISO 8372, Information Processing Systems: Data Encipherment: 657 Modes of Operation of a 64-bit Block Cipher. 659 [6] ANSI X9.17-1985, American National Standard, Financial 660 Institution Key Management (Wholesale), American Bankers 661 Association, April 4, 1985, Section 7.2. 663 [7] Voydock, V. L. and Kent, S. T., "Security Mechanisms in High- 664 Level Network Protocols", ACM Computing Surveys, Vol. 15, No. 665 2, June 1983, pp. 135-171. 667 [8] CCITT Recommendation X.509, "The Directory - Authentication 668 Framework", November 1988, (Developed in collaboration, and 669 technically aligned, with ISO 9594-8). 671 [9] Federal Information Processing Standards Publication (FIPS 672 PUB) 113, Computer Data Authentication, 1985 May 30. 674 [10] NIST Special Publication 500-183, Stable Implementation 675 Agreements for Open Systems Interconnection Protocols, Version 676 5, Edition 1, Part 11, December 1991. 678 [11] Kaliski, B., The MD2 Message-Digest Algorithm (RFC 1319), 679 April 1992. 681 [12] Rivest, R., The MD5 Message-Digest Algorithm (RFC 1321), April 682 1992. 684 [13] PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data 685 Security, Inc., June 3, 1991. 687 [14] Jueneman, R.R., S.M. Matyas and C.M. Meyer, "Message 688 Authentication With Manipulation Detection Codes", Proceedings 689 1983 IEEE Symposium on Security and Privacy, April 1983, 690 Oakland, CA, IEEE Computer Society, 1983, pp. 33-54. 692 Author's Address: 694 David Balenson 695 Trusted Information Systems 696 3060 Washington Road 697 Glenwood, Maryland 21738 699 Phone: 301-854-6889 701 EMail: balenson@tis.com