- From: <edsimon@xmlsec.com>
- Date: Fri, 30 Nov 2001 15:58:57 -0500
- To: xml-encryption@w3.org, rivest@mit.edu
I should add that URIs are used for retrieving data in the <CipherReference>, <DataReference>, and <KeyReference> elements. Upon initial consideration, the same views expressed below for <CipherReference> should hold for <DataReference> and <KeyReference> as well. Ed -- Original Message -- >On Fri, Oct 26 2001, Ron Rivest wrote: > >(2) You have provisions for referring to some elements indirectly (e.g. >through a URI), but you may need some way to ensure that what you retrieve >is what was intended (e.g. through a hash of the element to be retrieved). >Perhaps this is implicitly handled already... > >I respond: > >I think a key phrase in the comment is "ensure that what your retrieve is >what was intended". Of course, the definition of "what was intended" will >change from application to application. > >A common scenario would be data that was originally part of the document >in question, that was encrypted, and stored outside the document. If the >application intends that no alteration happen to that data while it is "away", >then it should create a signature of the encrypted data beforehand and verify >that signature before decrypting. Even if the data is not being stored >outside of the document but whose encrypted form is being stored inline, >it may be reasonable to use an XML Signature to protect its integrity. > >Another scenario is where a document has no or incomplete prior knowledge >of the plaintext content of an <EncryptedData> element. For example, suppose >information about Imelda's stock portfolio is encrypted (directly or indirectly) >with Imelda's encryption public key and held on a server at XYZ Corp. However, >Imelda has a financial management program on her PC that integrates data >from various sources, including her stock portfolio managed by XYZ Corp. > > >Imelda's financial info document stored on her PC might look like this: > ><MyFinancialInfo> > ><MyBankAccounts>...</MyBankAccounts> > >... > ><MyStockPortfolio> ><EncryptedData xmlns="..."> >... ><CipherData> > <CipherReference > URI="http://www.example.com/xyzcorp/OurClientsStockPortfolios/Imelda.xml"> > <Transforms> > <ds:Transform > Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> > <ds:XPath> > self::text()[parent::CipherValue[@id="StockPortfolio"]] > </ds:XPath> > <ds:Transform> > <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/> > </Transforms> > </CipherReference> ></CipherData> > ></EncryptedData> ></MyStockPortfolio> ></MyFinancialInfo> > >In the above example, the ciphertext octets that result from processing >CipherData might best be signed by XYZ Corp. since it would be XYZ Corp. >that would have last touched Imelda?s stock portfolio data. > >Regards, Ed > > >-- Original Message -- > >> >>http://www.w3.org/Encryption/2001/Minutes/011119-tele.html >> W3C XML Encryption WG >> >> 2001-November-19 >> Chair: Joseph Reagle >> Note Taker: Joseph Reagle [ascii] >> >>Participants >> >> * Joseph Reagle, W3C >> * Blair Dillaway, Microsoft >> * Ed Simon, XMLsec >> * Christian Geuer-Pollmann, University of Siegen >> * Eric Cohen, PwC >> >>News >> >>Status of documents >> >> * Last Call ended November 9th. I've sent a nagmail to SOAP, SAML, >> and Schema WGs since I got them to agree to consider the Last >> Call, but they never responded with a date of response -- nor >> comments obviously. >> >>Reviewing Previous Items >> >> 1. Eastlake: add real life examples in section 5.5 to illustrate. >> Pending. Open for re-assignment. >> 2. Action Hughes: ( XML Encryption Processing Model) Will investigate >> and send an email on Xerces implementation using XNI, or DOM when >> processing Element or Element Content. >> Pending. >> >>Requirements >> >> ... >> >>Draft >> >> Pending >> >> * Ed Simon >> 1. Should the CarriedKeyName attribute really be a child >> element? >> ACTION Reagle: change to a child element, cc: Merlin/Takeshi >> to see if they oppose. >> 2. Section 3.5: The ReferenceList Element In the schema >> definition, why not use <choice> rather than <sequence>? >> ACTION Reagle: change to choice. >> * Christian Geuer-Pollmann >> 1. (Many editorial comments) >> 2. Should we add a warning into section "3.1 EncryptedType" that >> it is not allowed (or could cause problems) if an >> EncryptedData element becomes the DocumentElement of a new >> Document with @Type="ElementContent" ? >> ACTION Reagle: add warning text on this point if it doesn't >> already exist, "decrypted content may not be well-formed >> XML." >> * Herzberg's comments on Decryption Transform >> 1. Requests a decrypt:Remove which indicates the identified >> element should not be part of the Signature. >> Reagle: I believe this functionality is addressed directly >by >> XML Signature. >> Telecon participants agree. >> * Takeshi Imamu >> 1. Should a nonce be associated with an EncryptedKey? A nonce >> cannot be used for encrypting a key, right? So I just thought >> that, if a user was trying to use a nonce for encrypting a >> key, it would be helpful to warn the user of the illegal use >> of nonce. Our implementation just ignores such a nonce, >> though. >> Reagle: I expect I'm not understanding the issue well, while >> I appreciate the algorithm itself might provide for a nonce, >> how would this redundancy hurt anything? >> Dillaway: agrees with Takeshi, EncryptedKey shouldn't have >a >> nonce because it can complicate the algorithms. For example, >> some algorithms expect particular key sizes that this would >> confuse. >> ACTION Reagle: remove Nonce attribute from Encrypted Key. >> >> (Section 5) >> * Ronald Rivest >> 1. Does this support "new combined "encryption+integrity" modes >> of operation >> Yes, one can specify the approriate algorithm and >> identifier." >> 2. "You have provisions for referring to some elements >> indirectly (e.g. through a URI), but you may need some way >to >> ensure that what you retrieve is what was intended (e.g. >> through a hash of the element to be retrieved). Perhaps this >> is implicitly handled already..." >> Dillaway: this might be accomplished via a Transform that >> contains a digest within a CipherReference. >> ACTION Simon: send email to a list exploring this scenario. >> 3. "There are of modes of encryption that won't fit your model, >> but which are very useful. For example, "secret-sharing" >> allows encryption of a document into several pieces, or >> shares, in such a way that a requisite number of them are >> required to decrypt/reconstruct the document. Just be sure >> you don't preclude somehow expansion to handle this sort of >> thing later on." >> Dillaway: way back when, we decided not to address threshold >> schemes. When Barb Fox asked the question, there was a >> resounding "no." However, I don't have a prolbem with someone >> layering it on top of what we specified. >> Reagle: do we then have some obligation to show how it can >be >> done? Is anyone interested in this enough to take that on? >> Dillaway: Might have time in three weeks time. >> Simon: Perhaps we could ask Rivest to point out if it can't >> be done. >> 4. "I'm very uncomfortable with allowing the encryption >> algorithm to be "understood" between the sender and the >> recipient; you should force the sender to be explicit. >> Non-explicitness is the cause of very many protocol >> failures." >> Reagle: we made SignatureMethod optional in xmldsig... >> Dillaway: Agrees it can be dangerous, but its difficult to >> keep people from doing it in their protocol if they always >> use a particular algorithm, just seems redundant to them >> then. >> Reagle: Do people on this call support any scenarios >> presently where this information isn't sent? >> Dillaway: Not yet, but I can think of a couple of protocol >> scenarios where this is unnecessary overhead. >> ACTION Reagle: add warning text if there's a place where it >> seem approriate, assume they both know and they are wrong. >> Reagle: is there a security problem when it relates to >> signing, where someone signs the ciphertext, but subsitutes >a >> different message with different algorith?... Suppose not, >as >> we already say if people want to secure plain text, that's >> what they need to sign. >> Simon: someone encrypted a flower, but gets white noise, the >> plaintext should've been signed. >> * Blake Dournaee >> 1. Is Canonical XML really a recommended serialization >> algorithm; when exactly must one use it? >> ACTION Eastlake: tweak the c14n in section 5, include >> exclusive canonicalization as an algorithm. >> * Yongge Wang >> 1. "Is it possible to change the order of the input to KM so >> that it will look like:" >> ACTION Eastlake: Edit section 5.5 . >> * Jiandong Guo >> 1. Nonce and Key Wrap Algorithm: "It seems to me that with the >> key wrap algorithm specified in section 5.6.2, there is no >> way a nonce can be used, although you may still set up one >in >> the corresponding CipherData element by the document." >> Defer until Eastlake can respond. >> * Christian Geuer-Pollmann >> 1. I want it fixed that 168 bit keys are transported in 192 bit >> form, that's all. >> Defer to Eastlake. >> * Blake Dournaee >> 1. <AgreementMethod> question. "it doesn't look like XML >> Encryption actually specifies the logistics to perform the >> key agreement without also specifying actual encrypted data, >> which is impossible because the shared key hasn't been >> generated " >> Defer to Eastlake. >> >> Resolved >> >> * Blake Dournaee: >> 1. Is the Nonce attribute of type intenger? >> Reagle: Yes. >> * Christian Geuer-Pollmann: >> 1. Encrypting IV in ECB >> Eatlake/Dillaway: Use a nonce. >> >>Misc. >> >> * Reagle: just to repeat, if you know folks from related communities >> that should review our specification, please do a little arm >> twisting. >> * Simon: The MS Web Services Security Language (WS-Security) Draft >> combines xmldsig, xenc, and web protocols/services and is perhaps >> a good source of issues for how these things will work together. >> >> >> >> > >----------------------------------------------------------------------------------------------- >Ed Simon >XMLsec Inc. > >Interested in XML Security Training and Consulting services? Visit "www.xmlsec.com". > > > ----------------------------------------------------------------------------------------------- Ed Simon XMLsec Inc. Interested in XML Security Training and Consulting services? Visit "www.xmlsec.com".
Received on Friday, 30 November 2001 15:59:14 UTC