Security protocols for TRP

["Burdett, David" <david.burdett@commerceone.com>]

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