Hi Rahul,
Thanks for the feedback.
My general sense is that having a signature is definitely not going to be
required in many cases, which was the main motivation for putting it in an
optional profile of its own. As you point out, TLS with Symmetric keys can
also do a great job of mutually authenticating two systems. Christian
brought forward what I think is a great idea of putting secure sockets into
a second optional profile called "Encryption Profile" which would capture
this concept (as well as allowing for public key encryption which at least
gives privacy).
That said, I think there a couple of use cases where a signature line would
help (or at least be a good option):
* In some infrastructures, SSL is handled by edge devices at the outside of
an application stack (e.g. Reverse proxies, governance tools, etc.) In
these cases, the devices bring a lot of value, but they also mean you lose
the end-to-end non-repudiation that a signature line brings unless you do a
bunch more fancy setup.
* In many cases, it would be nice to be able to just add a message listener
to an existing server application (e.g. a servlet container serving up a
web application that also requires HL7 messages to come in). In this case,
one might want to just take advantage of an existing public TLS certificate
that can already be used for encryption, and use another means for strong
authentication. On some server platforms, it may even be impossible to host
both a public key certificate and a symmetric one and be assured that web
requests are using one and HL7 request are using the other.
* There are always going to be cases where management wants to "turn the
security knobs up to 11". Using a standardized signature line is an easy
way to do this.
I guess the bottom line is that I really only see Signature Profile having
a use in places where complex layered applications are receiving data from
lots of HL7 data from lots of sources over non-trusted networks, but I see
it being hugely relevant to that scenario.
Comments on this position are certainly welcomed. If I'm really misguided
here and this doesn't add value maybe it should come out, but I feel like
maybe what the document needs is a better explanation of where Signature
Profile is appropriate and where it would be overkill.
Cheers,
James
On Tue, Jul 31, 2012 at 12:43 PM, Rahul Somasunderam <
r...@certifydatasystems.com> wrote:
> James,
>
> Thanks for putting this together.
> I'm looking at the Signature Profile and wondering if it buys us anything
> that Mutual Authentication (X.509) does not. Can we do away with the
> HL7-Signature header?
>
> R,
> rahul
>
> On Jul 30, 2012, at 7:20 PM, James Agnew wrote:
>
> Hi Everyone,
>
> The very first draft of a proposed specification for HL7 over HTTP has
> been posted here:
> http://hl7api.sourceforge.net/hapi-hl7overhttp/specification.html
>
> The spec as it stands incorporates most of the feedback I received on
> Blogspot and on the HAPI mailing list, so it's probably time to start
> getting feedback on how that all looks on paper.
>
> Some areas I'm particularly interested on opinions on:
>
> - For the internet protocol crowd: Is it really wise to specify that
> only the parts of RFC 2616 which are explicitly referenced in HoH are
> required to be supported? My hope is that this leads to an easier to
> implement spec (since features like redirect, multipart content,
> cache-control, etc. are not relevant to transactional system-to-system
> messaging). My fear is that we'll miss something critical (my first attempt
> skipped the "Host" header, which I then learned is an absolute must
> according to HTTP/1.1)
> - For the security crowd: Is SHA512 with RSA a good signature
> algorithm for message non-repudiation? At a glance it seems like it might
> be too java-centric. (Would a CMS signature be better? A CMS signed
> message?)
>
> I've also got a reference implementation started, with the hope that it
> will be usable in a wide variety of circumstances (e.g. servlet, standalone
> application, drop-in LLP implementation) and even in applications that
> don't otherwise use HAPI in order to encourage adoption. More to come on
> that, but please get in touch if you would like to get involved.
>
> Cheers,
> James
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> Hl7api-devel mailing list
> Hl7api-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Hl7api-devel mailing list
Hl7api-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
