RE: Security protocols for TRP

[Bob Haugen <linkage@interaccess.com>]

Krishna,

Many of the excellent issues you raise below have been addressed
in the BP "specification schema" developed in Boston last week.
(Note: "addressed" here does not mean full technical details,
which are the province of other groups, but more on the level
of parameters for runtime software.)

Some early documents are available on the BP mailing list archives.
Consolidated and agreed ones are due December 22.  This schema
is for B2B transactions, but would probably work for regrep interactions
as well.  I'm not saying the schema will solve all your problems, 
just that it will be worth looking at.

Some answers from the schema:

>	1.	Will the layers above the TRP (e.g.. Application layer) know that the
>(received) message was signed and encrypted ?

Yes.

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

Yes.

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

If you so specify.

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

Correct.

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

There will need to be more of a protocol stack than MSH<->Application.
A business document can be encrypted before it reaches the MSH,
and decrypted after on the other end.  For full discussion of repudiation,
see next answer.

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

I'm going to duck this one. There was a complicated discussion of this issue in Boston, 
and I am not sure of the full resolution, but it will be addressed at some level
in the Dec 22 documents.  

Hope this helps rather than confuses,
Bob Haugen