RE: XMLP/XMLE Use cases and processing models

I am generally in agreement with Chris.

If there is a desire to provide a hint as to what the decrypted content will
be of a MIME Content-Type labeled xenc:EncryptedData element, one
possibility would be to allow an optional parameter. Something like

Content-type: application/xenc+xml;
	decrypted-content="soap:Envelope xmlns:soap='...'"

or perhaps

Content-type: application/xenc+xml;
	decrypted-namespace="..."; decrypted-root="Envelope"

I'm not sure how often one would want a different decyrptor (or a standard
decryptor acting is a different way) depending on the type of decrypted
content but if you did, I would think you could sometimes tell what
decyrptor you wanted to use based just on the namespace of the decrypted
content.

If there is a consensus to allow the parts of a SOAP message to be
separately encrypted where this is currently prohibited by the SOAP schema,
the SOAP schema can be liberalized to permit this.

If you want to encrypt parts of a SOAP message in a way fitting into the
current SOAP processing flow, directed by header blocks, I don't see a
problem.

Donald

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Thursday, February 21, 2002 11:15 AM
To: noah_mendelsohn@us.ibm.com
Cc: david.orchard@bea.com; reagle@w3.org; 'www-xenc-xmlp-tf';
'xml-dist-app'; 'xml-encryption'
Subject: 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 Monday, 25 February 2002 12:16:10 UTC