RE: XMLP/XMLE Use cases and processing models

David Orchard writes:

>> My concerns have been about the case where a vocabulary that
>> knows nothing about encryption has a portion of an instance
>> encrypted, and keeping the namespace name and root element
>> of the vocabulary as if encryption didn't occur is "fibbing"
>> about the namespace.  Imagine if SOAP-SEC did NOT know about
>> encryption, yet had encrypted content, how would a
>> dispatcher know to decrypt content?  This is also assuming
>> there is no explicit soap actor.

(speaking for myself, not the Protocls WG)

The designs being worked on in the Protocols WG effectively cover this
case.  First of all, we would discourage such misuse of the QNames that
identify header blocks.  As described below, the preferred idiom would
be to repace the original block with one carrying a QName with the
semantic:  "this is encrypted content.'  The pertinent SOAP mechanisms
are as follows:

SOAP establishes a normative baseline model which is that an
intermediary processing a header block must do so in a manner that
conforms fully and completely to a specification associated with that
QName (we don't say how such specifications are established...it's
your responsibility in using a header block to know its
specification.) [1, 2]

{The above has been true for awhile; the mechanisms in the next few
paras were recently agreed to, but are not yet in the editors drafts
of the specifications.}

To handle cases like encryption, we allow an intermediary to remove a
block, and perhaps replace it with other (e.g. encrypted) content.  In
such cases, one of two things must be true.  Either a) one of the
blocks in the inbound message explicitly allowed the change or b)
[your case] the intermediarly that makes the change must introduce a
header >>> which has as its specification information sufficient to
alert downstream nodes to the nature of the change.<<< This can be as
simple as being careful with the specification associated with the
QName for the encrypted block itself.  In short, you MUST NOT just
switch the content on any old block;  you MUST properly use QName
identified blocks to indicate to downstream nodes any change in
the normal interpretation of the message.

How would this apply to your challenge above?  First of all, the usage
you describe is somewhat bizarre, and not intended as the normal way
of doing things.  We would generally prefer that you remove the
original unencryped header block and its QName and use a new QName to
indicate encrypted content.  Still, if you really wanted to put the
encrypted content under the original (and now misleading) QName,this
is how it would work: rule b above would require you to introduce a
second header block,labeled "mustUnderstand" with the semantic "don't
trust the other QNames in this message...I've overridden their
traditional meanings."  Again I am NOT encouraging this, but pointing
out that the message would necessarily contain a warning that this had
been done.  As the message moved downstream, either a decrypting
intermediary would act on the alert, do the decryption and put the
message back together, or the recipient would find a mustUnderstand
header warning of the problem.  It would either understand how to deal
with the mess, or would recognized that it did not understand, and
safely fault.

Bottom line: SOAP normatively requires you to use QNames according to
an associated specification.  If you really, really want to override
that, there are controlled and reasonably safe ways of doing so, but I
see no good reason for users to do misuse the system that way.

[1] http://www.w3.org/TR/2001/WD-soap12-part1-20011217/#muprocessing
[2] http://www.w3.org/TR/2001/WD-soap12-part1-20011217/#procsoapmsgs
------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Friday, 15 February 2002 19:41:09 UTC