- From: Blair Dillaway <blaird@microsoft.com>
- Date: Wed, 20 Jun 2001 14:10:14 -0700
- To: <edsimon@xmlsec.com>, <xml-encryption@w3.org>
Ed, Takeshi: Ed's example is just one possible case where default replacement of a EncryptedData by the decryped cipher data is not the desired behavior. This is why I raised the issue of what the mandatory behavior should be given the possible combinations of Type attributes and CipherData encodings. I agree with you that we can clarify this with some additional wording. I tend to agree with Takeshi that we should decouple a required processing behavior from the Type attribute. Also, I agree we don't need to introduce another attribute to make this happen. I believe the wording should indicate the default processing behavior when Type is element or element content is as described in the current draft. But, compliant implementations must allow the application to override this behavior and handle processing themself. I believe this will provide adequate guidance to tool developers. I suggest the following wording changes: Section 4.1, Step 4.1 - Add to the end Applications must be allowed to override this default behavior such that the processing described in step 4.2 is applied. Sectin 4.2, Step 4 - replace last sentence with Applications must be allowed to override this default behavior and handle processing of the decrypted octet sequence. For decrypted data not of type element or element content, the decrypted octet sequence is always the final result and is returned to the using application. -----Original Message----- From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com] Sent: Monday, June 18, 2001 6:37 AM To: xml-encryption@w3.org Subject: RE: Processing <CipherData> (was "RE: CipherReference + Transforms meaning") Actually, I think all that is needed is some minor changes to steps 4 of section 4.1 and 4.2 to supplement what Blair has proposed. I'll suggest wording in the next day or two (today's a beach day!). In fact, with respect to an application's options about encrypting XML elements and content, XSS4J (for example), already has the flexibility needed to implement the scenario I discussed. My problem with the current spec wording is that it is, subltly, a touch too restrictive. Ed -- Original Message -- > > >Ed, > >>One solution is to have a Type media type for XML elements that >>doesn't imply "decrypt AND replace". Another option, is to say the >>Type attribute simply says what the encrypted content was and not have >>a processing >semantic >>behind it; another attribute or parent element would indicate what to do. > >I prefer the second one, but I think that another attribute or >something is not needed in order to indicate what to do. This is >because each application must know what to do according to the Type >attribute (e.g., a >decryptor compliant to the XML Encryption spec must know that an >EncryptedData element with a Type attribute "Element" (which may be >contained directly or be specified by a user) is decrypted and >replaced). > >Thanks, >Takeshi IMAMURA >Tokyo Research Laboratory >IBM Research >imamu@jp.ibm.com > > > >From: edsimon@xmlsec.com@w3.org on 2001/06/16 09:47 AM > >Please respond to edsimon@xmlsec.com > >Sent by: xml-encryption-request@w3.org > > >To: xml-encryption@w3.org >cc: >Subject: RE: Processing <CipherData> (was "RE: CipherReference + > Transforms meaning") > > > >Blair, >I like the gist of your text but I have a scenario I'd like to present. > >Say, I have a application that synchronizes the content of replicated >XML files existing behind firewalls. Because only a few of the >elements in a file change between updates, I don't want to encrypt and >redistribute the entire file. So my application looks for changes to >certain XML elements, and, for each changed element, grabs it, encrypts >it, packages it into an ><EncryptedData> element. Once it has reviewed all the elements, it >stores the corresponding <EncryptedData> elements a >StuffToBeSynchronized.xml file >and distributes it. > >Though StuffToBeSynchronized.xml has <EncryptedData> elements >containing XML elements, my goal isn't to expand inine its ><EncryptedData> elements into plaintext XML elements. But I still >would like to use the Type attribute to indicate the contained >encrypted data is an XML element. > >One solution is to have a Type media type for XML elements that doesn't >imply "decrypt AND replace". Another option, is to say the Type >attribute simply says what the encrypted content was and not have a >processing semantic behind it; another attribute or parent element >would indicate what to do. > >Is this a realistic scenario? If so, what would the Type attribute be >set to? > >Regards, Ed > >-- Original Message -- > >>Thank you Ed. Your suggested additions to Section 4.2 look good. >> >>Didn't think I'd get to this today, but here is additional text I >>would like inserted in the other relevant sections. >> >>Section 3.3. Replace the last sentence with: >> >>Type is an optional attribute identifying type information about the >>decrypted content. This type information plays a key role in the >>behavior of compliant decryptors as decribed in Section 4.2. If the >>EncryptedData element contains data of type element or element >>content, and replaces that data in an XML Document context, it is >>strongly recommended the type attribute be provided. Without this >>information, the decryptor will be unable to automatically restore the >>XML Document to its original clear-text form. >> >> >>Section 4.1. Under step 4.1, add the sentence: >> >>It is strongly recommended compliant encryptors insert the optional >>Type attribute into EncryptedData with a value of 'Element' or >>'ElementContent' respectively to allow automated document restoration >>processing as described in Section 4.2. >> >> >>-----Original Message----- >>From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com] >>Sent: Friday, June 15, 2001 2:42 PM >>To: Blair Dillaway; Takeshi Imamura >>Cc: xml-encryption@w3.org >>Subject: Processing <CipherData> (was "RE: CipherReference + >>Transforms >>meaning") >> >> >>Blair wrote >> >>>Perhaps I am being unnecessarily concerned about this. I don't have a > >>>problem with the language you cite, what I have a problem with is the > >>>lack of discussion about the linkage between the OPTIONAL type >>>attribute on EncryptedData and the assumed processing. I am >>>concerned > >>>about confusion as to what is supposed to happen with various >>>combinations of specifying/not specifying the type and using >>>CipherValue vs CipherReference. >> >>I strongly agree with Blair. >> >>To review, there has been some discussion suggesting that if an >><CipherReference> is being used, there should be an assumption the >>data is not an element or element content, and if <CipherValue> is >>being used, then it is an element or element content. >> >>I would prefer NOT to second guess how applications want to do things. > >>There may indeed be apps that prefer to keep encrypted inline XML >>remote (perhaps for authorization/performance reasons), and there may >>be some that would rather not have to keep encrypted arbitrary data >>remote from <EncryptedData> elements. >> >>Here's the way I look at it... >> >>The result of processing a <CipherData> element is simply an octet >>stream to be sent to the decryption engine, no semantics are implied. >>If <CipherData> contains a <CipherValue> element, obtain the octet >>stream by de-base64ing its content. If <CipherData> contains a >><CipherReference> element, dereference the value of the URI attribute >>and applies the specified transforms (if >>any) to obtain the octet stream. >> >>Once the octet stream has been decrypted, process it based on the Type >>attribute of the <EncryptedData> element. If the Type attribute >>indicates an element or element content, replace <EncryptedData> with >>the decrypted element or element content; otherwise, hand the >>application a reference to the octet stream. >> >>[I submit the preceding two paragraphs for inclusion into the spec.] >> >>Ed >> >> >> >> >> >> >> > > > > > > > >
Received on Wednesday, 20 June 2001 17:20:04 UTC