idnits 2.17.1 draft-ietf-ediint-hl7-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-24) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 67 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 68 pages -- Found 68 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? 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 an Authors' Addresses Section. ** The abstract seems to contain references ([RFC2112], [RFC1767]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1119 has weird spacing: '...ecipher clea...' == Line 1121 has weird spacing: '...eartext ciphe...' == Line 1206 has weird spacing: '...lic key priv...' == Line 1215 has weird spacing: '...eartext symm....' == Line 1216 has weird spacing: '...nvelope deci...' -- 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 (July 21, 1998) is 9409 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? 'RFC 1767' on line 2265 looks like a reference -- Missing reference section? 'RFC 2112' on line 73 looks like a reference -- Missing reference section? 'RFC 821' on line 627 looks like a reference -- Missing reference section? 'RFC 1892' on line 690 looks like a reference -- Missing reference section? 'RFC 1872' on line 695 looks like a reference -- Missing reference section? 'RFC 1847' on line 1459 looks like a reference -- Missing reference section? 'RFC 822' on line 2214 looks like a reference -- Missing reference section? 'RFC 2015' on line 1464 looks like a reference -- Missing reference section? 'RFC 1848' on line 1465 looks like a reference -- Missing reference section? 'RFC 1421-1424' on line 1466 looks like a reference -- Missing reference section? 'RFC 2068' on line 2122 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Health Level Seven Gunther Schadow 3 EDIINT Working Group Mark Tucker 4 draft-ietf-ediint-hl7-00.txt Regenstrief Institute 5 Expires: in six months Wes Rishel 6 Wes Rishel Consulting 7 July 21, 1998 9 Secure HL7 Transactions using Internet Mail 11 draft-ietf-ediint-hl7-00.txt 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as ``work in progress.'' 25 To view the entire list of current Internet-Drafts, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 28 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 29 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Copyright Notice 33 Copyright (C) 1998, Health Level-7, Inc. All rights reserved. 35 Abstract 37 This memo describes the applicability of the Internet standardization 38 efforts on secure electronic data interchange (EDI) transactions for 39 Health Level-7 (HL7), an EDI standard for healthcare used worldwide. 40 This memo heavily relies on the work in progress by the IETF EDIINT 41 working group. It is in most parts a restatement of the EDIINTs 42 requirements document and application statement 1 (AS#1) tailored to the 43 needs of the HL7 audience. We tried to make this document as self 44 consistent as possible. The goal is to give to the reader who is not a 46 Secure HL7 Transactions using Internet Mail July 21, 1998 48 security or Internet standards expert enough foundational and detail 49 information to enable him to build communication software that complies 50 to the Internet standards. 52 Even though we rely on and promote the respective Internet standards 53 and drafts, we did not withstand from commenting on and criticising this 54 work where we see upcoming problems in use with HL7 or other EDI 55 protocols that have not been in the initial focus of the EDIINT working 56 group. We make suggestions to add parameters to the specification of the 57 MIME type for EDI messages [RFC 1767] in order to enhance functionality. 58 We give use cases for a larger subset of disposition types and modifiers 59 of message disposition notifications. 61 One key issue where this memo goes beyond the current EDIINT drafts 62 is the concept of non-repudiation of commitment to an EDI transaction. 63 Secure EDI transactions should be regarded as ``distributed contracts,'' 64 i.e. not only the sending and receiving of single messages should be 65 non-refutable but also the connection between messages interchanges. In 66 anticipation of this requirement HL7 usually requires a response message 67 to be sent to acknowledge every transaction. We therefore have the 68 requirement to securely couple an EDI response message to its request 69 message. Given the current shape of RFC 1767 this is generally possible 70 only if a response message is coupled with an MDN receipt and the 71 combination of both signed by the responder. This memo describes a 72 protocol to bundle MDN and response that uses the MIME multipart/related 73 content type [RFC 2112]. 75 Contents 77 Status of this Memo......................................... 1 78 Copyright Notice............................................ 1 79 Abstract.................................................... 1 80 Contents.................................................... 2 81 Figures..................................................... 4 82 Tables...................................................... 4 83 1 Introduction................................................ 4 84 1.1 Scope....................................................... 6 85 1.2 Limitations................................................. 7 86 1.3 Status...................................................... 8 87 1.4 Acknowledgements............................................ 9 88 2 How it works................................................ 9 89 2.1 Relevant Standards.......................................... 9 90 2.2 E-MAIL......................................................13 91 2.3 MIME........................................................13 92 2.4 MIME Security Multiparts....................................15 93 2.5 Message Disposition Notifications...........................15 95 Secure HL7 Transactions using Internet Mail July 21, 1998 97 2.6 MIME-EDI....................................................15 98 3 Security I: General Issues..................................18 99 3.1 Security Services...........................................18 100 3.1.1 Integrity...................................................18 101 3.1.2 Authenticity................................................18 102 3.1.3 Authorization...............................................19 103 3.1.4 Confidentiality.............................................19 104 3.1.5 Non-repudiation.............................................19 105 3.1.6 More About Security Services................................20 106 3.2 Mechanisms..................................................20 107 3.2.1 Cryptographic Algorithms....................................20 108 3.2.1.1 Message Integrity Check.....................................21 109 3.2.1.2 Symmetric Ciphers...........................................21 110 3.2.1.3 Asymmetric Ciphers..........................................23 111 3.2.2 Cryptographic Protocols.....................................24 112 3.2.2.1 Digital Envelope............................................25 113 3.2.2.2 Digital Signature...........................................26 114 3.2.2.3 Certificates................................................26 115 3.2.2.4 Non-Repudiation.............................................28 116 4 Security II: Implementation Issues..........................30 117 4.1 MIME Security in General....................................30 118 4.1.1 Authenticity: Multipart/Signed..............................31 119 4.1.2 Confidentiality: Multipart/Encrypted........................32 120 4.1.3 Non-repudiation of receipt: Multipart/Report................33 121 4.1.4 Non-Repudiation of Commitment: Multipart/Related............37 122 4.2 MIME-PGP....................................................40 123 4.2.1 Overview of PGP-Services....................................40 124 4.2.2 Digital Signature...........................................41 125 4.2.3 Digital Envelope............................................42 126 4.2.4 Certificates................................................43 127 4.3 S/MIME......................................................43 128 4.3.1 Overview of PKCS-Services...................................43 129 4.3.2 Digital Signature...........................................44 130 4.3.3 Digital Envelope............................................45 131 4.3.4 Certificates................................................46 132 5 A Detailed Example..........................................46 133 6 Architectural and Operational Considerations................57 134 6.1 Process Structure of the E-mail Handling Machine............57 135 6.2 Coexistence of E-mail and TCP/IP Based Communications.......60 136 6.3 Logging Messages and Receipts...............................62 137 6.4 Interface Negotiations for HL7 over E-mail..................64 138 6.4.1 Impact of the Medium........................................64 139 6.4.2 Negotiating Interface Agreements............................65 140 7 Endnotes....................................................65 141 8 Addresses of the Authors....................................66 142 9 Full Copyright Statement....................................67 144 Secure HL7 Transactions using Internet Mail July 21, 1998 146 Figures 148 Figure 1: Use of intermediary and terminal boundaries in multiparts. 14 149 Figure 2: The key in symmetric ciphers is a shared secret. 21 150 Figure 3: Asymmetric encryption uses two complementary keys. 23 151 Figure 4: Hybrid symmetric and asymmetric key encryption. The 25 152 asymmetric cipher is used only to encrypt the data 153 encryption key (DEK) while the bulk data of the message is 154 encrypted with one of the stronger and more efficient 155 symmetric ciphers. 156 Figure 5: A digital signature is an encrypted message integrity 26 157 check (MIC). The Data remains readable in transit, but 158 tampering it will invalidate the signature. 159 Figure 6: The normal HL7 transaction consists of two application 37 160 layer HL7 messages: request and response. The MDN receipt 161 for the request message can be bundled with the 162 application layer HL7 response. The second MDN receipt is 163 normally not needed. 164 Figure 7: Directing incoming e-mail to a program that processes HL7 58 165 messages. 166 Figure 8: HL7 using e-mail can pass a firewall through a gatekeeping 59 167 router. The gatekeeper needs not unwrap the message from 168 its protecting envelope. 169 Figure 9: The e-mail handler relays messages to existing HL7 60 170 applications. Surrogate processes provide separate TCP 171 services for each remote destination. The internal 172 communication that may or may not use a router hub can 173 treat the remote hosts as if they where local TCP servers. 175 Tables 177 Table 1: Reference to relevant standards.............................10 178 Table 2: Protocols for Multipart/Signed..............................31 179 Table 3: Protocols for Multipart/Encrypted...........................32 180 Table 4: Disposition types that are relevant to EDI..................35 181 Table 5: Disposition modifiers that are relevant to EDI..............36 182 Table 6: Journalized outgoing messages...............................63 183 Table 7: Pending messages file.......................................63 185 1 Introduction 187 HL7 is a volunteer organization to develop EDI standards supporting the 188 data interchange needs of the healthcare domain, including patient 189 administration, billing, clinical ordering and result reporting, 191 Secure HL7 Transactions using Internet Mail July 21, 1998 193 clinical trials and more. HL7 is accredited by the American National 194 Standards Institute but its use and participation in its development is 195 not limited to the United States. International affiliates and 196 participators, include Australia, Canada, Finnland, Germany, Japan, 197 Netherland and New Zealand. 199 This document is a draft HL7 Recommendation that describes how to 200 send HL7 messages using public Internet mail. The HL7 Board of Directors 201 commissioned the document as a ``fast track'' effort in its August 1997 202 meeting. This topic is becoming important to HL7 members because they 203 are finding their organizations increasingly dispersed and because they 204 are finding the need to communicate with HL7 among independent 205 organizations. HL7 public health transactions, for example, are 206 inherently transorganizational. 208 Using Internet e-mail to convey HL7 messages leverages an ubiquitous 209 and cost efficient channel for HL7 communications. However, it also 210 bears considerable risks: 212 o The privacy of health care data is threatened by interception of 213 messages on their route from senders to receivers, 215 o The correctness and reliability of data is threatened by fraudulent 216 messages, 218 o The accountability and again reliability of transactions is 219 threatened by allowing the communicating partners to repudiate that a 220 particular message has been sent or received. 222 Therefore, using the Internet requires measures to prevent these 223 threats. Technologies do exist, which are powerful enough to provide the 224 required security services at a high quality. In For the Record: 225 Protecting Electronic Health Information the Committee on Maintaining 226 Privacy and Security in Health Care Applications in the National 227 Information Infrastructure states that encryption can serve a number of 228 uses in health care settings, including those identified here. It 229 further states that tools based on encryption are largely underdeployed 230 and much more aggressive demonstration of these tools and their 231 integration into real systems is needed.(1) 1.fM Finally, it enumerates 232 a series of security practices that are recommended for immediate 233 implementation. One of these is Protection of external electronic 234 communications: 236 Organizations should encrypt all patient-identifiable 237 information before transmitting it over public networks, such 238 as the Internet. Organizations that do not meet these 239 requirements should either refrain from transmitting 240 information electronically outside the organization or should 242 Secure HL7 Transactions using Internet Mail July 21, 1998 244 do so only over secure dedicated lines.(1) 2.fM 246 Considerable progress is being made in drafting Internet standards 247 for the deployment of cryptographic techniques. These standards 248 effectively prevent the above mentioned threats by assuring the 249 integrity, authenticity, confidentiality and non-refutability of 250 messages. This document describes how to use these techniques to 251 transmit HL7 messages over Internet mail. 253 Another means of addressing these same needs is by using a private 254 network. Indeed, the vast majority of HL7 implementations today occur 255 on private networks that are entirely maintained by a single 256 organization and have restricted access outside their boundaries. 257 However, establishing and maintaining a private network across 258 geographically dispersed entities and among independent organizations is 259 an expensive proposition. Virtual private networks and value-added 260 networks also meet these needs, but the expense and the administrative 261 overhead in providing access is still substantial. 263 This recommendation meets the security requirements at the level of 264 operational expense and geographic distribution associated with public 265 Internet mail. For example, it could be economical to use these 266 recommendations for establishing communications from a physicians 267 practice system to city, county, or state health boards or among 268 regional and federal health authorities. It could also be used for 269 communications between care providers and home health systems. This 270 approach may be the most economical alternative anywhere the need for 271 timeliness is consistent with the capabilities of Internet mail. 272 Frequently the economic benefit will be sufficiently large to permit 273 applications of HL7 that would otherwise not be practical. 275 1.1 Scope 277 This document contains five categorically different kinds of 278 information: 280 1. A description of the document, its intent, scope, and limitations 281 (section 1) 283 2. Background information on Internet standards and the relevant 284 technologies (sections 2 and 3) 286 3. Specific recommendations for how to apply various Internet standards 287 and draft standards to transmit HL7 messages to meet the stated 288 requirements (section 2 and 4) 290 4. Some general discussion of how systems and organizations may choose 291 to implement these recommendations (section 6). 293 Secure HL7 Transactions using Internet Mail July 21, 1998 295 5. An example that shows the different steps and work products of a 296 complete secure HL7 transaction (section 5). 298 It is important to note that only sections 2 and 4 prescribe specific 299 formats or protocols that must be used for interoperability. 301 1.2 Limitations 303 This Recommendation is limited to exchanging authentic and private HL7 304 messages among organizations. Although one technique that it employs is 305 called digital ``signature,'' the reader should not expect to find an 306 approach for authentically determining the individual person who signs 307 orders, reports, or other information that might be contained within an 308 HL7 message. 310 The mechanisms stated in this document are based on cryptographic 311 technologies that use a pair of cryptographic keys, which allows them 312 not only to encrypt messages but also to securely identify the sender 313 and receiver of a message. These mechanisms are threatened by a number 314 of means including, but not limited to: 316 o Failure of the communicating partners to exchange their mutual public 317 keys in a trustworthy manner, 319 o Electronic attacks on systems that store those keys, 321 o Unscrupulous or careless current or former employees who deal with 322 organizational keys, 324 o Attacks on the information systems that produce or consume the actual 325 messages or handle them at intermediate points before they are 326 encrypted, 328 o Unscrupulous current or former employees who get or alter the clear 329 text messages. 331 Furthermore, the techniques here do nothing to guarantee that a 332 required message is ever initially sent. Organizations that are 333 obligated to send messages using these techniques must employ their own 334 means to ensure that their applications generate and send the initial 335 HL7 message of an exchange and that the appropriate reply is received in 336 the appropriate time frame. 338 Considerable work is underway to enhance the distribution of 339 authentic keys. This work includes the establishment of trusted 340 authorities who can dispense digital ``certificates''--combinations of a 341 name and a key that are signed by the authority. These certificates 342 provide assurance that the public keys are associated with that entity 344 Secure HL7 Transactions using Internet Mail July 21, 1998 346 they claim. This document does not require a trusted authority for 347 dispensing certificates. It is assumed that the communicating parties 348 will exchange certificates and other credentials in face-to-face 349 meetings, by fax, or using other means that they deem sufficiently 350 secure. 352 As this work is based on Internet-drafts and is itself a draft, 353 implementers must assume that there will be changes in the published 354 formats and protocol before the document and the standards upon which it 355 relies are final. This would not preclude implementations among 356 specific trading partners where they agreed to update their 357 implementations to the final versions. 359 1.3 Status 361 The document is a draft of an HL7 Recommendation with respect to its 362 applicability to HL7 versions in the 2.x series. As with all HL7 363 Recommendations, it is not intended to become an HL7 standard, will not 364 be required for a vendor to claim conformance to HL7. We do not plan to 365 present it to the American National Standards Institute for 366 certification as an ANSI standard. The intended use of this document 367 parallels that of the Lower Layer Protocols specification that HL7 368 published as appendix B of HL7 version 2.1 and as part of the 369 implementation guides for versions 2.2 and 2.3. It provides an approach 370 that organizations can agree to if they so choose. 372 The contents of this draft have been used as the basis for a 373 prototype that will be demonstrated in January 1998, at the HL7 Working 374 Group Meeting in New Orleans. Readers are invited to comment on the 375 document through the HL7 List Server.(1) 3.fM Work is underway to submit 376 essentially the same material to the Internet Engineering Task Force. 377 The commentary that follows, either through HL7 or though the IETF will 378 be the basis of modifications to this document before it is submitted 379 for ballot. 381 Sites that are interested in using this approach for prototyping or 382 on a trial basis are invited to do so. We hope that they will 383 collaborate with existing workers or report their work back through the 384 HL7 List Server. 386 This work is currently described in terms of the transfer of HL7 387 messages using e-mail. However, work is underway in the IETF to permit 388 the same techniques to be used to transfer EDI messages using the HTTP 389 protocol used by Web servers. The same techniques and formats will be 390 applicable to that communications mode. 392 Secure HL7 Transactions using Internet Mail July 21, 1998 394 1.4 Acknowledgements 396 Wes Rishel chaired the fast track group that prepared the document. 397 Gunther Schadow is the primary author with help from Mark Tucker. We 398 gratefully acknowledge the assistance of Mary Kratz, Mark Shafarman, 399 Wayne Wilson, and Rik Drummond in helping to shape its contents and sort 400 through the relevant issues. Thanks to the numerous other people, who 401 supplied comments, suggestions and encuragement. Special acknowledgement 402 to Clem McDonald, whose prudence and support made this work possible at 403 all. 405 2 How it works 407 2.1 Relevant Standards 409 This recommendation describes the exchange of HL7 messages using 410 Internet e-mail. Therefore, it is based on Internet standards and 411 depends on Internet policy and procedures. Internet standards come in 412 documents called ``Requests For Comment'' (RFC). RFC documents are 413 ASCII texts that are widely distributed on the Internet. Most major 414 public FTP sites have a subdirectory named /pub/doc/rfc where all RFCs 415 can be retrieved by their number. Each RFC has a unique number that is 416 issued sequentially. Although all Internet Standards are available as 417 RFC documents, not all RFC documents are Internet standards. There are 418 many other RFC documents of general interest describing history and 419 state of the art in networking technology. For an overview of the 420 classes of RFC documents and status of Internet standards refer to the 421 latest RFC entitled INTERNET OFFICIAL PROTOCOL STANDARDS.(1) 4.fM 423 Since this recommendation heavily depends on ongoing standardization 424 work, it is inevitable to refer to so-called ``Internet-Drafts.'' 425 Internet-Drafts are working documents of the Internet Engineering Task 426 Force (IETF), its areas, and its working groups. These documents are 427 valid for a maximum of six months and may be updated, replaced, or made 428 obsolete by other documents at any time. The Internet-Drafts referred 429 to in this Recommendation will most likely be consolidated into Internet 430 standards. However, it is expected that some details in this 431 recommendation may change in the future. Where changes are foreseeable 432 already, we have mentioned it so that implementers can prepare for the 433 upcoming standards now. In any case, it is advantageous for HL7 to make 434 an applicability statement about the use of Internet technology at that 435 early time. This allows time to realize problems that are relevant to 436 HL7 and the opportunity to influence the Internet-standardization 437 process. 439 This Recommendation describes a stack of lower layer protocols (LLP) 440 that can be used to transfer HL7 messages reliably and securely. While 441 focusing on Internet e-mail, this recommendation will be applicable for 443 Secure HL7 Transactions using Internet Mail July 21, 1998 445 other message exchange protocols with minimal changes. This flexibility 446 is possible because of a modular approach, where modules of higher 447 levels depend on modules of lower levels. If lower-level modules are 448 exchanged in order to cater to other transport protocols, the higher 449 level modules need not be touched. From lowest to highest level the 450 modules are: 452 1. Internet in general 454 2. Internet e-mail 456 3. MIME (multipurpose Internet mail extensions) 458 4. Security 460 5. Message disposition notifications 462 6. MIME-based secure EDI 464 The following table presents an overview of the documents that are 465 relevant to this recommendation. The list is compiled to clearly show 466 which documents are essential and at the same time suggest valuable 467 reading for those who might be new to Internet terms and procedures in 468 general or a specific protocol in particular. Each item has a relevance 469 indicator in the left-hand column. There are three degrees of 470 relevance: 472 R Required: An essential standard from the perspective of this 473 recommendation. Such a document is likely to depend on some other 474 Internet standard that is not referred to in this recommendation. 476 O Optional: An optional standard for which either there are or will be 477 alternatives or which can optionally be used for a specific useful 478 but non-essential purpose. 480 I Informational: A document to provide further information, contrast, 481 or background knowledge. 483 Table 1: Reference to relevant standards. 485 +----------------------------------------------------------------------+ 486 |1. Internet in general | 487 +--+------------+------------------------------------------------------+ 488 |I | RFC 1462 | FYI on ``What is the Internet?'' | 489 |I | RFC 1935 | What is the Internet, Anyway? | 490 |I | RFC 2200 | INTERNET OFFICIAL PROTOCOL STANDARDS | 491 +--+------------+------------------------------------------------------+ 493 Secure HL7 Transactions using Internet Mail July 21, 1998 495 +--+------------+------------------------------------------------------+ 496 |I | RFC 2026 | The Internet Standards Process--Revision 3 | 497 |I | RFC 1983 | Internet Users' Glossary | 498 |I | RFC 2135 | Internet Society By-Laws | 499 +--+------------+------------------------------------------------------+ 500 |2. Internet e-mail | 501 +--+------------+------------------------------------------------------+ 502 |R | RFC 822 | Standard for the format of ARPA Internet text | 503 | | | messages. | 504 |I | RFC 821 | Simple mail transfer protocol (SMTP) | 505 |I | RFC 2076 | Common Internet Message Headers | 506 |I | RFC 2068 | Hypertext Transfer Protocol--HTTP/1.1 | 507 +--+------------+------------------------------------------------------+ 508 |3. MIME (multipurpose Internet mail extensions) | 509 +--+------------+------------------------------------------------------+ 510 |R | RFC 2045 | Multipurpose Internet Mail Extensions (MIME) Part | 511 | | | One: Format of Internet Message Bodies | 512 |R | RFC 2046 | Multipurpose Internet Mail Extensions (MIME) Part | 513 | | | Two: Media Types | 514 |I | RFC 2048 | Multipurpose Internet Mail Extensions (MIME) Part | 515 | | | Four: Registration Procedures | 516 |I | RFC 2049 | Multipurpose Internet Mail Extensions (MIME) Part | 517 | | | Five: Conformance Criteria and Examples | 518 |O | RFC 2112 | The MIME Multipart/Related Content-type | 519 +--+------------+------------------------------------------------------+ 520 |4. MIME Security Multiparts | 521 +--+------------+------------------------------------------------------+ 522 |R | RFC 1847 | Security Multiparts for MIME: Multipart/Signed and | 523 | | | Multipart/Encrypted | 524 |O | RFC 2015 | MIME Security with Pretty Good Privacy (PGP) | 525 |I | RFC 1991 | PGP Message Exchange Formats | 526 |O | RFC 1848 | MIME Object Security Services | 527 |O | RFC 2311 | S/MIME Version 2 Message Specification | 528 |O | RFC 2312 | S/MIME Version 2 Certificate Handling | 529 |I | PKCS(1) #6 | Extended Certificate Syntax Standard | 530 |I | PKCS #7 | Cryptographic Message Syntax Standard | 531 |I | PKCS #10 | Certification Request Syntax Standard | 532 |I | RFC 1984 | IAB and IESG Statement on Cryptographic Technology | 533 | | | and the Internet | 534 |I | RFC 1421 | Privacy Enhancement for Internet Electronic Mail | 535 | | | (PEM): Part I: Message Encryption and Authentication | 536 | | | Procedures | 537 |I | RFC 1422 | PEM: Part II: Certificate-Based Key Management | 538 |I | RFC 1423 | PEM: Part III: Algorithms, Modes, and Identifiers | 539 |I | RFC 1424 | PEM: Part IV: Key Certification and Related Services | 540 +--+------------+------------------------------------------------------+ 542 Secure HL7 Transactions using Internet Mail July 21, 1998 544 +----------------------------------------------------------------------+ 545 |5. Message Disposition Notifications | 546 +--+------------+------------------------------------------------------+ 547 |R | RFC 1892 | The Multipart/Report Content Type for the Reporting | 548 | | | of Mail System Administrative Messages | 549 |R | RFC 2298 | An Extensible Message Format for Message Disposition | 550 | | | Notifications | 551 |I | RFC 1893 | Enhanced Mail System Status Codes | 552 |I | RFC 1894 | An Extensible Message Format for Delivery Status | 553 | | | Notifications | 554 +--+------------+------------------------------------------------------+ 555 |6. MIME-based Secure EDI | 556 +--+------------+------------------------------------------------------+ 557 |R | RFC 1767 | MIME Encapsulation of EDI Objects | 558 |R | draft- | MIME-based Secure EDI | 559 | | ietf- | | 560 | | ediint-as1 | | 561 |I | RFC 1865 | EDI Meets the Internet | 562 |I | draft- | Requirements for Inter-operable Internet EDI | 563 | | ietf- | | 564 | | ediint-req | | 565 +--+------------+------------------------------------------------------+ 566 5.fM 568 The existing lower layer protocols (LLP) that are widely used for HL7 569 versions 2.1, 2.2 and 2.3 are the minimal LLP (MLLP), the hybrid LLP 570 (HLLP), and a subset of ANSI X3.28 as described in appendix C of the HL7 571 Implementation Support Guide These three protocols have in common that 572 they require a bi-directional channel on which two HL7 applications 573 ``meet'' and exchange their messages. This mode of communication is 574 commonly known as rendezvous or synchronous communications. This is 575 because both parties meet each other at the same time on the channel, 576 and during that time their behavior is synchronized with regard to who 577 sends and who receives. 579 Conversely, HL7 communications over e-mail imply asynchronous 580 communications. Each HL7 application has a mailbox where incoming 581 messages are stored. There is no need for both applications to be 582 available at the same time, no need to wait for each other, because a 583 message can be delivered to the other's mailbox at any time. 584 Consequently, however, the sending application cannot be sure at what 585 time the receiver will process its message. For an HL7 application that 586 expects synchronous communication, it is often difficult to change its 587 design so that it can handle asynchronous communications properly. 588 However, it is possible with special EDI e-mail agents to translate 589 asynchronous to synchronous behavior. 591 Secure HL7 Transactions using Internet Mail July 21, 1998 593 Asynchronous message passing is not new to HL7 as store-and-forward 594 services are widely used today. In order to support these, the HL7 595 control committee defined different levels of acknowledgments since 596 version 2.2: accept acknowledgment and application acknowledgment. A 597 store and forward service responds with an accept acknowledgment if it 598 has taken responsibility to deliver a message to the final recipient. 599 The initiator of an HL7 transaction must nevertheless be prepared to get 600 an (unsolicited) application layer response from the final responder, 601 which can be an ORR-message from the filler application or just a 602 (possibly negative) application acknowledgment from any application. E- 603 mail messaging is conceptually very similar to the enhanced processing 604 rules of HL7.(1) 6.fM Thus, it should be straightforward to adjust for 605 e-mail communications in applications that implement the HL7 enhanced 606 processing rules. 608 2.2 E-MAIL 610 Internet mail must conform to the standard documented in RFC 822. An 611 Internet mail message consists of a header and a body. The header 612 consists of header fields that are lines of text that start with a 613 field-name followed by a colon (:) and a field-body. The field-body can 614 consist of unstructured text or can itself be structured. For example: 615 the Subject header-field of an e-mail contains unstructured text, while 616 the To header-field contains an address that has a defined format by 617 which user, host, domain, etc., are specified. 619 Header-field names are interpreted in a case-insensitive manner. 620 Although any printable ASCII character except the space and the colon 621 are allowed in header fields, the common practice is to use only letters 622 and dashes. Thus, dashes concatenate words. Often the first letter of 623 a field-name or that of each word is written in upper case; however, 624 this is just the common style. 626 Internet e-mail is typically exchanged using the simple mail transfer 627 protocol (SMTP) [RFC 821]. However, there is nothing in this 628 Recommendation that requires the use of SMTP. 630 2.3 MIME 632 The body of an RFC 822 message consists of lines of text. No special 633 provisions are made for encoding drawings, facsimile, speech, or 634 structured text. The Multipurpose(1) 7.fM Internet Mail Extension 635 (MIME) extends this. The MIME standard is defined in the RFC documents 636 2045-2049. These documents define media-types and encodings along with 637 rules that allow the extension of the basic MIME standard with new 638 media-types. Media-types specify how a given MIME message body (also 639 called entity) is to be interpreted. The encoding allows it to specify 640 an algorithm by which the lines of text found in the body of a MIME 642 Secure HL7 Transactions using Internet Mail July 21, 1998 644 entity translate into application data. Thus, MIME encodings allow the 645 sending of arbitrary binary data or text data that will be inert to 646 transformations performed by mail transfer agents. 648 Media-types are specified by a header field named Content-type. The 649 field-body contains the media-type identifier, a slash (/), and the 650 media-subtype identifier. The media type is the major category of the 651 data. The media-types used in this recommendation are text, 652 application, multipart and message. Text includes everything that is to 653 be read by humans. In this Recommendation, the only subtype of text 654 used is plain, which stands for straight ASCII text. The media-type 655 application usually represents data that is to be processed by computer 656 programs. This includes EDI messages in general and HL7 messages in 657 particular. A message media type is used to enclose Internet messages 658 (message/rfc822), to perform splitting (message/partial) or assembly 659 (message/digest), and for service messages of general relevance to 660 Internet messaging and MIME (message/disposition-notification). 662 The media type specifier is optionally followed by a semicolon (;) 663 and a list of parameters that are in turn separated by semicolons. A 664 parameter consists of a parameter-name followed by an equal (=) and a 665 value. The value should generally be enclosed in double quotes to 666 prevent misinterpretation of special characters. 668 +----------------------------------------------------------------------+ 669 |Content-Type: multipart/mixed; boundary="abc" | 670 |Content-Transfer-Encoding: base64 | 671 | | 672 |--abc | 673 | One intermediary boundary must precede the first body part. | 674 | This is the first body part | 675 | | 676 |--abc | 677 | One intermediary boundary occurs between every two body parts. | 678 | This is the second body part. | 679 | | 680 |--abc-- | 681 | The terminal boundary ends with another pair of dashes. | 682 | This is the end of the MIME entity. | 683 +----------------------------------------------------------------------+ 684 Figure 1: Use of intermediary and terminal boundaries in multiparts. 686 The media type multipart is special in that it allows the grouping of 687 other MIME entities. The entities enclosed by a multipart are usually 688 referred to as its body parts. Common multiparts include 689 multipart/mixed commonly used for e-mail attachments. A 690 multipart/report media type [RFC 1892] defines a structure for message 692 Secure HL7 Transactions using Internet Mail July 21, 1998 694 delivery status and disposition notifications. The multipart/related 695 media type [RFC 1872] is used in this recommendation in order to bundle 696 HL7 response messages with disposition notifications for the HL7 request 697 messages. 699 Boundary lines separate the body parts of a multipart. A boundary is 700 an arbitrary string of characters that begins with two dashes (--). 701 There are intermediary and terminal boundaries. Intermediary boundaries 702 are between two body parts of the same multipart MIME entity, while 703 terminal boundaries mark the end of the last body part. Terminal 704 boundaries end with two dashes. The boundary string must be defined 705 with the boundary parameter for the multipart MIME media type. 707 2.4 MIME Security Multiparts 709 An interface to the security services digital signature and encryption 710 is provided by the MIME Security Multiparts specification [RFC 1847]. 711 The MIME Security Multipart specifies a common general security 712 ``socket'', into which special security modules can be ``plugged'' in. 713 This is a very convenient approach as it can cope with the problem that 714 the final Internet message security specification is not yet defined. 715 Sections 3 and 4 are dedicated to the discussion of security. 717 2.5 Message Disposition Notifications 719 Message disposition notifications are used by the IETF working group on 720 EDI to implement non-repudiation of receipts. This concept is discussed 721 in the next two major sections. With HL7, message disposition 722 notifications are not really necessary, as HL7 has its own more powerful 723 means of keeping track of messages and transactions. If HL7 response 724 messages are signed, they convey not just non-refutable message-receipt 725 statements, but also a legally solid statement of commitment to the HL7 726 transaction. The approach of the Internet EDI working group is retained 727 here in order to be compatible with upcoming commercial software. 728 However, the group responsible for this recommendation has already 729 influenced the respective IETF working group. We will continue to 730 promote consensus for a solution that allows more concise methods for 731 interoperable secure HL7 transactions over Internet e-mail. 733 2.6 MIME-EDI 735 The IETF working group, Electronic Data Interchange (EDI), and its 736 successor group, Electronic Data Interchange--Internet Integration 737 (EDIINT), is developing standards for using the Internet for EDI 738 communications. This still ongoing effort is the heart of this 739 recommendation. Since 1994 there has been one informational RFC 1865 740 and one standards track RFC 1767 released. The standard MIME 741 Encapsulation of EDI Objects (MIME-EDI) [RFC 1767] defines the MIME 743 Secure HL7 Transactions using Internet Mail July 21, 1998 745 media types application/edifacT, application/edi-x12 and 746 application/edi-consent that are used to carry EDI messages in their 747 bodies. 749 Obviously, the standards EDIFACT and X12 have their own media 750 subtypes, while EDI-consent is meant to carry all other EDI standards. 751 This is not satisfactory for HL7 and other EDI standards organizations 752 that do not have the privilege of their own subtype. It has to be 753 noted, though, that it is not just a matter of being honored or not: the 754 subtype EDI-consent is just not interoperable. It is not interoperable 755 because the selection of the proper EDI protocol depends on site- 756 negotiations rather than being explicitly specified by the MIME subtype 757 or a parameter. In health care EDI this becomes a practical problem as 758 HL7, ASTM-E31.11, DICOM 3, X12N, EDIFACT and probably other EDI 759 protocols are often processed by the same message handling system. 760 Without an explicit protocol selector in the specification of MIME-EDI, 761 the whole approach would be unusable. 763 It is likely that a future revision of the MIME-EDI specification 764 will improve this situation. In anticipation of the definite solution, 765 an interoperable HL7 e-mail agent should recognize all three following 766 media type identifiers for HL7 messages: 768 Application/x-EDI-HL7 769 where the x- prefix is approved by Internet standards to mark media 770 subtypes that are not or not yet standardized by means of an RFC. 772 Application/EDI-HL7 773 should be accepted in anticipation of a definite standard media 774 subtype for HL7. However, today's implementations of this 775 recommendation should be conservative when sending messages and 776 progressive when accepting them. 778 Application/EDI-consent 779 can only be used in an environment where it is implicitly clear that 780 an HL7 message is expected in a MIME-EDI message. Since this is not 781 interoperable, today's implementations of this recommendation should 782 accept (if possible) but not send out HL7 messages with EDI-consent 783 subtypes. 785 To summarize, an HL7 message is sent over e-mail as follows: 787 +-------------------------------------------------------------------+ 788 | (1) Apply the traditional HL7 encoding rules to build a | 789 | presentation of an HL7 message. | 790 +-------------------------------------------------------------------+ 792 Secure HL7 Transactions using Internet Mail July 21, 1998 794 +-------------------------------------------------------------------+ 795 | (2) Transform the result of (1) into proper e-mail lines of | 796 | text either by base64 or by quoted-printable transfer | 797 | encoding. | 798 | (3) Encapsulate the result of (2) in a MIME-EDI entity by | 799 | appending it to the following two MIME header lines and | 800 | one empty line: | 801 | (4) The result of (3) is a complete MIME entity carrying an | 802 | HL7 message. You can proceed now by either of the | 803 | following: | 804 | | 805 | Content-Type: Application/x-EDI-HL7 | 806 | Content-Transfer-Encoding: base64 or quoted-printable | 807 | | 808 | | 809 | (4.1) Prepend e-mail headers [RFC 822] and send the e-mail | 810 | message to the receiver, | 811 |or (4.2) Wrap the result of (3) into MIME Security Multiparts as | 812 | described in section 4. | 813 +-------------------------------------------------------------------+ 815 For an example of an HL7 message encapsulated in MIME e-mail, please 816 refer to section 5. 818 Another problem with using the MIME-EDI specification for HL7 is that 819 there is no way to specify the encoding rules used to produce the 820 presentation of the HL7 message. Today this is a latent problem as 821 almost everyone is using the traditional HL7 encoding rules. However, 822 for HL7 version 3 there will be multiple Implementable Technology 823 Specifications (ITS). By that time, the problem will become manifest. 824 HL7 participates in the IETF to promote the following parameters for the 825 MIME-EDI media type to improve this and other shortcomings of the MIME- 826 EDI specification in the near future: 828 Syntax 829 by which encoding rules can be specified. Possible syntax- 830 identifiers would be tHL7er, ER7, XML, and BER. 832 Protocol 833 by which the EDI protocol can be specified. This will probably be 834 used if the IETF decides to keep the EDI-consent approach rather than 835 define new MIME subtypes for other EDI protocols. 837 Version 838 by which the version of the EDI protocols can be specified. For HL7 839 this could be 2.1, 2.2, 2.3, or 3.0. 841 Secure HL7 Transactions using Internet Mail July 21, 1998 843 Feature 844 by which other features of either the EDI protocol or the encoding 845 rules can be specified. 847 Please note that these parameters are not standardized yet and should 848 therefore not be produced by implementations of this recommendation. 849 Implementers who want to experiment with these features should always 850 add the x- prefix! 852 The specifications of the EDIINT group are documented in so-called 853 ``Applicability Statements'' (AS). The AS#1, MIME-based Secure EDI, 854 describes EDI message delivery using MIME extended e-mail and is the 855 basis of this recommendation. An AS#2, EDI over HTTP, extends the AS#1 856 to be useable for communication with WWW servers. HL7 is seeking to be 857 further compatible with this approach. Other applicability statements 858 will follow, including one that describes the HL7 use of the EDIINT 859 specifications. 861 3 Security I: General Issues 863 3.1 Security Services 865 When sensitive transactions are communicated over public networks, 866 security is always an issue. This is especially true when e-mail is 867 involved, because e-mail messages may be routed over unknown store-and- 868 forward servers. This means that the Internet would be inadequate to 869 convey sensitive data, unless security services are applied. There are 870 many security services. The most important services for our purpose are 871 integrity, authenticity, authorization, confidentiality and non- 872 repudiation. 874 3.1.1 Integrity 876 A receiving system needs to be sure that the messages exchanged are not 877 corrupted, either voluntarily by an offender or involuntarily through 878 technical defects. 880 3.1.2 Authenticity 882 A receiving system needs to be sure that the identity of the sender of a 883 message is as indicated. The identity of the sender is indicated by 884 either explicit information within the message, or by implicit 885 information about the environment in which the message was received 886 (e.g. remote address to which a socket is connected). However, these 887 indicators can be subject to forgery. Therefore it requires a special 888 service to determine the true sender of a message. 890 Secure HL7 Transactions using Internet Mail July 21, 1998 892 3.1.3 Authorization 894 A receiving system must decide whether the sender of a given message 895 is allowed to send that message or not. For example, if the message 896 conveys a request for a service it must be assured that the sender is 897 eligible to initiate this service. This requires that the identity of 898 the sender be known for sure, hence, authenticity is the basis for 899 authorization. 901 On the other hand, a sender submitting sensible information in a 902 message needs to be sure that only the authorized recipients of that 903 message will have access to that data. This aspect of authorization is 904 normally labeled confidentiality. 906 3.1.4 Confidentiality 908 Confidentiality means to assure that information in a message be 909 propagated only to authorized recipients and not disclosed to others. 910 However, it is important to distinguish between two different kinds of 911 unauthorized disclosure: The first is eavesdropping or interception that 912 occurs on the channel between two partners. But even though a message is 913 conveyed over a secure channel, the receiver might--voluntarily or 914 involuntarily--fail to handle the received information confidentially. 915 While interception between endpoints can readily be prevented by the 916 communication technology described in this document, assuring non- 917 disclosure at the communicating endpoints is much of a non-technical 918 issue. It requires not only that access control information be 919 exchanged, but also that a policy is in place to assure that all 920 communicating systems obey the access control information.(1) 8.fM 922 3.1.5 Non-repudiation 924 Non-repudiation is a general requirement in electronic business 925 communication. A statement that has been made electronically must have 926 the same legal dignity as one that has been made in written form on 927 paper. This is all-important, since the essence of EDI is to replace 928 paper-based communication. Business communication, whether on paper or 929 electronically, does not work without the chance to sue for and to be 930 sued for a commitment that has not been kept. Thus, non-repudiation is 931 about collecting evidence for the rare but significant cases where a 932 lawsuit is to be supported or defeated in court. 934 The security requirement for non-repudiation focuses on the 935 communicating partners and does not deal with attackers. However, 936 integrity and authenticity are the basis for non-repudiation. As long 937 as a third party could possibly forge messages, either party could 938 reasonably repudiate what has appeared to occur for the other. In EDI 939 communication in general, and for HL7 in particular, it is important to 941 Secure HL7 Transactions using Internet Mail July 21, 1998 943 distinguish three different kinds of non-repudiation: 945 1 Non-repudiation of origin is to assure that a sender of a message 946 cannot deny having sent that message including all information that 947 it contains. 949 2 Non-repudiation of receipt is to assure that a receiver of a message 950 cannot deny having been informed about the contents of that message. 952 3 Non-repudiation of commitment is to assure that neither party that is 953 involved in a transaction communicated by the exchange of messages 954 can later deny the agreement to the information exchanged and its 955 implied obligations. The difference between non-repudiation of 956 receipt versus commitment is important: to agree having received a 957 message is not the same as agreeing to what that message says. 959 3.1.6 More About Security Services 961 The security services discussed here are not the only ones known to the 962 literature, neither do they form a sufficient set to prevent against all 963 kinds of security threads. For instance time-related threads or 964 sequencing threads are not addressed by these services.(1) 9.fM 966 Obviously security services mutually depend on and overlap each 967 other. For instance, authenticity means not only that the sender of a 968 message is truly the sender, but also that the information within that 969 message is not altered by others, i.e. that the message integrity is 970 assured. To assure the integrity of a message is a special kind of 971 authorization, as write-access to the message is denied for unauthorized 972 entities. Confidentiality, on the other hand, is another special case of 973 authorization, where read-access to the message is granted only after 974 proper authorization. Authorization in turn requires identification and 975 authentication of the entity that wants to access services subject to 976 authorization. It is difficult to classify security services as of lower 977 and higher levels unless the abstract discussion is filled with concrete 978 mechanisms that implement these security services. 980 3.2 Mechanisms 982 3.2.1 Cryptographic Algorithms 984 Many security services are provided through cryptographic methods. An 985 encryption algorithm (cipher) takes a key and transforms the cleartext 986 message into a cryptogram (ciphertext) that is nearly impossible to 987 decipher without the knowledge of a key that unlocks the information. 988 Cryptoanalysis tries to guess the key of a cryptogram in order to gain 989 unauthorized access to the cleartext. Cryptoanalysis is an important 990 field of study in cryptology since only those cryptographic algorithms 992 Secure HL7 Transactions using Internet Mail July 21, 1998 994 can be considered secure that prove resistant to intensive attacks by 995 the brightest cryptologists in the world. The development of strong 996 checksum algorithms is another field of information science that has 997 many relationships to cryptology and is essential to modern 998 cryptographic technologies. 1000 3.2.1.1 Message Integrity Check 1002 Checksums have long been used in order to prove the integrity of a 1003 message. Since any communication channel bears some noise, generating 1004 and proving checksums on messages are essential disciplines in 1005 communication technology. Users of HL7 have seen checksums as check- 1006 digits (Mod 10 and Mod 11) in patient identifiers, or as the BCC or 1007 CRC-16 algorithms used in the HLLP or ANSI X3.28 lower level protocols. 1008 Cryptography, however, requires checksums that are stronger than Mod 10, 1009 Mod 11, BCC or CRC-16. The BCC algorithm is particularly weak since a 1010 modification can simply cancel out itself if it occurs at two different 1011 places in a message. 1013 With cryptographically strong checksums, also known as message 1014 digests, it is virtually impossible to modify a message while retaining 1015 the same checksum. Message digest algorithms commonly used today are 1016 MD5 (Message Digest 5), developed by Ron Rivest, and SHA-1 (Secure Hash 1017 Algorithm 1) published by the Government of the United States. MD5 1018 produces a 128-bit checksum and SHA-1 produces one with 160 bits. 1020 3.2.1.2 Symmetric Ciphers 1022 The simplest form of cryptography uses a single key for both encryption 1023 and decryption. This is what is called symmetric encryption with a 1024 secret key, since the same key is used for ciphering and deciphering and 1025 is therefore a shared secret between sender and receiver of an encrypted 1026 message. 1028 Through symmetric encryption, a message is not only protected against 1029 unauthorized interception, but also against meaningful alteration, 1030 because only someone who knows the key can produce valid cryptograms. 1031 However, symmetric encryption is unable to authenticate the originator 1032 of the message from among those who share the secret key. This helps to 1033 keep intruders out but fails to prevent repudiation and forgery among 1034 those who communicate. 1036 Because the key must be kept secret by all of the communicating 1037 partners, all of them need to trust each other. The more participants 1038 there are, the more fragile becomes the security. Whenever a 1039 participant has his copy of the key disclosed, voluntarily or not, the 1040 security is broken for all. Therefore, symmetric key encryption rarely 1041 works for more than two partners and requires that the key be frequently 1043 Secure HL7 Transactions using Internet Mail July 21, 1998 1045 +----------------------------------------------------------------------+ 1046 | | 1047 | . | 1048 | SENDER . RECIPIENT | 1049 | Key | 1050 | +--------( )--------+ | 1051 | | . | | 1052 | | . | | 1053 | | . | | 1054 | cleartext V cryptogram V cleartext | 1055 | (A)------>[ ]------>(?)------>[ ]------>(A) | 1056 | cipher . decipher | 1057 | . | 1058 | . | 1059 | | 1060 | | 1061 +----------------------------------------------------------------------+ 1062 Figure 2: The key in symmetric ciphers is a shared secret. 1064 changed, which must be negotiated through another secure channels. 1066 Typical symmetric encryption algorithms are the US Federal Data 1067 Encryption Standard (DES), which has been well known since the 1970s. 1068 It comes in many different variations. The electronic codebook (ECB) 1069 mode is the simplest and weakest and is not recommended by the US 1070 Government. Stronger but more complex modes are Cipher Feedback (CFB) 1071 and Cipher Block Chaining (CBC). Although the DES is the most widely 1072 used algorithm for commercial level cryptography, it has proved to be 1073 insecure. Even with brute-force attacks that are nothing more than 1074 trial and error, it is possible to decipher any key with the usual key 1075 length of 56 bits. It can be shown that for an investment of $10 1076 million, any DES cryptogram can be cracked within minutes. Therefore, 1077 the DES, which the US Government itself never trusted for classified 1078 data, is now considered dead for commercial applications as well. Of 1079 course, by lengthening the key by a factor of two, triple DES (DES3) 1080 could rescue the general approach, while being three times slower. 1082 The International Data Encryption Algorithm (IDEA), published in 1083 1990, is relatively new and therefore its weaknesses will be discovered 1084 only as time passes. However, it has already proved to be more 1085 resistant against one of the most challenging attacks on the DES. Many 1086 researchers and agencies are continuously trying to crack the IDEA and 1087 have so far been unable to do so. Because of this, confidence in this 1088 algorithm is growing. IDEA uses keys of a fixed length of 128 bits, 1089 which is more than DES3. 1091 Secure HL7 Transactions using Internet Mail July 21, 1998 1093 RC2 and RC4 are algorithms by RSA Data Security, Inc. that can use 1094 variable length keys. RC2 and RC4, like IDEA, are less well studied 1095 than DES. The US Government put export restrictions on software that 1096 allows more than 56 bits of key length. Since key lengths of at least 1097 128 bit are recommended for any serious application, applications 1098 created in the USA which use these algorithms cannot be used 1099 internationally. 1101 3.2.1.3 Asymmetric Ciphers 1103 As the terms symmetric encryption suggest, there is also an asymmetric 1104 encryption. Asymmetric encryption works with a pair of keys: one key is 1105 used to encrypt the data and the other is used for decryption. It does 1106 not matter which one is used for encryption, as long as the other is 1107 used for decryption. You cannot decrypt a ciphertext that was encrypted 1108 by the same key. Asymmetric encryption is also known as public key 1109 encryption, because everyone publishes one of the keys while keeping the 1110 other, the private key, very secret. 1112 +----------------------------------------------------------------------+ 1113 | | 1114 | | 1115 | Key1 | 1116 | SENDER ( ) | 1117 | | | 1118 | | | 1119 | V decipher cleartext | 1120 | (A)------>[ ]------>(?)------>[ ]------>(A) | 1121 | cleartext cipher cryptogram A | 1122 | | | 1123 | | | 1124 | ( ) RECIPIENT | 1125 | Key2 | 1126 | | 1127 | | 1128 +----------------------------------------------------------------------+ 1129 Figure 3: Asymmetric encryption uses two complementary keys. 1131 Through the policy that one key is known by everyone while the other 1132 key is kept secret to the owner, public key encryption immediately 1133 provide the following security services: 1135 Confidentiality 1136 Everyone can send data to you encrypted with your public key. This 1137 allows only you, the authorized reader, to decrypt the message with 1138 your secret key. Not even the originator can decipher this 1139 cryptogram. 1141 Secure HL7 Transactions using Internet Mail July 21, 1998 1143 Authentication 1144 You can send data to everyone encrypted with your secret key. This 1145 will not protect your data against unauthorized readers, since anyone 1146 may have access to your public decryption key and decrypt the data. 1147 You are, however, authenticated as the originator of the data, 1148 because you are the exclusive owner of the encryption key. 1150 Non-repudiation of origin 1151 As a consequence of authentication, you cannot deny being the 1152 originator of a message, because no one else could have encrypted it 1153 with your secret key. This performs a function similar to that of a 1154 signature in the world of paper documents. 1156 W. Diffie and M. Hellman discovered the first asymmetric encryption 1157 algorithm in 1976. The Diffie-Hellman (DH) algorithm is based on the 1158 problem of discrete logarithms. The algorithm supports variable key 1159 length, and is preferably used with 512 to 1024 bits. DH can be used to 1160 exchange session keys for a digital envelope, as described in the 1161 sections following. However, since it normally requires exchanging the 1162 keys before communication starts, it is suitable only in synchronous 1163 communication, and not for message passing. Moreover, DH key exchange 1164 cannot provide authentication. 1166 In 1977, R. Rivest, A. Shamir, and L. Adleman from MIT published 1167 the most widely used asymmetric encryption algorithm. The Rivest-Shamir- 1168 Adleman algorithm (RSA) is based on the problem of factoring out large 1169 integers. It allows for variable key length, where at least 512 bits 1170 are necessary and 1024 or even 2048 bits are recommended for critical 1171 applications. RSA with 1024 bit key length decrypts messages 4000 times 1172 slower than the 128 bit symmetric IDEA cipher, while 3100 bits are 1173 required in order to make an RSA cryptogram as secure as one created by 1174 IDEA.(1) 10.fM 1176 3.2.2 Cryptographic Protocols 1178 Symmetric ciphers, asymmetric ciphers, and checksums are not very useful 1179 on their own. Symmetric ciphers are inflexible concerning key 1180 management, while asymmetric ciphers are usually very inefficient in 1181 that they consume a lot of computation resources to produce cryptograms 1182 that can be cracked with a moderate effort. Message integrity checksums 1183 can only guarantee the integrity of a message if an offender is unable 1184 to replace a new checksum for the modified message. However, a 1185 combination of all three methods can provide the strength and 1186 flexibility that is required in secure communications. 1188 The combinations of these methods require protocols that specify 1189 which method is applied to which data and in which sequence. As with 1190 all protocols, such protocol frameworks that are built around 1192 Secure HL7 Transactions using Internet Mail July 21, 1998 1194 cryptographic algorithms require standardization in order to allow 1195 interoperable communications. And as with most standards, there are 1196 options, alternatives, and competitors. Regardless of how intensely 1197 this competition is fought, it is important to note that all these 1198 protocols follow the same essential design principles. They all build 1199 digital envelopes, digital signatures and certificates in mostly the 1200 same way. 1202 +----------------------------------------------------------------------+ 1203 | | 1204 | | 1205 | SENDER recipient's recipient's RECIPIENT | 1206 | public key private key | 1207 | ( ) ( ) | 1208 | generate | | | 1209 | random DEK V V DEK | 1210 | [ ]------>( )-->[ ]-->(?)-->[ ]-->( ) | 1211 | | asymm. : : asymm. | | 1212 | | cipher : : deciph. | | 1213 | V : : V | 1214 | (A)------>[ ]-------->(?)-------->[ ]------>(A) | 1215 | cleartext symm. digital symm. cleartext | 1216 | cipher envelope decipher | 1217 | | 1218 | | 1219 +----------------------------------------------------------------------+ 1220 Figure 4: Hybrid symmetric and asymmetric key encryption. The asymmetric 1221 cipher is used only to encrypt the data encryption key (DEK) while the 1222 bulk data of the message is encrypted with one of the stronger and more 1223 efficient symmetric ciphers. 1225 The competing cryptographic protocol suites that apply to e-mail are 1226 PGP v2 and S/MIME v2. Both protocol suites are used today in versions 1227 that are to be replaced in the near future. PGP v2 is replaced by 1228 ``Open PGP''(1) 11.fM and S/MIME v2 is replaced by S/MIME v3. The 1229 motivation for this change is primarily that the RSA algorithm, 1230 essential to old PGP and S/MIME v2, is encumbered with a patent and a 1231 restrictive license. This makes the world of security difficult. 1232 However, unencumbered alternatives for the RSA algorithm exist that are 1233 being used by both upcoming revisions of PGP and S/MIME. 1235 3.2.2.1 Digital Envelope 1237 The digital envelope ``wraps'' the message into a ciphertext using a 1238 symmetric algorithm with a key that is just a random sequence of bits 1239 generated for every envelope. This key is called the data encryption 1240 key (DEK) of the message and equals the session key in secure 1242 Secure HL7 Transactions using Internet Mail July 21, 1998 1244 synchronous communications. The data encryption key is in turn 1245 encrypted by an asymmetric cipher using the public key of the receiver 1246 of the message, which ``seals'' the envelope. 1248 A digital envelope is much more powerful than a paper envelope, as it 1249 allows itself to be ``opened'' only to the dedicated recipients. More 1250 than one recipient can be specified by appending the message-key 1251 encrypted with the public key of each recipient. 1253 3.2.2.2 Digital Signature 1255 Some kind of digital signature is performed when encrypting a message 1256 with one's secret key. The receiver decrypts the message with the 1257 matching public key knowing that only the holder of the secret key could 1258 have produced it. However, it is important that there be redundancy in 1259 the message by which the receiver can tell whether the decrypted data is 1260 really a meaningful message. Therefore, the digital signature only 1261 makes sense with a message digest. In order to conserve computation 1262 resources, the digital signature service is usually designed such that 1263 only the message digest is calculated over the whole message. The 1264 asymmetric encryption is done on the message digest only. 1266 +----------------------------------------------------------------------+ 1267 | | 1268 | | 1269 | SENDER sender's sender's RECIPIENT | 1270 | private key public key | 1271 | ( ) ( ) | 1272 | | digital | | 1273 | calculate MIC V signature V MIC verify | 1274 | [ ]----->( )-->[ ]--->(?)--->[ ]-->( )----->[ ] | 1275 | A asymm. : : asymm. A | 1276 | | cipher : : deciph. | | 1277 | | : : | | 1278 | (A)------------------>(A)------------------>(A) | 1279 | cleartext cleartext | 1280 | | 1281 | | 1282 +----------------------------------------------------------------------+ 1283 Figure 5: A digital signature is an encrypted message integrity check 1284 (MIC). The Data remains readable in transit, but tampering it will 1285 invalidate the signature. 1287 3.2.2.3 Certificates 1289 A certificate is a pair that includes the name of a person and its 1290 associated public key. This association, in order to be trustworthy, 1292 Secure HL7 Transactions using Internet Mail July 21, 1998 1294 must be electronically signed by someone else who guarantees that the 1295 public key really belongs to the person named in the certificate. 1296 Certificates are needed to make public key cryptosystems work. 1298 For digital signatures, this is especially obvious: you cannot trust 1299 a signature that you have never seen before, a signature whose 1300 authenticity has not been verified. Notably, the paper world works with 1301 such unverified signatures and there is always a risk that someone can 1302 place an order in another's name. If the filler has never seen the 1303 authorizing signature, he cannot tell whether it is truly authentic. 1304 The same is true for digital signatures. Certificates are used to 1305 verify the authenticity of someone's public keys, and therefore verify 1306 the authenticity of digital signatures that can be checked using that 1307 public key. 1309 The essential difficulty is that a secure communication environment 1310 cannot be synthesized de novo: There is no way to install a confidential 1311 communication without prior confidence. In the simplest case, the 1312 partners who wish to communicate securely can mutually exchange their 1313 public keys. However, at least message integrity and authenticity must 1314 be assured on the channel where the public keys are exchanged. This 1315 could ultimately be a face-to-face meeting. Conversely, exchanging 1316 public keys electronically without personal meetings is either 1317 impossible or unnecessary: it is impossible if there is no pre-installed 1318 secure electronic channel; but it is unnecessary if there is already a 1319 secure electronic channel! 1321 This dilemma can only be overcome by a third person stepping into the 1322 scene, a person, who knows one partner and his public key and whose name 1323 and public key is known and trusted by the other partner. Such a third 1324 person can ``introduce'' one partner to another. Thus, an essential 1325 component of a certificate is the digital signature of other persons who 1326 certify the association between name and public key and in whose 1327 certificates other people trust. This is the one and only way by which 1328 ``digital trust'' spreads throughout the world. 1330 There are, however, two competing architectures for establishing a 1331 confidential communication environment. One is a hierarchical 1332 organization of certification authorities who sign certificates and whom 1333 all communicating parties trust. Such an authority is also called a 1334 trusted third party (TTP). In another approach, every user acts as her 1335 own certification authority but not everyone needs to trust that 1336 authority. This approach has been called the web of trust. There is 1337 considerable competition between advocates of both approaches. However, 1338 it has to be noted that both are essentially the same: trust is mediated 1339 by third parties, regardless of whether they are organized 1340 hierarchically or more informally. Both approaches are useful in 1341 certain cases and both have their right to exist. Because both 1343 Secure HL7 Transactions using Internet Mail July 21, 1998 1345 approaches are essentially the same, both could, but are not currently, 1346 being implemented using a common interoperable protocol. 1348 3.2.2.4 Non-Repudiation 1350 All types of non-repudiation make use of the digital signature. All 1351 material that is to be protected against repudiation must be stored in 1352 the original form that was signed by the responsible person (individual 1353 or organization). In order to defeat a repudiation threat in court, 1354 that original piece of evidence along with the digital signature of the 1355 responsible person must be presented. It is not enough to log that a 1356 signature on some material had been validated if the material cannot be 1357 reproduced later in exactly the same form in which it was signed. With 1358 HL7 messages there are generally many ways to represent the same 1359 information, which is why non-repudiation requires the archiving of all 1360 inbound and outbound signed material. 1362 Although this Recommendation is about inter-systems communication 1363 rather than system architecture and policy, it is important to note that 1364 non-repudiation as a ``legal event'' requires a clear definition of who 1365 shall be held responsible for what actions or information communicated 1366 between systems. In short, the question is, who signs what? As opposed 1367 to signatures in the paper world, digital signatures can be 1368 organizational as well as individual. An organizational signature 1369 assigns responsibility to a group of individuals. Users in health care 1370 often do not communicate as individuals, but as professionals that fill 1371 certain roles. Furthermore, individual users normally do not produce 1372 HL7 messages directly so that they cannot be held individually 1373 responsible for the contents of the messages. Rather, the user 1374 interacts with one or more application programs that in cooperation with 1375 other users and programs eventually send HL7 messages. The individual 1376 user should not need to sign an HL7 message. An organizational 1377 signature should be applied on HL7 messages instead. Individual 1378 responsibilities should be tracked within, not between, the 1379 communicating systems.(1) 12.fM 1381 Non-Repudiation of Origin 1382 Non-repudiation of origin is readily implemented using digital 1383 signatures as described above. The digital signature identifies the 1384 signer and verifies the integrity of the signed information. 1386 Non-Repudiation of Receipt 1387 Non-repudiation of receipt can be established by non-repudiation of 1388 origin of a receipt statement that is returned to the sender of a 1389 message. A signed receipt notification once more requires a 1390 protocol: not only a protocol that describes message formats and 1391 contents, but also one that specifies rules of behavior with respect 1392 to when and how a receipt statement is returned. 1394 Secure HL7 Transactions using Internet Mail July 21, 1998 1396 The format of the receipt statement that is required here is 1397 described by the draft AS#1 issued by the Internet EDI working group 1398 that in turn refers to RFC 2298. Non-repudiation of receipt (NRR) is 1399 a ``legal event'' that occurs when a signed message disposition 1400 notification (MDN) has been returned by the receiver and has been 1401 checked by the sender for validity. 1403 Non-Repudiation of Commitment 1404 Non-repudiation of commitment requires that the responder of an 1405 interchange send back not just a receipt statement, but an explicit 1406 statement of commitment to the content of the message and its implied 1407 obligations. The commitment occurs on the application layer as 1408 opposed to the mere receipt statement that can be issued by transport 1409 layer agents. Some transactions seem not to require an explicit 1410 commitment statement. For instance, invoice messages do not require 1411 a commitment because the receiver of the invoice agrees to the 1412 invoice when he issues a purchase order. However, in court, the 1413 sender of the invoice cannot support his case only by presenting the 1414 invoice message and the respective receipt statement. He must rather 1415 present evidence that the invoice is justified by a purchase order 1416 and that he delivered the ordered goods. In court, no obligation can 1417 be claimed without an explicit non-refutable commitment that was made 1418 between the plaintiff and the adversary. Through non-repudiation of 1419 commitment, EDI transactions can be regarded as electronic contracts. 1421 Given this background, it is a questionable practice in many EDI 1422 protocols not to require explicit acknowledgment messages. Fortunately, 1423 HL7 is exemplary for its good practice here. Normally HL7 transactions 1424 consist of two messages, a request and a reply. The reply message often 1425 is an ACK, but it can be any other message that contains an MSA-Segment. 1426 Thus, for instance, ORM messages are correctly responded to by ORR 1427 messages. Other reply messages of HL7 v2.3 are: DSR, ADR, RRA, RRF, 1428 RRE, RRG, ORF, MFK, MFR, SRR, RPI, RPL, RPR, RCO, RCL, RPA, RRI, PRR, 1429 PPV, PGR, PTR, PPT and NMR. 1431 Because non-repudiation of commitment occurs on the application 1432 layer, only those HL7 reply messages can serve for non-repudiation of 1433 commitment that have an acknowledgment code AA (application 1434 acknowledgment). Note that an accept acknowledgment (CA) is meaningless 1435 for non-repudiation of commitment, since it can be followed by a second 1436 response message that reports an application error (AE) or application 1437 reject (AR). 1439 A signed accept acknowledgment is comparable to a signed receipt. 1440 However, it must be noted that an accept acknowledgment does not 1441 conclude an HL7 transaction. Therefore, a positive accept 1442 acknowledgment must not be misinterpreted as a statement of commitment 1443 to the application layer transaction. A signed accept acknowledgment 1445 Secure HL7 Transactions using Internet Mail July 21, 1998 1447 should, however, correctly be interpreted as the legally obliging 1448 response of a store and forward service, whose only obligation it is to 1449 forward a message to the ultimate recipient. Thus, the store and 1450 forward service can be held legally responsible for failure to deliver 1451 the message but not for failure of the ultimate recipient to comply with 1452 the message. 1454 4 Security II: Implementation Issues 1456 4.1 MIME Security in General 1458 This recommendation requires that secure e-mail communications use the 1459 MIME Security Multiparts [RFC 1847]. RFC 1847 specifies abstract 1460 classes for security services, digital signature and encryption. It 1461 does not suggest that any specific cryptographic algorithm or protocol 1462 suite be used, but acts as a common interface to any of the existing and 1463 future cryptographic suites. Today there are specializations for PGP 1464 2.6 [RFC 2015], and a general MIME Object Security Standard (MOSS) 1465 [RFC 1848]. MOSS was defined as a MIME compliant successor of PEM, the 1466 Privacy Enhanced E-Mail specification [RFC 1421-1424]. MOSS has not 1467 been widely recognized, probably due to the noise around S/MIME and PGP. 1468 S/MIME is a MIME-specification for the Public Key Cryptography Standards 1469 (PKCS) protocol suite by RSA Data Security, Inc. It has only rarely 1470 been noted that S/MIME does not completely fit into the framework of 1471 MIME Security Multiparts and the current drafts for the upcoming version 1472 3 of S/MIME do not seem to address this problem. The Open PGP protocol 1473 suite that will replace the old PGP version 2.6 will most likely plug 1474 into the MIME Security Multiparts as did its predecessor. 1476 The existing security protocol suites, PGP v2.6 and S/MIME v2, 1477 suffered from the fact that they used patented algorithms, RSA and IDEA. 1478 Because of the restrictive licensing policy of the patent holders, these 1479 algorithms do not meet the Internet community's policy that Internet 1480 standards be implementable by anyone without having to pay excessive 1481 royalties. The ongoing effort on Open PGP and S/MIME v3 will probably 1482 either change the patent holders' policies or replace the encumbered 1483 algorithms. At the present time, however, these specifications are 1484 still works in progress and are currently not available to production 1485 applications. It cannot be foreseen yet whether Open PGP or S/MIME v3 1486 will finally be selected as the standard, and it is very likely that 1487 both of them will remain widely used in the future independently of 1488 their official acceptance by the IETF. The modular approach of the MIME 1489 Security Multiparts specification allows coping with this delicate 1490 situation. It basically defines multipart/encrypted and 1491 multipart/signed media types. 1493 Secure HL7 Transactions using Internet Mail July 21, 1998 1495 4.1.1 Authenticity: Multipart/Signed 1497 The multipart/signed media type consists of two parts: The cleartext 1498 data of the message is conveyed in the first part, while the second part 1499 holds the signature for the first part. The format of the signature 1500 depends on the security protocol suite that is used. The security 1501 protocol suite is specified for the MIME multipart by a mandatory 1502 parameter named protocol. Another mandatory parameter micalg specifies 1503 the Message Integrity Check (Digest) Algorithm used for the digital 1504 signature. However, the micalg depends on the protocol and its 1505 specification is mostly redundant, although it is mandatory. Table 2 1506 gives a synopsis of the protocol and micalg parameters for signatures. 1508 Table 2: Protocols for Multipart/Signed. 1510 +---------+-----------------------------+---------+ 1511 |Suite | Protocol | MICALG | 1512 +---------+-----------------------------+---------+ 1513 |MIME-PGP | Application/pgp-signature | pgp-md5 | 1514 |MOSS | Application/moss-signature | any | 1515 |S/MIME | Application/pkcs7-signature | rsa-md5 | 1516 +---------+-----------------------------+---------+ 1518 Although the first body part contains a MIME entity in cleartext, it 1519 is important that the representation of this data be canonicalized. It 1520 must be guaranteed that no mail agent modifies the signed body part 1521 since the slightest modification would invalidate the signature. This 1522 can be assured if a proper MIME encoding is used. Base-64 encoding is 1523 usually the most efficient. If maximum human readability of the plain 1524 message is required for debugging purpose, the quoted-printable encoding 1525 can be used as well. MIME 7-bit encoding can be used only if the 1526 payload allows it, with EDI messages, this is normally not the case, 1527 even though the traditional encoding rules for EDI messages normally use 1528 only printable characters. In HL7, however, segment terminators are 1529 single carriage-return characters (ASCII code 13) which are not inert to 1530 translations in plain 7-bit e-mail messages. Therefore, signed HL7 1531 messages should always use base-64 or quoted-printable encoding. 1533 For signatures it is important to canonicalize the data to be signed 1534 before the calculation of the message digest. Canonicalization means 1535 that text data is represented in 7-bit ASCII with lines terminated by a 1536 carriage return (CR, ASCII code 13) and a line feed (LF, ASCII code 10). 1537 If a signature is calculated without canonicalization, it might be 1538 rendered invalid if the message is communicated between different 1539 operating systems. Canonicalization is done in the following steps: 1541 Secure HL7 Transactions using Internet Mail July 21, 1998 1543 +----------------------------------------------------------------------+ 1544 | (1) Generate base64 or content-transfer encoding of the | 1545 | presentation of the HL7 message. | 1546 | (2) Generate the MIME-EDI entity as described in section 2.6. | 1547 | (3) Convert the native end-of-line sequence to ASCII CR+LF. | 1548 | (4) Only then calculate the signature or the message integrity | 1549 | check. | 1550 +----------------------------------------------------------------------+ 1552 4.1.2 Confidentiality: Multipart/Encrypted 1554 The multipart/encrypted media type consists of two parts. The second 1555 part is simply an application/octet-stream, i.e., any sequence of bytes 1556 that contain an encrypted MIME entity. The first part is there to 1557 convey all necessary information in order to decrypt the second part 1558 correctly. Obviously, the first part must be specific to the security 1559 protocol suite. Its media-type is application, but its media subtype 1560 depends on the security protocol suite used for a particular message as 1561 shown in table 3. The security protocol suite is selected by a 1562 parameter protocol of the multipart/encrypted MIME entity. 1564 Table 3: Protocols for Multipart/Encrypted. 1566 +---------+---------------------------+ 1567 |Suite | Protocol | 1568 +---------+---------------------------+ 1569 |MIME-PGP | application/pgp-encrypted | 1570 |MOSS | application/moss-keys | 1571 |S/MIME | application/pkcs7-mime(1) | 1572 +---------+---------------------------+ 1573 13.fM 1575 Normally, a message should be signed and encrypted. In order to hide 1576 as much information as possible, a MIME-EDI entity after conversion to a 1577 canonical form should first be signed and then encrypted. Although some 1578 security protocol suites allow the signing and encryption of a message 1579 in a single step, this practice must not be followed according to this 1580 recommendation. The rationale is that encryption is usually required 1581 only for messages in transit over the network. When the message is 1582 finally delivered into a secure mailbox of the ultimate recipient, the 1583 digital envelope can be opened and thrown away. Conversely, it is 1584 essential that the message is always archived in its canonical form 1585 accompanied by the valid signature, as this is required to prove non- 1586 repudiation. 1588 Secure HL7 Transactions using Internet Mail July 21, 1998 1590 4.1.3 Non-repudiation of receipt: Multipart/Report 1592 An initiator of an HL7 transaction can request from the responder a 1593 signed receipt statement called a Message Disposition Notification 1594 (MDN). The request for a signed MDN is issued by including the 1595 following header lines into the e-mail message that conveys an HL7 1596 message: 1598 +----------------------------------------------------------------------+ 1599 |Disposition-Notification-To: | 1600 |Disposition-Notification-Options: signed-receipt-protocol=0,| 1601 | signed-receipt-micalg=0, | 1602 +----------------------------------------------------------------------+ 1604 The parameters and are the same as defined in 1605 table 2 for multipart/signed. 1607 Even if no signature protocol or message integrity check 1608 algorithm was requested, the responder of an HL7 message 1609 exchange should take notice of the level and methods of security applied 1610 by the initiator. When the responder sends its reply message, it should 1611 apply the same level and methods of security. Whether requested or not, 1612 we recommend that a responder always accompanies the HL7 response by an 1613 MDN receipt using the application/x-edi-response multipart specified in 1614 section 4.1.4. 1616 The responder then generates a signed receipt as follows: 1618 Secure HL7 Transactions using Internet Mail July 21, 1998 1620 +---------------------------------------------------------------------+ 1621 | (1) Create a MIME entity of type multipart/report as per | 1622 | RFC 2298. | 1623 | (2) Select a boundary string For example, use the | 1624 | following template: | 1625 | | 1626 | Content-Type: multipart/report; | 1627 | report-type="disposition-notification"; | 1628 | boundary="" | 1629 | Content-Transfer-Encoding: 7bit | 1630 | | 1631 | -- | 1632 | Content-Type: text/plain | 1633 | Content-Transfer-Encoding: 7bit | 1634 | | 1635 | | 1636 | | 1637 | -- | 1638 | Content-Type: message/disposition-notification | 1639 | Content-Transfer-Encoding: 7bit | 1640 | | 1641 | Reporting-UA: ; | 1642 | | 1643 | Final-Recipient: rfc822; | 1644 | Original-Message-ID: | 1645 | Disposition: automatic-action/MDN-sent-automatically; | 1646 | | 1647 | Received-Content-MIC: , | 1648 | | 1649 | ---- | 1650 | | 1651 | (3) If you want to append an HL7 response message continue as | 1652 | described in section 4.1.4; otherwise sign the MDN report | 1653 | as described in section 4.1.1. | 1654 +---------------------------------------------------------------------+ 1656 The above can be any string that indicates 1657 which HL7 mail agent (user agent) software has been used to receive the 1658 message and generate the report. The Original-Message-ID above repeats 1659 the RFC 822 Message-ID of the request message. The Received-Content-MIC 1660 is the message integrity check in base64 encoding of the body of the 1661 request message. This message integrity check is calculated over the 1662 same text that was subject to signature by the initiator. Note again 1663 that this text must be transformed into canonical form before the MIC is 1664 calculated. Examples for values are MD5 or SHA1, the EDIINT 1665 working group suggests using SHA1 by default. 1667 Secure HL7 Transactions using Internet Mail July 21, 1998 1669 The of the MDN indicates whether the message was processed 1670 successfully or not. RFC 2298 defines this field to be of the format 1671 /. The disposition types and 1672 modifiers that are relevant to EDI are those listed in tables 4 and 5. 1673 The EDIINT group's AS#1 document mentions only a subset of the 1674 disposition types and modifiers defined in RFC 2298. This does not, 1675 however, necessarily imply that the other types and modifiers defined 1676 for MDNs are not applicable to EDI. 1678 The normal disposition type of an EDI message is processed. It is 1679 important to take note of the exact definition of what ``processed'' 1680 actually means and what it does not mean. If not qualified by one of 1681 the modifiers error or warning, the initiator of an EDI transaction can 1682 only rely on a proper processing of the EDI request message. The result 1683 that is conveyed in the EDI response message can still be different from 1684 what the initiator expected. The statement of an MDN does therefore not 1685 obviate the need for the careful examination of the contents of the EDI 1686 response message, and does not conclude an EDI transaction as a ``legal 1687 event.'' 1689 Table 4: Disposition types that are relevant to EDI. 1691 +-----------+----------------------------------------------------+ 1692 |Type | Meaning | 1693 +-----------+----------------------------------------------------+ 1694 |processed | The message has been processed by the EDI | 1695 | | application. | 1696 |failed | The MDN receipt could not be generated. | 1697 |dispatched | The message has been forwarded to some other | 1698 | | recipient(s). | 1699 |deleted | The message has been deleted. | 1700 |denied | The return of a requested MDN receipt is denied | 1701 | | (see text). | 1702 +-----------+----------------------------------------------------+ 1704 The disposition type dispatched can be used by interface engines or 1705 other HL7 message routers to signify that the message has been forwarded 1706 to a particular recipient. In these cases, it is adequate to accompany 1707 the MDN by an HL7 accept acknowledgement as defined in the enhanced HL7 1708 processing rules. Message ``routing'' in the context of HL7 often means 1709 to determine an appropriate recipient for some information. For 1710 instance, laboratory results for a given patient should always be routed 1711 to the application that currently has care of the patient. The process 1712 of routing an encrypted EDI message normally requires unwrapping the 1713 message from the digital envelope that was addressed to the routing 1714 application and encrypting it again for the recipient to whom the 1716 Secure HL7 Transactions using Internet Mail July 21, 1998 1718 message is forwarded. 1720 If a store-and-forward service is unable to deliver some message to a 1721 final destination for a certain amount of time, it must be able to 1722 remove the message from its queue. This exceptional condition should be 1723 reported to the originator of the message. The disposition type 1724 deleted/expired is an adequate label for this case. Note that problems 1725 that occur with e-mail routing are reported by delivery status 1726 notifications and not by MDN. As explained above, EDI message routing 1727 can occur on a different level than e-mail message routing, and thus 1728 should use a different way to report problems. 1730 Table 5: Disposition modifiers that are relevant to EDI. 1732 +-----------+----------------------------------------------------+ 1733 |Modifier | Meaning | 1734 +-----------+----------------------------------------------------+ 1735 |error | An error occurred that prevented successful | 1736 | | processing. | 1737 |warning | An exception occurred, but processing was | 1738 | | successful. | 1739 |superseded | The message has been rendered obsolete by an other | 1740 | | message received. | 1741 |expired | Used with disposition type deleted. The message | 1742 | | has been automatically removed from the mailbox | 1743 | | after some time. | 1744 +-----------+----------------------------------------------------+ 1746 The deleted/superseded disposition type can be used in the situation 1747 where an EDI application received a retransmission or a correction on a 1748 message that has not yet been processed. This can occur when an 1749 initiating application has a short timeout interval, after which it 1750 retransmits the original request message if no response has been 1751 received. 1753 The EDIINT AS#1 states that an EDI mail agent must not be 1754 configurable to deny a request for an MDN receipt. Even though it may 1755 be generally reasonable to honor such a request, it certainly affects 1756 the autonomy of EDI applications concerning their administrational 1757 policy. MDNs, especially if signed, are acts of legal relevance and 1758 policy might require the withholding or denial of an MDN on a message to 1759 prevent sending an incorrect legal statement. Standardization of EDI 1760 communications should promote interoperability on a technical level. 1761 Administrational policy of autonomous systems should not be affected 1762 light-heartedly. In EDI, policy must always take precedence over 1763 technology. A technologically oriented standard that interferes with 1765 Secure HL7 Transactions using Internet Mail July 21, 1998 1767 policy forces a user to bend the standard in favor of policy. This in 1768 turn limits interoperability on the technical level. This 1769 notwithstanding, policy is a cornerstone of secure EDI messaging and 1770 should be covered in trading partner agreements. 1772 4.1.4 Non-Repudiation of Commitment: Multipart/Related 1774 A complete HL7 transaction should consist of a request message flowing 1775 from the initiator to the responder and the application response message 1776 flowing back from the responder to the initiator. When signed receipts 1777 are returned by each receiver of a MIME-EDI message, this results in 1778 four e-mail messages flowing back and fourth between initiator and 1779 responder on behalf of a single HL7 transaction. To increase 1780 efficiency, this recommendation defines a method by which an MDN receipt 1781 and an HL7 response message can be bundled. If the HL7 response message 1782 is bundled with the MDN-receipt for the request message and if the 1783 response message does not in turn request for an MDN receipt, the e-mail 1784 traffic involved with one HL7 transaction can be reduced. 1786 +----------------------------------------------------------------------+ 1787 | | 1788 | | 1789 | ............ ............ | 1790 | :I : HL7 request : R: | 1791 | :N [ ]------>(1)------>[ ] E: | 1792 | :I : MDN receipt : S: | 1793 | :T [ ]<------(2)<------[ ] P: | 1794 | :I : : : : O: | 1795 | :A [ ]<------(3)<------[ ] N: | 1796 | :T : HL7 response : D: | 1797 | :O [ ]------>(4)------>[ ] E: | 1798 | :R : MDN receipt : R: | 1799 | ............ ............ | 1800 | | 1801 | | 1802 +----------------------------------------------------------------------+ 1803 Figure 6: The normal HL7 transaction consists of two application layer 1804 HL7 messages: request and response. The MDN receipt for the request 1805 message can be bundled with the application layer HL7 response. The 1806 second MDN receipt is normally not needed. 1808 To bundle MDN receipts and HL7 response messages, create a MIME 1809 entity of type multipart/related as per RFC 1872. This MIME media type 1810 is used to send several MIME entities that relate to each other in a 1811 defined manner. The multipart/related requires one parameter type to 1812 specify the kind of relationship. For bundling an EDI response message 1813 with the MDN receipt for the respective request message, you should 1815 Secure HL7 Transactions using Internet Mail July 21, 1998 1817 specify the parameter type as application/x-EDI-response. This 1818 indicates that there are two body parts: The first body part is the MIME 1819 encapsulated HL7 response message and the second body part is the MDN 1820 receipt. 1822 For non-repudiation, a signature should be generated over the whole 1823 multipart/related entity rather than signing each of its body parts 1824 separately. This implements all three kinds of non-repudiation: 1826 1. Non-repudiation of receipt of the HL7 request message, provided that 1827 the Original-Message-ID and the Received-Content-MIC of the MDN 1828 receipt matches the request message. 1830 2. Non-repudiation of origin of the HL7 response message, provided that 1831 1 is true and the signature on the multipart/related object is valid. 1833 3. Non-repudiation of commitment of the HL7 transaction, provided that 1 1834 and 2 are true, the HL7 field MSA-1-acknowledgement-code in the 1835 response message indicates application acknowledgment (AA), and if 1836 the signature on the multipart/related entity authenticates the 1837 intended responder of the HL7 transaction. 1839 Note that for the ``legal event'' of non-repudiation of commitment to 1840 occur without multipart/related it is required that the MSA-2-message- 1841 control-ID of the response matches the MSH-10-message-control-ID of the 1842 request. However, this criterion is only reliable if truly unique HL7 1843 message control IDs are issued. Many existing HL7 applications do not 1844 issue unique message control IDs, for these cases it is required that 1845 the response be with multipart/related MIME entities. The MDN part is 1846 able to securely identify the request message with its Original-Message- 1847 ID and the Received-Content-MIC fields. 1849 Obviously, the MDN receipt carries context information about the HL7 1850 transaction that is currently negotiated by HL7 message exchange. This 1851 context information is valuable independently of any non-repudiation 1852 issues, because it allows an EDI e-mail agent to relate request and 1853 reply messages. Maintaining this relationship is called ``transaction 1854 tracking.'' A useful application of transaction tracking is an EDI e- 1855 mail agent that translates asynchronous message passing to virtual 1856 rendezvous communications. Such an e-mail agent would block the 1857 initiating process after having sent the request message until a 1858 response message is received. 1860 It is, however, not yet clear whether the MDN will be the standard 1861 way to perform EDI transaction tracking. Other alternatives are to 1862 define new header fields for transaction tracking in the application/edi 1863 MIME media type. Yet another alternative is to use RFC 822 headers from 1864 the enclosing e-mail message, such as In-Reply-To. For the time being, 1866 Secure HL7 Transactions using Internet Mail July 21, 1998 1868 using the MDN is the only standard way to convey at least some 1869 information about the transaction context of an EDI message and 1870 therefore the MDN should accompany any EDI message that is sent on 1871 behalf of some previously received EDI message. 1873 A multipart/related MIME entity of type application/x-EDI-response is 1874 generated as follows: 1876 +----------------------------------------------------------------------+ 1877 | (1) Prepare a MIME encapsulated HL7 response message as | 1878 | described in section 2.6. | 1879 | (2) Include the result of (1) as the first body part of a | 1880 | multipart/related MIME entity with a type parameter set to | 1881 | ``application/x-EDI-response.'' | 1882 | (2.1) Select a boundary string | 1883 | (2.2) Prepend the result of (1) with the following lines: | 1884 | | 1885 | Content-Type: multipart/related; | 1886 | type="application/x-edi-response"; | 1887 | boundary="" | 1888 | Content-Transfer-Encoding: 7bit | 1889 | | 1890 | ---- | 1891 | | 1892 | (2.3) Append a blank line and an intermediary boundary | 1893 | ``--'' | 1894 | (3) Prepare an MDN receipt as described in section 4.1.3 and | 1895 | append it to the result of (2). | 1896 | (4) Append a blank line and a terminal boundary | 1897 | ``----'' | 1898 | (5) The result of (4) is a complete MIME entity of type | 1899 | multipart/related that ultimately carries an HL7 message. | 1900 | Sign as described in section 4.1.1. | 1901 +----------------------------------------------------------------------+ 1903 The existence of the Disposition-Notification-To header and the 1904 bundling of HL7 responses with the message disposition notification 1905 raises the question to which destination a given pair of EDI response 1906 message and MDN is to be sent. There are a number of alternatives: 1908 1. Determine the return address from application data such as 1909 MSH-3-sending-application and MSH-4-sending-facility found in the 1910 request message. 1912 2. Use the address of the authenticated originator as determined from 1913 the signature. 1915 Secure HL7 Transactions using Internet Mail July 21, 1998 1917 3. Use the address given in the header field Disposition-Notification-To 1918 as per RFC 2298 and EDIINT AS#1. 1920 4. Use the e-mail addresses found in the RFC 822 header fields Reply-To, 1921 Return-Path, Sender, From. See also the comment found in RFC 2076. 1923 It is reasonable to define a strategy of determining the return 1924 address based on the above enumeration where the rules are listed from 1925 highest to lowest precedence. The problem is that different kinds of 1926 return material should probably be sent to different recipients. If all 1927 response material is bundled, the decision will always be a tradeoff 1928 between adhering to a particular standard and other considerations 1929 regarding security or application layer processing rules. The MDN 1930 specification clearly states that an MDN be sent to the address 1931 specified in the header field Disposition-Notification-To. Application 1932 layer consideration, however, would suggest replying to a recipient 1933 based on the content of the EDI message. Security considerations, in 1934 turn, suggest sending sensitive information to authenticated addresses 1935 only, as RFC 822 headers can be forged. Finally, if some higher 1936 precedence rule is not applicable because of missing information, the 1937 strategy must fall back to a lower precedence rule. Whatever strategy 1938 is chosen, it must be clearly defined and documented. 1940 4.2 MIME-PGP 1942 4.2.1 Overview of PGP-Services 1944 PGP services include digital envelope, signature, data compression and 1945 certificates. Data compression is relevant to security, because it 1946 reduces the redundancy of the cleartext before encryption and thus makes 1947 it harder to break the ciphertext. Normally, PGP does encryption and 1948 signature all in one step, however, this practice is not recommended in 1949 HL7 communication with MIME. 1951 Output of the PGP programs can be binary or ASCII-armored. The 1952 ASCII-armor is essentially base 64 encoding with a leading 1953 identification of the type of the PGP object. When PGP objects are 1954 encapsulated in MIME objects, one can use either the native ASCII-armor 1955 with a 7-bit MIME encoding or binary PGP output with a base 64 MIME 1956 encoding. Other combinations are possible but not reasonable, only 1957 binary PGP output with 7-bit, 8-bit or binary MIME encoding type is not 1958 allowed. 1960 The PGP 2.6.3 program by Phil Zimmerman allows to automatically 1961 canonicalize text before signing or encrypting it. This PGP 1962 canonicalization feature should not be used since the exact rules of 1963 canonicalization are more complex (such as code-page transformation) and 1964 are not specified in RFC 1991. Thus, it is likely that signatures would 1966 Secure HL7 Transactions using Internet Mail July 21, 1998 1968 differ between different implementation of PGP if canonicalization is 1969 applied. Only the simple canonicalization rule specified in section 1970 4.1.1 must always be applied in this manner! 1972 4.2.2 Digital Signature 1974 PGP supports signed data and detached signatures. The MIME Security 1975 Multiparts specifications require detached signatures. This is 1976 practically useful if applications are involved in the communications 1977 that cannot handle PGP signed data and that are not interested in 1978 authentication, integrity, or non-repudiation of origin. For example, 1979 an HL7 message router might not need that level of security. 1981 A PGP signature is appended to the HL7 message as a MIME entity of 1982 type application/pgp-signature as described in the following steps: 1984 +----------------------------------------------------------------------+ 1985 | (1) Prepare a MIME-HL7 entity as described in section 2.6. | 1986 | (2) Include the result of (1) as the first body part of a | 1987 | multipart/signed MIME entity. | 1988 | (2.1) Select a boundary string | 1989 | (2.2) Prepend the MIME-HL7 entity with the following lines: | 1990 | | 1991 | Content-Type: multipart/signed; | 1992 | protocol="application/pgp-signature"; | 1993 | boundary="" | 1994 | Content-Transfer-Encoding: 7bit | 1995 | | 1996 | -- | 1997 | | 1998 | (2.3) Append a blank line and an intermediary boundary | 1999 | ``--'' | 2000 | (3) Process the result of (2) by PGP to yield an ASCII-armored | 2001 | detached signature. | 2002 | Remember-to-sign-canonical-text-only!- | 2003 | (see section 4.1.1) | 2004 | (4) Include the output of (3) as the body of a MIME entity of | 2005 | type application/pgp-signature. | 2006 | (4.1) Prepend the PGP output with the following lines: | 2007 | | 2008 | Content-Type: application/pgp-signature; | 2009 | Content-Transfer-Encoding: 7bit | 2010 | | 2011 | | 2012 | (5) Include the output of (4) as the second body part of the | 2013 | multipart/signed MIME entity that has been created in (2). | 2014 | (5.1) Append the output of (4) at the output of (2). | 2015 +----------------------------------------------------------------------+ 2017 Secure HL7 Transactions using Internet Mail July 21, 1998 2019 +----------------------------------------------------------------------+ 2020 | (5.2) Append a blank line and a terminal boundary | 2021 | ``----'' | 2022 | (6) The result of (5) is a complete MIME entity of type | 2023 | multipart/signed that ultimately carries an HL7 message. | 2024 | You can proceed now by either of the following: | 2025 | (6.1) Prepend e-mail headers [RFC 822] and send the e-mail | 2026 | message to the receiver, | 2027 |or (6.2) Wrap it into a digital envelope as described in section | 2028 | 4.2.3. | 2029 +----------------------------------------------------------------------+ 2031 4.2.3 Digital Envelope 2033 A PGP encrypted message is appended as a MIME entity of type 2034 application/octet-stream as the second body-part of a MIME Security 2035 Multipart of type multipart/encrypted using the protocol 2036 application/pgp-encrypted. Do not use combined PGP signature and 2037 encryption. If you want a signature, make it an explicit 2038 multipart/signed MIME entity as described in section 4.2.2. 2040 +----------------------------------------------------------------------+ 2041 | (1) Prepare a MIME-HL7 entity as described in section 2.6. | 2042 | Sign this entity as described in section 4.2.2. | 2043 | (2) Process the result of (1) by PGP to yield an ASCII-armored | 2044 | digital envelope. | 2045 | (3) Create a MIME entity of type multipart/encrypted. | 2046 | (3.1) Select a boundary string | 2047 | (3.2) Prepend the result of (2) with the following lines: | 2048 | | 2049 | Content-Type: multipart/encrypted; | 2050 | protocol="application/pgp-encrypted"; | 2051 | boundary="" | 2052 | Content-Transfer-Encoding: 7bit | 2053 | | 2054 | -- | 2055 | Content-Type: application/pgp-encrypted | 2056 | Content-Transfer-Encoding: 7bit | 2057 | | 2058 | Version: 1 | 2059 | | 2060 | -- | 2061 | | 2062 | (3.3) Append a blank line and a terminal boundary | 2063 | ``----'' | 2064 +----------------------------------------------------------------------+ 2066 Secure HL7 Transactions using Internet Mail July 21, 1998 2068 +----------------------------------------------------------------------+ 2069 | (4) The result of (3) is a complete MIME entity of type | 2070 | multipart/encrypted that ultimately carries an HL7 | 2071 | message. Prepend e-mail headers [RFC 822] and send the e- | 2072 | mail message to the receiver. | 2073 +----------------------------------------------------------------------+ 2075 4.2.4 Certificates 2077 Before communications with PGP security can begin, all parties normally 2078 exchange their public keys. For most existing HL7 installations this is 2079 a sufficient and remarkably easy way to start secure communications. If 2080 there is a lot of fluctuation within the group of communication 2081 partners, it would be useful to also maintain the certificates at a 2082 central repository. Specifications and implementations for repositories 2083 of PGP public keys do exist, although there is currently no standard for 2084 this. 2086 If public keys are automatically retrievable from a repository, it is 2087 important that they are signed by someone who is trusted to certify the 2088 correctness of public keys. This can be handled very flexibly, as not 2089 everyone may trust in the same certifying person. If a central 2090 certification authority is required, this can be implemented with PGP as 2091 easily. Remember that the essence of a certification authority is not 2092 that it delivers certificates using a special protocol (such as X.509), 2093 but that it signs public keys and that this signature is trusted by 2094 anyone within the realm of the certification authority. 2096 4.3 S/MIME 2098 S/MIME is based on the Public Key Cryptography Standard (PKCS) by RSA 2099 Data Security, Inc. PKCS is a security protocol suite based on ISO/OSI, 2100 specified by ASN.1 notation and implemented using the Basic Encoding 2101 Rules (BER) [X.209] and the Distinguished Encoding Rules (DER) [X.509]. 2102 The purpose of S/MIME is to integrate PKCS into a MIME structure. 2103 However, S/MIME is not fully compliant to the MIME Security Multiparts 2104 as it only obeys the multipart/signature specification. For the digital 2105 envelope, it uses a separate MIME media type application/pkcs7-mime. In 2106 this Recommendation, we deal with S/MIME only insofar as integration 2107 into the framework of MIME Security Multiparts is concerned. Readers 2108 who want to learn more about S/MIME and PKCS should read the relevant 2109 documents RFC2311 and PKCS #7. 2111 4.3.1 Overview of PKCS-Services 2113 PKCS services include digested data, enveloped data, signed data, signed 2114 and enveloped data [PKCS #7], certificates [PKCS #6] and certificate 2115 request to certification authorities [PKCS #10]. The digital envelope 2117 Secure HL7 Transactions using Internet Mail July 21, 1998 2119 does not perform data compression prior to encryption. There is yet no 2120 standard way to compress MIME-EDI entities before encryption, however, 2121 the EDIINT working group suggests using a header field named Content- 2122 Encoding as per HTTP [RFC 2068]. This field would allow the 2123 specification that the message contents are compressed with the 2124 protocols gzip(1) 14.fM or compress(1) 15.fM PKCS #7 is a structure that 2125 allows encryption and signature all in one step. This practice, 2126 however, is not permitted in HL7 communication with MIME. 2128 The PKCS standards use the BER and DER, which means that PKCS data is 2129 binary and should be base64 encoded before being sent in an e-mail 2130 message. Canonicalization of MIME-EDI entities is still required in 2131 order to have any data that is to be signed produce the same DER 2132 encoding, regardless of the operating system. Obviously, this is an 2133 issue only for text data since binary data has no differences in 2134 representation on different systems. 2136 4.3.2 Digital Signature 2138 PKCS #7 originally supports only signed data, but the S/MIME 2139 specification defines a way to produce detached signatures. For e-mail 2140 communication, detached signatures are essential, since they are 2141 required by the MIME Security Multipart specifications. This is 2142 practically useful if sites are involved in the communications who 2143 cannot handle PKCS signed data and who are not interested in 2144 authentication, integrity and non-repudiation of origin. For example, 2145 an HL7 message router might not need that level of security. 2147 To append a PKCS signature to the HL7 message as a MIME entity of 2148 type application/pkcs7-signature, take the following steps: 2150 +----------------------------------------------------------------------+ 2151 | (1) Prepare a MIME-HL7 entity as described in section 2.6. | 2152 | (2) Include the result of (1) as the first body part of a | 2153 | multipart/signed MIME entity. | 2154 | (2.1) Select a boundary string | 2155 | (2.2) Prepend the MIME-HL7 entity with the following lines: | 2156 | | 2157 | Content-Type: multipart/signed; | 2158 | protocol="application/pkcs7-signature"; | 2159 | boundary="" | 2160 | Content-Transfer-Encoding: 7bit | 2161 | | 2162 | -- | 2163 | | 2164 | (2.3) Append a blank line and an intermediary boundary | 2165 | ``--'' | 2166 +----------------------------------------------------------------------+ 2168 Secure HL7 Transactions using Internet Mail July 21, 1998 2170 +----------------------------------------------------------------------+ 2171 | (3) Process the result of (2) to yield an S/MIME detached | 2172 | signature. | 2173 | Remember-to-sign-canonical-text-only!- | 2174 | (see section 4.1.1) | 2175 | (4) Include the output of (3) as the body of a MIME entity of | 2176 | type application/pkcs7-signature. | 2177 | (4.1) Prepend the S/MIME output with the following lines: | 2178 | | 2179 | Content-Type: application/pkcs7-signature; | 2180 | Content-Transfer-Encoding: 7bit | 2181 | | 2182 | | 2183 | (5) Include the output of (4) as the second body part of the | 2184 | multipart/signed MIME entity that has been created in (2). | 2185 | (5.1) Append the output of (4) at the output of (2). | 2186 | (5.2) Append a blank line and a terminal boundary | 2187 | ``----'' | 2188 | (6) The result of (5) is a complete MIME entity of type | 2189 | multipart/signed that ultimately carries an HL7 message. | 2190 | You can proceed now by either of the following: | 2191 | (6.1) Prepend e-mail headers [RFC 822] and send the e-mail | 2192 | message to the receiver, | 2193 |or (6.2) Wrap it into a digital envelope as described in section | 2194 | 4.3.3. | 2195 +----------------------------------------------------------------------+ 2197 4.3.3 Digital Envelope 2199 The S/MIME specification of the digital envelope does not adhere to the 2200 MIME Security Multiparts. The PKCS #7 data is directly converted to a 2201 single MIME entity of type application/pkcs7-mime. 2203 Do not use signed and enveloped data. If you want a signature, make 2204 it an explicit multipart/signed MIME entity as described in section 2205 4.3.2, and then pack it into an application/pkcs7-mime entity: 2207 +----------------------------------------------------------------------+ 2208 | (1) Prepare a MIME-HL7 entity as described in section 2.6. | 2209 | Sign this entity as described in section 4.3.2. | 2210 | (2) Process the result of (1) to yield a S/MIME | 2211 | application/pkcs7-mime entity. | 2212 | (3) The MIME entity resulting from (2) is at the same level as | 2213 | a multipart/encrypted. It ultimately carries an HL7 | 2214 | message. Prepend e-mail headers [RFC 822] and send the e- | 2215 | mail message to the receiver. | 2216 +----------------------------------------------------------------------+ 2218 Secure HL7 Transactions using Internet Mail July 21, 1998 2220 4.3.4 Certificates 2222 Before communications with PKCS security can begin, all parties normally 2223 have to register with a certification authority. If there is no such 2224 authority available, one needs to install a local certification 2225 authority service based on PKCS #10 and X.509. This approach can be 2226 downsized to the point where each user runs his own certification 2227 ``authority'' where the decisions about which certificates are trusted 2228 are completely up to the user. 2230 5 A Detailed Example 2232 This section gives a detailed example of an HL7 transaction over secure 2233 e-mail. It shows all relevant steps in building a secure e-mail from an 2234 HL7 request message, the reverse process that is applied by the 2235 responder to unwrap this HL7 message and the process of building and 2236 decomposing the response e-mail message. In order to show the relevant 2237 aspects of canonicalization of text lines explained in section 4.1.1, we 2238 assume that the initiating system is an MS-DOS PC using the end-of-line 2239 sequence , while the responding system is a UNIX system that 2240 uses a single as the line terminator. Note that the HL7 segment 2241 terminator always is the simple . In this example, the PGP suite of 2242 security protocols is used. 2244 The first step is the generation of the HL7 request message according 2245 to the rules of the application program. Suppose, for example, Dr. 2246 Schadow wants to send a new lab order message to the clinical laboratory 2247 department of Tucker General Hospital. The message requests several 2248 blood parameters related to the thyroid gland. 2250 +----------------------------------------------------------------------+ 2251 |MSH|^~\&|OE|DR.SCHADOW|LAB|TUCKER-GENERAL|...||ORM|RQ-O01-01|P|2.2| 2252 |PID|||08157411||Doe^John||19690219|M| | 2253 |PV1||O|||||0123^SCHADOW^GUNTHER||||||||||||12| | 2254 |ORC|NW|12345|||F| | 2255 |OBR||12345||||||19971226175948||7^ML||||||BLDV | 2256 |ORC|CH|12345-1|||F||12345| | 2257 |OBR||12345-1|||5383-5^THYROID MICROSOMAL AB^LN| | 2258 |ORC|CH|12345-2|||F||12345| | 2259 |OBR||12345-2|||5381-9^THYREOGLOBULIN AB^LN| | 2260 |ORC|CH|12345-3|||F||12345| | 2261 |OBR||12345-3|||5385-0^THYREOTROPIN RECEPTOR AB^LN| | 2262 +----------------------------------------------------------------------+ 2264 According to section 2.6, this message is to be wrapped into a MIME- 2265 EDI [RFC 1767] entity. The readability of this example suggests using 2266 quoted-printable transfer encoding rather than base64. Note that the 2268 Secure HL7 Transactions using Internet Mail July 21, 1998 2270 native text lines of Dr Schadow's order entry systems are terminated by 2271 the sequence . Note that in quoted printable encoding, the HL7 2272 segment terminator is transformed into the sequence ``=0D''. 2274 +----------------------------------------------------------------------+ 2275 |Content-Type: application/edi-hl7 | 2276 |Content-Transfer-Encoding: quoted-printable | 2277 | | 2278 |MSH|^~\&|OE|DR.SCHADOW|LAB|TUCKER-GENERAL|19971226175948||ORM=| 2279 ||RQ-O01-001|P|2.2=0DPID|||08157411||Doe^John||19690219|M|=0DP=| 2280 |ID|||08157411||Doe^John||19690219|M|=0DPV1||O|||||0123^SCHADO=| 2281 |W^GUNTHER||||||||||||12|=0DORC|NW|12345|||F|=0DOBR||12345||||=| 2282 |||19971226175948||7^ML||||||BLDV=0DORC|CH|12345-1|||F||12345|=| 2283 |=0DOBR||12345-1|||5383-5^THYROID MICROSOMAL AB^LN|=0DORC|CH|1=| 2284 |2345-2|||F||12345|=0DOBR||12345-2|||5381-9^THYREOGLOBULIN AB^=| 2285 |LN|=0DORC|CH|12345-3|||F||12345|=0DOBR||12345-3|||5385-0^THYR=| 2286 |EOTROPIN RECEPTOR AB^LN|=0D | 2287 +----------------------------------------------------------------------+ 2289 As a next step, the message shall be signed. A signature must be 2290 calculated over canonical text. All native line terminators must be 2291 translated to . Since in this example system the line endings 2292 are already in canonical form, no special translation step is required 2293 here. The signature is calculated over the MIME-EDI entity shown in the 2294 box above. The output of PGP is attached as the second body part of the 2295 multipart/signed MIME entity as described in section 4.2.2. 2297 +----------------------------------------------------------------------+ 2298 |Content-Type: multipart/signed; | 2299 | protocol="application/pgp-signature" | 2300 | micalg="pgp-md5"; boundary="sigbound" | 2301 | | 2302 |--sigbound | 2303 |Content-Type: application/edi-hl7 | 2304 |Content-Transfer-Encoding: quoted-printable | 2305 | | 2306 |MSH|^~\&|OE|DR.SCHADOW|LAB|TUCKER-GENERAL|19971226175948||OR= | 2307 |M|RQ-O01-001|P|2.2=0DPID|||08157411||Doe^John||19690219|M|= | 2308 |=0DPID|||08157411||Doe^John||19690219|M|=0DPV1||O|||||0123^S= | 2309 |CHADOW^GUNTHER||||||||||||12|=0DORC|NW|12345|||F|=0DOBR||123= | 2310 |45||||||19971226175948||7^ML||||||BLDV=0DORC|CH|12345-1|||F|= | 2311 ||12345|=0DOBR||12345-1|||5383-5^THYROID MICROSOMAL AB^LN|=0D= | 2312 |ORC|CH|12345-2|||F||12345|=0DOBR||12345-2|||5381-9^THYREOGLO= | 2313 |BULIN AB^LN|=0DORC|CH|12345-3|||F||12345|=0DOBR||12345-3|||5= | 2314 |385-0^THYREOTROPIN RECEPTOR AB^LN|=0D | 2321 |--sigbound | 2322 |Content-Type: application/pgp-signature | 2323 | | 2324 |-----BEGIN PGP MESSAGE----- | 2325 |Version: 2.6.3ia | 2326 | | 2327 |iQBVAwUANKPor3g+w2PflLsNAQH/iwIAnqYzaL0qs2hqItqniL1D3jpf3+9ku | 2328 |u6w5URl9G3KM9s6GzgtY0VgUCpO/gkToG3iRYLjhuKjmI2mJV76ItZMA== | 2329 |=52tL | 2330 | | 2331 |-----END PGP MESSAGE----- | 2332 | | 2333 |--sigbound-- | 2334 +----------------------------------------------------------------------+ 2336 The next step is to wrap the signed material above into a digital 2337 envelope. Note that the digital envelope can only be deciphered by the 2338 dedicated recipients of the message. 2340 +----------------------------------------------------------------------+ 2341 |Content-Type: multipart/encrypted; | 2342 | boundary="encbound"; protocol="application/pgp-encrypted" | 2343 | | 2344 |--encbound | 2345 |Content-Type: application/pgp-encrypted | 2346 | | 2347 |Version: 1 | 2348 | | 2349 | | 2350 |--encbound | 2351 |Content-Type: application/octet-stream | 2352 | | 2353 |-----BEGIN PGP MESSAGE----- | 2354 |Version: 2.6.3ia | 2355 | | 2356 |hEwDp7HUcMTu8A0BAf47c+gxPvgY90sbNmXK67p5AC0OjJ8ZYrSMJLmo6UTUU | 2357 |SyjikhDVjXSlaRK5L+rW8AzAbTcuJ3wA3y3wFrF+pgAAA/FHZhtIG/bSb0I8F | 2358 |YHK+rXFVL6zMGiVnJlrqcyHnaqQyxgAAhXwFNZODjEfuAxX5R6QzYPLZJiCAf | 2359 |9yGgHyW43qd0OqSZ1yjIazgS4JYXreRkkGvnKKI+gAHG9l9AuTqI384aKYZOX | 2360 |eIoDAOEJCVVeXiTAW4/AxZhinQDYmaLPSCExKZRx0qvFv8L5kX5VlgJ6e0MCc | 2361 |2b/K9guTM9dL0O7xyoQd5FDDwZja6mauhboGEsRzKHrpcyrgxNFL80/vLTnP5 | 2362 |TtBMc7vW6xRpW2l7NDVwpXQGi3zJU+zybRekOVg34xNcMjO/yZwfopmiCax41 | 2363 |KZu9ZW4Y2T3vkAKR6njbqvx7Y6ME6u+G+fd2wYVeCi3oI8t913ZAxn6MkO+dg | 2364 |oA4ehfdFrpSLNgSVQsgdxaS28Ew6Xuc6S4c9IVjI4xBYlo0XKzU8i5yZardXJ | 2365 +----------------------------------------------------------------------+ 2367 Secure HL7 Transactions using Internet Mail July 21, 1998 2369 +----------------------------------------------------------------------+ 2370 |hvD3o2Tm6BNCC8o3ODKTyfzbt0XamBr7oM4UfCTb29m90paxUuIonD8NWSl9H | 2371 |RCtS8ZWjlWYjMoDyDZ2ssFG0X46LVhHBSp3HR5gmhtaamTqhEG+0b/HRkc98A | 2372 |QysGFMIeZdw6SUilMHl0Vx7yZ+qimFRHVVYJVxKOCZ6weEzORdukB4rLOZNVL | 2373 |AO4lrDm6gMewehQ7nCTpaJuG1LrifeagcKAZqdQe5DkwnQRuEbh0ed1ivbVd5 | 2374 |cFTQiT5LG2i4G5Bu676WhIHoQXmBaMBlX1FaJddxdfIHoFL2J9RcfNwCka7YW | 2375 |hTGNM8PT5VSoW1Wd56BCQaOmySSaJ6C/HhGVoEQbcIElwWLiHqlGAMITlHwk8 | 2376 |UwI7mLBNugG5Z8QPfQAYlG5cSw3rwFQkfMo1GAYSQAcWK4vLZxhk84ar2jZc1 | 2377 |gdr0reXxZaso3PCchJMJ8CIPN771J64JtBRi4N2sbD5V8saPoyzTgvPVYkESs | 2378 |n+hPovIK8d/rgGNJ/WH0EXOALzmrdqmt+M2BD5einlgG9o43 | 2379 |=q5P+ | 2380 | | 2381 |-----END PGP MESSAGE----- | 2382 | | 2383 |--encbound-- | 2384 +----------------------------------------------------------------------+ 2386 This MIME entity is now prepended by RFC 822 e-mail headers and sent 2387 to the lab. The following box shows the message as received by the lab. 2388 Note that the laboratory information system runs on a different 2389 operating system that uses UNIX-style line terminators . 2391 +----------------------------------------------------------------------+ 2392 |Received: (from oe@schadow.practice.net) by edi.practice.net | 2393 | id SAA01629; Fri, 26 Dec 1997 18:26:06 +0100 | 2394 |Date: Fri, 26 Dec 1997 18:26:06 +0100 | 2395 |From: oe@schadow.practice.net | 2396 |To: lab@tucker-general.edu | 2397 |Message-Id: | 2398 |Subject: New order | 2399 |MIME-Version: 1.0 | 2400 |Disposition-Notification-To: oe@schadow.practice.net | 2401 |Disposition-Notification-Options: | 2402 | signed-receipt-protocol=0,application/pgp-signature; | 2403 | signed-receipt-micalg=0,pgp-md5 | 2404 |Content-Type: multipart/encrypted; | 2405 | boundary="encbound"; protocol="application/pgp-encrypted" | 2406 | | 2407 |--encbound | 2408 |Content-Type: application/pgp-encrypted | 2409 | | 2410 |Version: 1 | 2411 | | 2412 |--encbound | 2413 |Content-Type: application/octet-stream | 2414 | | 2415 +----------------------------------------------------------------------+ 2417 Secure HL7 Transactions using Internet Mail July 21, 1998 2419 +----------------------------------------------------------------------+ 2420 |-----BEGIN PGP MESSAGE----- | 2421 |Version: 2.6.3ia | 2422 | | 2423 |hEwDp7HUcMTu8A0BAf47c+gxPvgY90sbNmXK67p5AC0OjJ8ZYrSMJLmo6UTUUxXf | 2424 |SyjikhDVjXSlaRK5L+rW8AzAbTcuJ3wA3y3wFrF+pgAAA/FHZhtIG/bSb0I8FbUN | 2425 |YHK+rXFVL6zMGiVnJlrqcyHnaqQyxgAAhXwFNZODjEfuAxX5R6QzYPLZJiCAf5KR | 2426 |9yGgHyW43qd0OqSZ1yjIazgS4JYXreRkkGvnKKI+gAHG9l9AuTqI384aKYZOXdQN | 2427 |eIoDAOEJCVVeXiTAW4/AxZhinQDYmaLPSCExKZRx0qvFv8L5kX5VlgJ6e0MCc4VS | 2428 |2b/K9guTM9dL0O7xyoQd5FDDwZja6mauhboGEsRzKHrpcyrgxNFL80/vLTnP5iTV | 2429 |yTOwBVQ3Oc6Nr08u+3Ubl/BLzFEifnLrqRZgSlLUWgZsrR7vV7SDnVqsYoyyH6U4 | 2430 |w1sVk6TwooG6Y0oIo0tzo9cInW9CoWm8yt5oocgYwQnboHI9KR+BlHczdGNbfvtC | 2431 |SNLDzQkAwSC5jlL42pzVF1vkD9IUhDRJkkwKAGJYe488w4lKCrBeWbx7gRMzgCv3 | 2432 |UwI7mLBNugG5Z8QPfQAYlG5cSw3rwFQkfMo1GAYSQAcWK4vLZxhk84ar2jZc1H46 | 2433 |gdr0reXxZaso3PCchJMJ8CIPN771J64JtBRi4N2sbD5V8saPoyzTgvPVYkESsS/T | 2434 |n+hPovIK8d/rgGNJ/WH0EXOALzmrdqmt+M2BD5einlgG9o43 | 2435 |=q5P+ | 2436 | | 2437 |-----END PGP MESSAGE----- | 2438 | | 2439 |--encbound-- | 2440 +----------------------------------------------------------------------+ 2442 The laboratory unwraps the message from the digital envelope to yield 2443 the multipart/signed MIME entity. 2445 +----------------------------------------------------------------------+ 2446 |Content-Type: multipart/signed; | 2447 | protocol="application/pgp-signature"; | 2448 | micalg="pgp-md5"; boundary="sigbound" | 2449 | | 2450 |--sigbound | 2451 |Content-Type: application/edi-hl7 | 2452 |Content-Transfer-Encoding: quoted-printable | 2453 | | 2454 |MSH|^~\&|OE|DR.SCHADOW|LAB|TUCKER-GENERAL|19971226175948||ORM= | 2455 ||RQ-O01-001|P|2.2=0DPID|||08157411||Doe^John||19690219|M|=0DP= | 2456 |ID|||08157411||Doe^John||19690219|M|=0DPV1||O|||||0123^SCHADO= | 2457 |W^GUNTHER||||||||||||12|=0DORC|NW|12345|||F|=0DOBR||12345||||= | 2458 |||19971226175948||7^ML||||||BLDV=0DORC|CH|12345-1|||F||12345|= | 2459 |=0DOBR||12345-1|||5383-5^THYROID MICROSOMAL AB^LN|=0DORC|CH|1= | 2460 |2345-2|||F||12345|=0DOBR||12345-2|||5381-9^THYREOGLOBULIN AB^= | 2461 |LN|=0DORC|CH|12345-3|||F||12345|=0DOBR||12345-3|||5385-0^THYR= | 2462 |EOTROPIN RECEPTOR AB^LN|=0D | 2463 | | 2464 |--sigbound | 2465 +----------------------------------------------------------------------+ 2467 Secure HL7 Transactions using Internet Mail July 21, 1998 2469 +----------------------------------------------------------------------+ 2470 |Content-Type: application/pgp-signature | 2471 | | 2472 |-----BEGIN PGP MESSAGE----- | 2473 |Version: 2.6.3ia | 2474 | | 2475 |iQBVAwUANKPor3g+w2PflLsNAQH/iwIAnqYzaL0qs2hqItqniL1D3jpf3+9kuAu6 | 2476 |w5URl9G3KM9s6GzgtY0VgUCpO/gkToG3iRYLjhuKjmI2mJV76ItZMA== | 2477 |=52tL | 2478 | | 2479 |-----END PGP MESSAGE----- | 2480 | | 2481 |--sigbound-- | 2482 +----------------------------------------------------------------------+ 2484 The signature must be validated over the message text, in order to 2485 ensure that the message is authentic. When the authenticity is 2486 successfully validated, the data above can be stored into a non- 2487 repudiation log (see also section 3.2.2.4). For validation of the 2488 signature, the MIME-EDI entity must be transformed into canonical form 2489 of line terminators. 2491 +----------------------------------------------------------------------+ 2492 |Content-Type: application/edi-hl7 | 2493 |Content-Transfer-Encoding: quoted-printable | 2494 | | 2495 |MSH|^~\&|OE|DR.SCHADOW|LAB|TUCKER-GENERAL|19971226175948||ORM=| 2496 ||RQ-O01-001|P|2.2=0DPID|||08157411||Doe^John||19690219|M|=0DP=| 2497 |ID|||08157411||Doe^John||19690219|M|=0DPV1||O|||||0123^SCHADO=| 2498 |W^GUNTHER||||||||||||12|=0DORC|NW|12345|||F|=0DOBR||12345||||=| 2499 |||19971226175948||7^ML||||||BLDV=0DORC|CH|12345-1|||F||12345|=| 2500 |=0DOBR||12345-1|||5383-5^THYROID MICROSOMAL AB^LN|=0DORC|CH|1=| 2501 |2345-2|||F||12345|=0DOBR||12345-2|||5381-9^THYREOGLOBULIN AB^=| 2502 |LN|=0DORC|CH|12345-3|||F||12345|=0DOBR||12345-3|||5385-0^THYR=| 2503 |EOTROPIN RECEPTOR AB^LN|=0D | 2504 +----------------------------------------------------------------------+ 2506 After the HL7 message has been unwrapped from the MIME-EDI container, 2507 it is fed to the HL7 application of the laboratory information system, 2508 which generates the reply shown in the following box. 2510 Secure HL7 Transactions using Internet Mail July 21, 1998 2512 +----------------------------------------------------------------------+ 2513 |MSH|^~\&|LAB|TUCKER-GENERAL|OE|DR.SCHADOW|...|ORR|RP-O01-831|P|2.2| 2514 |MSA|AA|RQ-O01-001|ORDER ACCEPTED| | 2515 |PID||47110815|08157411||Doe^John|||| | 2516 |PV1||O|||||0123^SCHADOW^GUNTHER||||||||||||12| | 2517 |ORC|OK|12345|54321||SC | 2518 +----------------------------------------------------------------------+ 2520 The HL7 application also signals to the e-mail agent that the 2521 processing was successful. This information is reflected in the 2522 disposition notification status of processed. For the generation of a 2523 complete message disposition notification, described in section 4.1.3, 2524 we need to calculate a message integrity check over the same text that 2525 was subject to signature by the initiator. The message integrity check 2526 must be calculated over the same canonical text as was subject to 2527 signature validation. The MDN receipt that we create is shown next. 2529 +----------------------------------------------------------------------+ 2530 |Content-Type: multipart/report; | 2531 | report-type="disposition-notification"; | 2532 | boundary="repbound" | 2533 | | 2534 |--repbound | 2535 |Content-Type: text/plain | 2536 | | 2537 |your message has been processed | 2538 | | 2539 |--repbound | 2540 |Content-Type: message/disposition-notification | 2541 |Content-Transfer-Encoding: 7bit | 2542 | | 2543 |Reporting-UA: lab.tucker-general.edu; EDISend v1.0 | 2544 |Final-Recipient: rfc822;request@lab.tucker-general.edu | 2545 |Original-Message-Id: | 2546 |Disposition: automatic-action/MDN-sent-automatically; processed | 2547 |Received-content-MIC: 54ee0a959b7a92fdbe766538c948dbfeccdeb2,sha1 | 2548 | | 2549 |--repbound-- | 2550 +----------------------------------------------------------------------+ 2552 The MDN receipt above is bundled with the HL7 application-level 2553 response message in a special multipart/related MIME entity as explained 2554 in section 4.1.4. Again, the HL7 message has been wrapped into a MIME- 2555 EDI container with quoted-printable transfer encoding. 2557 Secure HL7 Transactions using Internet Mail July 21, 1998 2559 +----------------------------------------------------------------------+ 2560 |Content-Type: multipart/related; | 2561 | type="application/x-edi-response"; | 2562 | boundary="relbound" | 2563 | | 2564 |--relbound | 2565 |Content-Type: application/edi-hl7 | 2566 |Content-Transfer-Encoding: quoted-printable | 2567 | | 2568 |MSH|^~\&|LAB|TUCKER-GENERAL|OE|DR.SCHADOW|19971226182611||O= | 2569 |RR|RP-O01-883157170|P|2.2=0DMSA|AA|RQ-O01-001|ORDER ACCEPTE= | 2570 |D|=0DPID||47110815|08157411||Doe^John||||=0DPV1||O|||||0123= | 2571 |^SCHADOW^GUNTHER||||||||||||12|=0DORC|OK|12345|54321||SC=0D= | 2572 | | 2573 |--relbound | 2574 |Content-Type: multipart/report; | 2575 | report-type="disposition-notification"; | 2576 | boundary="repbound" | 2577 | | 2578 |--repbound | 2579 |Content-Type: text/plain | 2580 | | 2581 |your message has been processed | 2582 | | 2583 |--repbound | 2584 |Content-Type: message/disposition-notification | 2585 |Content-Transfer-Encoding: 7bit | 2586 | | 2587 |Reporting-UA: lab.tucker-general.edu; EDISend v1.0 | 2588 |Final-Recipient: rfc822;request@lab.tucker-general.edu | 2589 |Original-Message-Id: | 2590 |Disposition: automatic-action/MDN-sent-automatically; processed | 2591 |Received-content-MIC: 54ee0a959b7a92fdbe766538c948dbfeccdeb2,sha1 | 2592 | | 2593 |--repbound-- | 2594 | | 2595 |--relbound-- | 2596 +----------------------------------------------------------------------+ 2598 The signature that is applied over the bundle of MDN receipt and HL7 2599 response performs non-repudiation of receipt of the HL7 request message, 2600 non-repudiation of origin of the HL7 reply message, and non-repudiation 2601 of commitment to the transaction implied by the given pair of HL7 2602 messages. In this case, the laboratory system committed itself to fill 2603 all ordered tests at some time after the specimen has been received. A 2604 digital signature, again, must be calculated over canonical text. This 2605 time the line terminators must be explicitly translated to canonical 2606 form. 2608 Secure HL7 Transactions using Internet Mail July 21, 1998 2610 +----------------------------------------------------------------------+ 2611 |Content-Type: multipart/related; | 2612 | type="application/x-edi-response"; | 2613 | boundary="relbound" | 2614 | | 2615 |--relbound | 2616 |Content-Type: application/edi-hl7 | 2617 |Content-Transfer-Encoding: quoted-printable | 2618 | | 2619 |MSH|^~\&|LAB|TUCKER-GENERAL|OE|DR.SCHADOW|19971226182611||O= | 2620 |RR|RP-O01-883157170|P|2.2=0DMSA|AA|RQ-O01-001|ORDER ACCEPTE= | 2621 |D|=0DPID||47110815|08157411||Doe^John||||=0DPV1||O|||||0123= | 2622 |^SCHADOW^GUNTHER||||||||||||12|=0DORC|OK|12345|54321||SC=0D= | 2623 | | 2624 |--relbound | 2625 |Content-Type: multipart/report; | 2626 | report-type="disposition-notification"; | 2627 | boundary="repbound" | 2628 | | 2629 |--repbound | 2630 |Content-Type: text/plain | 2631 | | 2632 |your message has been processed | 2633 | | 2634 |--repbound | 2635 |Content-Type: message/disposition-notification | 2636 |Content-Transfer-Encoding: 7bit | 2637 | | 2638 |Reporting-UA: lab.tucker-general.edu; EDISend v1.0 | 2639 |Final-Recipient: rfc822;request@lab.tucker-general.edu | 2640 |Original-Message-Id: | 2641 |Disposition: automatic-action/MDN-sent-automatically; | 2642 | processed | 2643 |Received-content-MIC: 54ee0a959b7a92fdbe766538c948dbfecc,sha1 | 2644 | | 2645 |--repbound-- | 2646 | | 2647 |--relbound-- | 2648 +----------------------------------------------------------------------+ 2650 The response and its signature are packed into a multipart/signed 2651 MIME entity. 2653 +----------------------------------------------------------------------+ 2654 |Content-Type: multipart/signed; | 2655 | protocol="application/pgp-signature"; | 2656 +----------------------------------------------------------------------+ 2658 Secure HL7 Transactions using Internet Mail July 21, 1998 2660 +----------------------------------------------------------------------+ 2661 | micalg="pgp-md5"; boundary="sigbound" | 2662 | | 2663 |--sigbound | 2664 |Content-Type: multipart/related; | 2665 | type="application/x-edi-response"; | 2666 | boundary="relbound" | 2667 | | 2668 |--relbound | 2669 |Content-Type: application/edi-hl7 | 2670 |Content-Transfer-Encoding: quoted-printable | 2671 | | 2672 |MSH|^~\&|LAB|TUCKER-GENERAL|OE|DR.SCHADOW|19971226182611||O= | 2673 |RR|RP-O01-883157170|P|2.2=0DMSA|AA|RQ-O01-001|ORDER ACCEPTE= | 2674 |D|=0DPID||47110815|08157411||Doe^John||||=0DPV1||O|||||0123= | 2675 |^SCHADOW^GUNTHER||||||||||||12|=0DORC|OK|12345|54321||SC=0D= | 2676 | | 2677 |--relbound | 2678 |Content-Type: multipart/report; | 2679 | report-type="disposition-notification"; | 2680 | boundary="repbound" | 2681 | | 2682 |--repbound | 2683 |Content-Type: text/plain | 2684 | | 2685 |your message has been processed | 2686 | | 2687 |--repbound | 2688 |Content-Type: message/disposition-notification | 2689 |Content-Transfer-Encoding: 7bit | 2690 | | 2691 |Reporting-UA: lab.tucker-general.edu; EDISend v1.0 | 2692 |Final-Recipient: rfc822;request@lab.tucker-general.edu | 2693 |Original-Message-Id: | 2694 |Disposition: automatic-action/MDN-sent-automatically; processed | 2695 |Received-content-MIC: 54ee0a959b7a92fdbe766538c948dbfeccdeb2,sha1 | 2696 | | 2697 |--repbound-- | 2698 | | 2699 |--relbound-- | 2700 | | 2701 |--sigbound | 2702 |Content-Type: application/pgp-signature | 2703 | | 2704 |-----BEGIN PGP MESSAGE----- | 2705 |Version: 2.6.3ia | 2706 | | 2707 +----------------------------------------------------------------------+ 2709 Secure HL7 Transactions using Internet Mail July 21, 1998 2711 +----------------------------------------------------------------------+ 2712 |iQBVAwUANKPotKex1HDE7vANAQFYtgH9EZA4gWleqqZYUhTVsoLcYtykALNKCkqW | 2713 |nCYsPbnL43YSnuL0dWEavfoWT9i08QtzAVM+73Lhxm4bqJNjY+F/oA== | 2714 |=ldjq | 2715 | | 2716 |-----END PGP MESSAGE----- | 2717 | | 2718 |--sigbound-- | 2719 +----------------------------------------------------------------------+ 2721 Finally the signed response is encrypted and sent as an RFC 822 e- 2722 mail message back to the authenticated sender of the request message. 2724 +----------------------------------------------------------------------+ 2725 |From: lab@tucker-general.edu | 2726 |To: oe@schadow.practice.net | 2727 |Date: Fri, 26 Dec 1997 18:26:11 +0100 | 2728 |Message-Id: | 2729 |In-Reply-To: | 2730 |Subject: Re: New order | 2731 |MIME-Version: 1.0 | 2732 |Content-Type: multipart/encrypted; boundary="encbound"; | 2733 | protocol="application/pgp-encrypted" | 2734 | | 2735 |--encbound | 2736 |Content-Type: application/pgp-encrypted | 2737 | | 2738 |Version: 1 | 2739 | | 2740 |--encbound | 2741 |Content-Type: application/octet-stream | 2742 | | 2743 |-----BEGIN PGP MESSAGE----- | 2744 |Version: 2.6.3ia | 2745 |hEwDeD7DY9+Uuw0BAf0eLhV0xFGF9EQbe1OtcqnZQGWXhOEw+/8ibnHQ2BGHa | 2746 |zEsazOmBOiyf+gGm79ISQY83rZkZ0McHn4Yne72cpgAABdnTCq9qY6XrA1vmt | 2747 |HQT3WS5qU7aMSFcKusfVUmkW2Cy/RZrJBqV9bKuH2n3i01OcIBQVbHdUC01uH | 2748 |nvmn/J7tktA9b0W5yAWLaGbCufsyaZxJyS7e7JooAzrYx5Y229Lhgtykb9r2V | 2749 |GAqvd/qgN2ZPvDhkyfh0p58bHv+ePQqVB979GMLblagOUdp6XtBtl3uDD8h73 | 2750 |FgHpnP88M+U6AJReTgQAe01DKmUD4NaKxkZyPuHi9V/GCZdkCBZGOzBae2g3a | 2751 |fSo2aNqgjHGieF8CfJCHcMZKFgq8XNURQhAl+zcU02DpdH/aOnqWO3fPo5gCf | 2752 |cb3Nthm9vLIsQRA78TJAsxbKv8TVBQChutzDm19qdWemR5lmUIjheKEINd9nn | 2753 |HQ3oP0PC1PCNxJ7FWgUMxE3xZ6AaAC12YVSg14br6CFdCaDOA55flnNiLvdoC | 2754 |Llxi3UBsBGtaSfTsF5gtgumlV3xPpaS02c3sl7Mc7xcQkrg33smTkx3nhQDXs | 2755 |u4Ed1X67OOMTGVSbI5cGC1CYOI867ogI2B7Z0U274oQNH71xWchSHfbLwu7z9 | 2756 |wYnVZQLbb2ncmBArcPoCnIznfQ7COnmPwkFHNTNV55Cif12JxZXdQyEnDbMnK | 2757 +----------------------------------------------------------------------+ 2759 Secure HL7 Transactions using Internet Mail July 21, 1998 2761 +----------------------------------------------------------------------+ 2762 |Deyq6pHzaguq3PKxKt37aQtK1QSvhwBvcO4SMH5zJU/OR1R2Z+9ZpIeFoh79e | 2763 |LJZ60VAOuQ/lzejE8EI8R2Bcm9/GPRtCH6+CIEC2xgW/JfvyOtGcWUhVHrwGz | 2764 |jatqBGdqxyampHcGgnB1hPQVfhRzoI0jPdeEC5MBzD2feoTOj97MhGbx2oT8s | 2765 |FArMifectOLqayU3ELjGOdG6KvEc2sv68xeCv481yj3AoK6V3tvRJyukSaUXD | 2766 |yHUusUPyoZ4FTNjaXvHwEUmDkphT5XwithhKtr38id6eG+XubJMd1vKRbbsu5 | 2767 |90y+kGINWpAozwJY79Hf4v5dIMkTVYJdTRvTQgeMhkytSmbc4ONr40FLfcyCV | 2768 |tAYpLqVTsnLMblwPnS0qVNSZi72UD7G/1Lf2dpXzUh8PrNTbAWbMCeB/xrifC | 2769 |wAGjAEqRxFJKFwl2IHgoewEM/Yxt9L0DuPdB/ow8kF301p80iHZ1NL0V4lM= | 2770 |=wyMm | 2771 | | 2772 |-----END PGP MESSAGE----- | 2773 | | 2774 |--encbound-- | 2775 +----------------------------------------------------------------------+ 2777 Back at Dr. Schadow's order entry system, this message is decrypted 2778 and checked for authenticity. Then the disposition status is examined 2779 (section 4.1.3) and validated that the Received-content-MIC matches the 2780 originally sent request message. Finally, the HL7 response is consumed 2781 by the order entry application to validate if the order was accepted in 2782 all parts. 2784 6 Architectural and Operational Considerations 2786 The previous sections provide a roadmap of the relevant Internet 2787 standards, background information on encryption and the MIME e-mail 2788 formats, and detailed specifications of messages and how their content 2789 should be created. They are directed towards the implementers of the e- 2790 mail handling programs. This section examines a series of operational 2791 and architectural issues. It illustrates how the pieces can be fit 2792 together with existing TCP/IP based HL7 applications routers and 2793 firewalls. It further shows one way to provide the journalizing 2794 function necessary to disprove attempts to repudiate the sending and 2795 processing of a message. It discusses some specific issues in HL7 2796 transaction design that are related to the e-mail medium. Finally, it 2797 touches on issues in negotiating interfaces when the sending and 2798 receiving systems are not operated by the same organization. 2800 This section is not normative; its purpose is simply to illuminate 2801 issues that must be considered in applying the material of the previous 2802 section. 2804 6.1 Process Structure of the E-mail Handling Machine 2806 In this architectural model, the e-mail handling software will run on a 2807 designated machine for an institution. Incoming EDI e-mail messages 2808 will be directed to that machine. Processes on that machine will decode 2810 Secure HL7 Transactions using Internet Mail July 21, 1998 2812 the e-mail, recover the original HL7 message, and then transmit via 2813 TCP/IP to pre-existing HL7 applications that expect conventional TCP 2814 communication. 2816 +----------------------------------------------------------------------+ 2817 | | 2818 | | 2819 | .................................. | 2820 | :sendmail ; MIME ward@... : | 2821 | ( )------>[ ]------->( )content : | 2822 | e-mail : .; | : | 2823 | : ; | HL7email : | 2824 | : ; V handler HL7 : | 2825 | : ; o<--[ ]------->( )payload : | 2826 | :; | A | : | 2827 | : V | | : | 2828 | : PGP[ ]-->o V HL7 : | 2829 | : [ ]processor: | 2830 | .................................. | 2831 | edi@yourhospital.com | 2832 | | 2833 | | 2834 +----------------------------------------------------------------------+ 2835 Figure 7: Directing incoming e-mail to a program that processes HL7 2836 messages. 2838 Under the Unix operating system, e-mail arriving at a machine is 2839 handled by an SMTP server (normally a process named sendmail) listening 2840 on a well-known port. Sendmail examines the incoming mail, and if the 2841 address is local, it attempts to deliver it. Normally, sendmail appends 2842 it to the user's mailbox file, where the user's e-mail reading software 2843 will deal with it. However, it is possible to have sendmail process 2844 certain e-mail addresses through a program, instead of sending it to a 2845 mailbox. 2847 Consider the example depicted in figure 7. An encrypted EDI message 2848 arrives by e-mail addressed to ward@edi.yourhospital.com. The sending 2849 application created an HL7 message (aPayload.hl7) and constructed a MIME 2850 format e-mail message. The e-mail message arrived at the e-mail handing 2851 machine, edi.yourhospital.com addressed to ward@edi.yourhospital.com. On 2852 Unix systems, someone will have made an entry in the file /etc/aliases 2853 to inform sendmail that mail to the ``user'' ward should be piped to the 2854 program HL7emailhandler with arguments ``-u ward -.'' The special e-mail 2855 handling process HL7emailhandler will be told to use the passwords 2856 associated with the facility named ward, and to read the actual e-mail 2857 message from standard input. 2859 Secure HL7 Transactions using Internet Mail July 21, 1998 2861 HL7emailhandler will take the MIME formatted message, parse it 2862 according to the MIME specifications, and extract an encoded data file. 2863 HL7emailhandler will then call on external encryption programs such as 2864 pgp to decrypt the message, yielding a clear text message in pure HL7 2865 format, here denoted as the file aPayload.hl7. It then passes this pure 2866 HL7 message to the rest of the HL7 processing machinery as a regular HL7 2867 message. 2869 The figure also shows that one can use standard distributions of 2870 encryption software (such as PGP), and that one can constrain the 2871 security of the private keys to the one machine that handles e-mail 2872 (edi.yourhospital.com). In this case, the file 2873 /usr/ward/.pgp/secring.pgp contains the secret key for your institution. 2874 The secret key file is not itself usable by interlopers since the key 2875 itself is encrypted with a somewhat short passphrase, but access to this 2876 file should nonetheless be protected. 2878 +----------------------------------------------------------------------+ 2879 | | 2880 | | 2881 | ( )-------------+ | 2882 | email | | 2883 | V gatekeeper.yourhospital.com | 2884 | ####[G]############################# | 2885 | # | # | 2886 | # | .................... # | 2887 | # V : ; : # | 2888 | # ( )----->[ ]..; ward@... : # | 2889 | # email : ; : # | 2890 | # : ; : # | 2891 | # :; : # | 2892 | # :................... # | 2893 | # edi@yourhospital.com # | 2894 | #FIREWALL # | 2895 | #################################### | 2896 | | 2897 | | 2898 +----------------------------------------------------------------------+ 2899 Figure 8: HL7 using e-mail can pass a firewall through a gatekeeping 2900 router. The gatekeeper needs not unwrap the message from its protecting 2901 envelope. 2903 Firewall systems are an important part of the security measures in 2904 place in most sites. They serve as the only link between the systems on 2905 the Local Area Network (LAN) and the Internet at large. They shield the 2906 interior systems from most attacks by outsiders trying to retrieve or 2907 alter information. Figure 8 shows that EDI e-mail is no more 2909 Secure HL7 Transactions using Internet Mail July 21, 1998 2911 constrained by firewalls than any other Internet mail. Most firewall 2912 products are designed to pass e-mail carefully between interior machines 2913 and the outside world. E-mail messages are passed unchanged from the 2914 outside to the inside. Since some sites want to keep secret the machine 2915 names of interior machines, the sender address and the Message-Id field 2916 of outgoing messages are sometimes changed or scrambled by the firewall. 2917 The sender constructs its e-mail message, and sends it to the public e- 2918 mail address, edi@gatekeeper.yourhospital.com. The firewall system maps 2919 the user edi to an interior address edi@edi.yourhospital.com where it is 2920 handled as before. 2922 The approach described in this document does not fail when firewall 2923 systems alter e-mail messages to hide the interior addresses. 2925 6.2 Coexistence of E-mail and TCP/IP Based Communications 2927 A site can easily integrate E-mail based communication with existing TCP 2928 based HL7 applications. Suppose that an institution already has several 2929 TCP/IP based HL7 applications. It can create its version of 2930 HL7emailhandler to converse with remote senders using MIME formatted e- 2931 mail messages. On reception, HL7emailhandler recovers the pure HL7 2932 payload, then makes a standard TCP connection to the existing TCP based 2933 applications. The existing applications will operate without 2934 modifications. The ACK message flowing back from the existing 2935 application will be bundled into a MIME message and sent to the remote 2936 sender 2938 Installations using a router, mediator, or gateway product for 2939 messaging easily accommodate e-mail clients. The router will gain only 2940 one new TCP connection to the HL7emailhandler. 2942 As will be discussed in section 6.4, this architecture may be more 2943 appropriate for existing applications that are accepting unsolicited 2944 updates or queries. Applications that initiate updates or queries may 2945 not function without modification if they wait for a synchronous reply. 2947 Depending on the router product in use, there may be a drawback for 2948 this architecture. The HL7emailhandler may need to take on many of the 2949 functions of a router. It may need to inspect the HL7 payloads coming 2950 from the Router to determine the actual recipient, and then re-mail the 2951 HL7 messages accordingly. 2953 A simpler approach may be to use separate e-mail addresses for 2954 separate HL7 applications, and run many HL7emailhandler processes. To 2955 external applications, each internal application will have its own e- 2956 mail address, e.g., lab@edi.yourhospital.com, adt@edi.yourhospital.com, 2957 repository@edi.yourhospital.com. To internal applications, each external 2958 system would appear as a separate TCP port. 2960 Secure HL7 Transactions using Internet Mail July 21, 1998 2962 +----------------------------------------------------------------------+ 2963 | | 2964 | | 2965 | lab | 2966 | [ ]<------TCP-----+ | 2967 | A | | 2968 | remote[A]<--+ |tcp | | 2969 | | .............. V | | 2970 | | : surrogates : +------+ | | 2971 | +--->[A 9012]<--TCP-->|router| V | 2972 | remote[B]------->[B 9013]<--TCO-->| |<--TCP-->[ ]repository | 2973 | +--->[C 9014]<--TCP-->| hub | A | 2974 | | : : +------+ | | 2975 | | .............. A | | 2976 | remote[C]<--+ edi@yourhosp.com |tcp | | 2977 | V | | 2978 | [ ]<-----TCP-----+ | 2979 | adt | 2980 | | 2981 | | 2982 +----------------------------------------------------------------------+ 2983 Figure 9: The e-mail handler relays messages to existing HL7 2984 applications. Surrogate processes provide separate TCP services for each 2985 remote destination. The internal communication that may or may not use a 2986 router hub can treat the remote hosts as if they where local TCP 2987 servers. 2989 In this scenario, depicted above, each remote application has a 2990 ``surrogate'' process running on the HL7emailhandler machine. The 2991 surrogate acts as a TCP listener for a single remote e-mail client. 2992 Incoming messages are accepted, and retransmitted via e-mail to the 2993 actual recipient process. For example, when the router wants to send a 2994 message to the system ``Remote A'', its routing tables tell it to send a 2995 standard TCP message to port 9012 on your edi.yourhospital.com machine. 2996 Listening at port 9012 is a copy of the HL7emailhandler software that 2997 accepts the connection, mimics an accept ACK back to the router, then 2998 sends the HL7 payload off in MIME format via e-mail to the remote 2999 machine A. 3001 This architecture works without adding special routing functionality 3002 to the institution's version of HL7emailhandler. Existing HL7 3003 applications are told that three new applications exist. ``Remote A'' 3004 running on a local machine at port 9012, ``Remote B'' at 9013, and 3005 ``Remote C'' at 9014. 3007 Secure HL7 Transactions using Internet Mail July 21, 1998 3009 6.3 Logging Messages and Receipts 3011 One of the important requirements for sending e-mail messages via 3012 Internet mail is non-repudiation. Previous sections have shown how the 3013 appropriate combinations of message digests and digital signatures can 3014 allow a receiver to prove that the message it has received must have 3015 been originated by its putative sender. This requires a copy of the 3016 message as it was sent. In case of dispute, the receiver will not want 3017 to rely on the sender to provide a copy of the disputed message. 3019 When an organization sends a message it needs to be able to prove 3020 that the message was received, processed and agreed upon by the 3021 recipient. This requires copies of the original message and receipt 3022 messages that were returned. 3024 Establishing that certain messages were exchanged and accepted 3025 requires the organization to maintain two logs (outgoing.log, 3026 incoming.log), and, perhaps, a very small database of sent but not yet 3027 acknowledged messages (pending_messages.db). 3029 The HL7emailhandler process should maintain an outgoing.log file 3030 containing the e-mail messages it sent. Each entry in the outgoing.log 3031 can be a simple copy of the message it sent. In this case, by adding 3032 the line ``From edi@edi.yourhospital.com'', the file becomes a standard 3033 UNIX mailbox format file, that can be browsed by all most mail programs 3034 including Netscape. In order to allow quick searching and browsing it is 3035 recommendable to save the outgoing message in an unencrypted form after 3036 it is signed. 3038 +----------------------------------------------------------------------+ 3039 |From edi@edi.yourhospital.com | 3040 |To: edi@edi.somehosptial.com | 3041 |Content-type: mutlipart/encrypted; boundary="edi-msg-29292" | 3042 |Content-encoding: 7bit | 3043 |Message-id: 321431 | 3044 | ... | 3045 |--edi-msg-29292 | 3046 |Content-transfer-encoding: base64 | 3047 | | 3048 |aa78hh989hff5fkn99fkj24aserfakjfasodi2afmlsakfl32irafs | 3049 | ... | 3050 +----------------------------------------------------------------------+ 3052 If the organization ever needs to prove a message was sent, it can 3053 analyze each entry to recover the Message-id and the original HL7 3054 message. From this, it can compute the checksum of the original HL7 3055 message payload. These disputes should be very rare. The organization 3057 Secure HL7 Transactions using Internet Mail July 21, 1998 3059 can post-process the log files when the occasion demands and need not 3060 keep an index to the log files. The processed log will be the 3061 equivalent of a table of which table 6 is an example. 3063 Table 6: Journalized outgoing messages. 3065 +--------------------------------------------+ 3066 |Message-id Checksum Contents | 3067 +--------------------------------------------+ 3068 |321431 78920BD43 MSH|...|ORU... | 3069 |12342 02C89FC9 MSH|...|ADT^A02... | 3070 +--------------------------------------------+ 3072 If the organization can prove that a destination received the message 3073 with ID 321431 with checksum 78920BD43, then our recovered table can 3074 produce the HL7 message that had that checksum. 3076 As messages are sent, the organization will construct a 3077 PendingMessage file. Table 7 continues the example. 3079 Table 7: Pending messages file. 3081 +-----------------------+ 3082 |Message-Id Checksum | 3083 +-----------------------+ 3084 |321431 78920BD43 | 3085 |12342 02C89FC9 | 3086 +-----------------------+ 3088 For each outgoing message sent, a Message Disposition Notification 3089 will eventually be returned to us, containing an Original-Message-ID 3090 (e.g., 321431) and a Received-Content-MIC (e.g., 78920BD43). 3092 The HL7emailhandler will copy the full text of all incoming messages 3093 to incoming.log, and immediately extract the Message-id and the 3094 Received-content-MIC. 3096 Next, it will check its file pending_messages.db , find that message 3097 id 321431 indeed had checksum 78920BD43, and remove that entry from the 3098 pending message file. Should it find a disparity, it can alert 3099 personnel for corrective action. Any corruption of the original e-mail 3100 message should have been detected by the responder, and our message 3101 should have been rejected. It is almost certainly a software error for 3102 the responder to accept our message, and yet compute a different 3104 Secure HL7 Transactions using Internet Mail July 21, 1998 3106 checksum. 3108 A program must periodically examine the file pending_messages.db for 3109 outgoing messages. It will notify personnel to initiate corrective 3110 actions for outgoing messages that have not been matched with replies 3111 after a suitable period. 3113 6.4 Interface Negotiations for HL7 over E-mail 3115 Two overriding characteristics influence the implementation of HL7 over 3116 e-mail: the medium itself and the fact that the sending and receiving 3117 systems are not operated by the same organization. The response times 3118 in the e-mail medium are much slower and more variable than those that 3119 can be achieved with direct virtual circuits. Furthermore, the medium 3120 lends itself to batch operations. A message processor may choose to 3121 accumulate a group of transaction in e-mail messages and process them in 3122 periodic batches. There is no guarantee that responses will be returned 3123 in the order that the original messages were sent. There is the slight 3124 potential for e-mail messages to be lost and misrouted between the 3125 sender and receiver. There is the potential for ``spoofing'', sending 3126 counterfeit messages. 3128 Because there are different organizations there is necessarily an 3129 arms-length relationship among them that influences the interface 3130 negotiation and operation. 3132 6.4.1 Impact of the Medium 3134 Most HL7 installations design for synchronous acknowledgements. When a 3135 sender initiates an HL7 unsolicited update, it waits for an 3136 acknowledgement from the receiving application or the HL7 router. The 3137 sender enforces time-outs on the order of a few tens of seconds and 3138 retransmits if there is no response. When transactions are sent over e- 3139 mail, the response times will be much longer. The agreement among 3140 organizations that enables the use of e-mail transactions must specify 3141 transaction designs that do not include immediate application 3142 acknowledgements. In environments like that shown in Figure 9 the HL7 3143 router can supply accept acknowledgement messages (ACK with 3144 MSA-1-acknowledgement-code set to CA). This may permit existing 3145 applications that do not require immediate application response to 3146 continue to operate. 3148 The response times, the opportunities for batch processing, and the 3149 possibility of receiving responses out of order will affect the HL7 3150 application transaction design. The design must carefully consider the 3151 handling of application errors to determine whether they should be 3152 recognized in application acknowledgements or through a manual exception 3153 report. 3155 Secure HL7 Transactions using Internet Mail July 21, 1998 3157 6.4.2 Negotiating Interface Agreements 3159 Because independent organizations are negotiating the interface, the 3160 agreement is a contract. This implies a higher level of scrutiny than 3161 is typical of HL7 Implementation Agreements. Among other concerns, the 3162 agreement will address 3164 1. the message types, trigger events, segment and data field usage that 3165 is normally expected in HL7 implementation agreements 3167 2. exact usage of e-mail addresses 3169 3. the timing of transmissions and responses 3171 4. procedures for dealing with error situations including contact 3172 information, and 3174 5. operational or financial consequences of failure to send or process 3175 messages. 3177 The e-mail medium is well suited to data collection applications 3178 where software located in many organizations occasionally sends HL7 3179 transactions to a system that maintains a database. In these 3180 applications it is particularly critical that the application design 3181 include means for establishing that the expected data has been received. 3182 The interface agreements must clearly specify the means for follow-up. 3184 7 Endnotes 3186 1. ibid., p. 124. 3188 1. ibid., p. 8. 3190 1. The relevant e-mail lists are: hl7-mime@umich.edu or 3191 hl7@virginia.edu. 3193 1. e.g., RFC 2200, dated June 1997 3195 1. PKCS documents are available through RSA Data Security, Inc. 3197 1. see HL7 v2.3, section 2.1.2.1 3199 1. some say: ``Multimedia ...'' 3201 1. Access control enforcement is currently considered out of the scope 3202 of HL7, as it influences the communicating system's internal working 3203 rather than mere external communications. 3205 Secure HL7 Transactions using Internet Mail July 21, 1998 3207 1. One of the most curious security breaches that ever happened 3208 illustrates a sequencing thread: Jackpotting an ATM was done by 3209 interception of a confirmation message sent from the Bank to the ATM 3210 telling the ATM to dispense the requested amount of money. By 3211 continuous replay of this message, intruders were able to drain ATMs 3212 empty as if they had won the jackpot. [Ross Anderson. Why 3213 cryptoystems fail] 3215 1. see Phil Zimmerman: PGP User's Guide, Volume II: Special Topics; Oct 3216 11, 1994. 3218 1. Version 5 of PGP comes with unencumbered default algorithms already. 3220 1. European laws, however, require that digital signatures belong to 3221 individuals only, not organizations. They also require that every 3222 digital signatures be made as a conscious act of the signing 3223 individual in order to protect individuals from signing without their 3224 consent. This presents a dilemma: (1) the only person who may be 3225 conscious about the triggering of a message is an end user; (2a) but 3226 this end user is not individually responsible for the entire content 3227 of the message; (2b) the organization that is responsible for the 3228 message cannot sign it. In the paper-world, individuals who sign ex 3229 officio are usually backed by their organization, hence the work- 3230 around this dilemma may be to let individuals sign. However, digital 3231 signatures are much better manageable if organizations are the 3232 signers, for the recipient organization needs to know only the 3233 signature of the peer organization, rather than all signatures of 3234 every single employee working for the other organization. These 3235 issues will have to be revised in the legislation. One option is to 3236 regard organizational digital signatures as of the same legal dignity 3237 as organizational stamps and seals. 3239 1. Note that S/MIME does not obey the MIME Security Multipart 3240 specification for multipart/encrypted (see also section 4.3). 3242 1. Gzip is a very efficient compression program of the Free Software 3243 Foundation's GNU project. The gzip program has been ported to 3244 virtually all operating system platforms. 3246 1. Compress is the traditional UNIX(R) compression program. It is less 3247 efficient than gzip. 3249 8 Addresses of the Authors 3251 Secure HL7 Transactions using Internet Mail July 21, 1998 3253 Gunther Schadow 3254 Regenstrief Institute 3255 1001 W 10th Street, RG5 3256 Indianapolis, IN 46202 3257 Phone: +1 317 630 7960 3258 E-mail: gunther@aurora.rg.iupui.edu 3260 Mark Tucker 3261 Regenstrief Institute 3262 1001 W 10th Street, RG5 3263 Indianapolis, IN 46202 3264 Phone: +1 317 630 2606 3265 E-mail: tucker_m@regenstrief.iupui.edu 3267 Wes Rishel 3268 Wes Rishel Consulting 3269 970 Post Street 3270 Alameda, CA 94501 3271 Phone: +1 510 522 8135 3272 E-mail: wes@rishel.com 3274 9 Full Copyright Statement 3276 Copyright (C) 1998, Health Level-7, Inc. All Rights Reserved. 3278 This document and translations of it may be copied and furnished to 3279 others, and derivative works that comment on or otherwise explain it or 3280 assist in its implementation may be prepared, copied, published and 3281 distributed, in whole or in part, without restriction of any kind, 3282 provided that the above copyright notice and this paragraph are included 3283 on all such copies and derivative works. However, this document itself 3284 may not be modified in any way, such as by removing the copyright notice 3285 or references to Health Level-7, Inc. or Internet organizations, except 3286 as needed for the purpose of developing Internet standards in which case 3287 the procedures for copyrights defined in the Internet Standards process 3288 must be followed, or as required to translate it into languages other 3289 than English. 3291 The limited permissions granted above are perpetual and will not be 3292 revoked by Health Level-7, Inc. or its successors or assigns. 3294 This document and the information contained herein is provided on an 3295 "AS IS" basis and HEALTH LEVEL-7, THE INTERNET SOCIETY AND THE INTERNET 3296 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 3298 Secure HL7 Transactions using Internet Mail July 21, 1998 3300 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3301 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3302 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE