RE: XMLP/XMLE Use cases and processing models

XMLE supports encrypting entire or subsets of documents.  The question does
apply to any document type that is encrypted.

However, XMLE specifically calls out SOAP as a primary motivation for XMLE.
Further, the XMLE group specifically asked for XMLP group for comments.
While the issue I'm raising is applicable to more than just SOAP, it's clear
that SOAP is a primary customer.

What does it matter if the issue has broader applicability than SOAP?  It's
still an issue that applies when XMLE is used with SOAP.

My example was not about encrypting the soap envelope.  In that case, the
root element would be XMLE and the content-type would be
application/xenc+xml or somesuch.  My example was when the children of the
root element are encrypted and an XMLE decryption step is required before
the contents of the root element can be understood to match the root
elements namespace name.

This seems to be going in circles.  There is a clear case where the contents
are not valid according to the content-type or the namespace names of the
document, and it seems reasonable that XMLE should proscribe what should
happen in that case.  Especially when XMLE uses examples of encrypting
portions of a document.

Cheers,
Dave

> -----Original Message-----
> From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Tuesday, February 19, 2002 2:50 PM
> To: david.orchard@bea.com
> Cc: 'www-xenc-xmlp-tf'; 'xml-dist-app'; 'xml-encryption'
> Subject: RE: XMLP/XMLE Use cases and processing models
>
>
> If I understand your use case, it's essentially:  "We want to
> encrypt the
> entire SOAP envelope, not just some headers.  Now, what's the
> MIME type?"
> Question:  why wouldn't I be asking the same question about
> most >every<
> other XML vocabulary?  What about encrypted HTML?  Encrypted Employee
> Description?  Mime types don't make it easy to do this sort
> of thing.  You
> described the SOAP example as an 'edge case'.  Why is it more
> important to
> do this for SOAP than for any other MIME typed data you might want to
> "wrap" in an encrypted form?
>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
>
>
>
>
>
> "David Orchard" <david.orchard@bea.com>
> 02/18/2002 10:29 PM
>
>
>         To:     Noah Mendelsohn/Cambridge/IBM@Lotus
>         cc:     "'www-xenc-xmlp-tf'"
> <www-xenc-xmlp-tf@w3.org>, "'xml-dist-app'"
> <xml-dist-app@w3.org>, "'xml-encryption'" <xml-encryption@w3.org>
>         Subject:        RE: XMLP/XMLE Use cases and processing models
>
>
> Noah,
>
> My point isn't how SOAP could use Encryption in the manner that you
> suggest.
> That is one obvious solution, and I agree that it is a
> reasonable approach
> in many cases.
>
> My point is that XMLE allows the "edge" case that I described.  The
> difference between the two is that the example I gave has a
> xenc processor
> required to be the first step (yet is hidden inside a soap
> message) and
> your
> sample requires that a SOAP intermediary be the first step.
> I suggest
> that
> the first case can be made "legal" by having a MIME type.
> Another option
> would be for xenc to disallow the first case.  I'm trying to
> be flexible
> and
> search for a way of allowing the syntax to be legal and also
> allow correct
> dispatch.
>
> As an aside, I'm fully in favour of having an explicit
> processing model.
> Targetting actors is one way to get there.  I think that we
> will find over
> time that ordering becomes an issue, fwiw.
>
> Cheers,
> Dave
>
> > -----Original Message-----
> > From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com]
> > Sent: Monday, February 18, 2002 5:21 PM
> > To: david.orchard@bea.com
> > Cc: 'www-xenc-xmlp-tf'; 'xml-dist-app'; 'xml-encryption'
> > Subject: RE: XMLP/XMLE Use cases and processing models
> >
> >
> > David Orchard suggests:
> >
> >         <SOAP:Envelope xmlns:soap="..." >
> >         <xenc:EncryptedData xmlns:xenc="...">
> >         ...
> >         </xenc:EncryptedData>
> >         </SOAP:Envelope>
> >
> > which is indeed not valid SOAP, suggesting the need for a new
> > media type.
> > But... that's not how you would use SOAP IMO.  I suggest instead:
> >
> >         <SOAP:Envelope xmlns:soap="..." >
> >            <SOAP:Header>
> >                 <xenc:EncryptedData xmlns:xenc="..."
> >                             SOAP:mustUnderstand="true"
> >                             SOAP:role="decryptingIntermediary">
> >                 ...
> >                 </xenc:EncryptedData>
> >            </SOAP:Header>
> >            <SOAP:Body>
> >                 ...leave empty or put dummy element here
> >                 ...if you don't want unencrypted data
> >         </SOAP:Envelope>
> >
> > This is valid SOAP, does what you want, and doesn't need a
> > non-SOAP media
> > type, I think.
> >
> > ------------------------------------------------------------------
> > Noah Mendelsohn                              Voice: 1-617-693-4036
> > IBM Corporation                                Fax: 1-617-693-8676
> > One Rogers Street
> > Cambridge, MA 02142
> > ------------------------------------------------------------------
> >
> >
> >
> >
> >
> >
> >
> > "David Orchard" <david.orchard@bea.com>
> > 02/15/2002 08:35 PM
> >
> >
> >         To:     Noah Mendelsohn/Cambridge/IBM@Lotus
> >         cc:     "'www-xenc-xmlp-tf'"
> > <www-xenc-xmlp-tf@w3.org>, "'xml-dist-app'"
> > <xml-dist-app@w3.org>, "'xml-encryption'" <xml-encryption@w3.org>
> >         Subject:        RE: XMLP/XMLE Use cases and
> processing models
> >
> >
> > Noah,
> >
> > I completely understand the cases you are talking about, and
> > I agree with
> > the direction the XMLP wg is going wrt QNames and
> intermediaries.  My
> > comments on namespace names have specifically been around the
> > context of
> > potentially misleading qnames.   I agree the case I mentioned
> > is bizarre,
> > but part of our job is to examine these corner cases.
> >
> > After some twists and turns in the discussion, a sample
> > scenario should
> > illustrate.  For whatever reason, encryption of a portion
> of a message
> > occurs.  The downstream processor MUST decrypt the message
> to have it
> > conform to a Qname or media type.  Looking at a SOAP/HTTP fragment,
> >
> > Content-type: application/soap
> >
> > <SOAP:Envelope xmlns:soap="..." >
> > <xenc:EncryptedData xmlns:xenc="...">
> > ...
> > </xenc:EncryptedData>
> > </SOAP:Envelope>
> >
> > Now clearly this isn't valid.  My suggestion is that changing
> > the content
> > type to Content-type: application/xenc-xml solves the issue of
> > content-type
> > problem.
> >
> > This is very similar to the xhtml/xslt example that the tag
> > is discussing,
> > where one perspective is that
> >
> > <xhtml:html>
> > <xslt:...>
> > ....
> > </xslt:...>
> > </xhtml:html>
> >
> > SHOULD have a content-type of application/xslt(+xml)
> >
> > I'm trying to apply the same rule of the xslt example
> > (dispatch based upon
> > content-type, then qname) to XMLE.  To me, these are very similar
> > (transformational) cases.
> >
> > Joseph is strongly pushing back because he believes that XMLE
> > should not
> > try
> > to enforce behaviour on other applications.  As a result of our
> > discussions,
> > he has taken an action item to register an xenc
> content-type.  From my
> > perspective, I'm trying to get some rules in place for how that
> > content-type
> > should be used with xmle.  I suggested something along the
> > lines of "When
> > a
> > content-type is provided for a message, XML Encryption
> > requires that the
> > application/xenc+xml MUST be used when decryption is required
> > to correctly
> > interpret the content".  But we didn't get very far with that
> > suggestion.
> >
> > There is a section in the TAG draft findings on content-type
> > and namespace
> > disptach [1] that states "It is a serious error for the
> > resource body to
> > be
> > inconsistent with the assertions made about it by the MIME
> > headers. ",
> > which
> > I believe is the case in the SOAP example that I mentioned.  These
> > findings
> > are NOT ratified by the TAG, but I believe it likely that
> > there will be a
> > statement on this matter.
> >
> > Cheers,
> > Dave
> > [1] http://www.w3.org/2001/tag/2002/0129-mime
> >
> >
> >
> > > -----Original Message-----
> > > From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com]
> > > Sent: Friday, February 15, 2002 4:27 PM
> > > To: david.orchard@bea.com
> > > Cc: imamu; maruyama; reagle; www-xenc-xmlp-tf; xml-dist-app;
> > > xml-encryption
> > > Subject: 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 Tuesday, 19 February 2002 21:26:15 UTC