Re: Security protocols for TRP

[Prasad Yendluri <pyendluri@webmethods.com>]

Please see below my few cents  in <PY>..

christopher ferris wrote:

> Krishna,
>
> Some comments below.
>
> Cheers,
>
> Chris
>
> Krishna Sankar wrote:
> >
> > David,
> >
> >         Couple of questions (Actually more !) :
> >
> >         1.      Will the layers above the TRP (e.g.. Application layer) know that the
> > (received) message was signed and encrypted ?
>
> This depends. It is our intent to have the CPA define/describe the packaging
> and security aspects that the parties agreed to employ. If the scheme
> employed is to delegate the signing of the header/payload to the MSH
> (using XMLDSIG) then the answer would be no, although we should probably
> discuss how the MSH should interface with the application/application services
> layer above to communicate signature validation info, etc.
>
> If the payload is signed/encrypted with a MIME-based approach (S/MIME
> or PGP/MIME) then this is completely within the domain of the
> application or application services layer to process (validate
> signature and/or decrypt with private key, etc.)
>
> Again, our intent is to capture all of this information in the CPP/CPA.

<PY> It is possible for the CPA to specify > 1 valid possibilities, including
signing/encrypting/both and the specific mechanisms (S/MIME, PGP/MIME, XMLDSIG etc.) to be used.
Which particular one is employed by a message instance needs to be identified somewhere. CPP/CPA
may not be enough. I think this needs to be captured in the envelope. </PY>

> >         2.      On the flip side, I assume the layers above can specify the requirement
> > for encryption and signature when sending a message.
>
> That would again be in the CPA/CPP. The BPM specification actually determines
> the required security characteristics (non-repudiation, confidentiality,
> etc.) which are to be employed by the runtime. This is mapped/matched
> to a DeliveryChannel (DocExchange+Transport) which can support these
> characteristics which both parties can support (e.g. sending and
> receiving DeliveryChannels must support the same set of features). The CPA then
> describes how each message will be treated... Of course, all of this
> is dependent upon the application software (or application services
> software) also being able to read the CPA so that it "knows" how
> to handle sending/receiving messages, etc.

<PY> Again this would accommodate > 1 valid choices/combinations </PY>

> >         5.      On the question of non-repudiation, does the MSH perform the persistence
> > or is it a function of the application ? Thinking this thru, if the app has
> > to do the (non-repudiation related) persistence, it also needs to get the
> > message as received and also the decrypted message. Am I making sense ?
>
> Not sure I follow that one...

<PY> Since there is a choice to sign just the payload/headers or both, non-repudiation becomes
really subjective here. Both MSH and the application should persist the relevant parts as
applicable; MSH the entire message (for just headers/entire message signed case) and the payload
by the application for the payload signed case, IMHO.</PY>

> >         6.      The next one is, how does non-repudiation happen on the sending side ?
>
> In the security f2f, we identified two aspects of non-repudiation.
> non-repudiation of origin (signing the message) and non-repudiation
> of receipt (returning an ack which is signed and includes the signed
> digest of the original message). On the sending side, the message
> must be signed.
>
> Now, there are really two types of signing involved here. If the
> application holds the signing key, then IT has to be the entity which
> performs the non-repudiation function (I believe that this was also
> discussed during today's con-call). This would then involve MIME-based
> signing of the payload object and an application-level non-repudiation
> ack message (a BUSINESS message, not an MSH ack).

<PY> Whene there is a choice (architecturally) to sign either just the headers / payload or
both, non-repudiation aspects would be more complex than this..</PY>

> >
> > cheers
> >
> > > -----Original Message-----
> > > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > > Sent: Thursday, December 14, 2000 4:29 PM
> > > To: ebXML Transport (E-mail)
> > > Subject: Security protocols for TRP
> > >
> > >
> > > This note outlines how the Messaging Services spec should use digital
> > > signature technology to:
> > > 1. Digitally sign the ebXML Header,
> > > 2. Bind together the ebXML Header and the ebXML Payload
> > > 3. Encrypt the ebXML Payload.
> > >
> > > This is based on the consensus reached in the TRP conference call this
> > > morning.
> > >
> > > It is proposed that this description is discussed on the list and a vote
> > > taken at next weeks conference call.
> > >
> > > Note that this is a outline rather than the actual words that
> > > will go in the
> > > spec.
> > >
> > > Here's the description ...
> > > =======================
> > >
> > > EBXML HEADER SIGNATURE CREATION
> > > A digital signature, within the ebXML header, conforming to the W3C XML
> > > Signature specification MAY be used by a MSH that is sending a message to
> > > digitally sign:
> > > 1. the ebXML Header Document,
> > > 2. the complete ebXML Payload, or
> > > 3. the ebXML Header Document and the complete ebXML Payload so as to bind
> > > the ebXML Header Document and the ebXML Payload together
> > >
> > > When the XML Signature is created by the From Party's MSH, it must contain
> > > an XML Signature Manifest that contains digests of:
> > > 1. TBD ... we must itemize what gets signed including any
> > > references to the
> > > ebXML Payload
> > >
> > > When an Intermediate Party is forwarding a message to another
> > > Party then it
> > > must contain an XML Signature Manifest that contains digests of:
> > > 1. TBD ...
> > >
> > > EBXML HEADER SIGNATURE VALIDATION
> > > A MSH that receives a Message that contains a signature in the
> > > ebXML Header
> > > MAY verify the signature if the CPA indicates that signature validation is
> > > required.
> > >
> > > Verification of a signature must include:
> > > *     verification of each digest in the signature Manifest ...
> > > *     etc, etc.
> > >
> > > If the verification of the signature fails then the the MSH that verifies
> > > the message MUST send an Error Message to the From Party that created the
> > > Message.
> > >
> > > If the verification of the signature succeeds then it MAY be used by a
> > > recipient or reader of the Message to prove:
> > > 1. the authenticity of the Party that sent the Message. This may be:
> > >   a) the From Party that created the Message, and/or
> > >   b) the Sender of the Message
> > > 2. what data and information forms the message
> > >
> > > If the authenticated sender of the message is a Party that is unacceptable
> > > to the recipient of the Message, then the Party that verified the Message
> > > MUST send an Error Message to the From Party that generated the Message.
> > >
> > > EBXML PAYLOAD SIGNATURES
> > > Data contained within the ebXML Payload may be signed using
> > > either: W3C XML
> > > Signature, S/MIME, or PGP/MIME.
> > >
> > > If W3C XML Signature is being used, then it is RECOMMENDED that the
> > > following conventions are followed:
> > > *     TBD
> > >
> > > If S/MIME is being used, then it is RECOMMENDED that the following
> > > conventions are followed:
> > > *     TBD
> > >
> > > If PGP/MIME is being used, then it is RECOMMENDED that the following
> > > conventions are followed:
> > > *     TBD
> > >
> > > =======================
> > > ISSUES
> > > A few issues ...
> > > 1. Do we want to allow the MSH to sign data that is carried outside of the
> > > message (e.g. on the web) but is referenced by the Manifest. My guess is
> > > that we probably do, but how this is done is implementation dependent.
> > > 2. Do we need to spell out how the Payload should be signed, or
> > > do we leave it to the application protocol designer?
> > > 3. If the authenticated sender of an ebXML Header Message is a
> > > party who is unnacceptable, do we really want to let the sender of the
> > > messaage know that  they are "unacceptable".
> > >
> > > Regards
> > >
> > > David
> > >
> > >
> > > Product Management, Commerce One
> > > 4400 Rosewood Drive, Pleasanton, CA 94588, USA
> > > Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
> > > mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
> > >
> > >