OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ebxml-msg] Sign and Encrypt


Chris, OTOH, it doesn't matter if you can document.

The spec says

   "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."

This says that encryption "...MAY be provided by functionality possessed by a
MSH..."

Can it get much clearer than that?  If you want to put yours in an application,
be my guest.

David.

-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Monday, October 29, 2001 10:52 AM
To: Christopher Ferris
Cc: Arvola Chan; ebXML Msg
Subject: RE: [ebxml-msg] Sign and Encrypt


No, and your assertion does not agree with the spec.  Please document your
claim.

David.

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Monday, October 29, 2001 10:38 AM
To: David Fischer
Cc: Arvola Chan; ebXML Msg
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