Next in thread →
Next in month →
RE: [ebxml-msg] Sign and Encrypt
Title: RE: [ebxml-msg] Sign and Encrypt Hmmm... I would hope that the king would not put his seal on a letter until he first inspected it or at least knew the content. By putting his seal on the document, he implicitly approves of the contents. The document the king sealed is not encrypted and the king can read it prior to sealing. Signing an encrypted document is like the king putting his seal on a locked strong-box without knowing its contents (maybe it contains articles of surrender sent by the wicked Cardinal to the King's enemies . . . blah, blah -- you know the drill, "All for One and Three for Five!"). My Father taught me to never sign without reading first ;-). Regards, David. -----Original Message----- From: Miller, Robert (GXS) [mailto:] Sent: Monday, November 05, 2001 11:43 AM To: ebXML Msg Subject: RE: [ebxml-msg] Sign and Encrypt Hi All, Well now, the 'King' sealed his envelopes with a wax stamp using the ring he wore on his hand. This stamp served the purpose of protecting the content of the envelope from being altered while 'in transit'. Sounds very much like encrypt (seal) and sign (imprint ring stamp) to me. I don't know that the king also signed with his own hand the content of the envelope (the application data), but certainly he may have chosen to do so. Having provided some precedence for 'encrypt then sign', I feel led to concur there is a valid purpose to that sequence. Certainly, it is not the same purpose as is provided by the 'sign then encrypt' signature. Both the authority of the signer, and the timing and manner of the signature carry significance from a security perspective. Cheers, Bob Miller -----Original Message----- From: David Fischer [mailto:] 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:] 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:] 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:] 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:] > 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:] >>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 <> >>To: ebXML Msg <> >>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>
Next in thread →
Next in month →