[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Sign and Encrypt
Ralph, I apologize, it has been pointed out that I did not qualify this correctly. It is only the MSH which signs first then encrypts. There is nothing preventing the application from submitting a previously signed or previously encrypted payload to the MSH. Sorry about that. Regards, David. -----Original Message----- From: David Fischer [mailto:david@drummondgroup.com] Sent: Sunday, November 04, 2001 8:30 PM To: Ralph Berwanger; Christopher Ferris Cc: ebXML Msg Subject: RE: [ebxml-msg] Sign and Encrypt Hi Ralph, Actually, you asked me to take minutes in London, although, I confess, I gave up with all the shouting. It is incorrect from a security point of view to encrypt before signing. One thing about security, if you don't get it right to start with, it often never gets right. I remember, in London, all the work you and Chris did in the hotel lobby to create section 12 (now appendix C) -- thank you, it was much appreciated. I also remember some discussion when you presented your work. Without rejecting your work, we specifically decided to support only profiles 0 & 1. We did not make any decision on confidentiality other than to support XMLEncryption when it appears and allow S/MIME (and other current technologies) until then. Unfortunately, we can't just leave this to the implementors. We cannot just "decide" that we know better than all the security experts in the industry and go off our own way. First sign, then encrypt. This is the way it works. Unfortunately, we have put ourselves in a difficult situation. We are trying to use XML functions (XMLdSig, XMLEncryption) for non-XML constructs. The XMLdSig authors specifically rejected non-XML constructs while still allowing the use of bit-stream type data. We are attempting to use these specs where they were never intended. This is not necessarily bad since these specs give us some flexibility we might not otherwise have, but this means we must specifically specify how these non-XML constructs are to be supported, both now for dSig and later for XMLEncryption. Thus far we have not done that. We are attempting to work this out now. If, as you say, we made such a decision in the past, it is time to correct it now. Regards, David Fischer Drummond Group. -----Original Message----- From: Ralph Berwanger [mailto:rberwanger@bTrade.com] Sent: Sunday, November 04, 2001 9:04 AM To: David Fischer; Christopher Ferris Cc: ebXML Msg Subject: RE: [ebxml-msg] Sign and Encrypt David, I must agree with Chris. We were VERY CAREFUL to isolate all confidentiality functions to applications outside of the MSH. There was no standard method of providing this service so we punted. We said that the payload that we expected the user to apply any necessary security to the payload prior to handing it to the MSH. I have lots of notes regarding this topic. It was settled the last time during the FACE-2-FACE in London. Ralph Berwanger -----Original Message----- From: David Fischer [mailto:david@drummondgroup.com] Sent: Monday, October 29, 2001 10:35 AM To: Christopher Ferris Cc: Arvola Chan; ebXML Msg Subject: RE: [ebxml-msg] Sign and Encrypt 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> ---------------------------------------------------------------- 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