Re: XMLP/XMLE Use cases and processing models

+1

In fact, IMO, the proper way to encrypt the *entire* envelope
would be:

<xenc:EncryptedData xmlns:xenc="...">...</xenc:EncryptedData>

and *this* would be conveyed via the underlying transport with
the media type being requested for encrypted document
(application/encrypted or whatever) and thus be dispatched NOT
to a SOAP processor but to a decyphering processor.

Once the decryption has been effected, then, based
on the top-level element (SOAP:Envelope xmlns:SOAP="...") the
resultant document could be dispatched to a SOAP processor
and its media type would then be application/soap+xml (or
whatever we end up using).

At present, we also have constraints on our SOAP1.2 schema which
stipulate that a SOAP Envelope have exactly one Body element information
item which means that it is not possible to encrypt the Body element
itself, only its content. In addition, we preclude any other elements
as direct children of the Envelope save the Header element which
may be present at most once. Thus, it isn't possible to encrypt
the Header element itself, only its content.

Anything else would be an invalid SOAP message document w/r/t
the SOAP1.2 specification.

My 0.02 USD,

Chris

noah_mendelsohn@us.ibm.com wrote:

> David Orchard writes:
> 
> 
>>>Imagine I took a SOAP document and encrypted a big chunk of it,ie:
>>>
> 
>>><soap:envelope>
>>>     <xenc:encrypteddata>...</xenc:encrypteddata>
>>></soap:envelope>.
>>>
> 
>>>Again, this is not changing the SOAP spec in any way.
>>>
> 
> I beg to differ.  The envelope you show is assuredly not legal SOAP.  I 
> would recommend against anyone using this idiom.
> 
> There are of course an unbounded number of ways that one might consider 
> sending a message that conveys:  "I'll tell you that this is a SOAP 
> envelope, but the contents of this entire envelope are encrypted."  I 
> think that's what the above is trying to convey.  I suggest that the 
> example above is not a particularly good use of XML, Namespaces (it 
> violates the definition of soap:envelope) or SOAP (it's surely illegal 
> SOAP.)  SOAP provides mechanisms which are reasonably carefully crafted to 
> achieve what you want, in a much more controlled and namespace-compatible 
> manner.  I suggest we focus on those, and design MIME types accordingly. 
> Thank you!
> 
> ------------------------------------------------------------------
> 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/20/2002 12:38 AM
> 
>  
>         To:     <reagle@w3.org>, 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
> 
> 
> Joseph,
> 
> I'm not suggesting that XMLE try to automatically make pre-existing
> applications XML Encryption aware.  I don't follow how you get that
> extraordinary claim.  I'm suggesting that documents have content-type of
> application/xenc+xml for documents containing XMLE where XMLE decryption
> MUST be done to interpret the contents according to the namespace names
> within.
> 
> Imagine I took a SOAP document and encrypted a big chunk of it,ie
> <soap:envelope><xenc:encrypteddata>...</xenc:encrypteddata></soap:envelope>.
> The SOAP processor knows nothing about the soap document as encryption
> happened "afterwards".  When such a document was sent, decryption would be
> required first.  After decryption, then a SOAP processor would know what 
> to
> do with it.  While this particular document is encrypted, it is NOT a SOAP
> document as per the soap namespace name nor media type.
> 
> Making such a document have a media-type of application/xenc+xml ensures
> that the document can be dispatched to the correct piece of software, 
> which
> you can't do if it has media-type application/soap.
> 
> Again, this is not changing the SOAP spec in any way.
> 
> Cheers,
> Dave
> 
> 
>>-----Original Message-----
>>From: Joseph Reagle [mailto:reagle@w3.org]
>>Sent: Tuesday, February 19, 2002 10:43 AM
>>To: noah_mendelsohn@us.ibm.com; david.orchard@bea.com
>>Cc: 'www-xenc-xmlp-tf'; 'xml-dist-app'; 'xml-encryption'
>>Subject: Re: XMLP/XMLE Use cases and processing models
>>
>>
>>
>>Exactly. Applications which use to use XML Encryption or
>>otherwise expect
>>to have elements from other namespaces need to be savvy about
>>what they
>>want to do (e.g., encrypt the content of a SOAP:Header) and
>>how they want
>>to do it  (e.g., write a flexible, create a new namespace ,etc.)
>>Applications that haven't done this might have to take some
>>other steps
>>which won't as easy and straightforward but it's their call.
>>There's no
>>solution that automatically makes all pre-existing XML
>>applications XML
>>encryption aware or capable in every possible scenario --
>>like encryption
>>the SOAP header itself.
>>
>>On Monday 18 February 2002 20:21, noah_mendelsohn@us.ibm.com wrote:
>>
>>>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>
>>>
>>--
>>
>>Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
>>W3C Policy Analyst                mailto:reagle@w3.org
>>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
>>W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
>>
>>
> 
> 
> 
>

Received on Thursday, 21 February 2002 11:15:52 UTC