- From: Hiroshi Maruyama <MARUYAMA@jp.ibm.com>
- Date: Sat, 22 Dec 2001 07:23:40 +0900
- To: reagle@w3.org
- Cc: "David Orchard" <dorchard@bea.com>, www-xenc-xmlp-tf@w3.org, "Satoshi Hada" <SATOSHIH@jp.ibm.com>, "Takeshi Imamura" <IMAMU@jp.ibm.com>, Maryann_Hondo/Austin/IBM%IBMUS <mhondo@us.ibm.com>
Joseph, >Ah... So you think it is likely/desirable to create specific SOAP security >headers for this purpose? What are the semantics of these additional >headers over that of a message without them but the payload is still an >EncryptedData? Is it that if one has the SOAP-SEC:Encryption, if the data >can't be encrypted then SOAP has the capability to respond with an error >message (e.g., "Data un-decipherables")? No, the intention here is to let the receiving SOAP middleware know which EncryptedData elements needs to be decrypted and which ones are to be left encrypted (which are most likely in the message payload and need to be decrypted by the application at a later stage). Since a SOAP payload can just an arbitrary XML, it can contain EncryptedData that is nothing to do with SOAP processing; it is just part of data. Without a specific SOAP header, it would be difficult to tell which one is to decrypt and which one is not (one may argue that "try everyone of them and see if it is encrypted by a key known to me" would work but this strategy has many drawbacks). In addition, if an attachement is to be encrypted using XML Encryption, we need to have a processing model. An SOAP attachment encryption example follows: MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; start="<image.xml>" Content-Description: This is the optional message description. --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <image.xml> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <SOAP-SEC:Encryption xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12" SOAP-ENV:actor="some-URI" SOAP-ENV:mustUnderstand="1"> <SOAP-SEC:EncryptedDataList> <SOAP-SEC:EncryptedDataReference URI="cid:encrypted-image.xml"/> </SOAP-SEC:EncryptedDataList> <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="EK" CarriedKeyName="Symmetric Key" Recipient="John Smith"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:KeyName>John Smith's RSA Private Key</ds:KeyName> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>ENCRYPTED 3DES KEY......</xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI="cid:encrypted-image.xml"/> </xenc:ReferenceList> </xenc:EncryptedKey> </SOAP-SEC:Encryption> </SOAP-ENV:Header> <SOAP-ENV:Body> <image:info xmlns:image="some-URI"> <image:description>This is a jpeg image.</image:description> <image:content href="cid:image.jpg"/> </image:info> </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: application/xml; charset=UTF-8 Content-Transfer-Encoding: 8-bit Content-ID: <encrypted-image.xml> <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="encrypted-body-entry" Type="http://www.w3.org/2001/04/xmlenc#Element"> <xenc:EncrpytionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:RetrievalMethod URI="cid:image.xml#EK" Type ="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/> <ds:KeyName>Symmetric Key</ds:KeyName> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>ENCRYPTED IMAGE......</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> --MIME_boundary-- Hiroshi -- Hiroshi Maruyama Manager, Internet Technology, Tokyo Research Laboratory +81-46-215-4576 maruyama@jp.ibm.com From: Joseph Reagle <reagle@w3.org> on 2001/12/22 07:02 Please respond to reagle@w3.org To: Hiroshi Maruyama/Japan/IBM@IBMJP cc: "David Orchard" <dorchard@bea.com>, www-xenc-xmlp-tf@w3.org, Satoshi Hada/Japan/IBM@IBMJP, Takeshi Imamura/Japan/IBM@IBMJP, Maryann Hondo/Austin/IBM@IBMUS Subject: Re: XMLP Comments to XMLE LC On Wednesday 19 December 2001 04:32, Hiroshi Maruyama wrote: > We have been looking at applying XML Encryption to SOAP envelope. The > following is an example of SOAP header for XML encryption that we are > considering. The point here is that the receiving SOAP application knows > what <xenc:EncryptedData> elements are to be decrypted. Ah... So you think it is likely/desirable to create specific SOAP security headers for this purpose? What are the semantics of these additional headers over that of a message without them but the payload is still an EncryptedData? Is it that if one has the SOAP-SEC:Encryption, if the data can't be encrypted then SOAP has the capability to respond with an error message (e.g., "Data un-decipherables")? > <SOAP-SEC:Encryption> element is combined with <SOAP-SEC:Signature>, the > use of the decryption transform solve the interdependency problem. Also > our scenario includes encrypting SOAP attachments through a "cid: ..." > URI. (such as cid:image.jpg). Could you show that in an example too? -- 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 Friday, 21 December 2001 17:23:54 UTC