W3C home > Mailing lists > Public > xml-encryption@w3.org > October 2000

Re: Problem: How to encrypt nodes without breaking parsers

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Mon, 2 Oct 2000 20:07:10 +0900
To: Steve Wiley <steve@myProof.com>
cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org
Message-ID: <4925696C.003D3C1A.00@d22mta13.yamato.ibm.com>



Hello Steve,

Thank you for your suggestion.  I think your idea is really good and I would
like to incorporate it into our spec.

By the way, I heard there was a discussion on the validity of HTML/XML, that is,
how applications should work when detecting unknown vocabularies, and it reached
a consensus that unknown attributes (and resultant error messages) may be
ignored.  Considering this, adding an ID attribute to an element to be encrypted
and not changing its content model may not be so serious.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Japan, Ltd.
E-mail: imamu@jp.ibm.com



From: Steve Wiley <steve@myProof.com> on 2000/10/01 02:52 AM

To:   Hiroshi Maruyama/Japan/IBM@IBMJP, xml-encryption@w3.org
cc:    (bcc: Takeshi Imamura/Japan/IBM)
Subject:  Re: Problem: How to encrypt nodes without breaking parsers




Hello Hiroshi,

Thank you for your quick reply.  Your point about hiding structures is well
taken.  We are using that functionality and conforming with your specification.
It is working very well and we are happy with it.  The specification and other
documentation has been very helpful.

As I mentioned before we are working with legacy customer XML applications and
need to preserve the same content models.  We saw two potential problems.  The
first you addressed.  The second is still unanswered.
1. Preserving the content model.  The contents we need to encrypt are
are CDATA so from your comments it looks like we can conform to the
specification
as it stands.
2. Referencing the encrypted CDATA is very useful and perhaps even
necessary for
decryption.  To my understanding your specification does this by using the URI
attribute in the <Reference> element.  This does not work for us because we
cannot
add ID attributes to the legacy customer XML documents without breaking their
validity in the legacy applications.  So for the time being we are adding
our own
attribute XPath which works very well for us (see the example below).

Here is an actual implementation on a contrived document.
1.  Would you consider adding an XPath attribute to the <Reference>
element.  Or
is there another way we can achieve the same purpose.
2.  Could you let me know if the rest of the implementation looks OK and
conforms
to you specification.  Any suggestions for improvements would also be
appreciated.

Thanks for you time and attention, it is very much appreciated,
Steve

Example: A simple retail receipt where the buyer's personal information is
encrypted.
Note that the content model of the <receipt> cannot be changed except for
adding
the high level <Encryption> element.  I attached the file in case mail
mangles the format.
It was encrypted in two passed. First the child elements of the buyer's
address (street,
city, state, zip) and then the buyer's name.

<?xml version="1.0"?>

<?xml-stylesheet href ='receiptstyle.xsl' type='text/xsl'?>
<receipt version="1.001" type="retail receipt"
Unique_id="200001054CWOW0010050000000008D43200CF2A">
   <seller>
     <name>Joe's Hardware</name>
     <address>
       <street>123 Industry Ave.</street>
       <city>San Jose</city>
       <state>CA</state>
       <zip>95063</zip>
     </address>
   </seller>
   <buyer>
     <name>cfHB/A/KD0Cdb+Ozh+q/6A==</name>
     <address>
       <street>MrVkgoMORQhv98d52JDKkg==</street>
       <city>X2kMEA8p3EAQWEmUYGQqzA==</city>
       <state>prTBbXEPOS4=</state>
       <zip>NMaHaAMVSVA=</zip>
     </address>
   </buyer>
   <transaction type="CASH" />
   <date>
     <year>2000</year>
     <month>January</month>
     <day>05</day>
     <time>10:03</time>
   </date>
   <items>
     <item>
       <name>Hammer</name>
       <partNum>X09989-a</partNum>
       <quantity>1</quantity>
       <price>10.95</price>
     </item>
     <item>
       <name>Fence post repair kit</name>
       <partNum>142-6777-01</partNum>
       <quantity>3</quantity>
       <price>4.00</price>
     </item>
   </items>
   <summary>
     <cost>22.95</cost>
     <tax>1.98</tax>
     <total>24.93</total>
   </summary>
   <Encryption>
     <EncryptionInfos>
       <EncryptionInfo>
         <KeyInfo>
           <KeyName>com.sun.crypto.provider.DESKey@fffe7a46</KeyName>
         </KeyInfo>
         <EncryptedContentInfo>
           <ContentEncryptionMethod
