Re: Security protocols for TRP

[christopher ferris <chris.ferris@east.sun.com>]

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.

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

> 
>         3.      The major question is, at the receiving end, have the application layers
> access to the certificate and other artifacts used in the MSH level
> encryption and signature ?

Again, this depends on which approach is taken. The MIME-based
approaches
are handled directly by the application or application support layer
(typically the latter). Thus, it MUST have access to the requisite keys.

If the XMLDSIG approach (to sign the header and/or payload) then this
MUIST be performed in the MSH and thus the MSH MUST have access
to the requisite keys to perform the signing.

> 
>                 Just as a background, the registry security service could rely on the CN
> from the certificate used in the security layer, for authentication. But if
> the certificate is not visible, then the registry needs to add some more
> requirements.

Ahhh, this gets into the infamous service interface between the
MSH and the layer above it. I'm working on that...

> 
>                 Also for assuring integrity of the content, the registry needs the content
> signed, which from your scenario, looks like a payload related issue. But if
> you have step "1.5. Sign Payload", then we get the signature capability from
> the message layer. (May be your Issue 2. pertains to the same question)
> 
>         4.      Also, how does the MSH know who is "acceptable" and who is
> "unacceptable" ? It can know whether the signature passed or failed
> (including expired certs) - but anything else is at the application layer,
> which is not accesible to the MSH.

Again, the CPA is key. It is our intent to capture the certificate used
for authentication in the CPA so that it can be verified.

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

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

> 
>         Again, IMHO, we do have the luxury of not addressing all these issues in
> this Phase.

Great questions! I think that if we can get more discussion at this
level
that we'll shake out all of the kinks and have a solid spec to deal with
for the Vancouver POC.

> 
> 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
> >
> >
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard