[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Sign and Encrypt
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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC