RE: Security protocols for TRP

[Krishna Sankar <ksankar@cisco.com>]

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 ?

	2.	On the flip side, I assume the layers above can specify the requirement
for encryption and signature when sending a message.

	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 ?

		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.

		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.

	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 ?

	6.	The next one is, how does non-repudiation happen on the sending side ?

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

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