NEHTA Secure Messaging Silently Posts Some Old Documents. Wonder Why?

A day or so ago NEHTA quietly posted 3 new documents on their web-site.

http://www.nehta.gov.au/publications/whats-new

The documents are as follows:

Secure Messaging Delivery Overview 30/07/2010 10

Secure Message Delivery Technical Overview 30/07/2010 10

Secure Message Delivery SMIME Profile 30/07/2010 9

What is interesting is not only the content, but that the documents were finalised in September, 2009 – almost a year ago.

The most interesting bits are in the overview document. (Page 9)

1 Introduction

1.1 Background

NEHTA has developed a set of specifications and infrastructure to support secure messaging between health care providers. While the NEHTA vision identifies end-to-end specifications for communication in specific clinical domains (e.g. pathology, discharge summary), there is a business need to implement NEHTA messaging specifications using a staged approach, and also to facilitate communication between health care providers in situations where no domain-specific standard exists.

1.2 Purpose

This document describes the implementation of secure message delivery (SMD) using NEHTA messaging specifications and infrastructure. In particular it identifies the community roles in SMD and the endpoint specifications associated with those roles. The referenced specifications define interfaces, behaviour and conformance criteria for software implementing SMD according to NEHTA specifications.

The document is intended to provide a starting point for software vendors and developers implementing the specifications.

1.3 Scope

SMD focuses on the application of NEHTA messaging specifications and the use of NEHTA infrastructure services to transfer unspecified, opaque content between health care providers. Message content is defined sufficient to support the messaging interaction. No clinical domain content is included in any content specifications.

This document provides a high-level description of the roles and interactions and provides references to detailed specifications and conformance criteria.

----- End Extract.

Also of interest is this in the third document (Page 5).

1 Introduction

1.1 Background

The Secure Message Delivery (SMD) Endpoint Specification defines service interface specifications for delivering a payload which is secured from end-to-end.

To achieve this, the specification defines that the payload must be secured with XML Secured Payload (XSP) or optionally with S/MIME.

The S/MIME payload profile is designed as an interim solution to facilitate the adoption of SMD in the short term.

This document defines a profile of S/MIME which minimises choice associated with the S/MIME standard and also interoperates with existing deployments of messaging software.

1.2 Purpose

This document defines the format of the S/MIME payload used inside the SMD service interface specification. The constraints defined in this profile are intended to maximise interconnectivity across S/MIME payload encryption implementations.

1.3 Scope

This document does not define the contents being secured inside the S/MIME format. Payload specifications associated with SMD will be defined separately.

This is not a general profile of S/MIME. It is not designed to cover any use outside SMD. In particular, it is not intended to be a specification of how S/MIME is to be used for securing email communications.

The reader of this document is expected to have a detailed understanding of S/MIME, Cryptographic Message Syntax (CMS) and MIME.

1.4 References

1.4.1 Normative References

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For updated references, the latest edition of the referenced document (including any amendments) applies.

[RFC2119] IETF, RFC 2119: Keywords for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997, http://ietf.org/rfc/rfc2119.txt

[RFC2045] IETF, RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet message Bodies, N. Freed, N. Borenstein, November 1996, http://www.ietf.org/rfc/rfc2045.txt

[RFC2630] IETF, RFC 2630: Cryptographic Message Syntax, R. Housley, June 1999, http://www.ietf.org/rfc/rfc2630.txt

[RFC2633] IETF, RFC 2633: S/MIME Version 3 Message Specification, B. Ramsdell (editor), June 1999, http://www.ietf.org/rfc/rfc2633.txt

1.4.2 Informative References

[RFC2315] IETF, RFC 2315: PKCS #7: Cryptographic Message Syntax Version 1.5, B. Kaliski, March 1998, http://www.ietf.org/rfc/rfc2315.txt

----- End Extract.

Note how old these IETF Standards actually are!

For a bit of background go here:

http://en.wikipedia.org/wiki/S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of MIME data.

S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFCs. S/MIME was originally developed by RSA Data Security Inc. The original specification used the recently developed IETF MIME specification with the de facto industry standard PKCS#7 secure message format.

Change control to S/MIME has since been vested in the IETF and the specification is now layered on Cryptographic Message Syntax, an IETF specification that is identical in most respects with PKCS #7.

Function

S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and privacy and data security (using encryption). S/MIME specifies the application/pkcs7-mime (smime-type "enveloped-data") type for data enveloping (encrypting): the whole (prepared) MIME entity to be enveloped is encrypted and packed into an object which subsequently is inserted into an application/pkcs7-mime MIME entity.

S/MIME functionality is built into the majority of modern e-mail software and interoperates between them.

---- End Quote.

So what we now have NEHTA saying is essentially that it is probably going to take ages to get this web services stuff going so we will use what amounts to secure e-mail where it is in place and work out how the message contents and transmission is to be finally standardised and used later.

I note we now have very recent SMD standards available on the SAI Global site. This is explained at the NEHTA web site:

See here:

http://www.nehta.gov.au/connecting-australia/secure-messaging

“Secure Message Delivery Specifications
The documents which describe the Secure Messaging Delivery, Web Services Profile and the XML Secure Payload profile specifications are now Technical Specifications published by Standards Australia. The Endpoint Location Service specification is now a Technical Report also published by Standards Australia.

These documents are no longer available from the NEHTA website but can be downloaded for free from the “SAI Global website” at http://infostore.saiglobal.com/store/portal.aspx?portal=Informatics.

The Standards Australia document references are;

ATS 5820:2010 E-health Web Services Profile
ATS 5821:2010 E-health XML Secure Payload Profiles
ATS 5822:2010 E-health Secure Message Delivery
TR 5823:2010 Endpoint Location Service”

It would have been nice if the place of S/MINE could have been publicly confirmed ages ago, although I understand the various Secure Messaging Working Groups have had these documents for a while. (NEHTA is saying it was due to a revamp of the web site that these suddenly appeared!)

It does seem to me – as I have said in the past, to get a sensible and secure way of moving HL7 V2 messages moving on a common interoperable platform, and then work out the content details as we can. If this easily migrates to the desired end state better still!

I think this is a sensible, but over delayed, rational way forward for Australian e-Health. It seems some pragmatists have overcome the internal purists and made sure these documents are out – or was it just a slip up? Who knows?

I would love anyone who understands the apparently random nature of these releases to let us know!

David.