David:
Section 12.3.5 Persistent Confidentiality in the 1.0 spec used to state:
"However, this specification states that it is not the responsibility of the
MSH
to provide security for the ebXML 'Payloads'."
I don't recall anyone raising an issue to have the above statement removed.
I agree that your proposal makes logical sense. Perhaps the word
encryption in your Note should be qualified with the word payload.
Regards,
-Arvola
-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>; ebXML Msg
<ebxml-msg@lists.oasis-open.org>
Date: Friday, October 26, 2001 1:07 PM
Subject: RE: [ebxml-msg] Sign and Encrypt
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.
-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Friday, October 26, 2001 2:17 PM
To: David Fischer; ebXML Msg
Subject: Re: [ebxml-msg] Sign and Encrypt
David:
You proposed order of signing before encrypting works only if the MSH
takes care of both signatures and encryption.
In the current Messaging spec, the MSH is responsible for signing but
not encryption. Therefore, if you are concerned with persistent encryption
of the payload portion of an ebXML message, the encryption will have to
be performed first. The encrypted payload(s) will then have to be passed to
the MSH for packaging and signing.
Regards,
-Arvola
-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Date: Friday, October 26, 2001 12:02 PM
Subject: [ebxml-msg] Sign and Encrypt
I am looking through the spec and I don't see anywhere that says which to do
first, Sign or Encrypt. All security protocols of which I am aware always
sign
first and then encrypt. This may be obvious but I would like to add a note
to
this effect in section 4.1.4.5.
Note: When both signature and encryption are required, sign first and then
encrypt.
Regards,
David Fischer
Drummond Group.
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>