Blair, Sorry, you can't disagree with me this time because (as my original note says) I'm not pushing any particular position at this time, just curious about the different possibilities. I certainly agree we don't want to specify an API; I just used XSS4J's APIs as an example of how one Toolkit was designed. ( Don't worry, I'm sure there will be opportunities to disagree in the future.;-} ) Regards, Ed -- Original Message -- >Ed, > >I'm going to disagree with you. I believe XML Enc. Implementations >should implement the encryption and decryption processing for element >and element content as previously described in the spec. This is likely >to be the most common behavior and I'd like to see us encourage behavior >that avoids requiring applications to routinely implement their own >version of this processing. > >If you don't like the 'default' characterization, we could just describe >these as two required processing methods on an equal footing. > >I don't believe we should specify how this is implemented from an API >standpoint. It could be separate methods or some parameterization on a >single method. > >-----Original Message----- >From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com] >Sent: Wednesday, June 20, 2001 5:08 PM >To: xml-encryption@w3.org >Subject: RE: Processing <CipherData> (was "RE: CipherReference + >Transforms meaning") > > >Do we have to declare a default behaviour? Or should we just say an XML >Encryption Toolkit can include methods to >a) decrypt and return the decrypted object >b) decrypt and replace the <EncryptedData> node with the decrypted >object if the decrypted object is either an Element or NodeList > >An application using the Toolkit will be the one to decide what happens >to the decrypted data. XML Encryption can, and should, explaing how to >encrypt/decrypt XML elements and element content; but, it does not have >to require that the decrypted version of an <EncryptedData> element >(Type = Element or NodeList) in an XML instance necessarily, ultimately >belongs to that XML instance. That application will know what it wants >to do with the decrypted node; we don't have to specify a default >behaviour. Right? > >XSS4J, for example, has two methods: decrypt(<EncryptedData>) and >decryptAndReplace(<EncryptedData>). > decrypt() decrypts the <EncryptedData> element and returns an object of >type Element, NodeList, or InputStream without replacing the ><EncryptedData> node; decryptAndReplace() decrypts the <EncryptedData> >element and then replaces the <EncryptedData> node with the resulting >Element or NodeList. > >Not having looked at the internals at XSS4J, I don't know what context >baggage the result of a decrypt(<EncryptedData>) has. Maybe there are >some context gotchas like the namespace issues being discussed in XML >Signature now that are trickier than we think. > >I'm not taking a hard and fast position, just curious about the >different possibilities. Takeshi, any comments about the functionality >issues of >decrypt(<EncryptedData>) that I've overlooked. > >Ed > >-- Original Message -- > >>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 Thursday, 21 June 2001 20:50:54 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:19 GMT