Re: revised draft of Message Services spec for comments - Flames ;-)

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

Krishna,

Thanks for the careful review and comments.

Please see my responses below.

Cheers,

Chris

Krishna Sankar wrote:
> 
> Hi all,
> 
>         One of my favorite specifications is the ebXML TRP and Chris/David, you
> have improved on it ! Great job.
> 
>         Here are some of my thoughts - mostly security related (Version 0.9a):
> 
>         1.      I assume the MSH has the access to the CPA (thru the CPAId tag) - which
> means we need to tie this with the CPA versions. An older TRP implementation
> might not be able to deal with a newer version of CPA. Possibly add an error
> code wrongCPAVersion in Section 8.8.6.

Hmmm... good point. One might expect that the MSH software would report
an internal error. However, this is certainly worthy of some discussion.
Possibly we can discuss this at the f2f?

> 
>         2.      In many places you have mentioned CPA/CPP. I think the MSH should only
> handle CPA and should never be aware of CPPs. (Remember the DTDs of these
> two documents would be very different, may be even in different languages)

Well, they're actually quite similar;-) However, your point is well
taken.
The MSH deals only with the CPA.

> 
>         3.      Lines 69,70 talks about a Security Specification. I thought the security
> stuff would be part of this specification. Is anybody developing a separate
> security specification ?

See section 12. What is probably needed to be referenced at this point
is the ta-security appendix to the architecture document which addresses
security across the various ebXML components. The MS spec will have its
own section (12, which is still incomplete) detailing the specifics
of MSH and message-level security protocol and handling.

> 
>         4.      Lines 1604-1606 : So far, the TRP is a protocol specification  and by
> adding this it could become a service ! So I am not sure if this belongs
> here. I do not think the TRP should get into the authentication business -
> there are all kind of issues including policies, contexts, ...
> 
>                 Also this is the first time we have a SHOULD !
> 
>                 I would rather tie this to HeaderSignatureRequired or some similar pragma
> in the CPA. In all honesty, we should not build a security service in the
> MHS.

Hmmm... possibly this sect needs to be rephrased, but I think that the
sentiment
is correct. An implementation of an MSH most certainly SHOULD be capable
of recognizing and
defending itself against a DoS attack. Now, I should mention that this
section is 
more informative than anything else. We don't go into details as to how
an MSH
would do this. The MSH itself may not have anything to do with it at
all, but the
platform on which it is run is more than likely to do so. Thus, I take
your point
and will endeavor to rephrase it such that it is clearer.

> 
>         5.      Like the excellent diagrams in the reliability section, we need similar
> diagrams for the security section as well. We need to bring out the
> interactions.
> 
>         6.      Another important point is the application interface. i.e. how will the
> MSH talk to the application ? May be there is none.

This is what we've been calling the Service Interface. I've been working
on a draft, but it isn't complete and may not get added for v1.0.

> 
>         7.      On the same note, will the application get the headers and the signature
> ? I assume so. Is there a RequiresHeaderSignature element in the CPA ?

Not per se. There is a packaging profile that we're working on for the
CPP/CPA that will address these aspects and there are specific elements
in the CPA that address authentication and certificates.

> 
>         8.      I assume the TRP has no work in payload encrypting  Or Does the app give
> the cleartext to the TRP which in turn encrypts it ? If so is there a
> PayLoadEncryptionRequired element ?

The payload encryption is expected to be handled by the application or
application
services layer. That is not to say that the MSH might not offer the
service
to its applications to use as an add-on, it just isn't part of the
formal 
specification.

> 
>         9.      If the TRP handles the encryption/decryption, and if the CPA requires
> PayLoadEncryptionRequired = Yes, and if the payload is not encrypted, will
> TRP raise an error ?

MSH doesn't deal with encryption or decryption of the payload. That is
application
or application services responsibility. As far as MSH is concerned, the
payload is 
opaque.

> 
>         10.     Lines 1524,1525,1526 could be : Confidentiality, Integrity and
> Availability. Usually the security is talked about as a CIA (Pardon the pun
> !)
> 
>         11.     1627 - definitely needs explanation ;-)

Oh, come now... It is quite well worded, don't you think;-)

> 
>         12.     I think we need a section on Authentication and how it can be handled.
> I could write this up, if you want. This would talk lines 1604-1606 and
> expand on it.

Sure, please feel free to assist! 

> 
>         I am still reading and thinking thru. Will send more comments.
> 
>         How do you plan to co-ordinate the editing ? Do you want the changes in an
> e-mail ?

Yes, please. If you have specific edits, identify line number
and provide suggested new language accompanied with an explanation. If
you can,
please characterize as editorial, minor or major technical. Editorial is
just wordsmithing, minor technical is a perceived error in either the
text
or say a DTD and major technical is reserved for a change in semantic
meaning,
new functionality or worse;-)

A new section on authentication would be major technical. Something such
as your
comment 10 above would be editorial (most likely). #1 above falls
somewhere
between major and minor, probably more on the minor side...

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