- From: Steve Wiley <steve@myProof.com>
- Date: Mon, 02 Oct 2000 16:12:27 -0700
- To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
- Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org
At 08:07 PM 10/2/2000 +0900, Takeshi Imamura wrote: >Hello Steve, > >Thank you for your suggestion. I think your idea is really good and I would >like to incorporate it into our spec. Great! Thanks for looking into it. >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. Yes, that is good news. I am glad we can have that as a backup solution. The XPAth solution works best for us. We try at all costs to avoid altering a customer XML schema. The ID attribute seems rather safe to add but there may already be an ID attr. In that case we would have to map to the preexisting ID's. This isn't too bad but it complicates the application. You would also have to account for the possibility of ID's with duplicate values. Which, again, is not that hard to deal with. Very unlikely, but the customer could change the ID values without breaking the validity of the document but it would surely break our application. So, the XPath solution seems to be the safest and easiest solution for us. With the XPath addition, the specification meets all our needs. I'll keep you posted if there are any further developments. Thanks again, Steve >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()='receipt']/*[name()='buyer']/*[name()='address']/*/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()='receipt']/*[name()='buyer']/*[name()='name']/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-xm > lencoverview.html > > > > >and: 'Specification of Element-wise XML Encryption' > >http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/att-0005/01-xm > lenc-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 19:02:57 UTC