idnits 2.17.1 draft-ietf-smime-x400wrap-04.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 561 lines 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 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 129: '...Sending and receiving agents MUST support SHA-1 [SHA1]....' RFC 2119 keyword, line 133: '...Sending and receiving agents MUST support id-dsa defined in [DSS]. The...' RFC 2119 keyword, line 134: '...rithm parameters MUST be absent (not e...' RFC 2119 keyword, line 136: '...Receiving agents MAY support rsaEncryption, defined in [PKCS-1]....' RFC 2119 keyword, line 138: '...Sending agents MAY support rsaEncrypti...' (46 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.) -- 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 section? 'CMS' on line 493 looks like a reference -- Missing reference section? 'MSG' on line 507 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 510 looks like a reference -- Missing reference section? 'SHA1' on line 516 looks like a reference -- Missing reference section? 'DSS' on line 502 looks like a reference -- Missing reference section? 'PKCS-1' on line 513 looks like a reference -- Missing reference section? 'DH' on line 499 looks like a reference -- Missing reference section? 'ESS' on line 504 looks like a reference -- Missing reference section? '3DES' on line 487 looks like a reference -- Missing reference section? 'DES' on line 496 looks like a reference -- Missing reference section? 'SMTP' on line 520 looks like a reference -- Missing reference section? 'TRANSPORT' on line 523 looks like a reference -- Missing reference section? 'CERT3' on line 490 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Paul Hoffman, IMC 2 draft-ietf-smime-x400wrap-04.txt Chris Bonatti, IECA 3 August 27, 2001 Anders Eggen, FFI 4 Expires in six months 6 Securing X.400 Content with S/MIME 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. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes a protocol for adding cryptographic signature 31 and encryption services to X.400 content. 33 1. Introduction 35 The techniques described in the Cryptographic Message Syntax [CMS] 36 specification are general enough to support many different content 37 types. The [CMS] specification thus provides many options for providing 38 different security mechanisms. In order to ensure interoperability of 39 systems within the X.400 community, it is necessary to specify the use 40 of CMS features to protect X.400 content (called "CMS-X.400" in this 41 document). 43 1.1 Specification Overview 45 This document is intended to be similar to the S/MIME Version 3 Message 46 Specification [MSG] except that it is tailored to the requirements of 47 X.400 content rather than Multipurpose Internet Mail Extensions (MIME). 49 This document defines how to create an X.400 content type that has been 50 cryptographically enhanced according to [CMS]. In order to create S/MIME 51 messages carrying X.400 content, an S/MIME agent has to follow 52 specifications in this document, as well as the specifications listed in 53 [CMS]. This memo also defines new parameter values for the 54 application/pkcs7-mime MIME type that can be used to transport those 55 body parts. 57 Throughout this document, there are requirements and recommendations 58 made for how receiving agents handle incoming messages. There are 59 separate requirements and recommendations for how sending agents create 60 outgoing messages. In general, the best strategy is to "be liberal in 61 what you receive and conservative in what you send". Most of the 62 requirements are placed on the handling of incoming messages while the 63 recommendations are mostly on the creation of outgoing messages. 65 This document does not address transport of CMS-X.400 content. It is 66 assumed that CMS-X.400 content would be transported by Internet mail 67 systems, X.400, or other suitable transport. 69 1.2 Terminology 71 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and 72 "MAY" in this document are to be interpreted as described in RFC 2119 73 [MUSTSHOULD]. 75 1.3 Definitions 77 For the purposes of this document, the following definitions apply. 79 ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824. 81 BER: Basic Encoding Rules for ASN.1, as defined in ISO/IEC 8825-1. 83 Certificate: A type that binds an entity's distinguished name to a 84 public key with a digital signature. 86 DER: Distinguished Encoding Rules for ASN.1, as defined in ISO/IEC 87 8825-1. 89 7-bit data: Text data with lines less than 998 characters long, where 90 none of the characters have the 8th bit set, and there are no NULL 91 characters. and occur only as part of a end of line 92 delimiter. 94 8-bit data: Text data with lines less than 998 characters, and where 95 none of the characters are NULL characters. and occur only as 96 part of a end of line delimiter. 98 Binary data: Arbitrary data. 100 Transfer Encoding: A reversible transformation made on data so 8-bit or 101 binary data may be sent via a channel that only transmits 7-bit data. 103 Receiving agent: Software that interprets and processes S/MIME CMS 104 objects. 106 Sending agent: Software that creates S/MIME CMS objects. 108 S/MIME agent: User software that is a receiving agent, a sending agent, 109 or both. 111 1.4 Compatibility with Prior Practice of S/MIME 113 There are believed to be no existing X.400 implementations that support 114 S/MIME version 2. Further, signed interoperability between X.400 and 115 MIME systems that support S/MIME version 2 is not believed to be easily 116 achievable. Therefore backward compatibility with S/MIME version 2 is 117 not considered to be a requirement for this document. 119 2. CMS Options 121 CMS allows for a wide variety of options in content and algorithm 122 support. This section puts forth a number of support requirements and 123 recommendations in order to achieve a base level of interoperability 124 among all CMS-X.400 implementations. [CMS] provides additional details 125 regarding the use of the cryptographic algorithms. 127 2.1 DigestAlgorithmIdentifier 129 Sending and receiving agents MUST support SHA-1 [SHA1]. 131 2.2 SignatureAlgorithmIdentifier 133 Sending and receiving agents MUST support id-dsa defined in [DSS]. The 134 algorithm parameters MUST be absent (not encoded as NULL). 136 Receiving agents MAY support rsaEncryption, defined in [PKCS-1]. 138 Sending agents MAY support rsaEncryption. Outgoing messages are signed 139 with a user's private key. 141 2.3 KeyEncryptionAlgorithmIdentifier 143 Sending and receiving agents MUST support rsaEncryption. Incoming 144 encrypted messages contain symmetric keys which are to be decrypted with 145 a user's private key. 147 Sending and receiving agents MAY support Diffie-Hellman defined in [DH]. 149 2.4 General Syntax 151 The general syntax of CMS objects consist of an instance of the 152 ContentInfo structure containing one of several defined CMS content 153 types. CMS defines multiple content types. Of these, only the SignedData 154 and EnvelopedData content types are used for CMS-X.400. 156 2.4.1 SignedData Content Type 158 Sending agents MUST use the signedData content type to apply a digital 159 signature to a message or, in a degenerate case where there is no 160 signature information, to convey certificates. 162 2.4.2 EnvelopedData Content Type 164 Senders MUST use the envelopedData content type to apply privacy 165 protection to a message. A sender needs to have access to a public key 166 for each intended message recipient to use this service. This content 167 type does not provide authentication. 169 2.5 Attribute SignerInfo Type 171 The SignerInfo type allows the inclusion of unsigned and signed 172 attributes to be included along with a signature. 174 Receiving agents MUST be able to handle zero or one instance of each of 175 the signed attributes listed here. Sending agents SHOULD generate one 176 instance of each of the following signed attributes in each CMS-X400 177 message: 178 - signingTime 179 - sMIMECapabilities 180 - sMIMEEncryptionKeyPreference 182 Requirements for processing of these attributes MUST be in accordance 183 with the S/MIME Message Specification [MSG]. Handling of the signingTime 184 attribute MUST comply with clause 2.5.1 of [MSG]. Handling of the 185 sMIMECapabilities attribute MUST comply with clause 2.5.2 of [MSG]. 186 Handling of the sMIMEEncryptionKeyPreference attribute MUST comply with 187 clause 2.5.3 of [MSG]. 189 Further, receiving agents SHOULD be able to handle zero or one instance 190 in the signed attributes of the signingCertificate attribute [ESS]. 192 Sending agents SHOULD generate one instance of the signingCertificate 193 signed attribute in each CMS-X400 message. 195 Additional attributes and values for these attributes may be defined in 196 the future. Receiving agents SHOULD handle attributes or values that it 197 does not recognize in a graceful manner. 199 Sending agents that include signed attributes that are not listed here 200 SHOULD display those attributes to the user, so that the user is aware 201 of all of the data being signed. 203 2.6 ContentEncryptionAlgorithmIdentifier 205 Sending and receiving agents MUST support encryption and decryption 206 with DES EDE3 CBC, hereinafter called "tripleDES" [3DES] [DES]. 208 3. Creating S/MIME Messages 210 This section describes the S/MIME message formats and how they can be 211 used to secure X.400 contents. The S/MIME messages are a combination of 212 X.400 contents and CMS objects (i.e., a ContentInfo structure containing 213 one of the CMS-defined content types). The X.400 content and other data, 214 such as certificates and algorithm identifiers, are given to CMS 215 processing facilities which produces a CMS object. This document also 216 describes how nested, secured S/MIME messages should be formatted when 217 encapsulating an X.400 content, and provides an example of how a 218 triple-wrapped S/MIME message over X.400 content should be created if 219 backwards compatibility with S/MIME version 2 is of no concern. 221 S/MIME provides one format for enveloped-only data, several formats for 222 signed-only data, and several formats for signed and enveloped data. The 223 different formats are required to accommodate several environments, in 224 particular for signed messages. Only one of these signed formats is 225 applicable to X.400. 227 Note that canonicalization is not required for X.400 content because it 228 is a binary rather than text encoding, and only the "embedded" content 229 version is used. These dramatically simplify the description of S/MIME 230 productions. 232 The reader of this section is expected to understand X.400 as described 233 in [X.400] and S/MIME as described in [CMS] and [ESS]. 235 3.1 The X.400 Message Structure 237 This section reviews the X.400 message format. An X.400 message has two 238 parts, the envelope and the content, as described in X.402 [X.400]: 240 Envelope -- An information object whose composition varies from one 241 transmittal step to another and that variously identifies the message's 242 originator and potential recipients, documents its previous conveyance 243 and directs its subsequent conveyance by the Message Transfer System 244 (MTS), and characterizes its content. 246 Content -- The content is the piece of information that the originating 247 User Agent wants to be delivered to one or more recipients. The MTS 248 neither examines nor modifies the content, except for conversion, during 249 its conveyance of the message. MTS conversion is not applicable to the 250 scenario of this draft because such conversion is incompatible with CMS 251 protection mechanisms. 253 One piece of information borne by the envelope identifies the type of 254 the content. The content type is an identifier (an ASN.1 OID or Integer) 255 that denotes the syntax and semantics of the content overall. This 256 identifier enables the MTS to determine the message's deliverability to 257 particular users, and enables User Agents and Message Stores to 258 interpret and process the content. 260 Another piece of information borne by the envelope identifies the types 261 of encoded information represented in the content. An encoded 262 information type (EIT) is an identifier (an ASN.1 Object Identifier or 263 Integer) that denotes the medium and format (e.g., IA5 text or Group 3 264 facsimile) of individual portions of the content. It further enables the 265 MTS to determine the message's deliverability to particular users, and 266 to identify opportunities for it to make the message deliverable by 267 converting a portion of the content from one EIT to another. 269 This document describes how S/MIME CMS is used to secure the content 270 part of X.400 messages. 272 3.2 Creating a Signed-only Message with X.400 Content 274 The SignedData format as described in the Cryptographic Message Syntax 275 [CMS] MUST be used for signing of X.400 contents. 277 The protected X.400 content MUST be placed in the SignedData 278 encapContentInfo eContent field. Note that this X.400 content SHOULD 279 maintain the encoding defined by the content type, but SHOULD NOT be 280 MIME wrapped. The object identifier for content type of the protected 281 X.400 content MUST be placed in the SignedData encapContentInfo 282 eContentType field. 284 The signedData object is encapsulated by a ContentInfo SEQUENCE with a 285 contentType of id-signedData. The resulting CMS object MAY optionally be 286 wrapped in a MIME encoding. 288 Note that if SMTP [SMTP] is used to transport the resulting signed-only 289 message then the optional MIME encoding SHOULD be used. If binary 290 transports such as X.400 are used then the optional MIME encoding SHOULD 291 NOT be used. 293 There are many reasons for this requirement. An outer MIME wrapper 294 should not be used in X.400. Further, there are places where X.400 295 systems will interact with SMTP/MIME systems where the outer MIME 296 wrapper might be necessary. Because this wrapping is outside the 297 security wrappers, whatever gateway system that is bridging the gap 298 between the two systems will be smart enough to apply or remove the 299 outer MIME wrapper as appropriate. 301 3.2.1 MIME Wrapping to Dynamically Support 7-bit Transport 303 The signedData object MAY optionally be wrapped in MIME to dynamically 304 support 7-bit transport. In this case the application/pkcs7-mime type as 305 defined in S/MIME Version 3 Message Specification [MSG] SHOULD be used 306 with the following parameters: 308 Content-Type: application/pkcs7-mime; smime-type=signed-x400 309 Content-Transfer-Encoding: base64 311 If the application/pkcs7-mime MIME type is used to support 7-bit 312 transport, the steps to create this format are: 314 Step 1. The X.400 content to be signed is ASN.1 encoded. 316 Step 2. The ASN.1 encoded X.400 content and other required data is 317 processed into a CMS object of type SignedData. The SignedData structure 318 is encapsulated by a ContentInfo SEQUENCE with a contentType of 319 id-signedData. 321 Step 3. The CMS object is inserted into an application/pkcs7-mime MIME 322 entity. 324 The smime-type parameter for messages using application/pkcs7-mime with 325 SignedData is "signed-x400" as defined in [TRANSPORT]. 327 3.3 Creating an Enveloped-only Message with X.400 Content 329 This section describes the format for enveloping an X.400 content 330 without signing it. It is important to note that sending enveloped but 331 not signed messages does not provide for data integrity. It is possible 332 to replace ciphertext in such a way that the processed message will 333 still be valid, but the meaning is altered. 335 The EnvelopedData format as described in [CMS] is used for 336 confidentiality of the X.400 contents. 338 The protected X.400 content MUST be placed in the EnvelopedData 339 encryptedContentInfo encryptedContent field. Note that this X.400 340 content SHOULD maintain the encoding defined by the content type, but 341 SHOULD NOT be MIME wrapped. The object identifier for content type of 342 the protected X.400 content MUST be placed in the EnvelopedData 343 encryptedContentInfo contentType field. 345 The envelopedData object is encapsulated by a ContentInfo SEQUENCE with 346 a contentType of id-envelopedData. The resulting CMS object MAY 347 optionally be wrapped in a MIME encoding. 349 Note that if SMTP is used to transport the resulting enveloped-only 350 message then the optional MIME encoding SHOULD be used. If other binary 351 transport (e.g., X.400) is used then the optional MIME encoding SHOULD 352 NOT be used. 354 3.3.1 MIME Wrapping to Dynamically Support 7-bits Transport 356 The envelopedData object MAY optionally be wrapped in MIME to 357 dynamically support 7-bit transport. In this case, the 358 application/pkcs7-mime type as defined in S/MIME Version 3 Message 359 Specification [MSG] SHOULD be used with the following parameters: 361 Content-Type: application/pkcs7-mime; smime-type=enveloped-x400 362 Content-Transfer-Encoding: base64 364 If the application/pkcs7-mime MIME type is used to support 7-bit 365 transport, the steps to create this format are: 367 Step 1. The X.400 content to be enveloped is ASN.1 encoded. 369 Step 2. The ASN.1 encoded X.400 content and other required data is 370 processed into a CMS object of type EnvelopedData. In addition to 371 encrypting a copy of the content-encryption key for each recipient, a 372 copy of the content encryption key SHOULD be encrypted for the 373 originator and included in the EnvelopedData (see CMS Section 6). The 374 EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE with a 375 contentType of id-envelopedData. 377 Step 3. The CMS object is inserted into an application/pkcs7-mime MIME 378 entity to allow for 7-bit transport. 380 If the application/pkcs7-mime MIME entity is used, the smime-type 381 parameter for enveloped-only messages is "enveloped-x400" as defined in 382 [TRANSPORT]. 384 3.4 Nested CMS Structures 386 To achieve signing and enveloping, any of the signed-only and 387 encrypted-only CMS objects may be nested. 389 When nesting is used, backwards compatibility with S/MIME version 2 390 requires that each layer of the nested message are identified with the 391 OID id-data, and when id-data is used a MIME wrapper is required. This 392 can potentially lead to an enormous amount of overhead and should be 393 avoided. Because S/MIME version 2 compatibility is of no concern, 394 implementations SHOULD directly encode the encapsulated object as the 395 eContent of the current structure. 397 MIME wrapping to support 7-bit transport, is optional and need only be 398 used around the outermost CMS structure. In this case, the 399 application/pkcs7 content type MUST be used. 401 An S/MIME implementation MUST be able to receive and process arbitrarily 402 nested CMS structures within reasonable resource limits of the recipient 403 computer. 405 3.4.1 Creating a Triple Wrapped Message With an X.400 Content 407 The Enhanced Security Services for S/MIME [ESS] document provides 408 examples of how nested, secured S/MIME messages are formatted. ESS 409 provides an example of how a triple-wrapped S/MIME message is formatted 410 using application/pkcs7-mime for the signatures. 412 This section explains how an X.400 content may be conveyed within a 413 Triple Wrapped Message because S/MIME version 2 compatibility is of no 414 concern: 416 Step 1. Start with the X.400 content (called the "original content"). 417 The X.400 content MUST be ASN.1 encoded, but SHOULD NOT be MIME wrapped. 419 Step 2. Place the protected ASN.1 encoded X.400 content in the 420 SignedData encapContentInfo eContent field. Add any attributes 421 that are to be signed. 423 Step 3. Sign the result of step 2 (the original content). The SignedData 424 encapContentInfo eContentType MUST contain the object identifier of the 425 X.400 content. 427 Step 4. Encrypt the result of step 3 as a single block. The 428 EnvelopedData encryptedContentInfo contentType MUST be set to 429 id-signedData. This is called the "encrypted body". 431 Step 5. Using the same logic as in step 2 and 3 above, sign the result 432 of step 4 (the encrypted body) as a single block. The SignedData 433 encapContentInfo eContentType MUST be set to id-envelopedData. The outer 434 SignedData structure is encapsulated by a ContentInfo SEQUENCE with a 435 contentType of id-signedData. 437 Step 6. The resulting message is called the "outer signature", and is 438 also the triple wrapped message. 440 MIME wrapping to support 7-bit transport, is optional and MUST only be 441 used around the outermost CMS structure. In this case, the 442 application/pkcs7-mime content type MUST be used. The smime-type 443 in the case of adding a MIME wrapper MUST be consistent with 444 that appropriate to the innermost protection layer. 446 In some instances, an smime-type will be created that only reflects one 447 security service (such as certs-only, which is only for signed). 448 However, as new layers are wrapped, this smime-type SHOULD be propagated 449 upwards. Thus if a certs-only message were to be encrypted, or wrapped 450 in a new SignedData structure, the smime-type of certs-only should be 451 propagated up to the next MIME wrapper. In other words, the innermost 452 type is reflected outwards. 454 4. Use of Certificates 456 4.1 Certificate Enrollment 458 S/MIME v3 does not specify how to get a certificate from a certificate 459 authority, but instead mandates that every sending agent already has a 460 certificate. The PKIX Working Group has, at the time of this writing, 461 produced two separate standards for certificate enrollment: CMP (RFC 462 2510) and CMC (RFC 2792). 464 4.2 Certificate Processing 466 A receiving agent MUST provide some certificate retrieval mechanism in 467 order to gain access to certificates for recipients of digital 468 envelopes. This document does not cover how S/MIME agents handle 469 certificates, only what they do after a certificate has been validated 470 or rejected. S/MIME certification issues are covered in [CERT3]. 472 At a minimum, for initial S/MIME deployment, a user agent could 473 automatically generate a message to an intended recipient requesting 474 that recipient's certificate in a signed return message. Receiving and 475 sending agents SHOULD also provide a mechanism to allow a user to "store 476 and protect" certificates for correspondents in such a way so as to 477 guarantee their later retrieval. 479 5. Security Considerations 481 This entire document discusses security. Additional security issues are 482 identified in section 5 of [MSG], section 6 of [ESS] and the Security 483 Considerations section of [CMS]. 485 A. References 487 [3DES] ANSI X9.52-1998, "Triple Data Encryption Algorithm Modes of 488 Operation", American National Standards Institute, 1998. 490 [CERT3] Ramsdell, B., Editor, "S/MIME Version 3 Certificate 491 Handling", RFC 2632, June 1999. 493 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 494 1999. 496 [DES] ANSI X3.106, "American National Standard for Information Systems- 497 Data Link Encryption," American National Standards Institute, 1983. 499 [DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, 500 June 1999. 502 [DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18 May 1994. 504 [ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", 505 RFC 2634, June 1999. 507 [MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", 508 RFC 2633, June 1999. 510 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP14, RFC 2119, March 1997. 513 [PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 2.0", RFC 514 2437, October 1998. 516 [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National 517 Institute of Standards and Technology, U.S. Department of Commerce, 31 518 May 1994. 520 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 521 April, 2001. 523 [TRANSPORT] Hoffman, P. and Bonatti, C., "Transporting S/MIME Objects in 524 X.400", work in progress (will progress with this document). 526 [X.400] ITU-T X.400 Series of Recommendations, Information technology 527 - Message Handling Systems (MHS). X.400: System and Service Overview; 528 X.402: Overall Architecture; X.411: Message Transfer System: Abstract 529 Service Definition and Procedures; X.420: Interpersonal Messaging 530 System; 1996. 532 B. Editor's Address 534 Paul Hoffman 535 Internet Mail Consortium 536 127 Segre Place 537 Santa Cruz, CA 95060 USA 538 phoffman@imc.org 540 Chris Bonatti 541 IECA, Inc. 542 15309 Turkey Foot Road 543 Darnestown, MD 20878-3640 USA 544 bonattic@ieca.com 546 Anders Eggen 547 Forsvarets Forskningsinstitutt 548 Postboks 25 549 2027 Kjeller, Norway 550 anders.eggen@ffi.no