RE: Security protocols for TRP

[Krishna Sankar <ksankar@cisco.com>]

Bob,
	Excellent. Because, now we have a three way synergy - BP, TRP, RegRep and
some tracability between the groups' specifications. I will comb thru the BP
archives and wait for the BP document on the winter solstice !

	cheers

> -----Original Message-----
> From: Bob Haugen [mailto:linkage@interaccess.com]
> Sent: Thursday, December 14, 2000 6:06 PM
> To: 'Krishna Sankar'
> Cc: ebxml-ta-security@lists.ebxml.org; ebxml-regrep@lists.ebxml.org
> Subject: RE: Security protocols for TRP
>
>
> 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
>
>