Digital+Signature+ONC+Policy+Issues

=Security/Policy Questions=


 * 1) What is the intent for non-repudiation? We cannot assure non-repudiation of the entire message without signing the body, and non-repudiation is a stated NHIN goal and HHS / Federal policy (see the references section). However, the precise definition of non-repudiation for the NHIN has not been specified.
 * It is to ensure that the clinical document payload of the SOAP message has been viewed by a physician, and that the physician has digitally signed this clinical document payload? Or is the intended purpose to allow NHIN gateways to have the ability to prove that a given SOAP message was sent from another specific NHIN gateway? Or is this an obsolete requirement given the NHIN’s use of 2-way-SSL and ATNA logging
 * 1) What are NHIN's plans or future requirements forend-to-end SOAP message security, as opposed to the current gateway-to-gateway?
 * 2) Is it ONC policy that NHIN gateways are only allowed to interoperate with other NHIN gateways?
 * 3) Is it ONC policy to require implementation and periodic auditing of NHIN Gateway nodes to ensure proper IT-level security best practices are being employed?
 * 4) Is SOAP message integrity and tamper detection an objective?
 * If it is, then the current approach XML-DSig approach, taken out of context, is insufficient as only the two signed elements are protected. However, taken in context, we should either rely on 2-way-SSL, policy, and logging, or we should digitally sign the entire SOAP message.
 * Outstanding Questions and Issues (Forward Looking)**
 * 1) Will intermediaries be allowed and if so, will they be allowed to (or required to) add or replace XML-DSigs? Is the intermediary trusted? What are the boundaries of message level security? Some intermediaries are expected to change the message for example. If NHIN SOAP messages are subject to XML-DSig, which elements should be signed?
 * 2) What are the implications of a cloud model (some type of hosted intermediaries)?
 * 3) What are the implications of Edge systems (such as a push to a local practice EMR)?
 * 4) Is .NET stack support an objective, then the current approach is flawed and virtually unimplementable since the default .NET stack methods don’t support partial XML document signatures with different enveloping/reference mechanisms.
 * 5) If we don’t require XML-DSig now, will it be difficult to force support for it in the future?
 * 6) Federal cryptographic requirements may be higher than non-federal partners. Federal partners must use a higher level, potentially, that other entities. We must allow for the fact that policy, and technology, will change. This should be forward-looking enough to support the future, to the degree it can be anticipated such as new hashing and encryption algorithms. We should also allow for a transition period to accommodate this.
 * 7) In the future, will the NHIN allow plain text over an open channel? If so, then we will need to consider XML-DSig and XML-Encryption of the SOAP message (header and body).