- From: <edsimon@xmlsec.com>
- Date: Mon, 18 Jun 2001 09:37:24 -0400
- To: xml-encryption@w3.org
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 Monday, 18 June 2001 09:38:26 UTC