David/Arvola,
If the "application" is responsible for encrypting the
payload (as we have for v1.0 and v1.1) then from the
MSH's perspective, the payload is just a stream of bits
which can be signed. The purpose of the Signature on the
"message" is to ensure the integrity of the "message"
between parties. The "message" is the header and the payload
signed together (excluding the bits that are mutable).
I think that there are two considerations:
- if the encryption is applied first by the MSH
then the signature MUST be validated first (before decryption)
- if the signature is applied first, then
the decryptuion MUST be applied first (before validation)
This suggests that if and when we have the MSH responsible
for BOTH, that the two will need to be somehow inter-related
so as to enforce this algorithm.
Cheers,
Chris
David Fischer wrote:
> Arvola,
>
> Signing is not viable if done after encryption. From a legalistic point of
> view, if you sign the encrypted part, you have not made the required connection
> between what is being signed and the signer since the signer does not know what
> is being signed (like signing the outside of an envelope without being able to
> look at the contents.)
>
> This is not a choice, this is how it must happen. Encryption is handled by the
> MSH during packaging. See section 4.1.4.5
>
> ===============
> 4.1.4.5 Persistent Confidentiality
> <<snip>>
> Confidentiality for ebXML Payload Containers MAY be provided by functionality
> possessed by a MSH. Payload confidentiality MAY be provided by using XML
> Encryption (when available) or some other cryptographic process (such as
> [S/MIME], [S/MIMEV3], or [PGP/MIME]) bilaterally agreed upon by the parties
> involved. Since XML Encryption is not currently available, it is RECOMMENDED
> that [S/MIME] encryption methods be used for ebXML Payload Containers. The XML
> Encryption standard SHALL be the default encryption method when XML Encryption
> has achieved W3C Recommendation status.
>
> Note: When both signature and encryption are required, sign first and then
> encrypt.
>
> ===============
>
> If the Application wishes to submit an encrypted payload to the MSH, that's
> fine. They can also submit a previously signed payload. We can't control any
> of that. However, the MSH level encryption function must be done after the MSH
> level signature function. We need to say this.
>
> Regards,
>
> David Fischer
> Drummond Group.
>
>