Yes, we agreed that S/MIME could be used, but we did NOT
agree that it was a function of the MSH to perform the
S/MIME encryption. We said that this was an "application"
function until such time as the XML Encryption could be
incorporated...
Cheers,
Chris
David Fischer wrote:
> No, we never said encryption was an application function. We did agree to use
> XMLencryption when it becomes available, but for now we agreed to allow SMIME
> encryption on the payloads only. See figure 1. See section 4.1.4.5.
>
> David.
>
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: Monday, October 29, 2001 10:10 AM
> To: David Fischer
> Cc: Arvola Chan; ebXML Msg
> Subject: Re: [ebxml-msg] Sign and Encrypt
>
>
> I disagree. We said that encryption is an application
> function for v1.0 because XML encryption was nacent and
> unfinished. When it becomes a W3C Recommendation, we agreed
> to revisit the issue from an MSH perspective.
>
> If the "application" wants to use S/MIME to encrypt the
> payload, then it is free to do so, but the S/MIME encrypted
> payload then becomes an opaque payload from the MSH perspective.
>
> As to whether or not it is "correct" to sign an encrypted
> payload is not an answerable question without a specific
> context. I don't think that we can say one way or another
> whether it is right or wrong in any absolute terms.
>
> Cheers,
> Chris
>
> David Fischer wrote:
>
>
>>No, it is incorrect to sign an encrypted payload. See my message to Arvola.
>>
> It
>
>>is a function of the MSH to encrypt, after signing.
>>
>>Regards,
>>
>>David Fischer
>>Drummond Group.
>>
>>-----Original Message-----
>>From: Christopher Ferris [mailto:chris.ferris@sun.com]
>>Sent: Monday, October 29, 2001 9:06 AM
>>To: David Fischer
>>Cc: Arvola Chan; ebXML Msg
>>Subject: Re: [ebxml-msg] Sign and Encrypt
>>
>>
>>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.
>>>
>>>-----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>
>>>
>>
>>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>