[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Sign and Encrypt
David, Perhaps we should not categorically impose an order for encrypting and signing. Working drafts for the w3c provide examples of signing encrypted data: http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt.html#example The complexity of this issue is compounded by the notion that only portions of a document may be encrypted. If the entire document were to be encrypted, then it logically makes more sense to sign first. Perhaps we should provide the flexibility of encrypting first with a word of caution for its consequences and RECOMMEND signing first. I have read your "signing the outside of an envelope" argument. It confused me a bit since I thought that is what people did in times past by affixing their seal to the container of a message? The sentiment among hp developers is that signing/encrypting can go in either order. One developer cited a "WS-Security spec of Microsoft" as an example that anticipates different orderings (but I personally haven't had a chance to locate and study that document). b ============================================ Bruce Pedretti Hewlett-Packard Company Software Developer 6000 Irwin Road (856) 638-6060 Mt. Laurel, NJ 08054 http://www.hp.com/ ============================================ -----Original Message----- From: David Fischer [mailto:david@drummondgroup.com] Sent: Monday, October 29, 2001 10:28 AM To: Christopher Ferris Cc: Arvola Chan; ebXML Msg Subject: RE: [ebxml-msg] Sign and Encrypt 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