idnits 2.17.1 draft-ietf-smime-cmskea-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 553 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 are 29 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([CMS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 41: '...ument, the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 47: '...es as indicated by the MUST, MUST NOT,...' RFC 2119 keyword, line 48: '...SHOULD and MAY terms. The KEA and SKI...' RFC 2119 keyword, line 54: '...pes. Compliant software MUST meet the...' RFC 2119 keyword, line 56: '...cryption process MUST be padded to a m...' (85 more instances...) 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 (8 May 2000) is 8726 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? 'CMS' on line 488 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 497 looks like a reference -- Missing reference section? 'SJ-KEA' on line 500 looks like a reference -- Missing reference section? 'KEA' on line 490 looks like a reference -- Missing reference section? 'MSG' on line 495 looks like a reference -- Missing reference section? 'INFO' on line 493 looks like a reference -- Missing reference section? 'USSUP1' on line 503 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT John Pawling 2 draft-ietf-smime-cmskea-05.txt J.G. Van Dyke & Associates 3 8 May 2000 4 Expires: 8 November 2000 6 Use of the KEA and SKIPJACK Algorithms in CMS 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This document describes the conventions for using the Key Exchange 30 Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the 31 Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data 32 content types. 34 This draft is being discussed on the 'ietf-smime' mailing list. To 35 subscribe, send a message to ietf-smime-request@imc.org with the single 36 word "subscribe" in the body of the message. There is a Web site for 37 the mailing list at . 39 1. Introduction 41 Throughout this document, the terms MUST, MUST NOT, SHOULD and MAY are 42 used in capital letters. This conforms to the definitions in 43 [MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help 44 make the intent of standards track documents as clear as possible. The 45 same key words are used in this document to help implementers achieve 46 interoperability. Software that claims compliance with this document 47 MUST provide the capabilities as indicated by the MUST, MUST NOT, 48 SHOULD and MAY terms. The KEA and SKIPJACK cryptographic algorithms are 49 described in [SJ-KEA]. 51 2. Content Encryption Process 53 This section applies to the construction of both the enveloped-data and 54 encrypted-data content types. Compliant software MUST meet the 55 requirements stated in [CMS] Section 6.3, "Content-encryption Process". 56 The input to the encryption process MUST be padded to a multiple of 57 eight octets using the padding rules described in [CMS] Section 6.3. 58 The content MUST be encrypted as a single string using the SKIPJACK 59 algorithm in 64-bit Cipher Block Chaining (CBC) mode using 60 randomly-generated 8-byte Initialization Vector (IV) and 80-bit 61 SKIPJACK content-encryption key (CEK) values. 63 3. Content Decryption Process 65 This section applies to the processing of both the enveloped-data and 66 encrypted-data content types. The encryptedContent MUST be decrypted as 67 a single string using the SKIPJACK algorithm in 64-bit CBC mode. The 80- 68 bit SKIPJACK CEK and the 8-byte IV MUST be used as inputs to the SKIPJACK 69 decryption process. Following decryption, the padding MUST be removed 70 from the decrypted data. The padding rules are described in [CMS] 71 Section 6.3, "Content-encryption Process". 73 4. Enveloped-data Conventions 75 The CMS enveloped-data content type consists of an encrypted content and 76 wrapped CEKs for one or more recipients. Compliant software MUST 77 meet the requirements for constructing an enveloped-data content type 78 stated in [CMS] Section 6, "Enveloped-data Content Type". [CMS] Section 6 79 should be studied before reading this section, because this section 80 does not repeat the [CMS] text. 82 An 8-byte IV and 80-bit CEK MUST be randomly generated for each instance 83 of an enveloped-data content type as inputs to the SKIPJACK algorithm for 84 use to encrypt the content. The SKIPJACK CEK MUST only be used for 85 encrypting the content of a single instance of an enveloped-data content 86 type. 88 KEA and SKIPJACK can be used with the enveloped-data content type using 89 either of the following key management techniques defined in [CMS] 90 Section 6: 92 1) Key Agreement: The SKIPJACK CEK is uniquely wrapped for each 93 recipient using a pairwise symmetric key-encryption key (KEK) generated 94 using KEA using the originator's private KEA key, recipient's public KEA 95 key and other values. Section 4.2 provides additional details. 97 2) "Previously Distributed" Symmetric KEK: The SKIPJACK CEK is wrapped 98 using a "previously distributed" symmetric KEK (such as a Mail List Key). 99 The methods by which the symmetric KEK is generated and distributed are 100 beyond the scope of this document. Section 4.3 provides more details. 102 [CMS] Section 6 also defines the concept of the key transport key 103 management technique. The key transport technique MUST NOT be used with 104 KEA. 106 4.1. EnvelopedData Fields 108 The enveloped-data content type is Abstract Syntax Notation.1 (ASN.1) 109 encoded using the EnvelopedData syntax. The fields of the EnvelopedData 110 syntax must be populated as follows: 112 The EnvelopedData version MUST be 2. 114 If key agreement is being used, then the EnvelopedData originatorInfo 115 field SHOULD be present and SHOULD include the originator's KEA X.509 v3 116 certificate containing the KEA public key associated with the KEA private 117 key used to form each pairwise symmetric KEK used to wrap each copy of 118 the SKIPJACK CEK. The issuers' X.509 v3 certificates required to form 119 the complete certification path for the originator's KEA X.509 v3 120 certificate MAY be included in the EnvelopedData originatorInfo field. 121 Self-signed certificates SHOULD NOT be included in the EnvelopedData 122 originatorInfo field. 124 The EnvelopedData RecipientInfo CHOICE is dependent on the key management 125 technique used. Sections 4.2 and 4.3 provide more information. 127 The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm 128 algorithm field MUST be the id-fortezzaConfidentialityAlgorithm 129 object identifier (OID). The EnvelopedData encryptedContentInfo 130 contentEncryptionAlgorithm parameters field MUST include the random 8- 131 byte IV used as the input to the content encryption process. 133 The EnvelopedData unprotectedAttrs MAY be present. 135 4.2. Key Agreement 137 This section describes the conventions for using KEA and SKIPJACK with 138 the CMS enveloped-data content type to support key agreement. When key 139 agreement is used, then the RecipientInfo keyAgreeRecipientInfo CHOICE 140 MUST be used. 142 If the EnvelopedData originatorInfo field does not include the 143 originator's KEA X.509 v3 certificate, then each recipientInfos 144 KeyAgreementRecipientInfo originator field MUST include the 145 issuerAndSerialNumber CHOICE identifying the originator's KEA X.509 v3 146 certificate. If the EnvelopedData originatorInfo field includes the 147 originator's KEA X.509 v3 certificate, then each recipientInfos 148 KeyAgreementRecipientInfo originator field MUST include either the 149 subjectKeyIdentifier CHOICE containing the value from the 150 subjectKeyIdentifier extension of the originator's KEA X.509 v3 151 certificate or the issuerAndSerialNumber CHOICE identifying the 152 originator's KEA X.509 v3 certificate. To minimize the size of the 153 EnvelopedData, it is recommended that the subjectKeyIdentifier CHOICE be 154 used. 156 In some environments, the KeyAgreementRecipientInfo originator field MAY 157 include the originatorKey CHOICE. The originatorKey CHOICE SHOULD NOT be 158 used with KEA for e-mail transactions. Within a controlled security 159 architecture, a module may produce KEA key pairs for use in conjunction 160 with internal/local storage of encrypted data. In this case, there may 161 not be an X.509 certificate associated with a (possibly) short term or 162 one time use public KEA key. When originatorKey is used, then the KEA 163 public key MUST be conveyed in the publicKey BIT STRING as specified in 164 [KEA] Section 3.1.2. The originatorKey algorithm identifier MUST be the 165 id-keyExchangeAlgorithm OID. The originatorKey algorithm parameters 166 field MUST contain the KEA "domain identifier" (ASN.1 encoded as an OCTET 167 STRING) identifying the KEA algorithm parameters (i.e., p/q/g values) 168 associated with the KEA public key. [KEA] Section 3.1.1 describes the 169 method for computing the KEA domain identifier value. 171 4.2.1. SKIPJACK CEK Wrap Process 173 The SKIPJACK CEK is uniquely wrapped for each recipient of the 174 EnvelopedData using a pairwise KEK generated using the KEA 175 material of the originator and the recipient along with the 176 originator's User Keying Material (UKM) (i.e. Ra). The CMS 177 EnvelopedData syntax provides two options for wrapping the SKIPJACK 178 CEK for each recipient using a KEA-generated KEK. The "shared 179 Originator UKM" option SHOULD be used when constructing EnvelopedData 180 objects. The "unique originator UKM" option MAY be used when 181 constructing EnvelopedData objects. Compliant software MUST be capable 182 of processing EnvelopedData objects constructed using both options. 184 1) Shared Originator UKM Option: CMS provides the ability for a 185 single, shared originator's UKM to be used to generate each pairwise 186 KEK used to wrap the SKIPJACK CEK for each recipient. When using 187 the shared originator UKM option, a single RecipientInfo 188 KeyAgreeRecipientInfo structure MUST be constructed to contain the 189 wrapped SKIPJACK CEKs for all of the KEA recipients sharing the same 190 KEA parameters. The KeyAgreeRecipientInfo structure includes multiple 191 RecipientEncryptedKey fields that each contain the SKIPJACK CEK wrapped 192 for a specific recipient. 194 2) Unique Originator UKM Option: CMS also provides the ability for a 195 unique originator UKM to be used to generate each pairwise KEK used to 196 wrap the SKIPJACK CEK for each recipient. When using the unique 197 originator UKM option, a separate RecipientInfo KeyAgreeRecipientInfo 198 structure MUST be constructed for each recipient. Each 199 KeyAgreeRecipientInfo structure includes a single RecipientEncryptedKey 200 field containing the SKIPJACK CEK wrapped for the recipient. This 201 option requires more overhead than the shared UKM option because the 202 KeyAgreeRecipientInfo fields (i.e. version, originator, ukm, 203 keyEncryptionAlgorithm) must be repeated for each recipient. 205 The next two paragraphs apply to both options. 207 The KeyAgreeRecipientInfo keyEncryptionAlgorithm algorithm field MUST 208 include the id-kEAKeyEncryptionAlgorithm OID. The KeyAgreeRecipientInfo 209 keyEncryptionAlgorithm parameters field MUST contain a KeyWrapAlgorithm 210 as specified in [CMS] Appendix A, "ASN.1 Module". The algorithm field 211 of KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID indicating that 212 the FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK 213 CEK. Since the FORTEZZA 80-bit wrap function includes an integrity 214 check value, the wrapped SKIPJACK key is 96 bits long. The parameters 215 field of KeyWrapAlgorithm MUST be absent. 217 If the originator is not already an explicit recipient, then a copy of 218 the SKIPJACK CEK SHOULD be wrapped for the originator and included in 219 the EnvelopedData. This allows the originator to decrypt the contents 220 of the EnvelopedData. 222 4.2.1.1. SKIPJACK CEK Wrap Process Using A Shared Originator UKM Value 224 This section describes how a shared originator UKM value is used as an 225 input to KEA to generate each pairwise KEK used to wrap the SKIPJACK CEK 226 for each recipient. 228 When using the shared originator UKM option, a single RecipientInfo 229 KeyAgreeRecipientInfo structure MUST be constructed to contain the 230 wrapped SKIPJACK CEKs for all of the KEA recipients using the same 231 set of KEA parameters. If all recipients' KEA public keys were 232 generated using the same set of KEA parameters, then there MUST only be 233 a single RecipientInfo KeyAgreeRecipientInfo structure for all of the 234 KEA recipients. If the recipients' KEA public keys were generated 235 using different sets of KEA parameters, then multiple RecipientInfo 236 KeyAgreeRecipientInfo fields MUST be constructed because the 237 originatorIdentifierOrKey will be different for each distinct set of 238 recipients' KEA parameters. 240 A unique 128-byte originator's UKM MUST be generated for each distinct 241 set of recipients' KEA parameters. The originator's UKM MUST be placed 242 in each KeyAgreeRecipientInfo ukm OCTET STRING. 244 The originator's and recipient's KEA parameters MUST be identical to use 245 KEA to successfully generate a pairwise KEK. [KEA] describes how a KEA 246 public key is conveyed in an X.509 v3 certificate. [KEA] states that the 247 KEA parameters are not included in KEA certificates; instead, a "domain 248 identifier" is supplied in the subjectPublicKeyInfo algorithm parameters 249 field of every KEA certificate. The values of the KEA domain identifiers 250 in the originator's and recipient's KEA X.509 v3 certificates can be 251 compared to determine if the originator's and recipient's KEA parameters 252 are identical. 254 The following steps MUST be repeated for each recipient: 256 1) KEA MUST be used to generate the pairwise KEK based on the 257 originator's UKM, originator's private KEA key, recipient's 128 byte 258 public KEA key (obtained from the recipient's KEA X.509 v3 certificate) 259 and the recipient's 128-byte public KEA key used as the Rb value. 261 2) The SKIPJACK CEK MUST be wrapped using the KEA-generated pairwise 262 KEK as input to the FORTEZZA 80-bit wrap function. The FORTEZZA 80-bit 263 wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit integrity 264 checkvalue and produces a 96-bit result using the KEA-generated pairwise 265 KEK. 267 3) A new RecipientEncryptedKey SEQUENCE MUST be constructed for the 268 recipient. 270 4) The value of the subjectKeyIdentifier extension from the recipient's 271 KEA X.509 v3 certificate MUST be placed in the recipient's 272 RecipientEncryptedKey rid rKeyId subjectKeyIdentifier field. The 273 KeyAgreeRecipientIdentifier CHOICE MUST be rKeyId. The date and other 274 fields MUST be absent from the recipientEncryptedKey rid rKeyId 275 SEQUENCE. 277 5) The wrapped SKIPJACK CEK MUST be placed in the recipient's 278 RecipientEncryptedKey encryptedKey OCTET STRING. 280 6) The recipient's RecipientEncryptedKey MUST be included in the 281 KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF 282 RecipientEncryptedKey. 284 4.2.1.2. SKIPJACK CEK Wrap Process Using Unique Originator UKM Values 286 This section describes how a unique originator UKM value is generated 287 for each recipient to be used as an input to KEA to generate that 288 recipient's pairwise KEK. 290 The following steps MUST be repeated for each recipient: 292 1) A new RecipientInfo KeyAgreeRecipientInfo structure MUST be 293 constructed. 295 2) A unique 128-byte originator's UKM MUST be generated. The 296 originator's UKM MUST be placed in the KeyAgreeRecipientInfo ukm OCTET 297 STRING. 299 3) KEA MUST be used to generate the pairwise KEK based on the 300 originator's UKM, originator's private KEA key, recipient's 128-byte 301 public KEA key and recipient's 128-byte public KEA key used as the Rb 302 value. 304 4) The SKIPJACK CEK MUST be wrapped using the KEA-generated pairwise 305 KEK as input to the FORTEZZA 80-bit wrap function. The FORTEZZA 80-bit 306 wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit 307 integrity check value and produces a 96-bit result using the 308 KEA-generated pairwise KEK. 310 5) A new RecipientEncryptedKey SEQUENCE MUST be constructed. 312 6) The value of the subjectKeyIdentifier extension from the recipient's 313 KEA X.509 v3 certificate MUST be placed in the RecipientEncryptedKey 314 rid rKeyId subjectKeyIdentifier field. The KeyAgreeRecipientIdentifier 315 CHOICE MUST be rKeyId. The date and other fields MUST be absent from 316 the RecipientEncryptedKey rid rKeyId SEQUENCE. 318 7) The wrapped SKIPJACK CEK MUST be placed in the RecipientEncryptedKey 319 encryptedKey OCTET STRING. 321 8) The recipient's RecipientEncryptedKey MUST be the only 322 RecipientEncryptedKey present in the KeyAgreeRecipientInfo 323 recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey. 325 9) The RecipientInfo containing the recipient's KeyAgreeRecipientInfo 326 MUST be included in the EnvelopedData RecipientInfos SET OF 327 RecipientInfo. 329 4.2.2. SKIPJACK CEK Unwrap Process 331 This section describes the recipient processing using KEA to generate the 332 SKIPJACK KEK and the subsequent decryption of the SKIPJACK CEK. 334 1) Compliant software MUST be capable of processing EnvelopedData 335 objects constructed using both the shared and the unique originator UKM 336 options. To support the shared UKM option, the receiving software MUST 337 be capable of searching for the recipient's RecipientEncryptedKey in a 338 KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF 339 RecipientEncryptedKey. To support the unique UKM option, the receiving 340 software MUST be capable of searching for the recipient's 341 RecipientEncryptedKey in the EnvelopedData recipientInfos SET OF 342 RecipientInfo, with each RecipientInfo containing exactly one 343 RecipientEncryptedKey. For each RecipientEncryptedKey, if the rid 344 rkeyId CHOICE is present, then the receiving software MUST attempt to 345 match the value of the subjectKeyIdentifier extension from the 346 recipient's KEA X.509 v3 certificate with the RecipientEncryptedKey rid 347 rKeyId subjectKeyIdentifier field. If the rid issuerAndSerialNumber 348 CHOICE is present, then the receiving software MUST attempt to match 349 the values of the issuer name and serial number from the recipient's 350 KEA X.509 v3 certificate with the RecipientEncryptedKey rid 351 issuerAndSerialNumber field. 353 2) The receiving software MUST extract the originator's UKM from the 354 ukm OCTET STRING contained in the same KeyAgreeRecipientInfo that 355 includes the recipient's RecipientEncryptedKey. 357 3) The receiving software MUST locate the originator's KEA X.509 v3 358 certificate identified by the originator field contained in the same 359 KeyAgreeRecipientInfo that includes the recipient's 360 RecipientEncryptedKey. 362 4) KEA MUST be used to generate the pairwise KEK based on the 363 originator's UKM, originator's 128-byte public KEA key (extracted from 364 originator's KEA X.509 v3 certificate), recipient's private KEA key 365 (associated with recipient's KEA X.509 v3 certificate identified by the 366 RecipientEncryptedKey rid field) and the originator's 128-byte public KEA 367 key used as the Rb value. 369 5) The SKIPJACK CEK MUST be unwrapped using the KEA-generated pairwise 370 KEK as input to the FORTEZZA 80-bit unwrap function. 372 6) The unwrapped 80-bit SKIPJACK CEK resulting from the SKIPJACK CEK 373 unwrap process and the 8-byte IV obtained from the EnvelopedData 374 encryptedContentInfo contentEncryptionAlgorithm parameters field are 375 used as inputs to the SKIPJACK content decryption process to decrypt the 376 EnvelopedData encryptedContent. 378 4.3. "Previously Distributed" Symmetric KEK 380 This section describes the conventions for using SKIPJACK with 381 the CMS enveloped-data content type to support "previously distributed" 382 symmetric KEKs. When a "previously distributed" symmetric KEK is used to 383 wrap the SKIPJACK CEK, then the RecipientInfo KEKRecipientInfo CHOICE 384 MUST be used. The methods used to generate and distribute the symmetric KEK 385 are beyond the scope of this document. 387 The KEKRecipientInfo fields MUST be populated as specified in [CMS] Section 388 6.2.3, "KEKRecipientInfo Type". The KEKRecipientInfo keyEncryptionAlgorithm 389 algorithm field MUST be the id-fortezzaWrap80 OID indicating that the 390 FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK CEK. The 391 KEKRecipientInfo keyEncryptionAlgorithm parameters field MUST be absent. 392 The KEKRecipientInfo encryptedKey field MUST include the SKIPJACK CEK 393 wrapped using the "previously distributed" symmetric KEK as input to the 394 FORTEZZA 80-bit wrap function. 396 5. Encrypted-data Conventions 398 The CMS encrypted-data content type consists of an encrypted content, 399 but no recipient information. The method for conveying the SKIPJACK CEK 400 required to decrypt the encrypted-data encrypted content is beyond the 401 scope of this document. Compliant software MUST meet the requirements 402 for constructing an encrypted-data content type stated [CMS] Section 8, 403 "Encrypted-data Content Type". [CMS] Section 8 should be studied before 404 reading this section, because this section does not repeat the [CMS] 405 text. 407 The encrypted-data content type is ASN.1 encoded using the EncryptedData 408 syntax. The fields of the EncryptedData syntax must be populated as 409 follows: 411 The EncryptedData version MUST be set according to [CMS] Section 8. 413 The EncryptedData encryptedContentInfo contentEncryptionAlgorithm 414 algorithm field MUST be the id-fortezzaConfidentialityAlgorithm 415 OID. The EncryptedData encryptedContentInfo contentEncryptionAlgorithm 416 parameters field MUST include the random 8-byte IV used as the input to 417 the content encryption process. 419 The EncryptedData unprotectedAttrs MAY be present. 421 6. FORTEZZA 80-bit Wrap Function 423 The United States Government has not published the description of the 424 FORTEZZA 80-bit wrap function. 426 7. SMIMECapabilities Attribute Conventions 428 RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed attribute 429 (defined as a SEQUENCE of SMIMECapability SEQUNCEs) to be used to specify a 430 partial list of algorithms that the software announcing the 431 SMIMECapabilities can support. When constructing a signedData object, 432 compliant software MAY include the SMIMECapabilities signed attribute 433 announcing that it supports the KEA and SKIPJACK algorithms. 435 The SMIMECapability SEQUENCE representing KEA MUST include the 436 id-kEAKeyEncryptionAlgorithm OID in the capabilityID field and MUST include 437 a KeyWrapAlgorithm SEQUENCE in the parameters field. The algorithm field of 438 KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID. The parameters field of 439 KeyWrapAlgorithm MUST be absent. The SMIMECapability SEQUENCE for KEA SHOULD 440 be included in the key management algorithms portion of the 441 SMIMECapabilities list. The SMIMECapability SEQUENCE representing KEA MUST 442 be DER-encoded as the following hexadecimal string: 443 3018 0609 6086 4801 6502 0101 1830 0b06 0960 8648 0165 0201 0117. 445 The SMIMECapability SEQUENCE representing SKIPJACK MUST include the 446 id-fortezzaConfidentialityAlgorithm OID in the capabilityID field and the 447 parameters field MUST be absent. The SMIMECapability SEQUENCE for SKIPJACK 448 SHOULD be included in the symmetric encryption algorithms portion of the 449 SMIMECapabilities list. The SMIMECapability SEQUENCE representing SKIPJACK 450 MUST be DER-encoded as the following hexadecimal string: 451 300b 0609 6086 4801 6502 0101 0400. 453 8. Object Identifier Definitions 455 The following OIDs are specified in [INFO], but are repeated here for 456 the reader's convenience: 458 id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) 459 country(16) us(840) organization(1) gov(101) dod(2) infosec(1) 460 algorithms(1) keyExchangeAlgorithm (22)} 462 id-fortezzaWrap80 OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) country(16) 463 us(840) organization(1) gov(101) dod(2) infosec(1) algorithms(1) 464 fortezzaWrap80Algorithm (23)} 466 id-kEAKeyEncryptionAlgorithm OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) 467 country(16) us(840) organization(1) gov(101) dod(2) infosec(1) 468 algorithms(1) kEAKeyEncryptionAlgorithm (24)} 470 id-fortezzaConfidentialityAlgorithm OBJECT IDENTIFIER ::= {joint-iso- 471 ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) 472 algorithms(1) fortezzaConfidentialityAlgorithm (4)} 474 As specified in [USSUP1], when the id-fortezzaConfidentialityAlgorithm 475 OID is present in the AlgorithmIdentifier algorithm field, then the 476 AlgorithmIdentifier parameters field MUST be present and MUST include 477 the SKIPJACK IV ASN.1 encoded using the following syntax: 479 Skipjack-Parm ::= SEQUENCE { initialization-vector OCTET STRING } 481 Note: [CMS] Section 2, "General Overview" describes the ASN.1 encoding 482 conventions for the CMS content types including the enveloped-data and 483 encrypted-data content types in which the 484 id-fortezzaConfidentialityAlgorithm OID and parameters will be present. 486 A. References 488 [CMS] RFC 2630, Cryptographic Message Syntax, June 1999. 490 [KEA] RFC 2528, Representation of Key Exchange Algorithm (KEA) Keys in 491 Internet X.509 Public Key Infrastructure Certificates, March 1999. 493 [INFO] Registry of INFOSEC Technical Objects, 22 July 1999. 495 [MSG] RFC 2633, S/MIME Version 3 Message Specification, June 1999. 497 [MUSTSHOULD] RFC 2119, Key Words for Use in RFCs to Indicate 498 Requirement Levels. 500 [SJ-KEA] SKIPJACK and KEA Algorithm Specifications, Version 2.0, 501 http://csrc.nist.gov/encryption/skipjack-kea.htm. 503 [USSUP1] Allied Communication Publication 120 (ACP120) Common 504 Security Protocol (CSP) United States (US) Supplement No. 1, June 1998; 505 http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html#specs. 507 B. Acknowledgments 509 The following people have made significant contributions to this draft: 510 David Dalkowski, Phillip Griffin, Russ Housley, Pierce Leonberger, 511 Rich Nicholas, Bob Relyea and Jim Schaad. 513 C. Author's Address 515 John Pawling 516 J.G. Van Dyke & Associates, Inc., 517 a Wang Government Services Company 518 141 National Business Pkwy, Suite 210 519 Annapolis Junction, MD 20701 520 john.pawling@wang.com 521 (301) 939-2739 522 (410) 880-6095 524 D. Full Copyright Statement 526 Copyright (C) The Internet Society (date). All Rights Reserved. 527 This document and translations of it may be copied and furnished to 528 others, and derivative works that comment on or otherwise explain it 529 or assist in its implementation may be prepared, copied, published 530 and distributed, in whole or in part, without restriction of any 531 kind, provided that the above copyright notice and this paragraph 532 are included on all such copies and derivative works. However, this 533 document itself may not be modified in any way, such as by removing 534 the copyright notice or references to the Internet Society or other 535 Internet organizations, except as needed for the purpose of 536 developing Internet standards in which case the procedures for 537 copyrights defined in the Internet Standards process shall be 538 followed, or as required to translate it into languages other than 539 English. 541 The limited permissions granted above are perpetual and will not be 542 revoked by the Internet Society or its successors or assigns. This 543 document and the information contained herein is provided on an "AS 544 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 545 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 546 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 547 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 548 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.