Algorithm="http://www.w3c.org./xmlenc#des-ecb-pkcs5padding" />
           <Reference
XPath="/*[name()=&apos;receipt&apos;]/*[name()=&apos;buyer&apos;]/*[name()=&apos;address&apos;]/*/node()"

/>
         </EncryptedContentInfo>
       </EncryptionInfo>
       <EncryptionInfo>
         <KeyInfo>
           <KeyName>com.sun.crypto.provider.DESKey@fffe7a46</KeyName>
         </KeyInfo>
         <EncryptedContentInfo>
           <ContentEncryptionMethod
Algorithm="http://www.w3c.org./xmlenc#des-ecb-pkcs5padding" />
           <Reference
XPath="/*[name()=&apos;receipt&apos;]/*[name()=&apos;buyer&apos;]/*[name()=&apos;name&apos;]/node()"

/>
         </EncryptedContentInfo>
       </EncryptionInfo>
     </EncryptionInfos>
   </Encryption>
</receipt>



At 09:53 AM 9/28/2000 +0900, you wrote:


>Hi, Steve,
>
>I think one point that you are making is that it would be
>good if we can preserve the same content model
>(read: validity) after encryption as in your example.
>This is achievable if all the contents to be encrypted
>are CDATA.  However, sometimes we want to hide
>not only text strings but structures, perhaps by
>replacing a whole element (along with its all descendants)
>with a base64 encoded encrypted data, which may
>break the content model (if the parent content model
>is not MIXED).  See the following example:
>
>Plain XML:
>   <order>
>     <items> ... </items>
>     <payment>
>       <creditCard> ... </creditCard>
>     </payment>
>   </order>
>
>Encrypted  XML:
>   <order>
>     <items> ... </items>
>     <payment>Dkwo23PDqcdopqDESP4/dd==</payment>
>   </order>
>
>and the content model of <payment> is like this:
>
><!ELEMENT payment (creditCard | check | moneyOrder)>
>
>Hiroshi
>
>--
>Hiroshi Maruyama
>Manager, Internet Technology, Tokyo Research Laboratory
>+81-46-215-4576
>maruyama@jp.ibm.com
>
>
>
>From: Steve Wiley <steve@myProof.com> on 2000/09/28 06:00
>
>To:   xml-encryption@w3.org
>cc:    (bcc: Hiroshi Maruyama/Japan/IBM)
>Subject:  Problem: How to encrypt nodes without breaking parsers
>
>
>
>Hello,
>
>I just joined this group six days ago.Content-type: text/plain; charset=big5
>X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id
>UAA22626
>
>?I read: 'XML Encryption Syntax and
>Processing'
>
>http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/att-0001/01-xmlencoverview.html

>
>and: 'Specification of Element-wise XML Encryption'
>http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/att-0005/01-xmlenc-spec.

