idnits 2.17.1 draft-ietf-cat-p7im-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-25) 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 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([SPKM], [IDUP], [PKCS7], [IDUP-C], [RFC-1508], [Kerb5], [GSS]), 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'Kerb5' is mentioned on line 43, but not defined == Missing Reference: 'GSS' is mentioned on line 44, but not defined == Unused Reference: 'KRB5' is defined on line 351, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-cat-idup-gss (ref. 'IDUP') -- No information found for draft-ietf-cat-idup-cbind-0x - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IDUP-C' -- No information found for draft-ietf-cat-kerb5gss-0x - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'KRB5' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS7' ** Obsolete normative reference: RFC 1508 (Obsoleted by RFC 2078) ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) -- No information found for draft-ietf-cat-spkmgss-0x - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SPKM' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft C. Adams 2 draft-ietf-cat-p7im-00.txt NORTEL 3 Expires: November 30, 1996 May 30, 1996 5 PKCS #7-Based IDUP Mechanism (p7im) 7 STATUS OF THIS MEMO 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference 17 material or to cite them other than as "work in progress." 19 To learn the current status of any Internet Draft, please check the 20 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ds.internic.net (US East Coast), nic.nordu.net 22 (Europe), ftp.isi.edu (West Coast), or munnari.oz.au (Pacific Rim). 24 Comments on this document should be sent to "cat-ietf@mit.edu", the 25 IETF Common Authentication Technology WG discussion list. 27 ABSTRACT 29 The Independent Data Unit Protection Generic Security Service 30 Application Program Interface (IDUP-GSS-API) extends the GSS-API 31 [RFC-1508] for applications requiring protection of a generic data 32 unit (such as a file or message) in a way which is independent of the 33 protection of any other data unit and independent of any concurrent 34 contact with designated "receivers" of the data unit. Thus, it is 35 suitable for applications such as secure electronic mail where data 36 needs to be protected without any on-line connection with the 37 intended recipient(s) of that data. Subsequent to being protected, 38 the independent data unit can be transferred to the recipient(s) - or 39 to an archive - perhaps to be processed only days or years later. 41 This document is a companion document to IDUP-GSS-API [IDUP] and 42 IDUP: C-bindings [IDUP-C]. It provides a PKCS #7-based mechanism 43 for IDUP (analogous to [Kerb5] or [SPKM] which provide underlying 44 mechanisms for [GSS]). This mechanism specifies the procedures 45 for creating and processing security formats according to that 46 defined by the Public-Key Cryptography Standards set of documents 47 (specifically Part 7 of the set [PKCS7], which specifies the 48 "Cryptographic Message Syntax Standard"). Calling applications can 49 use this IDUP mechanism to assist them in creating true S/MIME 50 [S/MIME] objects. More precisely, a calling application is assumed 51 by this mechanism to be MIME-aware and thus capable of performing all 52 necessary canonicalization and (base64 or quoted-printable) encoding 53 on the data. The application thus uses the mechanism specified in 54 this document exclusively for the security aspects of S/MIME. 56 Adams Document Expiration: 30 Nov. 1996 1 57 1. INTRODUCTION 59 The Independent Data Unit Protection Generic Security Service 60 Application Program Interface (IDUP-GSS-API) [IDUP] provides security 61 services to calling applications in a local environment. This 62 PKCS #7-Based IDUP Mechanism (p7im) allows an application to 63 "protect" an independent data unit (IDU) for future use and to 64 "unprotect" a protected IDU, applying security services such as 65 confidentiality, integrity and data origin authentication on a 66 per-data-unit basis. 68 There are four stages to using the IDUP-GSS-API: 70 (a) The application acquires a set of credentials with which it may 71 bind its identity to a data unit. The application's credentials 72 vouch for its global identity, which may or may not be related to 73 the local username under which it is running. 75 (b) The application establishes a security environment using its 76 credentials. The security environment contains whatever 77 information is necessary in order to provide per-IDU security 78 services. 80 (c) Per-IDU calls are invoked to provide one of the following for 81 PKCS #7-based IDU protection: 82 - data origin authentication with data integrity (SignedData); 83 - data confidentiality (EnvelopedData); 84 - both of the above (SignedAndEnvelopedData). 85 The application wishing to "protect" an IDU will call the 86 protection set of IDUP-GSS-API routines, specifying the 87 appropriate security environment. The recipient (wishing to 88 "unprotect" the data) will pass the protected IDU (P-IDU) to 89 the unprotection set of routines to remove the protection and/or 90 to validate the data. 92 (d) At the completion of a security environment (which may extend 93 across several protection and unprotection operations), the 94 application calls an IDUP-GSS-API routine to abolish the security 95 environment. 97 2. INDEPENDENT DATA UNIT PROTECTION MECHANISM 99 2.1. Protection Token 101 A P-IDU is a caller-opaque data structure that p7im uses to store 102 protection information regarding an IDU. It is an OCTET STRING 103 generated during the protection set of calls for use by p7im or by 104 another mechanism during the unprotection set of calls. If 105 encapsulation is requested by the calling application, the P-IDU 106 consists entirely of the contents of the pidu_buffer, output_buffer, 107 and final_pidu_buffer parameters used in the IDUP protection set of 108 calls. Otherwise, the P-IDU consists of the contents of the 109 midu_buffer, output_buffer, and final_midu_buffer parameters, along 110 with the unencapsulated_token parameter. 112 Adams Document Expiration: 30 Nov. 1996 2 113 2.2. Security Services 115 p7im provides the security services given in Section 1(c) above. 116 The security services "proof of origin" and "service solicitation" 117 (such as a request for "proof of delivery"), as defined in [IDUP], 118 are not included in this PKCS #7-based IDUP mechanism. Receipt 119 generation and processing are beyond the scope of [S/MIME] and 120 other types of non-repudiable evidence generation and processing are 121 not addressed in this version of p7im but may be included in future 122 versions of this specification. 124 2.3. IDUP Parameter Bundle Uses and Defaults 126 The following parameter bundle uses and defaults are specified. 128 Mech_Specific_Info 129 - NOT USED (the only acceptable input, therefore, is NULL) 131 Idu_Sensitivity 132 - NOT USED (the only acceptable input, therefore, is NULL) 134 Service_Creation_Info 135 - NOT USED (the only acceptable input, therefore, is NULL) 137 Service_Verification_Info 138 - NOT USED (the only acceptable input, therefore, is NULL) 140 Quality 141 - the qop_algs parameter is supported. For p7im implementation 142 and interoperability purposes, the following qop_algs values are 143 defined. 144 * For the Confidentiality MA field: 0001 (1) = RC2-40-CBC 145 (this is also defined to be the TS "DEFAULT" conf. alg.); 146 0002 (2) = DES-CBC; 147 0003 (3) = DES-EDE3-CBC. 148 * For the Integrity MA field: 0001 (1) = RSA-MD5 149 (this is also defined to be the TS "DEFAULT" int. alg.); 150 0002 (1) = RSA-MD2. 151 - the parameters validity, policy_id, and allow_policy_mapping 152 are NOT USED (NULLs are therefore the only acceptable input) 154 Idu_Information 155 - the idu_type parameter must have a value representing a valid 156 PKCS #7 content type (i.e., "Data", "SignedData", 157 "EnvelopedData", "SignedAndEnvelopedData", "DigestedData, or 158 "EncryptedData") or any other valid MIME type, including 159 multipart (the DEFAULT value is specified to be "text/plain"); 160 - the idu_title parameter is NOT USED (the only acceptable input, 161 therefore, is NULL) 163 Adams Document Expiration: 30 Nov. 1996 3 164 Prot_Information 165 - the idu_type (in Idu_Information) parameter is read from the 166 S/MIME P-IDU and is output by IDUP_End_Unprotect() 167 - The originator_name parameter is read from the S/MIME P-IDU (the 168 "signerInfos" (and possibly "certificates") field in the 169 SignedData or SignedAndEnvelopedData content types) and is 170 output by IDUP_End_Unprotect() 171 - all other parameters are NOT USED (and therefore NULL) 173 Special_Conditions 174 - NOT USED (the only acceptable input, therefore, is NULL) 176 Target_Info 177 - this bundle is used as described in IDUP; no DEFAULT values are 178 specified 180 General_Service_Data 181 - the unencapsulated_token parameter is used only if 182 encapsulation_request is FALSE); 183 - the minor_status parameter is used to return minor status values 184 as specified in Section 5 below. 186 Prot_Service 187 - the prot_service_type parameter may have a value of "1" 188 ("perform unsolicited service") or NULL (which specifies the 189 DEFAULT value of "1"); 190 - the service_id parameter must have a value representing 191 "PER_CONF" or "PER_DOA"; 192 - the parameters Service_Creation_Info, service_to, 193 Service_Verification_Info, and service_verification_info_id are 194 NOT USED (and therefore NULL) 196 Unprot_Service 197 - the unprot_service_type parameter will always have a value of 198 "1" ("receive unsolicited service"); 199 - the service_id parameter will have a value representing 200 "REC_CONF" or "REC_DOA"; 201 - the parameters service_verification_info_id, 202 Service_Verification_Info, service_to, and 203 Service_Creation_Info, are NOT USED (and therefore NULL) 205 3. SUMMARY OF TRANSFORMATIONS 207 The following composition of transformations is applied to the IDU 208 for full S/MIME compliance during the IDUP protection set of calls 209 (see [S/MIME] for discussions of Content-Transfer-Encoding and 210 Canonicalization; "PerSecServ" refers to the performance of security 211 services): 213 Transmit_Form = C-T-Encode(PerSecServ(Canonicalize(Local_Form))) 215 The inverse transformations are performed, in reverse order, to 216 unprotect the IDU ("RemSecServ" refers to the removal/verification of 217 security services): 219 Adams Document Expiration: 30 Nov. 1996 4 220 Local_Form = DeCanonicalize(RemSecServ(C-T-Decode(Transmit_Form))). 222 It is the responsibility of the underlying p7im implementation to 223 perform the PerSecServ and RemSecServ transformations above. The 224 transformations Canonicalize, DeCanonicalize, C-T-Encode, and 225 C-T-Decode are expected to be performed by the calling application 226 unless one or more of the transformations is unnecessary (e.g., the 227 input data is already in canonical form). 229 Note that the Local_Form and the functions to transform messages to 230 and from Canonical_Form may vary between the protector and 231 unprotector systems provided there is no loss of information. 233 4. TOKEN FORMAT 235 This section discusses protocol-visible characteristics of p7im; it 236 defines elements of protocol for interoperability and is independent 237 of any IDUP language bindings. 239 The p7im IDUP-GSS-API mechanism will be identified by an Object 240 Identifier representing "p7im" , having the value: 241 { iso(1) org(3) dod(5) internet(1) security(5) p7im(xx) } 242 The token transferred between IDUP-GSS-API peers (for IDU protection 243 and unprotection purposes) is defined. 245 4.1. The Protected-IDU (P-IDU) Token 247 The Protected-IDU (from the output parameters of the protection set 248 of calls) is a PKCS #7 ContentInfo, which itself is BER-encoded. 249 The process for creating the P-IDU from the original input data 250 (the IDU) consists of the steps described in [S/MIME], Section 4.4, 251 after canonicalization and before base64 encoding (with all relevant 252 ASN.1 specifications as described in [PKCS7]). Processing this 253 token for the unprotection set of calls consists of the steps 254 described in [S/MIME], Section 4.5 after base64 decoding and before 255 de-canonicalization. 257 Thus, the input to the protection set of calls is treated as an 258 opaque object (which will typically be a properly-encoded MIME object 259 [RFC-1521]). This object is passed either in a single buffer to the 260 IDUP_Start_Protect() call, or in multiple buffers (of arbitrary size) 261 to the IDUP_Protect() call (one buffer per call). The result is a 262 properly-encoded PKCS #7 ContentInfo, which may be content-transfer- 263 encoded and placed within the body of an "application/x-pkcs7-mime" 264 body part to produce a properly-encoded S/MIME object. 266 For unprotection, the input is assumed to be a properly-encoded 267 S/MIME object (passed either as a single buffer to 268 IDUP_Start_Unprotect() or as multiple buffers to IDUP_Unprotect()). 269 The output is treated as an opaque object (but will typically be a 270 properly-encoded MIME object, ready to be passed to a MIME parser for 271 further processing. 273 Adams Document Expiration: 30 Nov. 1996 5 274 4.2. Example of Protection Tokens 276 4.2.1 Signed Data 278 In similar fashion to the example given in [S/MIME], Section 4.4, 279 assume that the MIME object (MO) to be protected is as follows: 281 Content-Type: text/plain; charset="us-ascii" 283 This is a signed message. 285 Using the IDUP protection set of calls with the p7im underlying 286 mechanism yields the following sequence of events. 288 * MO is canonicalized to have end-of-line delimiters 289 (this step is performed by the calling application). 291 * Assuming a signing algorithm of md5-with-RSA, and assuming that 292 certificates and CRLs do not need to be carried within the message 293 in this particular environment, the canonicalized MIME object 294 (CMO) is then signed according to PKCS #7 SignedData, so that the 295 resulting ASN.1 SEQUENCE has version=1, digestAlgorithms=md5, 296 contentInfo=CMO, and signerInfos={version=1, 297 issuerAndSerialNumber=..., digestAlgorithm=md5, 298 digestEncryptionAlgorithm=RSA, encryptedDigest=34iur8a...834rnfz}. 300 * The PKCS #7 ContentInfo structure is then the ASN.1 SEQUENCE 301 {contentType={pkcs-7 2}, content=SignedData}. 303 * ContentInfo is then BER-encoded. 305 * The BER-encoded ContentInfo is then base64-encoded 306 (this step is performed by the calling application). 308 * The BER-encoded, base64-encoded ContentInfo becomes the body of an 309 application/x-pkcs7-mime body part. The result might look like 310 the following: 311 Content-Type: application/x-pkcs7-mime 312 Content-Transfer-Encoding: base64 314 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 315 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 316 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 317 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 318 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 319 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 320 7GhIGfHfYT64VQbnj756 321 (this step is performed by the calling application). 323 This would be sent in a MIME message to the intended recipient, who 324 would reverse the above process (using the IDUP unprotection set of 325 calls with underlying mechanism p7im, or any other S/MIME processor) 326 to retrieve the original MIME object MO. This object can then be 327 passed to the recipient's MIME parser, which will process it and 328 display "This is a signed message." to the user. 330 Adams Document Expiration: 30 Nov. 1996 6 331 5. MINOR STATUS CODES 333 No minor status codes have yet been defined for S/MIM. 335 6. SECURITY CONSIDERATIONS 337 Security issues are discussed throughout this memo. 339 7. REFERENCES 341 [IDUP] C. Adams, "Independent Data Unit Protection Generic Security 342 Service Application Program Interface (IDUP-GSS-API)", 343 Internet Draft draft-ietf-cat-idup-gss.0x.txt (work in 344 progress). 346 [IDUP-C] D. Thakkar, D. Grebovich, "Independent Data Unit Protection 347 Generic Security Service Application Program Interface: 348 C-bindigs", Internet Draft draft-ietf-cat-idup-cbind-0x.txt 349 (work in progress). 351 [KRB5] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", 352 Internet Draft draft-ietf-cat-kerb5gss-0x.txt (work in 353 progress). 355 [PKCS7] RSA Laboratories, The Public-Key Cryptography Standards 356 (PKCS) #7: "Cryptographic Message Syntax Standard", version 357 1.5, November 1, 1993. 359 [RFC-1508] J. Linn, "Generic Security Service Application Program 360 Interface", RFC 1508. 362 [RFC-1521] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail 363 Extensions) Part One: Mechanisms for Specifying and 364 Describing the Format of Internet Message Bodies", September 365 1993. 367 [S/MIME] RSA Data Security, Inc., "S/MIME Message Specification: 368 PKCS Security Services for MIME", Aug. 29, 1995. 370 [SPKM] C. Adams, "The Simple Public-Key GSS-API Mechanism 371 (SPKM)", Internet Draft draft-ietf-cat-spkmgss-0x.txt (work 372 in progress). 374 8. AUTHOR'S ADDRESS 376 Carlisle Adams 377 NORTEL Secure Networks 378 P.O.Box 3511, Station C 379 Ottawa, Ontario, CANADA K1Y 4H7 380 Phone: (613) 763-9008 381 E-mail: cadams@bnr.ca