- From: Steve Wiley <steve@myProof.com>
- Date: Sat, 30 Sep 2000 10:52:20 -0700
- To: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org
- Message-Id: <4.3.2.7.2.20000930095307.00aab100@myProof.com>
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-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.
Attachments
- application/xml attachment: aa-simple-receipt-encrypt.xml
Received on Saturday, 30 September 2000 13:42:58 UTC