Re: RosettaNet response to ebXML MSS 0.98b

[Prasad Yendluri <pyendluri@webmethods.com>]

Continuing with RN issues clarifications.. Please
see below in <PY>

Regards, Prasad

>
> 1. ebXML does not allow headers to be encrypted; RNIF 2.0 does allow
> Service Header to be encrypted.  There is too much sensitive
> information in the header (what business processes/actions are being
> executed between the participants, for example).  While SSL offers
> some protection, it is limited to point-to-point, leaving headers
> exposed to third-party transaction routers, and at the internal hops
> before and after SSL.  Further, SSL is not available in most SMTP
> implementations.
>
>   An alternative is to encrypt the entire RNIF 2.0 package (with full
> headers) in a payload container and fill in ebXML header/body elements
> generically, but this does not allow RosettaNet users to take
> advantage of the ebXML MSS specification fully, for cases in which
> header encryption is required.

We acknowledge this limitation, but in truth, we feel it is only
temporary (inability to apply persistent confidentiality to
selected header information). We have had the W3C XML Encryption
identified as the technology/mechanism that will allow for
selective encryption of header and body when that technology becomes
available, probably some time in the next year or so.

In the meantime, S/MIME or PGP/MIME can be applied to the payload
objects if persistent confidentiality is required for the
application payload information.

As you correctly cite, SSL (or IPSEC) may be used to provide
for transient confidentiality, e.g. on the wire of messages, but this
clearly doesn't protect the message from intermediary access,
nor does it protect the message once it is inside the sending or
receiving
enterprise (where in truth is is far more vulnerable!)

It does, however, satisfy the 80/20 rule in that we believe that
this level of security is adequate for a large majority of
prospective users and the technical approach that would need to have
been applied to allow for selective encryption of header elements
would have significantly increased the complexity of the
solution space to a point that it might become impractical if
not impossible to engineer a low-cost solution that could be
targeted to SMEs.

<PY> RosettaNet identified all the elements *minimally*
needed to "route" a message without having access to other header elements
/ payload. This includes the From / To party identities, a GUID for the
message (for tracking), Date&Time stamp and other elements like isSecureTransportRequired,
and put them in a separate header section called "DeliveryHeader", so that
even when everything else except the DeliveryHeader is encrypted, the message
can still be delivered.

It perhaps makes sense to review the grouping of ebXML header elements from the perspective of ease of encryption of the headers when needed (in the future).
</PY>

>
> 2. The RNIF 2.0 Receipt Acknowledgment contains the Message Digest of
> the original message.  This is stronger proof than ebXML's inclusion
> of the MessageHeader.MessageData.RefToMessageId, because it does not
> depend on the originator having generated a truly globally unique ID.

This is currently under discussion. In fact, the Business Process
specification has adopted the RNIF Receipt Acknowledgment and we
are working towards a process of reconciling the specifications.

<PY>This is an interesting point but, in RosettaNet
space the digest goes in the "payload" of the acknowledgment message and
it is perhaps easier if RN acknowledgments continue to go in the payload 
(from ebXML perspective), in stead of trying to use the ebXML header level
acknowledgment mechanism (or whatever the ebXML BP team eventually settles
on).

On  that question, what is the binding on / relationship between third party payloads / business process definitions from the ebXML BP group? I mean is there a conflict in RosettaNet (continuing) to put their Ack messages in the payload with the Service / Action in ebXML Header identifying appropriately?
</PY>

> 3. Non-repudiation of Relay message is not supported by ebXML.  While
> RNIF 2.0 also does not yet allow for this feature, it is an important
> member requirement that will affect future direction decisions.

I'm not sure that I understand what a Relay message is. Are you
talking about NR of messages exchanged p2p between nodes of a network
of RNIF systems (what we have called intermediaries) as a message
works its way from To->From?

Can you please explain why the extension mechanism isn't
adequate to your needs if the feature you require is not
directly supported?

<PY> Non-Repdudiation of Relay is ensuring that
a third-party-router / intermediary can not deny (later) that they had
"relayed" a message received from X to Y.  This would call for some
protocol between 'sending-party and intermediary' and 'intermediary and
receiving party', that involves digital signatures.
</PY>

