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