W3C home > Mailing lists > Public > www-xenc-xmlp-tf@w3.org > December 2001

Re: XMLP Comments to XMLE LC

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>
Message-ID: <OF9CA32FF0.3BC66354-ON49256B29.0079FBD4@LocalDomain>

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 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 25 March 2005 11:21:54 GMT