>
> 4. ebXML supports multiple digital signature components.  Suggested
> use cases for this feature would be desirable.

If a message is augmented as it passes through an intermediary
it might be desirable to have the intermediary sign the augmented
message. Of course, this requires that the signature of the originator
of the message not be invalidated by the change, but that is another
matter.

Another use case is a message generated by an individual, signed
by her certificate keys, that is authenticated by her enterprise
and asserted so by including a signature generated with the
certificate of the enterprise authentication service.

See the work being done in the OASIS Security Services TC on
SAML.

<PY> I guess the issue was, are there any *concrete*
use cases for allowing multiple-signatures in the schema at this point?
Section 12.3.1.1 (in .98b specification) explicitly excludes the containing
TraceHeaderList element and all its descendants as these elements are subject
to change. In the second use case that was listed above, does the first
signature by individual need to be exposed to external parties? Could that
be an internal authentication matter? But, if we do want to keep the schema
to permit multiple signatures, it perhaps calls for offering some more
explanation on the intended use in the specification.
</PY>

> 5. RNIF has the concept of UnknownInitiatingPartner that includes
> explicit routing information (URL) for the (unknown) initiator.  It is
> not clear where this information could be carried in ebXML.  If this
> is not included, initiator's information would have to exist in a
> registry.

Quite possibly. In truth, there is no reason why the URL may not be
used as the identifier.

<PY> I agree. For a sending party that does not
have a prior contract with the receiving party, a URL can go in the URI
(value) for the partyId and some special string in the "type" attribute,
as "publicized" by the receiving party(?)
</PY>
> >
> > 6. RNIF also has a locationID that allows partner identification
> to
> > be more granular than DUNS+4.  It is not clear how one might
> encode
> > DUNS+4 plus additional locationID in ebXML.
<PY> In case it was not clear from the above text,
the purpose of the locationID (an example of which is "Sunnyvale-Facility"),
to use it in conjunction with the PartyId (e.g. Intel's DUNS+4) to point
to a more granular delivery location (URL) for the receiving (and sending)
party. This can be easilty satisfied with an optional "locationId" string
type attribute in partyId element.
</PY>.
> > 9. RNIF inReplyTo.ActionControl.ActionIdentity
> element tells what type
> > of message is being responded to.  This is implied by a combination
> of
> > the process specification and RefToMessageId, given some effort to
> look
> > them up first, but some implementations find it useful to have this
> > information in the header.
<PY> This is perhaps important. The reply messages
need to have elements (optional), that provide more contextual information
on the message being responded to than just the RefToMessageId. The ConversationId
is at a much higher level, and does not provide the much narrower context
of the message being replied to.
</PY>

>
> 10. RNIF's GlobalUsageCode is used to indicate test mode, negating the
> legally binding effect of transactions that aren't meant to be
> enforced.  Without it, out-of-band legal agreements must likely be
> made in order to distinguish binding transactions from testing.

This issue was discussed ad nauseum a while back (late last year I believe)
and we concluded that because you could extend the message envelope,
that we need not provide for this.

<PY>Yup. I also conveyed that :) but, if 
one received a signed order for 1 million widgets supposedly in test mode,
if the "test" aspect is not captured in the message itself, there could
be cases where this might be an issue. A small boolean that says this is
a message in "test" mode might help. Oops! not starting it again :)  
</PY>

> 11. RNIF Service Header contains KnownInitiatingPartner, which remains
> constant throughout the conversation.  This, can be determined through
> analysis of the choreography specification and "From" element of logged
> messages, but not easily.

In the present version, we only consider the exchange of messages
between two parties. This describes a collaboration between multiple
parties. That is a horse of a different color;-) We will need to
address multi-party collaborations in whatever comes next for ebXML.
 

<PY> This is not a multi-party issue. In a transaction
between two parties, that spans multiple message exchanges, this field
identifies, who "initiated" the transaction and stays constant for all
message exchanges.
</PY>