>html
>
>The 'XML Encryption Syntax and Processing' document addresses issues that are
>important to us such as being able to encrypt the content of an element (text
>node or
>attribute) but not the element itself.?However, the 'Specification of
>Element-wise XML Encryption'
>doesn't seem to allow encrypting text node or attributes.?Also, we need a
>better way of
>referencing nodes besides URI's.
>
>We are working with legacy customer XML applications that will choke if the
>structure of the
>document changes.?Therefore we would like to see that functionality in 'XML
>Encryption Syntax
>and Processing' makes it into 'Specification of Element-wise XML Encryption'.
>And that:
>
>1. The <Reference> element needs an attribute to refer to nodes by XPath.?A
>URI won't work
>???for us because we would have to add ID attributes to the referenced node
>thus changing the
>???XML schema.
>2. Node and attribute values must be able to be encrypted without adding new
>elements into
>???the parent element for the same reason.
>
>Here is contrived example of what we need.?All the employee information would
>be
>encrypted but different departments would have the keys to look at information
>approved
>for their department.
>
><employee-database>
>????????employee emp-type='contract' salary-level='eng-4' >
>????????????????name>Joan Doe</name>
>????????????????med-plan>Blue Cross</med-plan>
>???????????????? . .
>????????/employee>
>???????? . .
></employee-database>
>
>The application can handle unknown high level elements but can NOT handle
>new elements inserted into elements like <med-plan>.?Therefore we would like
>to encrypt node or attribute values and replace them with the base64 string.
>This way we don't break any legacy parsers.?We would then like to note which
>keys apply to which nodes or attributes to decrypt.?However we can NOT use
>a <reference URI='xxx'> because we would have to insert an 'Id' attribute into
>every <employee> or <med-plan> element.?We would like to use
><reference XPath='xxx'> which would allow easy access to decrypt.?Could an
>XPath attribute be added to <Reference>??Here is how I think it could be
>applied
>to the above example:
>
><employee-database>
>???<employee emp-type='contract' salary-level='DHI&^BhU==' >
>???????<name>Joan Doe</name>
>???????<med-plan>cb6Tyre4</med-plan>
>???????. . .
>???</employee>
>???. . .
>???<Encryption xmlns="http://www.w3.org/xmlenc">
>???????<EncryptionInfos>
>???????????<EncryptionInfo>
>???????????????<KeyInfo>
>???????????????????<KeyName>MED-PLAN</KeyName>
>???????????????</KeyInfo>
>???????????????<EncryptedContentInfo>
>???????????????????<ContentEncryptionMethod
>Algorithm="http://www.w3.org/xmlenc#des-ecb-pkcs5padding" />
>???????????????????<Reference
>XPath='/employee-database/employee/med-plan/node()'>
>???????????????????????<CanonicalizationMethod
>Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" />
>???????????????????</Reference>
>???????????????</EncryptedContentInfo>
>???????????</EncryptionInfo>
>????????????<EncryptionInfo>
>???????????????<KeyInfo>
>???????????????????<KeyName>SALARY-LEVEL</KeyName>
>???????????????</KeyInfo>
>???????????????<EncryptedContentInfo>
>???????????????????<ContentEncryptionMethod
>Algorithm="http://www.w3.org/xmlenc#des-ecb-pkcs5padding" />
>???????????????????<Reference
>XPath='//*/attribute::salary-level'>
>???????????????????????<CanonicalizationMethod
>Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" />
>???????????????????</Reference>
>???????????????</EncryptedContentInfo>
>???????????</EncryptionInfo>
>??????</EncryptionInfos>
>???</Encryption>
></employee-database>
>
>Thus, in this example we didn't need to alter the structure (add any elements)
>to <employee-database>
>and only need <EncryptionInfo> element for each type of node or attribute that
>needs encryption.
>
>Any ideas, corrections or thought are welcome.?I am new to this so I may have
>overlooked
>or misunderstood the specs.
>
>So, to summarize:
>1. The <Reference> element needs an attribute to refer to nodes by XPath.?A
>URI won't work
>???for us because we would have to add ID attributes thus changing the XML
>schema.
>2. Node and attribute values must be able to be encrypted without adding new
>elements into
>???the parent element.
>
>Thanks,
>Steve Wiley
>
>P.S.
>
>  I just joined this group six days ago.?I haven't seen any mail activity and
>the mail
>archives don't show anything past August.?Are things that quiet or is there a
>mail
>server problem.
Received on Monday, 2 October 2000 07:07:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:17 GMT