idnits 2.17.1 draft-balenson-secure-email-00.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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 61 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 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.) ** The abstract seems to contain references ([5], [4,5], [10]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 30, 1996) is 10063 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? '4' on line 370 looks like a reference -- Missing reference section? '5' on line 375 looks like a reference -- Missing reference section? '10' on line 394 looks like a reference -- Missing reference section? '9' on line 390 looks like a reference -- Missing reference section? '1' on line 360 looks like a reference -- Missing reference section? '7' on line 382 looks like a reference -- Missing reference section? '2' on line 363 looks like a reference -- Missing reference section? '0' on line 193 looks like a reference -- Missing reference section? '3' on line 366 looks like a reference -- Missing reference section? '6' on line 379 looks like a reference -- Missing reference section? '8' on line 386 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Balenson (TIS) 2 J. Cook (TIS) 3 R. Housley (SPYRUS) 4 September 30, 1996 6 Internet Secure Electronic Mail: 7 Algorithms, Modes, and Identifiers for FORTEZZA Cryptography 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 valid for a maximum of six months and may be 17 updated, replaced, or obsoleted by other documents at any time. It 18 is inappropriate to use Internet-Drafts as reference material or to 19 cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in one of the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This document provides definitions, formats, references, and 30 citations for cryptographic algorithms, usage modes, and associated 31 identifiers and parameters used in support of the FORTEZZA suite of 32 cryptographic algorithms with Privacy Enhanced Mail (PEM) [4,5] and 33 MIME Object Security Services (MOSS) [10]. This document is 34 organized in the same manner as RFC 1423 [5]. It is divided into 35 four primary sections, dealing with message encryption algorithms, 36 message integrity check algorithms, symmetric key management 37 algorithms, and asymmetric key management algorithms (including both 38 asymmetric encryption and asymmetric signature algorithms). 40 Acknowledgments 42 The authors would like to thank Mark Feldman, Jim Galvin, and Sandy 43 Murphy from TIS for their contributions to this document. 45 Table of Contents 46 1. Message Encryption Algorithms ....................... 2 47 1.1 SKIPJACK in CBC Mode (SKIPJACK-CBC) ................ 2 48 2. Message Integrity Check Algorithms .................. 3 49 2.1 Secure Hash Algorithm (SHA-1) ...................... 3 50 3. Symmetric Key Management Algorithms ................. 4 51 4. Asymmetric Key Management Algorithms ................ 4 52 4.1 Asymmetric Keys .................................... 4 53 4.1.1 KEA-DSA Keys ..................................... 4 54 4.2 Asymmetric Encryption Algorithms ................... 5 55 4.2.1 Key Exchange Algorithm (KEA) ..................... 6 56 4.3 Asymmetric Signature Algorithms .................... 7 57 4.3.1 Digital Signature Algorithm (DSA) ................ 7 58 5. Descriptive Grammar ................................. 8 59 References .............................................. 8 60 Patent Statement ........................................ 9 61 Security Considerations ................................ 10 62 Authors' Addresses ..................................... 10 64 1 Message Encryption Algorithms 66 This section identifies the alternative message encryption algorithms 67 and modes that shall be used to encrypt message text. Character 68 string identifiers are assigned and any parameters required by the 69 message encryption algorithm are defined for incorporation in a 70 "DEK-Info:" header field. 72 Only one alternative is currently defined in this category. 74 1.1 SKIPJACK in CBC Mode (SKIPJACK-CBC) 76 Message text is encrypted using the SKIPJACK algorithm in the Cipher 77 Block Chaining (CBC) mode of operation. SKIPJACK is a symmetric 64- 78 bit block cipher designed to the requirements of the Escrowed 79 Encryption Standard (EES) [9]. It uses an 80-bit cryptographic key. 80 The FORTEZZA PCMCIA crypto card incorporates a "Capstone" chip which 81 implements the SKIPJACK algorithm. Further details of the SKIPJACK 82 algorithm are beyond the scope of this document. 84 The SKIPJACK CBC mode of operation of is similar to that provided in 85 ISO IS 8372 [1]. The character string "SKIPJACK-CBC" within the 86 "DEK-Info:" header field indicates the use of this algorithm/mode 87 combination. 89 The input to the SKIPJACK CBC encryption process shall be padded to a 90 multiple of 8 octets, in the following manner. Let n be the length 91 in octets of the input. Pad the input by appending 8-(n mod 8) 92 octets to the end of the message, each having the value 8-(n mod 8), 93 the number of octets being added. In hexadecimal, the possible 94 paddings are: 01, 0202, 030303, 04040404, 0505050505, 060606060606, 95 07070707070707, and 0808080808080808. All input is padded with 1 to 96 8 octets to produce a multiple of 8 octets in length. The padding 97 can be removed unambiguously after decryption. 99 The SKIPJACK CBC encryption process requires a 80-bit cryptographic 100 key. A new, pseudorandom key is generated for each ENCRYPTED 101 message. 103 The SKIPJACK CBC encryption process also requires a 192-bit 104 Initialization Vector (IV). A new, pseudorandom IV shall be 105 generated for each ENCRYPTED message. The IV is transmitted with the 106 message within the "DEK-Info:" header field. 108 When this algorithm/mode combination is used for message text 109 encryption, the "DEK-Info:" header field carries exactly two 110 arguments. The first argument identifies the SKIPJACK CBC 111 algorithm/mode using the character string defined above. The second 112 argument contains the IV, represented as a contiguous string of 48 113 ASCII hexadecimal digits. 115 No symmetric key management is employed with this algorithm/mode. 117 2 Message Integrity Check Algorithms 119 This section identifies the alternative algorithms that shall be used 120 to compute Message Integrity Check (MIC) values for messages. 121 Character string identifiers and ASN.1 object identifiers are 122 assigned for incorporation in "MIC-Info:" header fields to indicate 123 the choice of MIC algorithm employed. 125 Only one alternative is defined in this category. 127 2.1 Secure Hash Algorithm (SHA-1) 129 The Secure Hash Algorithm (SHA-1) message digest is computed using 130 the algorithm defined in FIPS 180-1 [7]. The character string "SHA- 131 1" within a "MIC-Info:" header field indicates the use of this 132 algorithm. 134 As specified in the SDNS Message Security Protocol (MSP) [2], the 135 ASN.1 object identifier 137 id-mosaicUpdatedIntegrityAlgorithm OBJECT IDENTIFIER ::= { 138 joint-iso-ccitt (2) country (16) us (840) organization (1) 139 u.s.government (101) dod (2) 1 1 21) 141 } 143 identifies the SHA-1 algorithm. When this object identifier is used 144 with the ASN.1 type AlgorithmIdentifier, the parameters component of 145 that type is the ASN.1 type NULL. 147 The SHA-1 accepts as input a message of any length and produces as 148 output a 20-octet (160-bit) quantity. 150 3 Symmetric Key Management Algorithms 152 There are no symmetric key management algorithms for FORTEZZA. 154 4 Asymmetric Key Management Algorithms 156 This section identifies the alternative asymmetric keys and the 157 alternative asymmetric key management algorithms with which those 158 keys shall be used, namely the asymmetric encryption algorithms with 159 which DEKs and MICs are encrypted, and the asymmetric signature 160 algorithms with which certificates and certificate revocation lists 161 (CRLs) are signed. 163 4.1 Asymmetric Keys 165 This section describes the asymmetric keys that shall be used with 166 the asymmetric encryption algorithms and the signature algorithms 167 described later. ASN.1 object identifiers are identified for 168 incorporation in a public-key certificate to identify the 169 algorithm(s) with which the accompanying public keys are to be 170 employed. 172 4.1.1 KEA-DSA Keys 174 A KEA-DSA set of asymmetric key pairs is comprised of two sets of 175 matching public and private keys. The first set is a Key Exchange 176 Algorithm (KEA) public/private key pair and the second set is a 177 Digital Signature Algorithm (DSA) public/private key pair. 179 As specified in SDNS Message Security Protocol (MSP) [2], the 180 following ASN.1 object identifier identifies KEA-DSA public key 181 pairs: 183 id-mosaicKMandUpdSigAlgorithms OBJECT IDENTIFIER ::= { 184 joint-iso-ccitt (2) country (16) us (840) organization (1) 185 u.s.government (101) dod (2) 1 1 20) 186 } 188 When this object identifier is used with the ASN.1 type 189 AlgorithmIdentifier, the parameters component of that type is the 190 ASN.1 type Kea-Dss-Parms, which is specified in [2] as: 192 Kea-Dss-Parms ::= CHOICE { 193 [0] Different-Parms, 194 [1] Common-Parms 195 } 197 Different-Parms ::= SEQUENCE { 198 Kea-Parms, 199 Dss-Parms 200 } 202 Kea-Parms ::= SEQUENCE { 203 p OCTET STRING, 204 q OCTET STRING, 205 g OCTET STRING 206 } 208 Dss-Parms ::= SEQUENCE { 209 p OCTET STRING, 210 q OCTET STRING, 211 g OCTET STRING 212 } 214 Common-Parms ::= SEQUENCE { 215 p OCTET STRING, 216 q OCTET STRING, 217 g OCTET STRING 218 } 220 The format of the KEA-DSA public key pair carried in a FORTEZZA 221 public-key certificate is described in detail in the FORTEZZA 222 Application Implementors Guide [3]. 224 4.2 Asymmetric Encryption Algorithms 226 This section identifies the alternative algorithms that shall be used 227 when asymmetric key management is employed to encrypt DEKs and sign 228 MICs. Character string identifiers are assigned for incorporation in 229 "Key-Info:" and "DEK-Info:" header fields to indicate the choice of 230 algorithm employed. 232 Only one alternative for each of asymmetric encryption and asymmetric 233 signatures is presently defined in this category. 235 4.2.1 Key Exchange Algorithm (KEA) 237 The asymmetric Key Exchange Algorithm (KEA) is used for DEK exchange. 238 The character string "KEA-SJ" within a "Key-Info:" header field 239 indicates the use of this algorithm. 241 The only type of DEK that undergoes KEA processing is a DEK generated 242 for the SKIPJACK algorithm. The KEA process employs a 128-octet 243 (1024-bit) random value, Ra, to create a token encrypting key (TEK). 244 The TEK is then used to "wrap" (encrypt) the DEK. 246 When KEA is used, the second argument in a "Key-Info:" header field 247 is represented using the "base 64" printable encoding technique 248 defined in Section 4.3.2.4 of RFC 1421 [4]. This second argument is 249 a printably encoded ASN.1 sequence of three items: (a) the TEK- 250 wrapped DEK (12 octets), (b) the random Ra value (128 octets), and 251 (c) the KEA public key Y (128 octets) used to generate the TEK. In 252 particular, the ASN.1 sequence is defined as: 254 SEQUENCE { 255 wrappedDEK OCTET STRING -- 12 octets 256 ra OCTET STRING -- 128 octets 257 y OCTET STRING -- 128 octets 258 } 260 The Ra and Y values are needed by the recipient to generate the TEK 261 needed to decrypt the DEK (the value of the "random" value Rb is 262 always one). 264 Section 4.2.1 of RFC 1423 [5] indicates that, for RSA Encryption [6], 265 only the printably encoded RSA-encrypted DEK is included in the 266 second argument of the "Key-Info:" header field. This would not be a 267 viable solution for FORTEZZA, as the recipient must obtain the random 268 value Ra and the KEA public key Y of the originator before the DEK 269 can be decrypted (unwrapped). The KEA public key could be extracted 270 from the originator's certificate if the message was signed, but for 271 encrypted-only messages the originator is not identified and 272 therefore the KEA public key of the originator must be provided to 273 permit the recipient to decrypt the DEK. 275 The appearance of the KEA public key Y of the originator within a 276 "Key-Info:" header field associated with an encrypted MOSS body part 277 is required for message decryption, but Y can also be used to infer 278 the identity of the originator and thus can provide a form of 279 authentication. The Y value is the minimum amount of originator 280 information required and thus provides the weakest implication 281 possible as to the identity of the originator. This information 282 shall not be used by MOSS to provide authentication, because 283 confidentiality is the only security service provided by MOSS for 284 encrypted body parts. Authentication is provided by MOSS for signed 285 body parts only. 287 4.3 Asymmetric Signature Algorithms 289 A description of the algorithms used to asymmetrically sign 290 certificates and certificate revocation lists (CRLs) for FORTEZZA is 291 outside the scope of this document. 293 This section identifies the alternative algorithms which shall be 294 used to asymmetrically sign messages, public-key certificates and 295 certificate revocation lists (CRLs). An ASN.1 object identifier is 296 identified for incorporation in certificates and CRLs to indicate the 297 choice of algorithm employed. 299 Only one alternative is presently defined in this category. 301 4.3.1 Digital Signature Algorithm (DSA) 303 The Digital Signature Algorithm (DSA) defined in FIPS 186 [8], is 304 used for digital signatures. The character string "DSA" within a 305 "MIC-Info:" header field indicates the use of this algorithm. 307 The only type of MIC value that undergoes DSA encryption is a 20- 308 octet MIC generated by the SHA-1 algorithm. The result is a 40-octet 309 signed MIC. 311 As specified in the SDNS Message Security Protocol (MSP) [2], the 312 ASN.1 object identifier 314 id-mosaicUpdatedSigAlgorithm OBJECT IDENTIFIER ::= { 315 joint-iso-ccitt (2) country (16) us (840) organization (1) 316 u.s.government (101) dod (2) 1 1 19) 317 } 319 identifies the combination of the DSA and SHA-1 algorithms. When 320 this object identifier is used with the ASN.1 type 321 AlgorithmIdentifier, the parameters component of that type is the 322 ASN.1 type Dss-Parms, which is specified in [2] as: 324 Dss-Parms ::= SEQUENCE { 325 p OCTET STRING, 326 q OCTET STRING, 327 g OCTET STRING 328 } 330 When DSA encryption is used to sign a MIC, the third argument in a 331 "MIC-Info:" header field, an asymmetrically signed MIC, is 332 represented using the printable encoding technique defined in Section 333 4.3.2.4 of RFC 1421." 335 5 Descriptive Grammar 337 ; Addendum to PEM BNF representation, using RFC 822 notation 338 ; Provides specification for FORTEZZA cryptographic algorithms, 339 ; modes, identifiers and formats. 341 ; Imports and from RFC 1421 343 ::= "SKIPJACK-CBC" 344 ::= "KEA-SJ" 345 ::= "DSA" 346 ::= "SHA-1" 348 ::= 349 ::= 350 ::= 352 ::= 354 ::= 356 ::= 48*48 358 References: 360 [1] ISO 8372, Information Processing Systems: Data Encipherment: 361 Modes of Operation of a 64-bit Block Cipher. 363 [2] "SDNS Message Security Protocol (MSP)", Specification SDN.701, 364 Revision 4.0, 1996-01-16. 366 [3] "FORTEZZA Application Implementors Guide for the FORTEZZA Crypto 367 Card (Production Version)", Document #PD4002103-1.01, SPYRUS, 368 1995. 370 [4] Linn, J., "Privacy Enhancement for Internet Electronic Mail: 372 Part I: Message Encryption and Authentication Procedures", RFC 373 1421, February, 1993. 375 [5] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: 376 Part III: Algorithms, Modes, and Identifiers", RFC 1423, 377 February 1993. 379 [6] PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data 380 Security, Inc., June 3, 1991. 382 [7] Federal Information Processing Standard (FIPS) 180-1, Secure 383 Hash Standard, National Institute of Standards and Technology, 384 May 31, 1994. 386 [8] Federal Information Processing Standard (FIPS) 186, Digital 387 Signature Standard, National Institute of Standards and 388 Technology, May 19, 1994. 390 [9] Federal Information Processing Standard (FIPS) 185, Escrowed 391 Encryption Standard, National Institute of Standards and 392 Technology, February 9, 1994. 394 [10] S. Crocker, N. Freed, J, Galvin, and S. Murphy, MIME Object 395 Security Services, RFC 1848, October 1995. 397 Patent Statement 399 FORTEZZA cryptography relies on the use of patented public key 400 technology, namely DSA. The Internet Standards Process as defined in 401 RFC 1310 requires a written statement from the Patent holder that a 402 license will be made available to applicants under reasonable terms 403 and conditions prior to approving a specification as a Proposed, 404 Draft or Internet Standard. 406 A patent statement for DSA follows. This statement has been supplied 407 by the patent holder, not the authors of this profile. 409 Digital Signature Algorithm (DSA) 411 The U.S. Government holds patent 5,231,668 on the Digital Signature 412 Algorithm (DSA), which has been incorporated into Federal Information 413 Processing Standard (FIPS) 186. The patent was issued on July 27, 414 1993. 416 The National Institute of Standards and Technology (NIST) has a long 417 tradition of supplying U.S. Government-developed techniques 418 committees and working groups for inclusion into standards on a 419 royalty-free basis. NIST has made the DSA patent available royalty- 420 free to users worldwide. 422 Regarding patent infringement, FIPS 186 summarizes our position; the 423 Department of Commerce is not aware of any patents that would be 424 infringed by the DSA. Questions regarding this matter may be 425 directed to the Deputy Chief Counsel for NIST. 427 Security Considerations 429 This documents defines the use of FORTEZZA cryptographic algorithms 430 with secure Internet electronic mail. 432 Authors' Addresses: 434 David Balenson 435 Trusted Information Systems 436 3060 Washington Road 437 Glenwood, Maryland 21738 USA 438 EMail: balenson@tis.com 440 Jeff Cook 441 Trusted Information Systems 442 11340 W. Olympic Blvd. 443 Los Angeles, California 90064 USA 444 EMail: jvc@tis.com 446 Russell Housley 447 SPYRUS 448 PO Box 1198 449 Herndon, VA 22070 USA 450 EMail: housley@spyrus.com